Re: [TLS] ChaCha and IVs

[Robert Cragie <[e-mail]>]

This seems to be a non-issue to me. In SP 800-38D section 8.2.1, the 
deterministic construction is described using an IV with an invocation 
field. If the invocation field is specified as an integer counter, it 
will, by definition, increment by one every time the AES-GCM encrypt 
function is invoked for a particular key. Maybe I missed it, but I 
didn't notice the requirement that the invocation field starts at a 
random starting point? Therefore, this could start at 0 on provision of 
a new key and also be the basis of the sequence number. If there is 
insistence that this is generated within a cryptographic module for 
validation purposes, in the TLS case, the module would use the 
deterministic construction with the invocation field as an integer 
counter and export the invocation field to form the TLS sequence number. 
In this way, there would be no need to have to supply any additional 
code as part of the validation.

Robert

On 05/03/2014 1:47 PM, Dr Stephen Henson wrote:
> On 05/03/2014 13:28, Alyssa Rowan wrote:
>> Random IVs risk collision earlier, burn valuable entropy faster, and are
>> far more fragile.
>>
>> Sequential IVs are deterministic, verifiable, debuggable, and implicit.
>>
>> It is crystal-clear to me that sequential IVs are the correct approach. I
>> would be interested to hear NIST's reasons for recommending otherwise.
>>
> In the case of AES-GCM the relevant FIPS specifications *do* permit sequential
> IVs. One permitted construction is a random starting point generated within
> the module which is then incremented on each invocation.
>
> That "random starting point" requirement means you can't use the sequence
> number directly though.
>
> One way round that would be to have a way to specify the starting point. An
> explicit IV in the first record for example, but that looks messy to me.
>
> Steve.