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

[Daniel Bleichenbacher <[e-mail]>]

On Fri, Jun 24, 2016 at 3:08 PM, Blumenthal, Uri - 0553 - MITLL <
[e-mail]> wrote:

> What is the probability of a sender (accidentally?)‎ generating a key that
> results in H being 0?
>
>
Random key generation is not my concern. My concern is a sender choosing a
key on purpose in such a way that
he does not have to authenticate additional data. The typical assumption is
that if an integrity check passes
then the sender is aware of the plaintext. Should this also be the case for
the additional data?


> Should a protocol check the H value and refuse to proceed (request
> re-generation) if H is 0?
>
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Daniel Bleichenbacher
> *Sent: *Friday, June 24, 2016 07:35
> *To: *[e-mail]
> *Subject: *[Cfrg] AES-GCM-SIV security of the additional data
> ‎
>
> 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.
>
>
>