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

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

What is the probability of a sender (accidentally?)‎ generating a key that results in H being 0? 

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.