Re: [Cfrg] Salsa20 stream cipher in TLS

[Simon Josefsson <[e-mail]>]

Adam Langley <[e-mail]> writes:

> On Mon, Mar 18, 2013 at 4:42 PM, Simon Josefsson <[e-mail]> wrote:
>> instead).  I don't believe the AEAD mechanism works: there is no field
>> to put the MAC in it.
>
> There's no field for the GHASH tag for AES-GCM either: the
> construction of the authentication is opaque to the user of the AEAD
> algorithm. If you were to define an AEAD for this then you could
> decide where you would like the MAC to know, but it's a property of
> the AEAD, not of TLS.

Right, agreed.  Equally, the content of the ciphertext for a
GenericStreamCipher is opaque to TLS, so we could put a nonce in there
if that was necessary (but we don't need to).  Having stream ciphers
expand data is a bit unorthodox, but from a TLS protocol point of view
it may work.  Some implementation assume there is no message expansion
for stream ciphers, but I haven't seen anything in the specification
that assumes or require that.

>> Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a
>> HMAC-SHA1 variant in the working copy.  It is not clear to me whether
>> keeping HMAC-SHA256 is useful.
>
> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the
> typical combination.

That could be another option.  The only reason is that I haven't worked
with any implementation of Poly1305, so I'm not that familiar with it.

/Simon