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

["Paterson, Kenny" <[e-mail]>]

Hi Antonio,

On 24/06/2016 14:40, "Antonio Sanso" <[e-mail]> wrote:

>hi Kenny
>
>On Jun 24, 2016, at 3:24 PM, Paterson, Kenny <[e-mail]>
>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"
>> <[e-mail] on behalf of [e-mail]> 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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>