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?


3 Answers 3


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."

  • $\begingroup$ Which kind of security requirements do you have that you use the AES-256? See also my comment to Rook's answer. $\endgroup$
    – j.p.
    Commented Aug 18, 2011 at 9:23
  • 1
    $\begingroup$ 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. $\endgroup$
    – j.p.
    Commented Aug 18, 2011 at 17:56
  • $\begingroup$ 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... $\endgroup$
    – Marsh Ray
    Commented Aug 18, 2011 at 18:22
  • 1
    $\begingroup$ @Marsh: I wouldn't worry about crypto in 100 years. In 35 years nobody will be able to read your disks and file formats ;-). $\endgroup$
    – j.p.
    Commented Aug 19, 2011 at 6:18
  • $\begingroup$ I like the link and the idea of a 100 year crypto system. I think this is a pragmatic approach. $\endgroup$
    – Rook
    Commented Aug 21, 2011 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.


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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