What's the appeal of using ChaCha20 instead of AES?

Question

I read about ChaCha20 being used in TLS by Google, SSH, and towards standardization in general.

What's the appeal of using something other than AES, what with AES receiving dedicated CPU instructions on various architectures to make it so efficent?

Answer 1

I believe there are three main reasons why ChaCha20 is sometimes preferred to AES.

1. On a general-purpose 32-bit (or greater) CPU without dedicated instructions, ChaCha20 is generally faster than AES. The reason for this is the fact that ChaCha20 is based on ARX (Addition-Rotation-XOR), which are CPU friendly instructions. At the same time, AES uses binary fields for the S-box and Mixcolumns computations, which are generally implemented as a look-up table to be more efficient.

2. AES's use of a look-up table with an index derived from the secret makes general implementations vulnerable to cache-timing attacks. ChaCha20 is not vulnerable to such attacks. (AES implemented through AES-NI is also not vulnerable).

3. Daniel J. Bernstein is having significant greater-than-average success in advertising his algorithms. (I'm not implying there are no merits. I'm just stating the fact that his algorithms have success in terms of deployment).

Of course, other reasons justify the choice of AES instead of ChaCha20.

To name a few:

• Dedicated instructions on high-end CPUs
• Amount of received cryptanalysis
• Availability of studies on side-channel (other than cache timing) protections

Answer 2

Unless we find information from Google - such as white papers & mailinglist posts - we can only speculate why ChaCha20 is chosen. I think that efficient software implementation is still the most likely reason. That AES-GCM is relatively brittle - for instance with regards to timing attacks - could be another.

Note that even though AES-NI is becoming more commonplace in the x86 processor market, that doesn't mean that other processor architectures are implementing AES acceleration. For instance cheap Android phones may not incorporate it. Furthermore, although AES-NI support is on the CPU, that doesn't mean that the software is actually using the instruction. GCM mode can be sped up using additional instructions to speed up the Galois field multiplication.

It is possible to use AES CTR and Poly1305 together (while making sure that the keys aren't reused in an insecure fashion). But then the organization would have to define that AEAD algorithm first before you can use it. So using AES probably means GCM authentication and ChaCha20 gives you Poly1305.

Answer 3

Quoting RFC 8439 (emphasis mine):

The Advanced Encryption Standard (AES — [FIPS-197]) has become the gold standard in encryption. Its efficient design, widespread implementation, and hardware support allow for high performance in many areas. On most modern platforms, AES is anywhere from four to ten times as fast as the previous most-used cipher, Triple Data Encryption Standard (3DES — [SP800-67]), which makes it not only the best choice, but the only practical choice.

There are several problems with this. If future advances in cryptanalysis reveal a weakness in AES, users will be in an unenviable position. With the only other widely supported cipher being the much slower 3DES, it is not feasible to reconfigure deployments to use 3DES. [Standby-Cipher] describes this issue and the need for a standby cipher in greater detail. Another problem is that while AES is very fast on dedicated hardware, its performance on platforms that lack such hardware is considerably lower. Yet another problem is that many AES implementations are vulnerable to cache- collision timing attacks ([Cache-Collisions]).

So the question to "why use anything other than AES" is the old saw "don't keep all your eggs in the same basket." The question then remains, "why ChaCha20 and not, say, Rabbit or SOSEMANUK or any other eSTREAM portfolio cypher?" ChaCha20 has the advantage of having a 256-bit key, while the other cyphers in the eSTREAM portfolio are 128-bit; HC-128 has an analogous HC-256 stream cypher which does have 256-bit security, and could be used instead. Benchmarks, however, show it to be slower by an order of magnitude compared to ChaCha20. However, if 128-bit security is enough for you, Rabbit is specified in RFC 4503 and implemented in a few crypto libraries. SOSEMANUK and HC-128 don't have RFCs, but have reference implementations that could be used to implement a TLS mode, if the standard allowed for it.

Answer 4

Professor Daniel J. Bernstein is the author of Salsa20 and her sister streaming cipher suites like ChaCha20. The European Union had their eSTREAM contest and paper sharing and DJB came out ahead by about a mile. Refer to his site https://cr.yp.to/ and then there is the competition site in the E.U. http://www.ecrypt.eu.org/stream/salsa20p3.html

Answer 5

Not sure if my speed test could help to get an idea on this topic.

ChaCha20-IETF-Poly1305 is actually now 10% slower than AES-256-GCM on my mobile TLS speed test in 2020, even since 2019. AES-256-GCM was much slower back in 2015, but I had lower-end CPU back then.

I can not run SSH on mobile as it isn't rooted, but on the desktop I can't find the differences.

My phone specification, QC Snapdragon 845 4x 2.8 GHz Kryo 385, 4x 1.8 GHz Kryo 385.

Server spec, 2 servers,

1. Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
2. Intel Core Processor @ 2.4Ghz (Broadwell, no TSX, IBRS)

I can not test on lower-end phones, but I heard Chacha20 Poly1305 do better on lower-end CPUs.

I don't find any TLS or SSH differences on my Dual Xeon E2670 desktop.

On an IoT device, such as WRT routers with low Bogomips, feedback ciphers do better latencies than chachas, the trade-off will be the security. This is also from my tests.

Therefore, I prefer the James Yonan's recommendations.