Re: [Cfrg] Salsa20 stream cipher in TLS

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

Hi Simon,

On 3/18/13 4:42 PM, "Simon Josefsson" <[e-mail]> wrote:

>"David McGrew (mcgrew)" <[e-mail]> writes:
>
>> Hi Simon,
>
>Hi David.  Thanks for quick review.

Thanks for the quick response, more inline:

>
>> 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.

I'm not sure what you mean about the lack of a MAC field.  It would not be
hard to define an AEAD algorithm based on Salsa20; I would be surprised if
there is not a submission to CAESAR using that cipher.  And using the AEAD
in TLSv1.2 is straightforward.   (Is the issue a desire to use Salsa20 in
older versions?)

>
>>>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].

Looks good.

David

>
>/Simon