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

[Shay Gueron <[e-mail]>]

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 <[e-mail]>:

>
>   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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>