Re: [TLS] Salsa20 and Poly1305 in TLS

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, Jul 29, 2013 at 9:09 PM, Adam Langley <[e-mail]> wrote:
> I cannot make it to Berlin I'm afraid (or, indeed, any meetings until
> at least IETF 91) so I'm writing my thoughts on
> draft-josefsson-salsa20-tls-02, which is scheduled for discussion.
[...]
> Salsa20/12 is something that we are currently working on supporting.
> However, I believe that Poly1305 is superior to UMAC and we're looking
> at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the
> nonce generated directly by Salsa20/12, not via AES.)

Thanks. The choice between UMAC and Poly1305 is indeed an open issue right now.

> (For the following, I used UMAC in nettle 2.7 and Andrew M's
> implementation of Poly1305[1], both on a E5-2690@2.90GHz with
> Hyperthreading and Turboboost disabled.)
> UMAC96 (with AES for the nonce generation) takes 9146.1ns to
> authenticate 1K of data, HMAC-SHA1(1K) takes 3667ns and Poly1305 takes
> 561.4ns.
> However, that's not the whole story for UMAC because it can use 1.5KB
> of memory for precomputation, after which it can authenticate 1KB of
> memory in just 329ns with that in L1. That's typically the headline
> speed that's advertised.

That is, however, an important advantage in dedicated peer-to-peer
connections (e.g., VPN), which is how I test the current ciphersuites.

btw. was Poly1305 used with salsa20/12 in this comparison or AES? If
it is salsa20, I believe that the numbers would be quite different for
UMAC if used with salsa20 as well.

In any case, whether AES is used on the MAC (UMAC or Poly1305) or the
cipher of the ciphersuite is also an issue to be addressed. The only
issue for using the cipher instead of AES, is the fact that there are
no test vectors (in an RFC or any other document), and both of these
variants were defined using AES so by combining the MAC with another
cipher TLS will be quite unique. Nevertheless that idea of combining
them with the actual cipher in use is quite nice and has advantages in
a number of systems.

> Additionally, Poly1305 can be written in a tweet(*), while UMAC is
> dramatically more complex. Since they are both Wegman-Carter style
> hashes I believe that they both have, fundamentally, well understood
> security properties. (See [2] for a good overview.)

Complexity is indeed an issue, but tweetocity doesn't seem to be a
clear advantage :)

> Thus Poly1305 is looking much more attractive to us.

While I like UMAC, but I also see the advantages of Poly1305. In any
case, I think it would be a good idea to add them to the list (or even
replace umac if there are no clear advantages) if that draft proceeds.

regards,
Nikos