[TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02

[Nikos Mavrogiannopoulos <[e-mail]>]

Hello,
 We are about to update draft-josefsson-salsa20-tls-02 by replacing
UMAC-AES with POLY1305-AES, and given the opportunity we made a
comparison of the two drafts that add a new stream cipher to TLS. That
is draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02.

* Salsa20 vs Chacha

draft-josefsson-salsa20-tls-02 uses Salsa20, a winner of an
international competion of stream ciphers (eStream), which is easily
implementable without leaking information through side-channels (i.e.
timing attacks).

draft-agl-tls-chacha20poly1305-02 selects Chacha instead, a derivative
of Salsa20 that has been shown to be 7% faster in hardware and occupy
10% less space [0]. However, it only combines that cipher with a MAC
that is of questionable efficiency in hardware (according to CFRG
synopsis). This results overall, in a combination that isn't really well
suited for hardware.

Nevertheless, even if draft-agl-tls-chacha20poly1305-02 could be made
efficient in hardware, in our opinion the performance benefits don't
justify switching from a winner of an international competition to
another algorithm (even if it is a derivative of it).


* Applicability to Datagram TLS

The draft-agl-tls-chacha20poly1305-02 is only applicable to TLS and not
DTLS. That is because its combination with poly1305-chacha results to an
RC4-like effect where rearranged or lost packets result in a
desynchronization of the peers. draft-josefsson-salsa20-tls-02 applies
to both TLS and DTLS (this results from the choice of having the block
cipher AES in UMAC-AES). Having a stream cipher in DTLS was a main
reason (for me at least) for draft-josefsson-salsa20-tls-02.


* Adding a new cipher in stream or AEAD mode?

The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing
implementations and can be combined with the existing MAC algorithms in
TLS (i.e., HMAC-SHA1). That is not the case in the
draft-agl-tls-chacha20poly1305-02 draft, where a single combination is
registered (of chacha with poly1305). Adding additional combinations in
the latter draft would require defining more AEAD modes, something that
could be a significant barrier that prevents its implementation (in
contrast with just replacing a cipher in the stream setting of TLS).

While I understand that there is quite some argumentation for using the
AEAD mode in TLS for every cipher/mac combination I don't find it
particularly convincing. In this specific case the AEAD mode adds 8
bytes of explicit nonce to the TLS record packet without providing any
clear advantages compared to the original stream cipher interface.


* An interesting observation on the usage of EtA in
draft-agl-tls-chacha20poly1305-02 vs AtE.

Both drafts introduce a universal hash based MAC. However, the
chacha-poly1305 draft uses the encrypt-then-authenticate (EtA)
construction while the salsa20 draft uses TLS' authenticate-then-encrypt
(AtE) construction. When combined with ideal ciphers and MAC algorithms
both modes can be equivalent. However, the AtE construction has the
advantage of not revealing the MAC nor the authenticated data to an
adversary. Interestingly enough the only known attacks on universal hash
based MACs require access to MAC and data [1]. That is, these attacks
(the key guessing and the divide and conquer) do not directly apply to
draft-josefsson-salsa20-tls-02.

Of course these attacks are of high complexity and impractical (unless
some other weakness in the TLS protocol, or the MAC algorithm is found),
but they nevertheless reinforce the view that the AtE construction has
advantages on non-ideal MAC algorithms.

best regards,
Nikos


[0]. Henzen, Luca, et al. "VLSI hardware evaluation of the stream
ciphers Salsa20 and ChaCha, and the compression function Rumba."
Signals, Circuits and Systems, 2008. SCS 2008. 2nd International
Conference on. IEEE, 2008.

[1]. Handschuh, Helena, and Bart Preneel. "Key-recovery attacks on
universal hash function based MAC algorithms." Advances in
Cryptology–CRYPTO 2008. Springer Berlin Heidelberg, 2008. 144-161.