Re: [TLS] Consensus for AEAD IV

[Yoav Nir <[e-mail]>]

Both CCM and GCM use a concatenation of the explicit IV (which is obviously not secret and allowed to be predictable) with a salt that is derived from the keying material. This concatenation forms the nonce which is input to the AEAD.

RFC 4309 (CCM) says "The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.”
RFC 4106 (GCM) says "The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret.”

The ChaCha20-Poly1305 for IPsec draft does the same thing, and in fact so does RFC 5288 (AES-GCM for TLS 1.2)

So no, that salt (and by extension, the proposed 96-bit value) need not be secret, but it’s never transmitted. This also shows that there is good precedent for generating such a doesn’t-really-need-to-be-secret value from the key_block or KEYMAT.

Yoav

> On Apr 27, 2015, at 12:28 AM, Michael StJohns <[e-mail]> wrote:
> 
> On 4/26/2015 2:20 PM, Ilari Liusvaara wrote:
>>> There is no reason to treat the 96 bit quantity as secret and no one else
>>> >does.
>> (To lesser extent, IPSEC, there the session nonce is 32 bits and secret).
>> 
> 
> This is directly from section 2.3 of the IPSec ESP RFC 4303
> 
> 
>> With regard to ensuring the alignment of the (real) ciphertext in the
>>    presence of an IV, note the following:
>> 
>>          o For some IV-based modes of operation, the receiver treats
>>            the IV as the start of the ciphertext, feeding it into the
>>            algorithm directly.  In these modes, alignment of the start
>>            of the (real) ciphertext is not an issue at the receiver.
>> 
>> 
>>          o In some cases, the receiver reads the IV in separately from
>>            the ciphertext.  In these cases, the algorithm specification
>>            MUST address how alignment of the (real) ciphertext is to be
>>            achieved.
> 
> And RFC4309 - CCM mode has this:
> 
>> ESP Payload
>> 
>>   The ESP payload is composed of the IV followed by the ciphertext.
>>   The payload field, as defined in [ESP], is structured as shown in
>>   Figure 1.
>> 
>>       0                   1                   2 3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                     Initialization Vector                     |
>>      |                            (8 octets)                         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                                                               |
>>      ~                  Encrypted Payload (variable)                 ~
>> |                                                               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                                                               |
>>      ~                 Authentication Data (variable)                ~
>> |                                                               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> Again, newer modes may have done something else, but the above is strong indication that IVs were not generated as secrets as a general matter.
> 
> Later, Mike
>