2

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?

vy32
  • 439
  • 3
  • 13
  • TDES is still a "valid" algorithm when run in keyingOption1, and is weaker than AES. I think AES has a while yet. – Kritner Sep 23 '17 at 17:25
  • 11
    "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" – poncho Sep 23 '17 at 17:30
  • 2
    What was the conference about? Guess not cryptography :) – DrLecter Sep 23 '17 at 17:58
  • 2
    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. – Richie Frame Sep 23 '17 at 17:58
  • 2
    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???

     – Swashbuckler Sep 23 '17 at 20:29
  • Great comments, but I'd love to see some answers... – vy32 Sep 23 '17 at 20:32
  • 1
    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 ) – SEJPM Sep 23 '17 at 21:37
  • What is the source of the information? – zaph Sep 23 '17 at 22:06
  • I've updated the question – vy32 Sep 23 '17 at 22:51
  • What was the speaker offering as explanation and alternative? – eckes Sep 24 '17 at 00:31
  • @Swashbuckler ChaCha20, of course :-) – Reid Sep 24 '17 at 01:10
  • @Swashbuckler Old age is incredibly important. People try coming up with their own new and fancy algorithms all the time, but you have no idea if that algorithm is going to get cracked within a day, a month, a year, you just don't know. It's exceedingly common for a "new faster" crypto algorithm to be cracked, new ones just aren't really as safe. Remember that for a lot of cryptography there's no actual "proof" that it works, RSA could be cracked any day, along with ECC. Our only "proof" of it working is that you'd be a billionaire if you cracked it, and no one has. – Nicholas Pipitone Feb 20 '20 at 00:17
  • Upgrade no, replace use AES-256. Any block cipher with 128-bit key will face the attacks describe here. If re-opens we can find dupes like that. – kelalaka Feb 20 '20 at 16:33

1 Answers1

0

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.

eckes
  • 646
  • 5
  • 11
  • 2
    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. – vy32 Sep 24 '17 at 00:31
  • @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. – eckes Sep 24 '17 at 00:45
  • 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... – vy32 Sep 24 '17 at 00:55
  • @vy32 not sure why, but if you say so... – eckes Sep 24 '17 at 00:56
  • 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. – vy32 Sep 24 '17 at 00:57
  • @vy32 i am not sure why you think it is needed (but my answer was not addressing the type of cipher directly anyway) – eckes Sep 24 '17 at 00:58
  • libsodium uses aes128 in counter mode as its stream cipher. – vy32 Sep 24 '17 at 01:02
  • And secretbox uses xsalsa20 – eckes Sep 24 '17 at 01:16
  • What's all this about geographies? – Melab Sep 25 '17 at 17:22
  • In Russia you have Ghost and in Japan and Europe you have Camellia as compliant alternatives, @melab – eckes Sep 26 '17 at 00:01
  • Is a 128-bit block size really a problem? it would require exabytes of data to be encrypted with the same key to measure deviations from a random function. I mean it might be a thing eventually but I don't think this will be an issue for many decades. – Seawaves32 Feb 20 '20 at 16:14
  • If it was a real issue they would have changed it. :) But it is a weakness which becomes a issue in the future. And since you can't undo weak encrypted data you need to be careful of you require long term security. For new designs of block ciphers it is something to take into account. I think there are other answers here which can classify the magnitude (it was also related to quantum resistance, but I am not sure how concrete those concerns where) – eckes Feb 20 '20 at 18:29