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

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 24 Jun 2016 13:08:09 +0000

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: [email-masked]
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.

---

From: Daniel Bleichenbacher <[email-masked]>
Date: Fri, 24 Jun 2016 15:17:25 +0200

> What is the probability of a sender (accidentally?)‎ generating a key that
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?

> *From: *Daniel Bleichenbacher
> *Sent: *Friday, June 24, 2016 07:35
> *To: [email-masked]
> *Subject: *[Cfrg] AES-GCM-SIV security of the additional data
> ‎
>
> 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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 24 Jun 2016 18:03:13 +0000

> On Fri, Jun 24, 2016 at 3:08 PM, Blumenthal, Uri - 0553 - MITLL
> <[email-masked]> wrote:
> 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.

If our threat model is malicious sender that may try to “disown” his message
or deliberately allow somebody else to modify it – that same malicious
sender could covertly share his key and claim that adversaries guessed it
(highly improbable but not impossible).

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

Probably not, if/when the sender deliberately makes it not so.

???

P.S. How easy is it to find such a key [that makes H = 0]?

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