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

From: Martin Willi <[email-masked]>
Date: Wed, 01 Apr 2015 14:37:45 +0200

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?

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.

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.

Kind regards
Martin

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Apr 2015 17:50:02 +0300

> On Apr 1, 2015, at 3:37 PM, Martin Willi <[email-masked]> wrote:
> 
> Hi,
> 

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.

> 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.

> processing without operating on partial blocks.

I doubt it would produce a measurable difference in performance, but I agree.

Yoav