I was at a conference earlier this week sponsored by a library about data archiving. The conference was not about cryptography. One of the speakers said that the Advanced Encryption Standard (AES) was going to be 20 years old next year (Rijndael was first published in 1998) and that it was getting near the end of its life.

I'm familiar with cryptography, and I've been troubled by this statement ever since, because I didn't think that AES was in any danger. The algorithm has sufficient key lengths, even to resist quantum computer attacks, and there are no algorithmic flaws that have been discovered. Recall that DES was showing its age in the mid 1990s, but that was because it's key length was unreasonably short, not for any other reason.

Are there current reasons to consider upgrading or replacing AES?

  • 11
    $\begingroup$ "This crypto algorithm is getting old, hence it ought to be replaced" is an odd sounding argument; shouldn't it be more like "This crypto algorithm is old and has resisted an enormous amount of cryptanalysis, hence we can put a great deal of trust in it" $\endgroup$ – poncho Sep 23 '17 at 17:30
  • 2
    $\begingroup$ What was the conference about? Guess not cryptography :) $\endgroup$ – DrLecter Sep 23 '17 at 17:58
  • 2
    $\begingroup$ The original expectation was that AES have a 30 year operational life. That timer expires in 11 years, so I would say his statement is accurate. $\endgroup$ – Richie Frame Sep 23 '17 at 17:58
  • 2
    $\begingroup$ Old age shouldn't be a criterion to measure the usefulness of a crypto algorithm. Security and speed are what's important. I'm not aware of any significant security concerns with AES and with hardware assisted implementations speed seems to be adequate. Of course, if something new comes along that provides the same level of security (or better) and is also faster then let's take a look. What you should have asked him is "What will we replace it with?" If tomorrow someone published research that broke AES, what would we replace it with??? $\endgroup$ – Swashbuckler Sep 23 '17 at 20:29
  • 1
    $\begingroup$ The area where we see a lot of research right now is the lightweight cryptography to secure the IoT and devices which don't have hardware acceleration for AES and where even AES (which was already seen as quite lighweight during the AES competition) is "too heavy / slow" (sorry for not answering :p ) $\endgroup$ – SEJPM Sep 23 '17 at 21:37

The two main weaknesses where AES shows its age are the 128bit blocksize and the fact that AES 192 and 256 have far less security margin than the pure key size would suggest (some reasons for that here).

Besides that the concept of a block cipher with modes begins to be regarded as risky (authentication, padding, nonces) and more higher level primitives should be used in APIs (newer approaches like NaCl secretbox).

So from a crypto community standpoint it shows its age but is still time proofen and not broken. Especially since alternatives enjoy less general acceptance (especially if compliance voodoo is required).

I would argue long term archives cannot escape the voodoo argument for now, so they do rely on AES (at least in western geographies).

I think a successor will provide more than 128bit block size (or state), start with large key sizes and support efficient authenticated methods and maybe some support for parallelisation. It will hopefully define a approved family of modes/parameters in favor of free composition of primitives.

  • 2
    $\begingroup$ Hi. Your comment on libsodium doesn't make sense to me. Libsodium is not a block encryption algorithm, it is a high-level API. It requires AES as a block cipher. You can't say that a block cipher doesn't make sense in light of ideas like libsodium; that's like saying that having SCSI commands doesn't make sense for a hard drive, because higher-level access modes like the unix file system makes read-and-write block primitives obsolete. $\endgroup$ – vy32 Sep 24 '17 at 0:31
  • $\begingroup$ @vy32 Part of the API design was to not offer low level primitives as they are often used wrongly. crypto_secretbox is therefore the higher level mechanism I was alluding to (and it does not default to AES). Reworded my answer a bit. $\endgroup$ – eckes Sep 24 '17 at 0:45
  • $\begingroup$ that's true, but you still need to have a block encryption algorithm. Your revised answer makes more sense. But I don't think that a longer key size is necessary... $\endgroup$ – vy32 Sep 24 '17 at 0:55
  • $\begingroup$ @vy32 not sure why, but if you say so... $\endgroup$ – eckes Sep 24 '17 at 0:56
  • $\begingroup$ You're not sure why a block encryption algorithm is needed, or why a longer key size should not be necessary? A longer key size shouldn't be necessary, because a 256-bit key should be able to withstand any brute force attack. $\endgroup$ – vy32 Sep 24 '17 at 0:57

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