On 9/10/13 2:42 PM, Ben Laurie wrote:
On 10 September 2013 18:00, zooko <zo...@zooko.com <mailto:zo...@zooko.com>> 
    Please ask your friendly neighborhood TLS implementor to move fast on
    http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt .

We prefer https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/.


Let's get behind this!  It does things a bit differently than I'd choose,
but fits the discussion we had a few months ago (on the companion list)
about the next algorithm to choose, and seems to fit the TLS paradigm.

I applaud moving the ICV outside the encryption.  Phil Karn and I were
advocates of this (for denial-of-service protection) going back long
before there were known theoretical attacks on inner protection.

   ChaCha20 is run with the given key and nonce and with the two counter
   words set to zero.  The first 32 bytes of the 64 byte output are
   saved to become the one-time key for Poly1305.  The remainder of the
   output is discarded.

Why generate the ICV key this way, instead of using a longer key blob
from TLS and dividing it?  Is there a related-key attack?

   Authenticated decryption is largely the reverse of the encryption
   process: the Poly1305 key is generated and the authentication tag
   calculated.  The calculated tag is compared against the final 16
   bytes of the authenticated ciphertext in constant time.  If they
   match, the remaining ciphertext is decrypted to produce the

If AEAD, aren't the ICV and cipher text generated in parallel?  So how do
you check the ICV first, then decipher?

Needs a bit more implementation details.  I assume there's an
implementation in the works.  (Always helps define things with
something concrete.)

The cryptography mailing list

Reply via email to