Write Up: PRIMER 1.0.1 (chp. 4 + 5)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 4: [:()[:|:&};:]

In chapter 4 I was met by a continuation of the story, and a link to Chapter 5 (the start of Part 2). EOF.

PART 2/CHAPTER 5: [0xC00007B]

Following the link landed me on a page with a javascript window prompt. No continuation of the story here!

 

So I opened up the browser debugger to inspect the javascript. In doing so I actually saw the hidden HTML on the page which revealed the URL for chapter 6. I ignored it and decided to complete this little JS challenge anyway.

As can be seen from the JS, 

var X is a  user inserted string, var L is some arbitrary string. 

The if conditions are true if the string is null or if a substring (X.substr) of var X is equal to 

var L. 

Considering the 1st if condition (from testing) is not the desired result, it is the 2nd if condition that needs satisfying.

The parameters of X.substr show that the substring is made using the chars from the second char through to, and ending on seven chars along from the second char of the user inputed string var X.

This means that the var X must contain var L "Ikdf076" prepended with two other arbitrary chars. Such as "00Ikdf076". 

The string was submitted and the second if condition was satisfied. The window prompt was then removed and revealed the underlying HTML.

Another URL to chapter 6.. Until the next post.

Write Up: PRIMER 1.0.1 (chp. 3)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 3: ["[^"\r\n]*"]

This chapter has probably taught me the biggest lesson so far.. don't get carried away. I have spent hours on this chapter, when in fact, its probably the easiest and most simple chapter yet. Instead of hiding my mistake, there might be some comedy valuable learning opportunities in sharing it.

So from the beginning.. I was greeted again by the now expected block of text and little else. This section of the story seemed to offer some hints to the solution. I fell for it hook line and sinker!

As I read the text, the following line stuck out to me ".. slowly d[i]sintegrating with lightspeed, a thousand years each nano second". This sentence appeared to be the only real candidate for a hint in the text, so I went with it...

I looked at the headers. I noticed that (unlike previous chapters) there were "If-Modified-Since" and "Etag" fields in these headers. Aha! this most be what that sentence was hinting at.. time.. "thousand years" etc.

So I jumped into curl to spoof the "If-Modified-Since" field to generate a response from the server. Sure enough, changing the date of the field to "Sun, 25 oct 2015 12:59:55 GMT" produced a 304 Not modified response, However nothing else, no extra field in the header or anything to indicate I had solved the chapter. I must have been missing something.

So I decided to read up more on properties of the "If-Modified-Since" and "Etag" fields. I began by reading rfc2616 section 14 "Header Field Definitions" for any further information. Although very illuminating, I wasn't any closer to solving the chapter. I did some more searching, read some more papers, I spent the best part of 2 hours trying to prise a hint of a way of exploiting this specific feature of HTTP headers, I came out empty handed.

So out of frustration, I thought I would see what happened if I spoofed a header where the "If-Modified-Since" field was in date; that is to say, a fresh copy of the page would be sent as it had been modified since the date I had fabricated in the request header. Sure enough, I got the HTML back, wait.. what does that say?!..

"<meta http-equiv="hint" content="Think, but don't act like a robot."/>"

Why had I not noticed this earlier?! It cant be! seriously? not robots.txt.. it cant be that straight forward?!

Yes it was that straight forward...

The moral of the story, Don't get carried away. I should have simply read the HTML first, like I had in the previous chapters. But what a valuable lesson to learn! Also, I now know quite allot about ETags and If-Modified-Since header fields!

On to chapter 4, a little bit wiser...

Write Up: PRIMER 1.0.1 (chp. 2)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 2: [(α=β)<=>(α<=>β)]

I am progressing through this VM somewhat faster than I originally anticipated, also the chapters are shorter than I imagined, none the less I will continue as intended and post one chapter at a time.

Lets continue.

This chapter, much like the first, features a block of text which continues the vague story littered with small clues.

The most telling of these clues are as follows..

"..needed to penetrate the next circle, blocked of[f] to unauthorized access".

"But she felt a presence of something left behind. Like breadcrums, not intentional, but something forgotten by an incomplete piece of code to handle access".

At this point, my mind first went to cookies... breadcrumbs!

However, more haste, less speed. I first checked the HTML to see if there were any further clues, unfortunately, none to be found there. I then thought to have a quick look at the css and there we have another comment!

This comment confirmed my suspicions. "Clean sessions terminate without leaving things behind..", "Sometimes, an exploit is as simple as changing a simple value in a local file". Yep, definitely cookies!

I then looked at the GET request headers to see what parameters are being passed. There we have it! 

"activeSession=false"

I wonder if it is as simple as changing the active session value to true? Is that all the server is checking for an active session? The clues seem to suggest it.. so I fired up a plugin to edit the cookie and gave it a try.

I found the relevant cookie, altered the value from false to true, saved the now manipulated cookie and reloaded the page.

Sure enough! 302 found, redirect! On to Chapter 3..

Write Up: PRIMER 1.0.1 (chp. 1)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here.

What follows is a write up of the first of 7 chapters in this VM. I intend to write about each chapter as I complete them. 

So far this VM is thoroughly enjoyable with a wonderful and unique style of story telling. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 1: [__init__]

Once the VM was installed, up and running, I did a quick nmap -sn 192.168.1.*. The -sn flag to skip port scanning, simply to identify which IP the VM had grabbed. This revealed 192.168.127.

Another quick nmap -sV showed ports 22 and 80 running OpenSSH and Apache respectively.

Now I knew a web server was running, I opened up a browser and typed in the IP. A web page dutifully rendered.

 A block of text and a login form. From reading the text, it appears to be a stylistically unusual story. The way it is written is quite vague and loosely tied together. None the less, its enjoyable to read and appears to contain some hints.
The last paragraph appeared to be most relevant..

"There was one spot that attracted her naturally, a point w[h]ere the traces accumulated and forward a connection, a terminal accepting input from the us3rland, a f0rm. This one was of a family very well known to her, easily exploited to grand you access to another level, and that was she needed for now. Reaching in she began to twist the stream, adjust the flow and after a few practiced moves, she felt it, access, the meta, finally moving on."

This is clearly hinting at the login form, requiring some SQL injection. The story itself indicates that this may not be too difficult -".. a few practiced moves..".

To check for any further hints, I inspected the HTML which revealed some hidden text.

This revealed; "Some f0rms are easier than others. This one was just a means to get to the next level so there was no need for her to apply her full set of skills or fake credentials. Manufacturing a boole4n response would probably be en[o]ugh to let her pass."

This reaffirmed my suspicions that this required a simple SQL injection. Clearly just a boolean response was required for this function.

I began with some well established code which would evaluate to TRUE. I only used the Username field, leaving password empty. It was clear from the first attempt that all errors from the SQL server were being caught, there were no prompts or notifications for failed attempts. This meant there was nothing else to go on other than what was provided in the story, effectively educated guesses. I continued and tried a multitude of variations, such as ' OR '1'='1' , ' OR 1=1 -- , 1" OR 1=1 -- etc. Eventually, after a significant amount of attempts ' OR '1'='1' -- was successful. The first ' closes out the single apostrophe encapsulating the variable, OR provides the ability to negate the first statement requirement to evaluate to TRUE. '1'='1' clearly computes to TRUE and the -- (with an important space after it!) then comments out the rest of the query, therefore making the password field redundant.

Once login was pressed, I arrived at the next page. This again included a block of text.

This portion of the story continued the vagueness from the first page. However there were a few notable parts; "..specific string all users transmit.." , "Drifting around the 7th circle of security layers.." , "..this little script just checked for an identifier, a hash, no credentials or secrets..". These hinted at the User Agent Identifier. I then checked the HTML source code for any further hints.

I found a comment! This one reads:

"This bot was looking for a Sosu User Agent Identifier she had cracked weeks ago, easy sauce, just a simple md5 hash of the first 7 digits of pi. It was basically common knowledge to the entities moving in these areas but obscurity does create a, albeit virtual, layer of security".

This clearly indicates that I need to spoof the User Agent Identifier to solve this page. First of all, I need to make the MD5 Hash of 3.141592. md5sum in the terminal produced the required hash:

d483d00d07fcc80319d170ccf07fb5be.

Next I installed a User Agent Switcher ad-on in firefox. I then created a new User Agent profile and input the hash in the user agent field.

I then switched to the new User Agent Profile and reloaded the page - Redirect. It worked! on to the next chapter! ..Coming soon.

Black Hat Europe 2015

For the past couple of years the Black Hat conference has offered scholarships to students entering the security industry. I was ecstatic to find out that I had been selected this year.

On the 11th November I boarded a flight from London Stansted to Amsterdam Schipol, After I took my seat I began to remember how much I had read about the Black Hat and Defcon conferences in Las Vegas. I felt excited to finally experience a conference of that calibre (albeit the European leg) and to finally experience the first (of what I fully intend to be many) Black Hat attendances.

I landed early in the morning on the day before the conference began, this enabled me to beat the crowds to collect my pass and the associated attendee paraphernalia and to get familiar with the conference grounds.

I got back my hotel room which was conveniently located opposite the conference centre, I pulled the conference agenda out of my very stylish attendee back pack and began to circle talks or 'briefings' that I wanted to attend. This was far more of a monumental task that I was anticipating.
I found myself quickly double booking myself, but none the less, I arrived at my first day itinerary.

The next morning arrived and I was ready for my minute and a half commute to the conference centre. With my Black Hat badge around my neck I made my way to a very well organised breakfast, in a dining area which would be more accurately described as a hangar than a hall - it was huge. The seats filled up and I got my first look at just how many people were attending the conference. Needless to say, it was enough to fill a dining hangar.

I eagerly ate breakfast and gave myself some buffer time to find the main conference hall for the Keynote. My navigation skills didn't fail me, I was among the first to take a seat (close to the front of course).

The Dark Tangent (Jeff Moss) took to the stage, he began by announcing some Black Hat statistics and mentioned the Scholarship Scheme, my student colleagues and I were asked to raise our hands and make ourselves known to other attendees, I dutifully obliged.
Jeff introduced the Keynote speaker - Haroon Meer and one of the best talks of the conference began. Haroon set the tone for the conference, which by my measure, was one of self reflection. I had often read and heard of the "hacking community", this was the first time I had experienced it. Haroon addressed the audience as colleagues, opening a discussion of the failings of the security industry and how we all need to do better. It may sound negative, but it definitely was not.

From here the briefings began! I could write for hours about each one - they were fascinating. But I feel a list coming on.

Day 1

• Even he Last Pass Will be Stolen, Deal With it! - Martin Vigo and Albert Garcia
• Stegosploit - Exploit Delivery with Steganography and Polyglots - Saumil Shah
• OSxCollector - Kuba Sendor
• Commix: Detecting and Exploiting Command Injection Flaws - Anastasios Stasinopoulos

Day 2

• Hiding in Plain Sight: Advances in Malware Covert Communication Channels - Pierre-Marc Bureau and Christian Dietrich
• Maintaining Ethics in Today's Cyber World - SecureAuth
• VoIP Wars: Destroying Jar Jar Lync - Faith Ozaci
• Self-Driving and Connected Cars: Fooling Sensors and Tracking Drivers - Jonathan Petit
• Bypassing Local Windows Authentication to Defeat Full Disk Encryption - Ian Haken

The briefings were exceptional, what really stuck with me was the sense of community, there were plenty of questions and the speakers took allot of time to answer and speak with the audience, I felt a real sense of being among peers.

Outside of the briefings this atmosphere continued, Other attendees were more than happy to impart knowledge and shared in my enthusiasm.

The conference concluded with a Locknote in which Jeff informed us all that Black Hat Europe is to move from Amsterdam to London next year. It was said that the purpose of this move is to foster a similar social experience as the conference in Las Vegas. As if I wasn't already desperate to attend in 2016! 

The Black Hat Student Scholarship Scheme provided me with a wonderful experience and a valuable introduction to the community and industry, I am extremely grateful.

Draft Investigatory Powers Bill

On the 4th November 2015, The Home Secretary Theresa May introduced the first draft of the Investigatory Powers Bill to Parliament.

The Investigatory Powers Bill is essentially an updated and (some might say) improved version of Regulation of Investigatory Powers Act 2000 (RIPA). The draft Bill features a consolidation of existing Acts that were used by the intelligence community and police to gather information by multiple communication means, most notably internet communications.

The draft Bill introduces a new term; ICR. An ICR is an 'Internet Communication Record' - Theresa May went to great lengths to explain that an ICR is essentially the meta-data, or the Who, Where, When of internet communication, Not the content.
The Bill places a requirement on Internet Service Providers, and other unspecified 'Communication Services' to record everyone's (literally everyone's) ICRs on a rolling 12 month basis for possible future interrogation by Intelligence and Police services via a warrant.

I, Like many others, have read the draft Bill with great concern. Of course the internet and online communication as a whole needs to be policed, the intelligence community and the police should have the capability to detect and prevent crime in all public spaces. However I believe this should not be at the expense of the civil liberties and privacy of innocent people.

Fortunately this legislation has not yet passed and amendments will surely be made. This gives all of us the opportunity to contact our MPs and express our concerns (if you have them of course!).


The Open Rights Group is a organisation that stands up for digital civil liberties and the right of privacy in the UK. It is currently fighting for our rights online and helping to steer the government in the right direction when it comes to legislation impacting the internet.
The Open Rights Group provides a service on their website that will enable you to simply and easily email your MP to express your concerns with regards to this Bill. It can be found here.

For inspiration, My email to my MP is shown below. (I have removed some personal information which I do not wish to publish online).

".. I am writing to express my concerns about the Government's draft Investigatory Powers Bill. I would like you to use your position in the Conservative party to push for changes to the Bill.

The Bill in its current form represents a significant risk to the privacy of any and all users of the internet in Britain.
In particular, the proposed requirement of internet service providers and communications providers to record internet connection records (ICRs) for up to 12 months.
As a degree student of IT Security and Computer Forensics I can inform you that criminals who choose to utilise the internet as a means of achieving criminal goals could easily circumnavigate this form of detection by using freely available technology, such as a VPN. 

A VPN is a Virtual Private Network. A commercial VPN (designed for privacy) is typically a paid service used by an individual (criminals, businesses and law abiding persons alike) to forward all network traffic from their computer to a remote server (typically outside of the UK) which places encrypted requests for websites and other online services on their behalf and forwards them back. This has an effect of hiding and the users traffic and the true origin of the request. Technology such as a VPN would render the proposed form of surveillance useless.
VPNs are a vital technology, extensively used in the business sector and for individuals who require more advanced security when communicating online. I am by no means indicating that VPNs pose a risk in any way, simply they are an example of the technology available to defeat this form of surveillance.

With this said, my concern is that the proposed legislation (in particular the recording of ICRs) will do nothing more than to record the internet communication of innocent persons while professional criminals will use a cheap and trivial means to hide their online activities. 

I have further significant concerns with regards to privacy and how this will negatively impact Britain's direction in online communication going forward. These concerns are already well published and at the risk of this email becoming even longer, I will simply say that my views on privacy in this matter are firmly with those of the Open Rights Group (www.openrightsgroup.org).
I am more than happy to speak further with yourself or a representative if that would be of benefit in any way.
Thank you for taking the time to read my concerns."

TalkTalk data breach

TalkTalk is a large UK based telecommunications company. It has approximately 4 Million subscribers of Internet access, pay TV/IPTV and mobile phone services across the country.

TalkTalk (I will abbreviate to TT for the purposes of this post) has been subject to public scrutiny through the media after being subject to a number of hacking and fraud related incidents in recent years.

On Wednesday 21st October the TT home page and sales website(s) (sales.talktalk.co.uk and talktalk.co.uk) were reportedly DDoS'd resulting in the TT websites going down.

It would appear that this was either a diversionary tactic or possibly a method to leverage access to TT's SQL server(s). This is my own summation given the facts - details of this kind have not been confirmed, by nature of this being an on going investigation.

TT's own homepage reported on Thursday 22nd October that an investigation into the DDoS'ing and simultaneous database raid had been opened by the (London) Metropolitan Police Cyber Crime Unit (MPCCU). It would appear that the MPPCU is leading the investigation, possibly in-stead of the National Crime Agency National Cyber Crime Unit (NCCU).

Pastebin

As is often the case with data breaches, sample data is often posted to Pastebin by the attackers as evidence of the raid. A search conducted today on Pastebin (and since reported in the media) revealed a paste titled "TalkTalk Database list" submitted on Thursday 22nd October by a "guest" on the service.

The paste lists 64 "available" databases, which from this limited information I am presuming are for customer related services and back-end records and products and services. These details have not been confirmed as genuine - as this could only be confirmed by TT themselves.

On the same day, another paste was submitted titled "Message from TalkTalk Hackers", also submitted through a "guest" account (again not confirmed as genuine).

The paste appears to take responsibility for the attack. Written in broken English it begins with "Statement To: Th3 W3b Of H4r4m ~" - Haram being an Arabic term for any act that is forbidden by god. That sentence could therefore mean that the Internet itself (or parts of it) are forbidden by god. This could indicate that TT was (in part) targeted due to being an ISP?

The paste also goes on to state that the individuals taking responsibility for this attack are from "The Soviet Russia". It would appear that the justification of this attack is of political/religious ideologies.

Instinctively it is difficult to link the nature of this raid with a statement such as this. However the timing fits.

Sample Data Analysis

The statement continues with a three samples of the stolen data (which I have not included). the first sample claims to be from a "password change log". 28 rows of data are shown under the following column titles: message, log_timestamp, email_address.

The message column shows only "Update Submitted" which would be consistent with a password change log. The log_timestamp column however shows rows of 10 digits which immediately wouldn't (atleast to me) indicate a time stamp, however this may simply be due to implementation of the database.
[EDIT] I have since been informed that a 10 digit time stamp such as this would likely be in epoch time. As a result the time stamps in this sample are all from 1500hrs (+/- 2mins) July 2011. Credit and thanks to basically_asleep.


The last column lists email addresses (all @tiscali.co.uk), this could be evidence of TT data due to tiscali (previously an ISP) merging with TT in 2009.

The secound sample claims to be "Order Identifier Data" this includes the following columns idType, idValue, onlineOrderId, onlineOrderIdentifierID, createdOn, lastUpdated, SGOMappingType. The sample data includes email address from various email providers, a time stamp and what appear to be various ID numbers. Curiously all of the time stamps are from 6th July 2012 between midnight and 01:49 am.

The third sample is titled "Order Data: (Bank Info Removed For Pastebin)". The columns are SIMO_ORDER_ID, SIMO_HISTORY_ID, STATUS, REQUEST, RESPONSE, CREATED_ON.

This sample is more concerning, it appears to contain 2 entries consisting of multiple key value pairs. These entries appear to be for only two separate customers with sequential order IDs. This information contains the customers first and last name, date of birth, telephone number, email address, bank sort code, bank name and account number marked  "REMOVED", home address and post code.

Ransom

On Friday 23rd October it was reported by the media that the TT CEO had received an email containing a ransom from a group purporting to be the attackers. No further details of this ransom have been made public at this stage.

If indeed the ransom is genuine, a ransom would not seem consistent with the Pastebin statement. My rationale behind this is that the attackers would most likely make their demands at the point of publicly taking responsibility rather than to do it almost a day after the attack and privately to the CEO.

It also happens that the CEO of TT had been addressing the media through-out the day and was highly visible to the public. It could be that the ransom email was an attempt from an un-associated group to extort money from TT while the identity of the attacker remained unconfirmed.

Of course, in the absence of any concrete details, this is pure speculation over the nature of the ransom.

None the less, this is a significant data breach, potentially impacting millions of customers and severely damaging TT reputation. However with the ever growing rate of computer enabled extortion, and the alleged amount of cover-ups by companies who are victims of extortion, TT have taken the correct course of action by going public straight away. This at least gives their customers the opportunity to attempt to protect themselves against some of the threats they are likely to be exposed to due to this data breach.

I have deliberately not provided links to the Pastebin pages that I have discussed in this post. Great care has been taken to discuss the example data in general terms and to not reveal any personal details that may have been released by the individuals claiming responsibility for this hack.
The example data I have analysed is openly available to the public through pastebin.com.

The trouble with crypto: Qubits

Up until the mid 1990s computer security was thought of in terms of isolationism.
For a large portion of that time computers and hardware in general were prohibitively expensive. Computing remained the purview of large corporations, academia and governments.

Towards the beginning of the 1980s this began to change. Isolation remained through restricted networks by nature of their cost and lack of infrastructure.
Come the turn of the century and computer security through isolation (in this form) was gone.

In hindsight, its almost comical to consider that relying on isolationism: the fact that computers were expensive and networks were inaccessible, was a good strategy for security.

Fortunately, far more sophisticated security concepts have been implemented to keep our information safe. That being said, it is undeniable that computer security is almost entirely dependant on crypto.

Cryptography in turn is also dependant on a strategy not too distant from the days of isolationism. This is because it relies on the fact that data is encrypted with a sufficiently complex cipher that is incredibly resource intensive to crack. That is to say, to crack it in a period of time that is useful, requires a level of computing power that is not available.


Massive Numbers

AES-256 is a widely used crypto specification. AES-256 features a key of up to 256 bits, of course, this means there are 2^256 possible combinations of bits in a 256 bit key.
To put that into perspective; if you were to count all the atoms in the universe, you would be well on your way when you reached 2^256.

To crack this 256 bit key, we would need a massive amount of computing power. A high end GPU can do approximately 2 billion calculations a second. If we had 1 billion of these GPUs working in parallel they could churn through 2e+18 keys per second.

At this rate it would take those 1 billion GPUs 14 billion years (the age of the universe) multiplied by 6.7e+40 to reach approximately half of the total bit combinations.
It is fair to say, that is not a useful time period.
Credit to INCOMPLETE_USERNAM for the math.


Quantum Bits

Bits and qubits have everything in common and nothing in common, a relationship itself which is in a quantum state.
A bit is a unit of information capable of indicating values based on receiving current or not receiving current; 1 or 0 respectively. Of course the mechanics of this are more complex.
A qubit (one quantum bit) is also a unit of information capable of indicating values. However, the process of this being achieved is entirely different to a bit. It goes without saying that the mechanics of this process are incredibly complex.

Courtesy of D-Wave Systems Inc.

Qubits on their own however are not generally more powerful than bits. When they are paired or “coupled” to each other then the true value of qubits is realised.

It would appear that it is possible to establish equivalencies between bits and coupled qubits.
Associate Professor Andrea Morello of the University of New South Wales (UNSW) Faculty of Engineering explains here, that the equivalent number of “classical bits” to qubits can be calculated with the following:

2^n where n = the number of qubits.

For example, using this equation 300 qubits are equivalent to 2.037036e+90 classical bits.

For perspective the highest transistor count in a commercially available CPU today is approximately 5.5e+9 (5.5 billion) transistors (18-core Xeon Haswell-EP made by Intel).
2.037036e+90 transistors would be needed to represent 300 qubits of information.

This month (6th October) engineers at the University of New South Wales in Sydney reported that they had demonstrated a 2 qubit logic gate in silicon for the first time. This has made calculations between two qubits possible. Crucially using a well established material already used in the computer industry – silicon.

In September, Google and NASA announced that they were upgrading their D-Wave quantum computer from 512 qubits to more than 1000 qubits, however it would appear that the true power of the qubits in the D-Wave have not been realised. In fact, its title of quantum computer has been questioned by some as it currently does not offer an advantage over a classical computer.
It would appear that quantum computing which offers the bit equivalency shown above, is not here yet.


Quantum Computing vs Crypto

Public information about quantum computers indicates they are still a number of years away before the technology could be used to crack (previously) highly secured cryptography.

None the less, ETSI (European Telecommunications Standards Institute) has formed The ETSI Quantum-Safe Cryptography Industry Specification Group. The group has identified quantum computing as posing a significant threat to crypto now and in the future.

The group state on their website “Without quantum-safe cryptography and security, all information that is transmitted on public channels now – or in the future – is vulnerable to eavesdropping. Even encrypted data that is safe against current adversaries can be stored for later decryption once a practical quantum computer becomes available.”

It is clear that quantum computers offer a giant leap forward in computing and as a result will provide a tremendous amount of computing power, an amount of computing power which might render some of our existing crypto useless, and at least significantly reduce the amount of time it would take to crack some of the strongest crypto standards that are used today. That said, AES-256 is considered a “quantum-safe” or “post-quantum” standard, provided it is used with sufficiently large key sizes (256 bit).

At this point in time, quantum computers are the purview of large corporations, academia and governments. Considering their huge computational power, quantum computers
are perfectly suited to tackling massive calculations at exponentially faster speeds; which makes them exceptionally good at (among other things) brute forcing crypto, and as a result, probably of great interest to government agencies.