Re: [IPsec] ChaCha20/Poly1305 padding (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-01.txt)

[Yoav Nir <[e-mail]>]

> On Apr 1, 2015, at 3:37 PM, Martin Willi <[e-mail]> 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