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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

I don't think I understand this entire thread, starting with the perceived threat.

What sense does it make to ‎pass something confidential as Authenticated (but NOT encrypted) Data? What sense does it make for the sender to deliberately send Authenticated Data that cannot be authenticated (especially within symmetric encryption setting, where non-repudiation doesn't apply anyway)? Etc.

Regardless, the latest proposal by Shay seems to eliminate this threat, however artificial it may be.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Jim Schaad
Sent: Friday, June 24, 2016 17:40
To: 'Daniel Bleichenbacher'; 'Paterson, Kenny'
Cc: [e-mail]
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data

 
 
From: Cfrg [mailto:[e-mail]] On Behalf Of Daniel Bleichenbacher
Sent: Friday, June 24, 2016 7:15 AM
To: Paterson, Kenny <[e-mail]>
Cc: [e-mail]
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data
 
 
 
On Fri, Jun 24, 2016 at 3:53 PM, Paterson, Kenny <[e-mail]> wrote:
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
 
I'm not familiar with JWE so I can't comment on this protocol.
A typical scenario where S can't be used directly as key are low entropy secrets
such as passwords.
 
One motivation for me  to look into this is the question whether AES-GCM-SIV
could be used as a drop-in replacement for AES-GCM without doing an additional
security review of the resulting protocol.
So far, I'm not convinced that this can be done in all cases.
 
[JLS] This is probably not a good example for doing this.  I would agree that having separate keys for this is not a good way to approach this situation.  Just not having AD is a better way even if you have to generate the key.
 
JWE is a poor example of this because it is difficult to generate situations where there is not additional data generated by JWE itself for encrypting the content.  Also, if one is interested in doing a degree of origination one would either directly generate the key, in which case generating the authentication key would be part of the process or one would want to use the value in the KDF step rather than having an indirection involved.  Doing the indirection almost guarantees that you need to have additional steps in the process to guarantee that origination is going to be part of the process.
 
Jim
 
 
 
>
>> . 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
>