Re: [Cfrg] Task for the CFRG

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

I concur, and second the recommendation to use Chacha instead of Salsa.

TNX!
-- 
Regards, 
Uri Blumenthal                           Voice: [phone]




On 8/8/13 16:24 , "Ted Krovetz" <[e-mail]> wrote:

>
>> The TLS WG has asked the CFRG for their opinion for a stream cipher,
>>eSTREAM-SALSA20,
>> and two MAC algorithms, UMAC and POLY1305, that have been suggested for
>>use in TLS
>
>I am well familiar with all three. I edited the UMAC RFC, have been
>working with a Salsa variant called Chacha, and have used several
>polynomial hashes similar to Poly1305.
>
>I have no security concerns for any of the three. I do have a few
>comments.
>
>UMAC: Uses a large internal key (about 1KB), and complex code. UMAC has
>very high speed if key can be kept in cache. I suggested to the TLS
>mailing list VMAC as an alternative that uses less internal key and is of
>similar speed.
>
>Salsa20/12: The estream variant under consideration is the 12-round one.
>All the fastest Salsa implementations are SIMD, and Salsa's prolog and
>epilog are complicated under SIMD. Dan Bernstein recognized this and made
>a SIMD-friendly variant called Chacha. Chacha also made a couple rotation
>tweaks that improve speed and (Dan speculates) improves security. I wish
>everyone would forget about Salsa and replace it with Chacha.
>
>Poly1305: This is a standard polynomial evaluation hash with good
>security. As with UMAC and VMAC, it depends heavily on multiplication (in
>this case 128x128->256 bits followed by divisionless mod), making it
>expensive in hardware (same for UMAC and VMAC).
>
>If all the TLS group wants is our security assessment of Salsa, UMAC and
>Poly1305, we should give them a positive one. If we wish to give some
>advice as well, I'd recommend consideration of VMAC over UMAC and,
>especially, Chacha over Salsa.
>
>-Ted
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg