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

["Blumenthal, Uri - 0553 - MITLL" <[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.

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


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