Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02

From: [email-masked] (Niels Möller)
Date: Fri, 06 Feb 2015 15:10:51 +0100

Adam Langley <[email-masked]> writes:

> On Thu, May 8, 2014 at 12:32 AM, Niels Möller <[email-masked]> wrote:
>> Is this something you'd want to address? After all, high performance is
>> one of the primary design goals for both chacha and poly1305. The easiest
>> way I see is to change the formatting for authentication to
>>
>>   ad | pad1 | cryptotext | pad2 | length(ad) | length(cryptotext)
>
> I think this might be a good idea, thanks!

I've now updated my implementation to match
draft-irtf-cfrg-chacha20-poly1305-08
(https://git.lysator.liu.se/nettle/nettle/blob/master/chacha-poly1305.c).
I have a couple of comments on the testcases.

In section 2.4.2, the test vector for the chacha20 cipher, I think it
would be good to have an example with initial counter = 0. I think
that's going to be the typical case when using chacha as cipher only.

In section 2.8.2, the nonce is given in two pieces, an "IV" and a
"32-bit fixed common part". It's not crystal clear how to put then
together. Please also write out the complete 12-byte nonce explicitly.

For naming, I think it would be more consistent with the (admittedly
confused) terminology used in the literature to consistently write
"chacha", not "chacha20", and "salsa20", not "salsa".

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Adam Langley <[email-masked]>
Date: Fri, 6 Feb 2015 10:15:21 -0800

> I have a couple of comments on the testcases.

+Yoav, so that he sees this, as he's doing the editing work on this
draft in practice.

> that's going to be the typical case when using chacha as cipher only.

The draft defines an AEAD so I think it's ok that the examples are
focused on that.

> together. Please also write out the complete 12-byte nonce explicitly.

It does seem that this section might be a little IPSec focused. The
nonce is called an nonce elsewhere in the draft, but is given as an
"IV" and "fixed-common part" here, but those terms are never used
elsewhere. Possibly they should be merged and called an nonce,
although I'm sure that Yoav will decide what's best here.

> "chacha", not "chacha20", and "salsa20", not "salsa".

ChaCha is the family and ChaCha20 is an instance with a specific
number of rounds. I think the two names are ok, although I do think
there's a little confusion at the beginning of section 2.3 where it
might be worth mentioning that the the ChaCha20 block function is
specifically the ChaCha block function with 20 rounds.

Cheers

AGL

---

From: [email-masked] (Niels Möller)
Date: Fri, 06 Feb 2015 20:49:38 +0100

> The draft defines an AEAD so I think it's ok that the examples are

Now I see that there are additional test vectors in appendix A.2, that's
nice, sorry I missed that initially. But I think it would be valuable to
add a test vector with a non-zero nonce, say 01 02 03 04 05 06 07 08 09
0a 0b 0c, a non-zero key, and a zero initial counter, and two blocks of
data. That should test for most of the formatting pitfalls with a single
test-case for the most basic encryption interface, without
random-access-features.

> although I'm sure that Yoav will decide what's best here.

I think that division can also be found in RFC 5116, but I think it's
important that it's crystal clear what the inputs are. It's fine to list
both the pieces and the combined 12-byte nonce, if you think the
division is important.

Regards,
/Niels