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

On Fri, Jun 24, 2016 at 3:53 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
wrote:

> Hi Antonio,
>
> On 24/06/2016 14:40, "Antonio Sanso" <asanso@adobe.com> wrote:
>
> >hi Kenny
> >
> >On Jun 24, 2016, at 3:24 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
> >wrote:
> >
> >>
> >> 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
> >
> >to me this seems a pretty common scenario.
> >If I am not completely wrong in my understanding is for example what JWE
> >does [0] and [1] for example
> >
> >regards
> >
> >antonio
> >
> >[0] https://tools.ietf.org/html/rfc7516#page-32
> >[1] https://tools.ietf.org/html/rfc7516#page-36
>
> Key transport via PKE using, for example RSA-OAEP, is a certainly an
> option in JWE. But what Daniel describes has an additional symmetric key
> ("S") for the purposes of authentication, I think, and does not strictly
> match anything I've seen in the JSON RFCs. But let's allow Daniel to
> answer on that one...
>
> Cheers
>
> Kenny
>

I'm not familiar with JWE so I can't comment on this protocol.
A typical scenario where S can't be used directly as key are low entropy
secrets
such as passwords.

One motivation for me  to look into this is the question whether AES-GCM-SIV
could be used as a drop-in replacement for AES-GCM without doing an
additional
security review of the resulting protocol.
So far, I'm not convinced that this can be done in all cases.

>
>
>
> >> . 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-int
> >>er
> >> im-2016-cfrg-1)
> >>
> >> Regards
> >>
> >> Kenny
> >>
> >>
> >> On 24/06/2016 12:35, "Cfrg on behalf of Daniel Bleichenbacher"
> >> <cfrg-bounces@irtf.org on behalf of bleichen@google.com> 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.
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg@irtf.org
> >> https://www.irtf.org/mailman/listinfo/cfrg
> >
>
>