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

[Antonio Sanso <[e-mail]>]

hi Kenny

On Jun 24, 2016, at 3:24 PM, Paterson, Kenny <[e-mail]> wrote:

> Hi Daniel,
> 
> Thanks for your message.
> 
> The usual expectation in AEAD is that the AD is integrity protected, but
> there's no assurance as to its confidentiality. It's not usually
> considered part of the ciphertext, but might be included along with it in
> a message being sent to a receiver, or might be reconstructed from other
> data/context by the receiver.
> 
> 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

> . 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-inter
> 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