On Tue, Jan 21, 2014 at 9:45 AM, Niels Möller nisse@lysator.liu.se wrote:
Would make sense, once the spec is stable. Comment on aead-interfaces in
general is appreciated. Maybe RFC5116 is useful guidance,
[0]. http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04
Thanks for the pointer. Are you (or anyone else on this list) involved in this ietf process? On which ietf list is it discussed?
The IETF WG chairs plan to forward that. Whether the final version will be the same is unknown, but I find it highly unlikely to change.
After a quick reading, the following jumps out at me (in Sec. 5):
The reason for generating the Poly1305 key like this rather than using key material from the handshake is that handshake key material is per-session, but for a polynomial MAC, a unique, secret key is needed per-record. As far as I understand, you can use the same poly1305 key for a large number of records/messages, as long as you have a unique nonce for each message.
Indeed, the reason (I presume) for this construction is to avoid a "flaw" in polynomial MACs. The "flaw" is that if you use a constant key per session, once an attacker manages to make few forgeries he can recover the key. This construction by re-keying poly1305 on each record avoids that issue.
Am I missing something? I guess Adam Langley usually knows what he's doing. But otherwise, the paragraph in the draft, and the awkward method it describes, makes absolutely no sense to me.
That construction (or at least a very similar one) is described by Bernstein in "Cryptography in NaCl".
regards, Nikos