Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recentally, an attack on AES was discovered which reduces its computationally complexity, by a very slight amount.

  • The first key recovery attack on the full AES-128 with computational complexity $2^{126.1}$.
  • The first key recovery attack on the full AES-192 with computational complexity $2^{189.7}$.
  • The first key recovery attack on the full AES-256 with computational complexity $2^{254.4}$.

There is also the new AES-NI instruction set, which allows attackers to make hundreds of billions of parallel guesses per day.

In light of these emerging threats, have you made changes to your designs to mitigate the impact? If so, what has changed?

share|improve this question
up vote 6 down vote accepted

We in the Tahoe-LAFS project had already been planning to switch from AES-256 to XSalsa20⊕AES-128, for One hundred year cryptography.

This news makes me think "Oh yeah, we should really get around to doing that soon." It also makes me think "Hm, maybe the extra CPU cycles for AES-256 vs. AES-128 is worth it for added longevity and for advance notice of plausible future attacks."

share|improve this answer
Which kind of security requirements do you have that you use the AES-256? See also my comment to Rook's answer. – j.p. Aug 18 '11 at 9:23
As Rook removed his (down-voted) answer and replaced it by a new one, I repeat my comment on his idea to use AES-192: It's an overkill. The only attacks one should be worry about are side channel attacks like cache attacks or, if applicable, SPA and DPA. – j.p. Aug 18 '11 at 17:56
I think the "100 year crypto" concept is cool enough that it should be exempt from the usual advice about appropriately-sized functions. Isn't that sort of the point? Hmm, I think I'm going to open a question about this... – Marsh Ray Aug 18 '11 at 18:22
@Marsh: I wouldn't worry about crypto in 100 years. In 35 years nobody will be able to read your disks and file formats ;-). – j.p. Aug 19 '11 at 6:18
I like the link and the idea of a 100 year crypto system. I think this is a pragmatic approach. – Rook Aug 21 '11 at 18:32

No, an attack on AES-128 requiring $2^{126.1}$ computations and $2^{88}$ bytes of known plaintext is not a concern. Brute-force guessing of keys (e.g., using the AES-NI instructions you mentioned) will succeed in $2^{127}$ computations on average and requires negligible known plaintext. Part of why key lengths are selected conservatively is precisely to ensure a safety margin which renders these tiny differences insignificant.

What the paper presents is an interesting method of analyzing block ciphers using a technique developed for analyzing hash functions. That this novel cryptanalysis technique fails to improve on brute force by even a full bit confirms the fundamental soundness and resiliency of AES's design.

Still, this technique is new and the paper explores multiple approaches to applying it. Cryptographers will be watching with interest to see if anyone goes farther with it, either through refinement or in combination with other cryptanalytic techniques.

Edit: In other discussion it was pointed out that this attack succeeds with probability 1, so an apples-to-apples comparison would be with worst-case brute force at $2^{128}$. It would be an exceedingly unlucky attacker who actually paid worst-case cost! A comparison of the typical scenario seems more relevant. The average-case for this AES-attack is probably a bit better than $2^{126.1}$, but it's not obvious from the paper. Still, the difference seems likely to be under a couple of bits (for now), while brute force retains its overriding advantage of not requiring $2^{88}$ data.

Of course one can build a weak protocol (or use a non-weak protocol in a weak way) on top of AES-128. WPA2-PSK can usually broken quite easily, because the pre-shared key is derived from a user-given password, which can be brute-forced in a short time. Even changing to an algorithm with a 10000-bit key would not help, if this key is derived from a weak password.

share|improve this answer

No, these new attacks are not a practical concern, and not a reason to change what you're doing.

@Marsh Ray already did a good job of explaining the main reason why: 128-bit keys are already long enough that there is a tremendous safety margin here. The biclique attacks speed up exhaustive search by less than a factor of 2. We already have a safety margin of many orders of magnitude, so a 2x speedup just doesn't matter. Similarly for the AES-NI instructions; there's so much safety margin against exhaustive keysearch that a 10x or 100x speedup just doesn't matter.

In addition, there's a second reason why the new biclique attacks are not a threat in practice: they require an absolutely, totally impractical amount of chosen plaintext/ciphertext pairs. For instance, their 2126.2 attack on AES-128 requires the attacker to ask for the encryption of 288 chosen-plaintexts, all encrypted under the same AES key. No current system is ever going to give an attacker the chance to acquire anywhere near that many chosen plaintexts within our lifetime. Not gonna happen.

So these attacks are completely outside the realm of practicality. They are nothing to worry about. In practice, the way that modern systems get broken is by bypassing the crypto, not by breaking the crypto. There's no way that biclique cryptanalysis of AES is gonna be the cheapest way to break into any real-world system: no way, no how.

So, don't worry about it. While the new results on biclique cryptanalysis are a highly impressive feat of mathematics, they are not a reason to shy away from AES or to change your practices. Personally, I'd say that AES is holding up remarkably well: after a decade of intense cryptanalysis, it still looks like a solid, well-thought-out design.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.