7
$\begingroup$

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?

$\endgroup$
  • 6
    $\begingroup$ "...ChaCha20 is faster than AES..." - is it? It is possible to implement AES with hardware support and most modern CPU do have specific instructions for this. In this case AES is about five times faster than ChaCha20, see calomel.org/aesni_ssl_performance.html. Only if you don't have AES-NI or similar instructions and have to rely on software only it will be slower than ChaCha20. $\endgroup$ – Steffen Ullrich Nov 11 '17 at 7:28
  • 6
    $\begingroup$ Personally I'd like to see Rijndael256 standardized. 128-bit blocks are a bit narrow, considering the amount of data we're dealing with nowadays. $\endgroup$ – CodesInChaos Nov 12 '17 at 10:35
  • 2
    $\begingroup$ Still better than the 1 bit block size of ChaCha20 :P $\endgroup$ – Maarten Bodewes Nov 13 '17 at 10:29
  • 3
    $\begingroup$ @MaartenBodewes When considering the birthday bound limiting the amount of data, ChaCha20 has a block-size of 512. $\endgroup$ – CodesInChaos Nov 13 '17 at 13:59
  • 2
    $\begingroup$ @Florian: "If ChaCha20 is faster in software-only implementations it would also be faster as a hardware implementation." - sounds logical but is still wrong. There are algorithms which are specifically designed to run fast on general purpose CPU while there are algorithms designed to make fast hardware implementations possible. Hardware implementations have different possibilities and restrictions than software, especially regarding the amount of memory needed, space on die (i.e. the chip), possible parallelization etc. $\endgroup$ – Steffen Ullrich Nov 14 '17 at 5:46
9
$\begingroup$

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

|improve this answer|||||
$\endgroup$
19
$\begingroup$

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.

|improve this answer|||||
$\endgroup$
  • 1
    $\begingroup$ Indeed, AES-256 is thought to be "quantum secure". Basically for most symmetric ciphers it is thought that quantum analysis halves the amount of security - if I understood correctly anyway. Now AES-128 would in that case have a security of 64 bit against quantum computing analysis. That's rather on the low side in case quantum computers really mature, so I'd still use AES-256 for top secure stuff instead of AES-128 and the largely unused AES-192. $\endgroup$ – Maarten Bodewes Nov 13 '17 at 10:27
  • $\begingroup$ For reference, the halving of bit security is due to Grover's algorithm, which---when applied to AES---would model AES as a black box function. Grover's algorithm is asymptotically optimal for this kind of search. So in terms of brute force attacks on block ciphers and hash functions, this is as good as it's going to get for quantum computers. $\endgroup$ – bkjvbx Nov 13 '17 at 21:24
  • $\begingroup$ I know that aes if faster becuase of they hardware acceleration. But wouldn't chacha20 have faster hardware implementations than AES, because it's faster at all? Also, many smartphones are using ChaCha20 for TLS right know, even if there's a hardware acceleration. $\endgroup$ – Florian Nov 14 '17 at 1:49
  • 1
    $\begingroup$ Hardware implementations of AES tend to be smaller and faster than hardware implementations of ChaCha20, because these 32-bit adders use a lot of silicon area and have non-negligible latency. What makes ChaCha20 efficient on 32-bit CPU is that these CPU already have optimized adders. In big CPU that have both ChaCha20 hardware (i.e. 32-bit adders) and AES hardware, AES is faster. In smaller CPU without AES hardware, ChaCha20 still benefits from the adders. $\endgroup$ – Thomas Pornin Nov 15 '17 at 14:11
1
$\begingroup$

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.

|improve this answer|||||
$\endgroup$
  • 3
    $\begingroup$ The comparison with DES is a little flawed though, because when DES was released, a full search over the key was already within the reach of what could be achieved (very expensive and would take a long time, but possible). Full search of AES-256 is far beyond what is possible within the limitations of human existance. $\endgroup$ – tylo Nov 14 '17 at 15:23
  • 1
    $\begingroup$ As an aside, Moore's law is not rooted in any physics and should not be considered a basis for anything. Transistor scaling for power is dead, and is pretty much just advertising at this point. Transistors are at velocity saturation at threshold in every node below 24nm that I've tested. We did a good job, but the party is over. $\endgroup$ – b degnan Nov 14 '17 at 15:33
  • $\begingroup$ @bdegnan Party over? My graph at the bottom of crypto.stackexchange.com/a/61759/23115 seems to suggest otherwise. No? $\endgroup$ – Paul Uszak Sep 18 '18 at 14:58
  • $\begingroup$ @PaulUszak That "up tick" is false. GF started counting transistors the way Intel does, which is "per gate", but there's two gate minimum per physical transistor. Also, remember "Moore's Law" is a density trend, the assumptions about power are generally false. The biggest issue I saw at 14nm/7nm was that channel saturation was reached before threshold. GF/Intel likes to try to market their way out of physics, which is not possible. $\endgroup$ – b degnan Sep 19 '18 at 16:19
  • $\begingroup$ @bdegnan Transistors? There are no transistors. The PassMark is based on raw computational power per CPU using bench marking. And it's going up as per my graph. $\endgroup$ – Paul Uszak Sep 19 '18 at 16:36
-1
$\begingroup$

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.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ elaborate this point "AES has more weaknesses than strengths against the others" $\endgroup$ – hardyrama Sep 18 '18 at 9:41
  • $\begingroup$ @hardyrama Monocryptography is it's greatest weakness. As are all monocultures. This is unequivocal. $\endgroup$ – Paul Uszak Sep 18 '18 at 16:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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