[Cryptography] Evaluating draft-agl-tls-chacha20poly1305

[William Allen Simpson]

On 9/10/13 2:42 PM, Ben Laurie wrote:
> On 10 September 2013 18:00, zooko <zooko at zooko.com <mailto:zooko at zooko.com>> wrote:
>     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/.
>
Hooray!

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

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