31
$\begingroup$

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?

$\endgroup$
42
$\begingroup$

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
$\endgroup$
  • 1
    $\begingroup$ What secret-derived index? $\endgroup$ – Melab Nov 9 '17 at 4:35
  • 2
    $\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
11
$\begingroup$

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. Notice for instance that AES-GCM is only accelerated in Java 9. GCM mode requires additional instructions for the Galois field multiplication.

Some library implementations of AES_GCM also buffer the ciphertext until the authentication tag is verified instead of using the online properties of the underlying CTR mode decryption. This could efficient implementations harder with regards to memory management.


It is of course 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/AES.

$\endgroup$
  • $\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
5
$\begingroup$

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

$\endgroup$
  • 6
    $\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
5
$\begingroup$

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.

$\endgroup$

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.