
ChaCha20- and Poly1305-based Cipher Suites for TLS - moonboots
https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01
======
acrispino
related blog post from agl:
[https://www.imperialviolet.org/2013/10/07/chacha20.html](https://www.imperialviolet.org/2013/10/07/chacha20.html)

~~~
andrewcooke
with interesting info on them dropping SSLv3 from chrome to google in an
attempt to identify what is downgrading connections (which must be extra fun
if you are wondering who is hiding in the noise).

------
rainsford
I think it's an interesting idea, but I admit I'm a bit surprised at the
choice of ChaCha20. The related Salsa20 algorithm has received far more public
analysis and while ChaCha20 has some interesting (if minor) performance and
theoretical security improvements, but they don't seem worth giving up the
assurance you get from the extra review of Salsa20.

~~~
agl
The feeling seems to be that the analysis of Salsa carries to ChaCha and that
ChaCha is slightly preferable: [http://www.ietf.org/mail-
archive/web/tls/current/msg10222.ht...](http://www.ietf.org/mail-
archive/web/tls/current/msg10222.html)

I started out with Salsa but switched because I also slight prefer ChaCha and
people seemed to agree.

~~~
rainsford
I agree that ChaCha seems like a better function (designed for faster
diffusion, better block layout, etc), and it is comforting that fewer ChaCha
rounds can be attacked with the same attacks that apply to Salsa. But ChaCha
does still represent a substantial change in the core function from Salsa, and
I do wonder if it's possible those changes introduce a problem not found in
Salsa. To be honest, I really suspect the answer is no, and that ChaCha is a
good choice...just surprising given the relative interest in Salsa compared to
ChaCha. But maybe your choice will also spur more people to consider ChaCha
for both usage and further cryptanalysis.

~~~
floody-berry
One positive is the indirect attention it has received through BLAKE and
BLAKE2, where it has done extremely well.

------
devx
By Google's Adam Langley. Nice. I know he's been a big supporter of DJB's
curves.

~~~
tptacek
He is, but just for what it's worth, ChaCha20 (and Salsa20, from which it's
derived) and Poly1305 aren't based on elliptic curves, and the TLS ECC
features aren't based on Curve25519/Ed25519.

------
andrewcooke
why does DJ Bernstein advocate using a counter for _r_ (see section 3 of the
poly1305 paper)? this RFC uses a random value (derived from the one-time key),
which seems reasonable to me (i think there are 106 bits available, so you're
getting a collision in 53 bits, which at 1000 connections a second is over
10^5 years).

just seems odd to go to the effort of specifying how to safely implement a
counter in some detail in the paper when a random value seems fine (it's also
quite possible i've misunderstood something - these are all new to me).

~~~
agl
The paper specifies Poly1305-AES, which is a little different.

In Poly1305-AES, the point at which the polynomial is evaluated (r) is random,
but the value added at the end is calculated as AES_k(nonce). Basically, AES
was used to map from a counter to a secret value. It's very important that
that value not be reused, because the security the system falls apart.

In my draft, I'm not using AES. Rather I use a block of ChaCha20 to generate
the value to add at the end _and_ a different r value for each message.

But there is essentially the same problem: an nonce still needs to be fed into
the cipher and it must not repeat. (Additionally, repeating the nonce here
breaks confidentiality too as the keystream will repeat and the attacker gets
the XOR of the two plaintexts.)

TLS already has a counter for this, which is used here.

(Alternatively, some AES-GCM implementations in TLS use an 8-byte, random
value as the nonce, which stands a good chance of repeating after 2 __32
records :( )

~~~
floody-berry
For anyone wondering, Cryptography in NaCl [1] goes in to some detail about
the benefit of generating a per-message r vs a static r in section 9.

[1]
[http://cr.yp.to/highspeed/naclcrypto-20090310.pdf](http://cr.yp.to/highspeed/naclcrypto-20090310.pdf)

------
mentat
Why do people consider GCM difficult to implement in software?

(disclaimer: I worked for a company that sold a GCM implementation)

~~~
tel
My understanding is that fast implementations in software require look up
tables which are susceptible to timing attacks.

~~~
sweis
OpenSSL has a GCM implementation which is very fast and I believe is not
susceptible to timing attacks due to using vpclmulqdq:
[http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto...](http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/modes/asm/aesni-
gcm-x86_64.pl;h=3781933917227dd127352fa8d7d066804dacba13;hb=HEAD)

You can debate whether it's a "software implementation" since it's using AESNI
and PCLMULQDQ.

~~~
tptacek
I think PCLMULQDQ is noncontroversial, but also considered "hardware
supported".

------
tel
Exciting!

