On 9/10/13 2:42 PM, Ben Laurie wrote:
On 10 September 2013 18:00, zooko <zo...@zooko.com <mailto:zo...@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.)
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
