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

Hello to Daniel (and all) –

This is a very interesting point, raised by Daniel.
It does not attack AES-GCM-SIV, but rather a particular (imaginary) way 
to (not) use it.
Daniel's demonstration shows that there exists a protocol that is safe 
(I guess) when using AES-GCM as a component, but not safe when 
(carelessly) using AES-GCM-SIV as this component. Indeed, so.

But, as Daniel indicated, it does not violate the promise of 
AES-GCM-SIV, and the simple answer is: don’t use protocols (certainly 
not made-up) without proper analysis.

To Kenny: it does not matter here if the there is a single key where a 
part of it are used for encryption, and another part for the 
authentication, or 2 separate keys. Because, the adversary controls this 
key (or the two keys) in the described scenario.

About the protocol: if there is already a shared secret (S), why not use 
it directly with AES-GCM-SIV (where different nonces, that yield 
different encryption keys), as Kenny has already indicated.

If someone insists on using such a hybrid protocol (why?), then how 
about this change in it: draw K1 and x uniformly at random, and define 
K1 as the encryption key, and K2 = ENC_S (x) as the authentication key. 
Then use AES-GCM-SIV with these keys and the mentioned protocol. This 
addresses the root cause for the protocol’s failure: now, the adversary 
does not control the authentication key and cannot force a “weak” (zero) 
one to be used.
[disclaimer: I have not analyzed the protocol in depth]
Thanks, Shay
------ Original Message ------
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "Antonio Sanso" <asanso@adobe.com>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Sent: 6/24/2016 4:53:46 PM
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data

>Hi Antonio,
>
>On 24/06/2016 14:40, "Antonio Sanso" <asanso@adobe.com> wrote:
>
>>hi Kenny
>>
>>On Jun 24, 2016, at 3:24 PM, Paterson, Kenny 
>><Kenny.Paterson@rhul.ac.uk>
>>wrote:
>>
>>>
>>>  In your scenario it looks like you are trying to use the shared 
>>>secret S
>>>  to provide authentication of the sender to the receiver, along with
>>>  confidentiality for the message being delivered
>>
>>to me this seems a pretty common scenario.
>>If I am not completely wrong in my understanding is for example what 
>>JWE
>>does [0] and [1] for example
>>
>>regards
>>
>>antonio
>>
>>[0] https://tools.ietf.org/html/rfc7516#page-32
>>[1] https://tools.ietf.org/html/rfc7516#page-36
>
>Key transport via PKE using, for example RSA-OAEP, is a certainly an
>option in JWE. But what Daniel describes has an additional symmetric 
>key
>("S") for the purposes of authentication, I think, and does not 
>strictly
>match anything I've seen in the JSON RFCs. But let's allow Daniel to
>answer on that one...
>
>Cheers
>
>Kenny
>
>>
>>>  . In this scenario, it's
>>>  not clear to me why the sender and receiver would not just use S as 
>>>an
>>>  AES-GCM-SIV key to transport a session key K, and then use K in 
>>>another
>>>  instance of AES-GCM-SIV to transport the desired messages. Of 
>>>course,
>>>this
>>>  construction would not prevent replay attacks; for that you'd need
>>>  additional mechanisms, like incorporating a counter into the AD of 
>>>the
>>>  key-transporting AEAD.
>>>
>>>  But perhaps one should not underestimate the ingenuity of 
>>>implementers
>>>in
>>>  wanting to use public key encryption. Is this where you are coming 
>>>from?
>>>
>>>  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 minutes of the meeting can be found here:
>>>
>>>https://www.ietf.org/proceedings/interim-2016-cfrg-01/minutes/minutes-int
>>>er
>>>  im-2016-cfrg-1)
>>>
>>>  Regards
>>>
>>>  Kenny
>>>
>>>
>>>  On 24/06/2016 12:35, "Cfrg on behalf of Daniel Bleichenbacher"
>>>  <cfrg-bounces@irtf.org on behalf of bleichen@google.com> wrote:
>>>
>>>>  I'm wondering what can or should be expected about the security of 
>>>>the
>>>>  additional data.
>>>>
>>>>
>>>>  In particular, I'm considering the following scenario:
>>>>
>>>>
>>>>  Sender and receiver share a secret S.
>>>>  The sender knows the public key of the receiver and the receiver of
>>>>  course knows the private key.
>>>>  They use a hybrid encryption as follows:
>>>>
>>>>
>>>>  The sender chooses a new AES-GCM-SIV key, encrypts his message
>>>>  and includes S as additional data. The AES-GCM-SIV key is wrapped 
>>>>with
>>>>  the receivers public key and the wrapped key and ciphertext are 
>>>>sent to
>>>>  the receiver.
>>>>
>>>>
>>>>  Here an attacker can use that AES-GCM-SIV allows to select a key 
>>>>such
>>>>  that the
>>>>  element H used for POLYVAL is 0. In this case it would not be 
>>>>necessary
>>>>  for the sender
>>>>  to know S to construct a ciphertext that validates.
>>>>  A similar attack using AES-GCM seems much harder since the value H 
>>>>for
>>>>  the GHASH
>>>>  is obtained by encrypting 0 and thus I'm not aware of a way to do 
>>>>the
>>>>  same thing here.
>>>>
>>>>
>>>>  The attack does of course not violate any of the guarantees 
>>>>claimed.
>>>>  However, in the industry lots of ad hoc protocols are designed 
>>>>without
>>>>  proper security reductions and hence it seems a bit scary to me to
>>>>allow
>>>>  this kind of "weak" keys. And since abuse resistance is
>>>>  one of the goals it might be a good idea to avoid such type of 
>>>>abuses.
>>>>
>>>>
>>>>
>>>
>>>  _______________________________________________
>>>  Cfrg mailing list
>>>  Cfrg@irtf.org
>>>  https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg