Re: [Cfrg] Salsa20 stream cipher in TLS

[Simon Josefsson <[e-mail]>]

"David McGrew (mcgrew)" <[e-mail]> writes:

> Hi Simon,

Hi David.  Thanks for quick review.

> It is not exactly clear what problem is being addressed by this work.
> Would be good to add a problem statement section.

Good idea, the document now contains this paragraph:

   The purpose of this document is to provide an alternative stream
   cipher for both TLS and DTLS that is comparable to RC4 in speed on a
   wide range of platforms.

There are other soft factors too.  In general the goal is to offer
something that can replace use of RC4 in TLS.  I'm guessing speed is one
reason people use RC4 in TLS today.

> Some more detailed comments, quoting from the draft:
>
>    Recent attacks has indicated problems with CBC-mode cipher suites in
>    TLS/DTLS and problems with the only supported stream cipher (RC4) in
>    TLS has been known for a long time.  While AEAD cipher suites address
>    these issues, concerns about performance are sometimes raised.
>
>
> What are the performance concerns?   I suggest citing some relevant
> performance data.

If there are implementations of this, we can benchmark them and compare
them against other cipher suites and include some numbers or pointers to
comparisons.  I believe Salsa20 is faster than for example AES GCM on
most platforms.

>   Because the GenericStreamCipher definition in TLS does not provide
>    any way to transport the Salsa20 nonce that is required for
>    functionality and needed to provide the random access property, we
>    let the output from the stream cipher operation be the concatenation
>    of the IV and the encrypted data.
>
>
> Please, define a Salsa20-based AEAD mechanism instead of a new TLS format!

That paragraph has been removed from the current work in progress, it
was incorrect (the record sequence number will be used as nonce
instead).  I don't believe the AEAD mechanism works: there is no field
to put the MAC in it.

>>Some elements of the draft is still in flux.  For example,
>>initial performance benchmarks suggests HMAC-SHA256 was a poor choice
>>for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives.
>>Still, all comments are appreciated.
>
> If anything other than HMAC-SHA1 is used, that would underscore the value
> of defining an AEAD algorithm.   If the main motivation for this work is
> encryption that is computationally cheap, then it makes sense to pair the
> algorithm with an authentication method with the same characteristics.

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.

> For security considerations, I suggest citing the analysis of Salsa20, and
> adding a sentence or paragraph summarizing the best-known attacks.
> Something like "Salsa20 has been analyzed by X independent teams, and the
> best known attack breaks 8 of 20 rounds."

Good idea, the first paragraph of the security considerations is now:

   The security of Salsa20 is discussed in the Salsa20 security
   [SALSA20-SECURITY] paper.  The reader must consult cryptographic
   research to find out the current security status of Salsa20.  At the
   time of writing this document, there are no known significant
   security problems with Salsa20/12 or Salsa20/20.  As of early 2013,
   the best cryptanalysis breaks 8 out of 20 rounds to recover the 256-
   bit secret key in 2^251 operations, using 2^31 keystream pairs (see
   [SALSA20-ATTACK]).  For more background, see the eSTREAM report
   [ESTREAM].

/Simon