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

[Yoav Nir <[e-mail]>]

On Oct 7, 2014, at 1:35 AM, Dan Harkins <[e-mail]> wrote:

> 
> 
> On Mon, October 6, 2014 2:53 pm, Adam Langley wrote:
>> On Mon, Oct 6, 2014 at 2:50 PM, Yoav Nir <[e-mail]> wrote:
>>> I’m not quite sure I follow. The construction uses a 96-bit nonce
>>> precisely
>>> so that we comply with RFC 5116. What requirement of 5116 are we not
>>> fitting
>>> into?
>> 
>> I think Dan is just saying that the limits need to be specified. For
>> example see page 8 in
>> https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-5
>> (although these values are wrong now).
> 
>  I'm sorry, I meant the formation of the AAD. Is it a single blob that
> gets passed to the algorithm? Does the mode allow for multiple distinct
> AAD inputs ala RFC 5297? What if the protocol I want to use with this
> mode has several distinct blobs I want to use as AAD (like how IEEE Std
> 802.11 uses AAD with AEAD cipher modes-- take these bits and then
> concatenate these addresses, etc)? I suspect it's all just a single
> concatenated blob but it would help to say so explicitly and to define
> the RFC 5116 interface.

Oh, I see. OK. Our construction does not make any particular provisions for multiple blobs of AAD. Of course the application is free to create such a structure by making it a series of TV or TLV, or if they really want to be fancy, a BER-encoded SEQUENCE (please don’t), but the code for ChaCha20-Poly1305 does not recognize such a structure.

>  It obviously takes AAD since section 2.8 mentions it as something to
> include as input to AEAD_CHACHA20-POLY1305. So I'm suggesting you
> define what AAD looks like when it is delivered to the mode: "Distinct
> AAD shall be concatenated into a single input to
> AEAD_CHACHA20-POLY1305", for example.

OK. I’ll add a sentence like that.

Thanks,

Yoav