[TLS] ChaCha20 + Poly1305 in TLS

[Adam Langley <[e-mail]>]

I've just posted a draft defining ChaCha20+Poly1305 cipher suites for
TLS: https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/

(To those who might not read this mailing list all the time, this was
prompted by attacks on RC4 and CBC mode earlier this year and is not a
response to any recent press stories.)

Neither RC4 nor the current CBC modes are looking very attractive in
light of recent attacks. AES-GCM is in the process of being deployed
but both AES and GHASH are very troublesome to implement in software
in a way that is fast, secure and has good key agility.

Modern Intel chips implement AES-GCM in hardware and future, high-end
ARM chips may also. But I expect that there will always be a large
number of devices without that capability and there are currently no
good options for them in TLS.


I know that Nikos presented about using Salsa20+UMAC at the last
meeting and, although close to this proposal, I obviously made some
different choices.

I picked ChaCha20 over Salsa20. ChaCha20[1] is a tweak of Salsa20 to
achieve better diffusion. It is conjectured to be stronger than
Salsa20 and an attack against a reduced round Salsa20 in [2] broke one
fewer rounds of ChaCha20.

ChaCha20 received some positive remarks at the CFRG[3] and is slightly
faster. Salsa20 has been the target of more analysis.

Overall, I weakly preferred ChaCha20 over Salsa20.


I picked Poly1305 over UMAC/VMAC. UMAC/VMAC have a clear speed
advantage (~2x) on high-end chips when key agility isn't important and
Nikos indicated that such a scenario is important to him[4]. However,
I think that use case is likely to be met with hardware AES-GCM
implementations.

Otherwise, I like the conceptual simplicity of Poly1305, the lack of
precomputed tables, and the theoretical benefits of randomly varying
the point at which the polynomial is evaluated. It is also currently
slightly faster on ARM, although in single-key benchmarks I suspect
that advantage could be eliminated with more optimisation, based on
the x86-64 numbers.

Overall, Poly1305 over [UV]MAC was a clearer choice than ChaCha vs Salsa.


ChaCha20 is very simple and even a completely naïve implementation
will be secure. Poly1305 is somewhat more complex to implement but
again lends itself to secure implementations. Several high-quality,
optimised, public domains implementations are available of each.


I have implemented this draft in NSS and OpenSSL. No heroic
optimisation was done, but I used implementations by Andrew Moon, Ted
Krovetz, djb and Peter Schwabe.

The following numbers are encryption rates for a 1K block size with
with AES-128-GCM or ChaCha20+Poly1305. The AES-128-GCM implementation
is OpenSSL 1.0.1e compiled with gcc 4.6.3 and -O3, unless other
compiler flags are noted.

On an E5-2690@2.90GHz with Hyperthreading and Turboboost disabled:

AES-128-GCM, AES-NI disabled: 131 MB/s
AES-128-GCM, AES-NI enabled: 311 MB/s
AES-128-GCM, AES-NI enabled & -march=native: 308 MB/s
ChaCha20+Poly1305: 420 MB/s
ChaCha20+Poly1305, -march=native: 560 MB/s

On a Galaxy Nexus (ARM Cortex-A9@1.2GHz), gcc 4.7:

AES-128-GCM: 27 MB/s
ChaCha20+Poly1305: 78 MB/s

Note that I'm being rather unfair to ChaCha20 here: I'm comparing
128-bit AES against a 256-bit ChaCha20.

Intel suggests[5] that an E5-2690 (Sandy Bridge) should be able to do
AES-128-GCM in ~2.55 cycles/byte, giving speeds of ~1.1GB/s. Possibly
I've messed something up with OpenSSL, or the implementation in
OpenSSL 1.0.1e is underperforming, but I'm reporting what I see.

Of course, in general, one is not going to beat dedicated hardware in
software. When both parties to a TLS connection have AES-GCM hardware
implementations then AES-GCM is likely to be the most performant
option.


Cheers

AGL

[1] http://cr.yp.to/chacha/chacha-20080128.pdf
[2] http://eprint.iacr.org/2007/472.pdf, section 3.5.
[3] http://www.ietf.org/mail-archive/web/cfrg/current/msg03491.html
[4] http://www.ietf.org/mail-archive/web/tls/current/msg09712.html
[5] http://2013.diac.cr.yp.to/slides/gueron.pdf, page 17.