9

AES is secure, but compared to other encryption algorithm which are marked as secure, it's slow. For example, ChaCha20 is faster than AES, but still secure.

Also other standard-algorithms like SHA were upgraded in the last few years, so can we expect a AES upgrade in the near future?

Florian
  • 201
  • 2
  • 3

4 Answers4

20

No.

Basically your question is:

The car maker X recently updated its flag ship car and the motor cycle maker Y makes a bike that is accelerating faster in straight lines - will the Lorry maker Z make a new lorry soon?

And I‘ll try to put this in laymen’s terms:

AES as a successor of DES is - in comparison to the lifetime of DES - relatively young.

Additionally, you are comparing ciphers that are not equivalent. ChaCha20 is a stream cipher and AES is a block cipher. The SHA family of hashing functions got new family members because the existing ones were showing signs of age and were generally thought to be feasible to break in several years because of the increasing computing power as well as increased progress in the cryptanalysis of sha1.

As to why you think AES would be slow, as Steffen said in the comments: this only might be true for software implementations. Yet, even smartphones do have hardware accelerated AES.

The process of replacing a cipher is very lengthy and I didn’t yet hear a call for papers for a successor of AES, so there should be at least years until AES gets replaced, probably a decade or two.

That being said, post-quantum cryptography is an active field of research and depending on when good enough quantum computers will be possible, a paradigm shift in standard ciphers will be necessary - yet I don’t think this applies to AES.

mat
  • 2,558
  • 1
  • 14
  • 28
Tobi Nary
  • 371
  • 2
  • 8
15

Comparing algorithm speeds is a difficult art. ChaCha20 is faster than AES on "small to medium" CPU, basically from the ARM Cortex M0 at one end of the range, up to Intel Core2. More recent "big" CPU have dedicated opcodes for AES (and this includes some ARM processors on smartphones) and this makes AES consistently faster than ChaCha20 on these CPU. For very small CPU, I don't have figures at hand, but I would expect the 32-bit additions in ChaCha20 to imply a hit, as well as requiring more RAM. This extends to hardware circuits (FPGA, ASIC): making an efficient circuit for AES seems easier than an efficient circuit for ChaCha20. Thus, small 8-bit CPU can be more easily expanded with an AES accelerator than a ChaCha20 accelerator.

Another point is that AES is a block cipher, i.e. a relatively versatile primitive that can be used to encrypt data, but also for other tasks in which ChaCha20 is not an obvious drop-in replacement. This makes such comparisons delicate.

However, none of this implies that AES is perfect. It mostly means that making a function that behaves better on most architecture where AES runs is a challenging task, and ChaCha20 is an incomplete solution to that.

An additional parameter is side-channel attacks. It is well-known that table-based classic AES implementations are susceptible to cache attacks (timing attacks that exploit the common behaviour of cache memory). A more recent trend is to point out that ARX designs like ChaCha20 ("ARX" = "add-rotate-xor"), apart from their relatively high cost in hardware (because of the carry propagation in adders), might be more susceptible to fault attacks. Thus a blooming branch of cryptography hard at work trying to design alternate solutions; e.g. Gimli. This latter example is a good illustration of modern fashions in several ways:

  • A non-ARX, non-table design: no S-box (contrary to AES or DES), but no "complicated" operation like a 32-bit addition either (contrary to ChaCha20).

  • It is not a stream or block cipher; it is an un-keyed permutation, which is meant to be used as primitive to build higher-level functions, such as, indeed, encryption, but also hashing or MAC.

To sum up, while AES has known shortcomings, there is not a single, obvious and clear replacement strategy. We have lots of interesting ideas and possible designs, and their shortcomings are still largely unexplored. Therefore, a cautious normalization entity like NIST should adopt a wait-and-see posture. Consequently, I don't expect an AES-replacement competition within the next few years.

(In fact, considering that some big parts of the industry, e.g. banking, are only just now beginning to switch from DES to AES, I'd say that we'll have to support AES for another 20 years at least.)

Thomas Pornin
  • 88,324
  • 16
  • 246
  • 315
1

AES would be dropped when (or if) it is considered insecure. The speed is considered when they are picking a crypto system but because of Moore's law it doesn't really weigh into when a system should be abandoned.

The history of DES is probably the closest thing to a guide of the possible timing, but the key size difference means that it will not be the exact same story again.

daniel
  • 912
  • 5
  • 15
-2

Why only focus on AES? In fact, AES can easily replaced with stronger algorithms like, Twofish, Serpent, or newer ones like AEGIS and MORUS. And without the strenght of AES-NI, AES has more weaknesses than strengths against the others. Really, forget about standards like AES and bet on crypto-diversity. And don't use software which only supports AES for cryptography. It's always better to have possibilities.

Nick
  • 7