Re: [Cfrg] AES-GCM-SIV security of the additional data

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

I would like to clarify a point.

The API is a technical matter, so K1||K2 are K1, K2 are the same - from 
the logical viewpoint. The interface can use a single 32/48 bytes key, 
and this is how the draft is stated. This separation seemed to us as a 
*advantage* of the design, and this is what I tried to communicate in 
Vienna. I guess the confusion is due to my explanation... and hope it is 
clarified here.

With both interfaces, the property is that the authentication key is 
independent of the encryption key, and both are a direct input (unlike 
AES-GCM that derives the authentication key from a single input key).

Daniel's example showed that here exists a (flawed/artificial) protocol 
that would not work when using AES-GCM-SIV, but would be OK with 
AES-GCM.
It is not a problem of AES-GCM-SIV, which is designed as an AEAD scheme 
for the standard usage, and also, the protocol does not make much sense 
(to me, at least). Still, it is a very interesting observation.

The difference stems exactly from using 2 independent keys with 
AES-GCM-SIV, while using a single key with AES-GCM, and deriving H from 
it (by a one way function). It is the same for other AEAD schemes that 
use independent encryption and hash keys, where there are some "weak" 
hash keys (e.g., 0). This property affects any protocol that benefits a 
malicious sender (who could choose a bad hash key).

Should this needs to be addressed? I am not sure. A malicious sender is 
not part of the AEAD threat model.

But in any case, it could be addressed if AES-GCM-SIV used a single key 
(MK) and derived K1 and K2 from MK (and possibly the nonce). I raised 
this point in another thread.

Thanks, Shay

------ Original Message ------
From: "Paterson, Kenny" <[e-mail]>
To: "Adam Langley" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 6/25/2016 11:40:51 AM
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data

>Hi Adam,
>
>Thanks for the clarification. My remarks were based on the scheme as 
>presented by Shay at Vienna; there, he introduced the misconception 
>that two separate keys were involved; he did not clarify this during 
>questioning (see the minutes).
>
>Of course the draft is definitive document and it's good that it 
>presents the normal API.
>
>Cheers,
>
>Kenny
>
>Sent from my iPhone
>
>>  On 25 Jun 2016, at 02:43, Adam Langley <[e-mail]> 
>>wrote:
>>
>>  On Fri, Jun 24, 2016 at 6:24 AM, Paterson, Kenny
>>  <[e-mail]> wrote:
>>>  On a related point, my view is that it is a disbenefit that the
>>>  AES-GCM-SIV proposal has two separate keys (one for encryption, the 
>>>other
>>>  for authentication) as inputs. That's not the AEAD interface that we 
>>>have
>>>  raised our implementers on. I raised this point at the CFRG meeting 
>>>in
>>>  Vienna back in May. Simply concatenating the two keys in the current
>>>  proposal into one would address this issue, but not the one you 
>>>raise (if
>>>  I understand it correctly).
>>
>>  The two keys are already concatenated in the draft, or else I
>>  misunderstood your point:
>>  https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01#section-6
>>
>>  "Since the definition of an AEAD requires that the key be a single
>>  value we define AEAD_AES_128_GCM_SIV to take a 32-byte key: the first
>>  16 bytes of which are used as the authentication key and the 
>>remaining
>>  16 bytes are used as the AES key. Likewise AEAD_AES_256_GCM_SIV takes
>>  an 48-byte key: the first 16 bytes are again the authentication key
>>  and the remaining 32 bytes is the AES key."
>>
>>
>>  Cheers
>>
>>  AGL
>>
>>  --
>>  Adam Langley [e-mail] https://www.imperialviolet.org
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg