Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt

[Yoav Nir <[e-mail]>]

On Oct 13, 2014, at 3:24 PM, Ilari Liusvaara <[e-mail]> wrote:

> On Mon, Oct 13, 2014 at 02:32:23PM +0300, Yoav Nir wrote:
>> 
>> Hi.
>> 
>> I haven’t submitted anything yet, but I’ve made a few changes to
>> my local copy:
>> I’ve added the AEAD parameters from RFC 5116.
> 
> - Isn't K_LEN = 32, not 16?

Argh, shouldn’t write drafts after midnight.

> - Isn't A_MAX = 2^64 - 1, not 2^64?

Yes, see above. Fixed in my copy and Google docs.

> - AFAIK, RFC5116 requries returning the ciphertext and tag as single
>  octet string (most likely concatenation).

   An AEAD algorithm MAY structure its ciphertext output in any way; for
   example, the ciphertext can incorporate an authentication tag.

Following that, I calculated C_MAX to be P_MAX + 16.

> - RFC5116 requires specifying relation between plaintext and
>  ciphertext lengths (most likely |C|=|P|+16).

Yes.

> - RFC5116 recomends specifying just how badly things blow up
>  if nonce is reused (AFAIK, XOR of plaintexts is revealed and
>  arbitrary messages with that nonce may be forged).

Same authentication key and same keystream, so at least the XOR of the plaintexts is revealed and the same one-time Poly1305 is used. So if you know the plaintext and can choose the nonce, you will be able to encrypt another arbitrary message, but you will still fail tag calculation. I’ll add something to the security considerations.

> Also, writing IANA consideration to register this
> (AEAD_CHACHA20_POLY1305?) could be useful (as already suggested by
> someone). Apparently the registry is called "AEAD algorithms" (at
> least it is that way on IANA site, even if I can't find that in
> RFC 5116). 

Will do.

Yoav