16

Has AES-128 been broken over the full 10 rounds? If so, by what means? By a commercial entity? By a supercomputer?

If not, why is AES-256 used to replace AES-128 so frequently?

kelalaka
  • 48,443
  • 11
  • 116
  • 196
Offir
  • 283
  • 1
  • 3
  • 5

3 Answers3

42

AES is a block cipher and is supposed to be a pseudorandom permutation. It can achieve IND-CPA or IND-CCA or authenticated encryption by using the appropriate mode of operation together with AES. Let see what can be achieved or not.

Has AES been fully (10-rounds) broken? by what means? (commercial? supercomputer?)

  • Direct brute-forcing

  • The total BitCoin miners reached $\approx 2^{92}$ double SHA-256 calculations in a year. So you need on average

    • $2^{35}$ multiple power of this monstrous computing power to break AES-128
    • or wait for $2^{35}$ years.
  • The Summit in Oak Ridge can reach $2^{71}$ SHA-1 in a year so no threat there.


In short, there is no threat from here.

  • Best Known Cryptographic Attacks

    The key of AES-128 can be recovered with a computational complexity of $2^{126.1}$ shown in Biclique Cryptanalysis of the Full AES by Bogdanov et. al, using the biclique attack, achieved in 2016. Note this is not the related-key-recovery attack from the same authors and that such attacks are not practical since we are generating the keys randomly. The attack requires $2^{88}$ data complexity and $2^8$ memory complexity.

In short, theoretically, one can say it is broken since the attack requires less than the brute force. However, the attack time and data complexity are not practical, either. From the paper; As our attacks are of high computational complexity, they do not threaten the practical use of AES in any way.

The other theoretical attacks on AES-128 are based on the Biclique Cryptanalysis;

  1. Biclique Cryptanalysis of the Full AES, Bogdanov et al.
  2. Better than Brute-Force - Optimized Hardware Architecture for Efficient Biclique Attacks on AES-128, Bogdanov et al.
  3. Sieve-in-the-Middle: Improved MITM Attacks, Canteaut et al.
  4. A Framework for Automated Independent-Biclique Cryptanalysis, Abed et al.
  5. Bicliques with Minimal Data and Time Complexity for AES, Bogdanov et al.
  6. Improving the Biclique Cryptanalysis of AES Tao et al.

\begin{array}{|c|c|c|c|c|r|}\hline \text{data} & \text{w/o SIM} & \text{Mem. Bytes} & \text{with SIM} & \text{Mem. Bytes} & \text{reference} \\ \hline 2^{88}& 2^{126.21}& 2^{14.32}& - & - & \text{Bogdanov et al. 2011}\\ \hline 2^{4}& 2^{126.89}& 2^{14.32}& - & - & \text{Bogdanov et al. 2012}\\ \hline - & - & - & 2^{126.01} & 2^{64} & \text{Canteaut et al. 2013}\\ \hline 2^{72}& 2^{126.72}& 2^{14.32}& - & - & \text{ Abed et al. 2014}\\ \hline 2 & 2^{126.67} & 2^{14.32} & 2^{126.59} & 2^{64} & \text{Bogdanov et al. 2015}\\ \hline 2^{64} & 2^{126.16} & 2^{14.32} & 2^{126.01} & 2^{64} & \text{" "}\\ \hline 2^{56} & 2^{126.13} & 2^{22.07} & 2^{125.99} & 2^{64} & \text{Tao et al. 2016}\\ \hline 2^{72} & 2^{126.01} & 2^{26.14} & 2^{125.87} & 2^{64} & \text{Tao et al. 2016}\\ \hline \end{array}

Where SIM is Sieve-In-the-Middle technique

  • Multi-Target attack

    If you had plaintext-ciphertext pairs with different encryption keys then with a multi-target attack you can find some keys faster. The expected cost of finding a key from $t$ targets is $2^{128}/t$. If you have a billion targets that you will be able to find the first key much lower than 128-bit security. The cost would be below $2^{100}$ and the time would be below $2^{70}$. This applies not only to AES but all block ciphers.

  • Post-Quantum Crypto

    Due to Grover's seminal work we know that the security of any block-cipher is halved in key size and it is shown to be asymptotically optimal.

    Thus, AES-128 will have 64, and AES-256 will have 128-bit security if someone can build the QC. If you consider your assets valuable, the reasonable choice is to double the key size.

    One can also use Grover's algorithm in parallel like in classical parallelization. One, however, will get $\sqrt{K}$ speed gain with $K$ copies.

why has 256 bit key based encryption is used so much to replace it?

Therefore, to mitigate the attacks that exist now or in a possible future, you need to double the key size. In AES, this makes AES-256. If you consider the overhead of using the AES with 256-bit key, in which we need 14 rounds, in CPU this makes around 40% percentage overhead. So, as stated in comments by Prof. Lindell, in marketing AES-256 sounds better, and becomes the standard.

The 256-bit marketing also may come from the US/NATO military regulations which use several distinct security levels (e.g. confidential =128, secret =192, top-secret =256). The 17 years old document from June 2003 states top-secret must be used 192 or 256 bits keys;

The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use


In a side note, according to leaked documents by Snowden, NSA looking for tau statics to break AES. After this revelation, consistent and strong encryption is required from governments. After 5 years, nothing has been related to tau statics and AES appeared in academics area.

Current Nist Recommendation NIST as of March 2019 disallows less than 112-bit security for block cipher in SP 800-131A Rev. 2:

The use of keys that provide less than 112 bits of security strength for key agreement is now disallowed.


Validation of the 40% overhead of AES-256 with AES-NI

The below numbers are from a laptop with a i7-6700HQ CPU to validate the performance overhead with AES-NI.

$openssl speed -evp aes-128-ctr
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr     509191.01k  1592361.66k  3090684.67k  4237894.66k  4708169.05k  4763506.01k

$openssl speed -evp aes-256-ctr The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-ctr 439608.45k 1479537.77k 2478394.14k 3129161.54k 3255877.41k 3396628.62k

lamontap
  • 833
  • 5
  • 12
kelalaka
  • 48,443
  • 11
  • 116
  • 196
  • 1
    I've edited with correct performance numbers on a beefy but old laptop. kelalaka, you got 110MB/sec of AES-256 and you didn't think "that must be wrong"? ChaCha20 runs at 1.7GB/sec! – Z.T. Jan 01 '20 at 00:36
  • 2
    AES is certainly not IND-CPA. AES is a block cipher and is supposed to be a pseudorandom permutation. You can achieve IND-CPA or IND-CCA or authenticated encryption using AES, by using the appropriate mode of operation together with AES. – Yehuda Lindell Jan 01 '20 at 06:20
  • @YehudaLindell thanks a lot. I've updated it. – kelalaka Jan 01 '20 at 06:56
  • @Z.T. you are right. I think I've forgotten the -evp. Thanks. – kelalaka Jan 01 '20 at 12:39
  • @kelala: ah I might have finally got what the paper means. There indeed is $2^8$ (blocks of 128 bits) of memory, and $2^{88}$ is the number of plaintext/ciphertex pairs nedded. These do not account as memory, because they can be queries to an encryption device/oracle that knows the key and accepts to use it to encipher (or is it decipher). I'm no longer so puzzled. But some rebuttal of the article that I posted today in comment was invoking an embarrassingly wrong reason. – fgrieu Jan 14 '20 at 22:10
  • @kelalaka: and now I'm puzzled again about how that "memory complexity $2^8$" in Bogdanov/Khovratovich/Rechberger becomes $2^{14.32}$ bytes in the account of that by Tao and Wu's Improving the Biclique Cryptanalysis of AES, Table 1. – fgrieu Jan 14 '20 at 22:54
  • @fgrieu in the first article page 14 says; - $2^8$ full computations of $g$-. That makes $2^8$ times 128-bit storage, $2^{15}$ bits . They say that this is an upper bound. – kelalaka Jan 15 '20 at 11:58
  • @fgrieu the second article, uses some facts about the same values and they say we don't need to store. Not a big words since don't contain much amount. – kelalaka Jan 15 '20 at 12:13
  • @kelalaka: I agree with your numbers. Note that the second article states that the attack in the first article (the second article's reference [9]) uses $2^{14.32}$ bytes, that is $2^{17.32}$ bits, sizably more than $2^{15}$ bits. A possibility is that the attack in the first article needs to search a 128-bit value among $2^8$ and return the (is it 8-bit?) input, which requires $2^{8}$ 128-bit entries of associative memory, or sizably more standard RAM memory. – fgrieu Jan 15 '20 at 12:29
  • 1
    @fgrieu I've updated with the works before 2016 and table based on the Tao et al.'. I think that is the current consensus between you and me. – kelalaka Jan 15 '20 at 13:28
  • Those quoted "regulations" are incorrect, at least for the USA. AES-128, not 192, is sufficient to protect information at the Secret level. (It's obviously still considered Secret at the paperwork level, but no further crypto is required to be done to it.) – Ti Strga Jan 15 '20 at 20:10
  • @TiStrga is there a link for this that I can read? – kelalaka Jan 15 '20 at 20:11
  • @TiStrga+ sorry, CNSSP15 was revised in 2016 at the forget-SuiteB-wait-for-PQ change; it now requires AES-256 'up to' TOP SECRET (pending PQ). Of course we don't really know why. – dave_thompson_085 Feb 08 '20 at 04:06
  • 1
    Also, 800-131A rev2 is 2019, but 'rev0' in Feb. 2011 had minimum 112 symmetric (TDEA option 1) starting 2016 but hash/etc and asymmetric equivalent to 112 (SHA-224, DSA/DH/RSA-2048, EC-224) starting 2014. This relaxed 800-57.1r2 in 2007 which had planned 112 across the board in 2011 (and 128 in 2031). I don't know if these are linkable; it was before NIST started doing DOIs. – dave_thompson_085 Feb 08 '20 at 04:32
  • @dave_thompson_085 oh Lord, trying to keep up with the churn of regulations is like Sisyphus and his damned hill, I give up. Scratch my comments then, I'm behind the curve. Thank you for the link! – Ti Strga Feb 10 '20 at 20:35
  • 1
    The leaked document does not say Tau statistic is investigated against AES by NSA. It says "TUNDRA, research of a new statistic for codebook analysis (..) Electronic codebooks, such as the Advanced Encryption Standard, are both widely used and difficult to attack cryptanalytically. NSA has only a handful of in-house techniques. The TUNDRA project investigated a potentially new technique -- the Tau statistic -- to determine its usefulness in codebook analysis. This project was supported by (redacted) of R21." – fgrieu Apr 20 '21 at 12:57
  • See also: https://crypto.stackexchange.com/a/102672/1267 – Mikko Rantalainen Nov 12 '22 at 14:09
  • Re your "Direct brute-forcing" section: are the computational resources required to test one candidate AES symmetric key (given the ciphertext only) similar to the computational resources required to perform one double SHA-256 calculation? – tparker Nov 10 '23 at 17:28
  • @tparker it is an approximation since we don't have a similar public computing power. I don't claim that one AES encryption = double SHA-255. It gives an example of computational power to estimate. We can get some metrics from openssl speed. – kelalaka Nov 10 '23 at 17:41
20

No, AES-128 has not been broken by any means in any practical sense.

Maeher
  • 6,818
  • 1
  • 33
  • 44
1

The AES algorithm is not broken.

With a single or a few fault injections during encryption, it is easy to recover the key in a matter of seconds/minutes/hours depending of the position of the faults and your computation material.

So in that sense it is broken, but the AES algorithm is not broken in its practical use.

  • 6
    This is a problematic answer. This is also true of RSA, ECC and more. This does not mean that it's broken in any way at all. – Yehuda Lindell Dec 31 '19 at 13:59
  • 2
    @YehudaLindell This is exactly what I said. –  Dec 31 '19 at 14:06
  • 9
    @corpsfini What you believe you said, and what you said are two different things. AES as an algorithm is not broken; however, you are conjecting attacks that could break it, which is out of the scope of the question. Furthermore, most people have no idea that AES is based in Rijndael. – b degnan Dec 31 '19 at 14:44
  • 5
    Also, whether a specific implementation is vulnerable to fault attacks depends on the details of the implementation. One can certainly build an AES implementation that is resistant to fault attacks... – poncho Dec 31 '19 at 17:10
  • @YehudaLindell It is broken in the fully academic sense of the question, e.g. with biclique attacks which provide a slight advantage over exhaustive search. But it isn't practically broken. – forest Feb 13 '21 at 23:23
  • 1
    @forest I do not agree that any slight advantage over exhaustive search makes it broken in the academic sense. – Yehuda Lindell Feb 14 '21 at 07:57
  • @YehudaLindell According to Schneier, "Breaking a cipher simply means finding a weakness in the cipher that can be exploited with a complexity less than brute-force.". We can disagree about whether or not "broken" is a meaningful label for a cipher like AES, but it's not possible to argue the definition of broken. See for example https://crypto.stackexchange.com/a/24323/54184 – forest Feb 14 '21 at 08:08
  • 3
    @forest Sorry, but the fact that Schneier defines what he wants to define does not mean that I or others in the community have to agree. An attack on AES that takes $2^{127}$ time is of interest academically and can and should be published. But no reasonable academic cryptanalyst will tell you that this means that AES is "broken". On the contrary, they will tell you that the fact that they worked for years and this is all they could do is a good sign for the security of AES. Sorry; we just disagree. – Yehuda Lindell Feb 14 '21 at 08:46
  • @YehudaLindell I suppose we can disagree on that. Can we at least agree that some cryptographers use "broken" in the more liberal sense, and others restrict it to refer only to practical breaks? – forest Feb 14 '21 at 08:47
  • @forest That's easy to agree upon :-) – Yehuda Lindell Feb 14 '21 at 08:56
  • You are in NO position to claim what is broken or not. None of us are. The best we can do is to describe the current situation as it is. Personal opinions are never part of the scientific inquiry – daparic Nov 02 '21 at 03:37