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

["Gueron, Shay" <[e-mail]>]

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.

Thanks, Shay