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?


I believe there are three main reasons why ChaCha20 is sometime 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, while AES uses binary fields for the Sbox and Mixcolumns computations, which are generally implemented as look up table in order to be more efficient.

  2. The fact that AES uses lookup 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 a significant above-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 there are other reasons that 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
  • 1
    $\begingroup$ What secret-derived index? $\endgroup$ – Melab Nov 9 '17 at 4:35
  • 3
    $\begingroup$ The Sbox. The common way to implement the 8-bit AES SBox is through a lookup table. During round 0 the input/index is the plaintext xorred with the key (the secret). $\endgroup$ – Ruggero Nov 9 '17 at 8:26
  • 1
    $\begingroup$ I tried several HTTPS websites with Nexus 5 which I believe does not support AES-NI. Those websites support ChaCha20, but order it after AES. Chrome shows that it is connecting via AES. I guess that server order has higher preference? If most servers specify order (out of security I guess) then advantage of ChaCha20 will not affect many use cases. $\endgroup$ – Franklin Yu Jul 31 '18 at 19:59
  • $\begingroup$ Just a note that it is possible to implement AES somewhat efficiently without lookup-based S-box: eprint.iacr.org/2009/129. $\endgroup$ – Pieter Wuille Sep 7 '20 at 19:05
  • $\begingroup$ @PieterWuille true but it works only for parallellizable mode like CTR. It does't work for e.g. AES-CBC. So to be generic we compare between single encryption calls taking into account the output size. $\endgroup$ – Ruggero Sep 8 '20 at 7:43

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.

  • 1
    $\begingroup$ What do you mean by brittle? $\endgroup$ – JDługosz Apr 12 '16 at 19:07
  • 3
    $\begingroup$ I mean that although it is thought to be secure with regards to the full algorithm, it breaks down rather fast when anything is wrong; nonce reuse, small tag size, timing attacks etc.. For more information, see here (the key is of course still protected by AES though). $\endgroup$ – Maarten Bodewes Apr 12 '16 at 20:32
  • 1
    $\begingroup$ Also noteworthy is the fact that AES-NI, like any CPU instruction set, is a black box with no publicly available information about its implementation. Distrust towards CPU manufacturers is yet another reason to not chose AES. $\endgroup$ – Dreadlockyx Feb 26 '20 at 8:19
  • 2
    $\begingroup$ @dreadlockyx Unlike with hardware RNGs, I don't understand this particular concern. AES is a deterministic algorithm: you can use AES-NI to encrypt an object and use a software-only algorithm, and verify that they are bit-for-bit identical. Heck, you could write a crypto library which randomly chooses a small percentage of enciphered blocks to verify against a software implementation. What concern am I missing here? Are there worries that AES-NI could leak something via a side-channel backdoor? $\endgroup$ – Dan Lenski Mar 20 '20 at 6:11

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.


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

  • 13
    $\begingroup$ This is essentially a link-only answer, which is frowned upon on Stack Exchange. Could you summarize the criteria directly in your Answer? $\endgroup$ – JDługosz Nov 18 '17 at 3:32

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.

  • 4
    $\begingroup$ I'm pretty sure that Snapdragon CPU has AES hardware acceleration which makes it entirely unsurprising that it performs that well. $\endgroup$ – SEJPM Sep 7 '20 at 8:50
  • 2
    $\begingroup$ It seems to use teh Armv8 Cryptographic Extensions. It seemingly performs (raw) AES at 1 GB/s which makes it pretty likely that it is accelerated. According to Wikipedia Qualcom implements it in Snapdragon 805 onwards. Actually, since the independent SPU also seems to contain AES hardware support, it could well be that there is more than one AES implementation in there. $\endgroup$ – Maarten Bodewes Sep 7 '20 at 9:14
  • $\begingroup$ I would argue that 10% slower without hardware acceleration is pretty good! $\endgroup$ – A. Hersean Sep 7 '20 at 14:50

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.