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

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

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