Re: [Cfrg] Acceptance call for draft-nir-cfrg-chacha20-poly1305-05.txt

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 26/06/2014 23:11, Alexey Melnikov wrote:

> CFRG chairs received a request to accept
> draft-nir-cfrg-chacha20-poly1305-05.txt as a RG document:

> http://datatracker.ietf.org/doc/draft-nir-cfrg-chacha20-poly1305/

> The document was discussed on the mailing list and chairs would
> like to know if there is enough interest to complete this document
> in CFRG.

+1 strong support!

I think this is a great AEAD - at least as good as AES-GCM, and easier
to make constant-time; IPR free; faster in software. I think it also
suits hardware/embedded implementations quite well.


For those of you (or me!) maybe reaching this in a search in years to
come: the ChaCha20-Poly1305 AEAD from the CFRG proposed here for
adoption differs from draft-agl-tls-chacha20poly1305-04 originally
proposed by Adam Langley & Wan-Teh Chang (which has now expired, as
it's being replaced with draft-mavrogiannopoulos-chacha-tls-02 which
uses the final AEAD construction being defined here).

Instead of the lengths directly following their ciphertexts:

  draft-agl-tls-chacha20poly1305-04:
  AAD | len_AAD | ciphertext | len_ciphertext

this final version of the AEAD pads the Additional Authenticated Data
(if any) and ciphertext to a 16-byte block boundary (using between
0-15 zero bytes) and moves the lengths to the end:

  draft-nir-cfrg-chacha20-poly1305 (the final AEAD specified here):
  AAD | padding1 | ciphertext | padding2 | len_AAD | len_ciphertext

which is more efficient to implement (block-aligned, and the recipient
knows the lengths are at the end, instead of having to jump backwards
to find len_AAD). Thanks to Niels Moeller for that idea.


It's also different to the AEAD used in [e-mail],
by the way, which uses different Poly1305 padding and tries to encrypt
the length using a second stream cipher instance (but doesn't do
anything else to conceal the length at present).

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTsDF3AAoJEOyEjtkWi2t6XR4QAKcK9m2irYm4EEBYS3bctbfP
KQyPt+2OGmIbeOz5HBfyKtHzDPYYG/pNuzuGvKWFUDgigB2nAEFgIM1aausPDdCG
xdgnfWrkXxesZN6tGLYhcrzS6fZ1gLLf+7JybNSLIdPZFZsT/HhtL9bTPDI/FkVc
EfkCwVGNT7Xj45QFlWUodDUpDm3xFFtDKU7MUYlwWXeAC6E7vJ/jNGpc8uXlvgC6
z0q0etdA/GKwNQly/FIqLR3kOXhgIoFgEAK240qvD/IFiorRkNZWJuo59qB44AY9
f2tQE2YzxTdC6hZ5cHkewL2r0h032x+7nUJ1v6AAoHyA0EgUOLzFbQujN8FjzSQz
xRBo9TgX2jptWaAa/KppfselSF82mLsoiuzaSZBF/RiIpW0rrNXkJGD0EcRrLkfk
3icX1bH0Rmi4gDg6Xvonpbu4PL35yXpQV6j1axxUYybhyVG+PqbqHRhLGaE/2Kvh
gzH9xsvUbSGZMyRoPLKZd1cg8iUSFazIrlz+WDRMI0aUtOi/Sbv52Yoa4Rdu1tN6
pKa8iabBYK9023Kxpe3/xo6OC7k27dO+9KkTO+ggcx9Q6aq0kBjI56n/jIvIbIfj
q+S1i5gD4XMA+UslYLm+oP0g0CxHXMl78zICOcUZxczfrQIjytay8jJbrs7Lu4ew
A2j0MipSrD8Kdfgnk38W
=CUNx
-----END PGP SIGNATURE-----