> On Apr 1, 2015, at 3:37 PM, Martin Willi <mar...@strongswan.org> wrote: > > Hi, > > In Section 2, draft-ietf-ipsecme-chacha20-poly1305-01 has the following > text: > >> o Finally, the Poly1305 function is run on the data to be >> authenticated, which is, as specified in section 2.7 of >> [chacha_poly] a concatenation of the following in the below order: >> >> * The Authenticated Additional Data (AAD) - see Section 2.1. >> * The AAD length in bytes as a 32-bit network order quantity. >> * The ciphertext >> * The length of the ciphertext as a 32-bit network order >> quantity. > > First, I assume [chacha_poly] should be updated to > draft-irtf-cfrg-chacha20-poly1305, where section 2.7 is now 2.8?
Right you are. Thanks. I’ve fixed it in my local storage. draft-irtf-cfrg-chacha20-poly1305 is now in the RFC editor’s queue. In a few weeks it will be published as an RFC, and then I will update the reference. > draft-irtf-cfrg-chacha20-poly1305-10 2.8 defines AEAD construction for > Poly1305 with padding and a final block with two 64-bit little endian > length fields; in contrary to what is defined here. Oh, right. That justifies a new revision immediately. The question is whether I should just delete the bullet points, leaving only the reference to the CFRG document, or fix it here. > The GCM-like padding is certainly preferable, as it allows > implementations to run four Poly1305 iterations on each ChaCha20 block. > This is not only simpler, but allows parallel ChaCha20/Poly1305 > processing without operating on partial blocks. I doubt it would produce a measurable difference in performance, but I agree. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
