Subject: Re: [Cfrg] AES-GCM-SIV with a new key hierarchy

From: Dan Harkins <[email-masked]>
Date: Tue, 10 Jan 2017 16:22:23 -0800

Hello,

On 6/24/16 10:10 AM, Gueron, Shay wrote:
> Hello everyone,
>
> I start a new tread.
>
> It is a branch off the one entitled "AES-GCM-SIV security of the 
> additional data" and initiated by Daniel.
>
> It combine Kenny's inputs about having two separate keys and the AEADE 
> interface (which he raised at the CFRG meeting in
> Vienna in May and also mentioned, in the previous thread, that 
> concatenating 2 separate keys does not solve the problem that Daniel 
> raised).
>
> It also address a comment that Bart Preneel made at that CFRG meeting.
>
> ****
>
> It is possible to define AES-GCM-SIV with a standard interface that 
> has a single key (say, MK for "Master Key"), which can be 128 or 256 
> bits. Basically, by adding the following key derivation step:
>
>     Using MK, derive two new keys K and H: K for encryption and H for 
> authentication.
>     From that point on, apply AES-GCM-SIV as it is defined now, where 
> (K, H) are the keys.
>
> Note that K and H are derived statically from MK. The "record 
> encryption key" for the encryption depends on the nonce N, via another 
> derivation, as it is currently defined in AES-GCM-SIV.
>
> Note: the derivations are different for the 128 and the 256 bit keys, 
> but such derivations are already in use by AES-GCM-SIV.
> With this, AES-GM-SIV could be used with the protocol Daniel 
> described, and would address Kenny's comment on the AEAD interface.
> (I guess that it could be better viewed as a drop in replacement to 
> AES-GCM)
>
> The cost is the additional key derivation. this cost could be low if 
> the message is long, or if many messages are encrypted (so that K, H 
> can be cached).
>
> An alternative would be to incorporate the nonce from the beginning, 
> during the derivation of K, H from MK. This will modify the record 
> encryption key and also the hash key per each nonce. In that case the 
> extra derivation of the record encryption key (per nonce) could be 
> skipped (but also could be not done).
>
> I would appreciate any comments on this.

   Why not just have a single double-wide key the way AES-SIV (RFC 5297) 
does?
It's 256 bits or 512 bits. KDFs are good at generating streams of any 
length so
why not just let the KDF give you all that you need instead of doing 
additional
derivations inside?

   regards,

   Dan.

>
> Thanks, Shay
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Shay Gueron <[email-masked]>
Date: Thu, 12 Jan 2017 12:01:16 +0200

Hi Dan,

Thanks for your question.

In general, some KDF is needed, in order to increase the number of times
that the algorithm can be used with a given key. So, we start with a KDF
that has a master key and derives a new key(s)  per nonce.

The "cascade" method we use now is also some kind of a KDF, and there can
be others.

However, your timing with this question is fantastic. Indeed, we were not
satisfied with the serialized nature of the current KDF, and are working on
a different (better) one. This work is coming to an end, and we expect to
post the revision of AES-GCM-SIV next week.

Thanks, Shay

2017-01-10 16:22 GMT-08:00 Dan Harkins <[email-masked]>:

>> It is possible to define AES-GCM-SIV with a standard interface that has a
>> single key (say, MK for "Master Key"), which can be 128 or 256 bits.
>> Basically, by adding the following key derivation step:
>>
>>     From that point on, apply AES-GCM-SIV as it is defined now, where (K,
>> H) are the keys.
>>
>> Note that K and H are derived statically from MK. The "record encryption
>> key" for the encryption depends on the nonce N, via another derivation, as
>> it is currently defined in AES-GCM-SIV.
>>
>> Note: the derivations are different for the 128 and the 256 bit keys, but
>> such derivations are already in use by AES-GCM-SIV.
>> With this, AES-GM-SIV could be used with the protocol Daniel described,
>> and would address Kenny's comment on the AEAD interface.
>> The cost is the additional key derivation. this cost could be low if the
>> message is long, or if many messages are encrypted (so that K, H can be
>> cached).
>>
>> encryption key and also the hash key per each nonce. In that case the extra
>> derivation of the record encryption key (per nonce) could be skipped (but
>> also could be not done).
>>