Subject: [jose] FW: GCM nonce reuse question

From: "Jim Schaad" <[email-masked]>
Date: Thu, 28 Mar 2013 19:01:58 -0700

For those people not on the CFRG list -

Jim

From: David McGrew (mcgrew) [mailto:[email-masked]] 
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: GCM nonce reuse question

Hi Jim,

From: Jim Schaad <[email-masked]>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: GCM nonce reuse question

David,

In doing a write up I became worried about a security property of the GCM
encryption mode in the way that the JOSE group is currently using it.

There are known problems with not having a unique set of values for IVs and
Key pairings.  Do these problems apply to having a different set of
auxiliary data as well as the plain text?

Yes.  The security issues are summarized in
http://tools.ietf.org/html/rfc5116#section-5.1.1  but apparently they are
not described generally enough.   They should read "plaintext or associated
data values".

Specifically the current way that GCM mode is being used in JOSE is

Recipient #1 authentication tag = GCM(Key, Recipient #1 data, nonce, plain
text)

Recipient #2 authentication tag = GCM(Key, Recipient #2 data, nonce, plain
text)

As the key, nonce and plain text are fixed it would produce the same
encrypted text value but different authentication tags.

Can't do that.   Each invocation of the encryption operation needs a
distinct nonce, unless all of the encryption operation inputs are identical.

Many thanks for calling this out, Jim.

David

Jim

---

From: Mike Jones <[email-masked]>
Date: Fri, 29 Mar 2013 02:05:25 +0000

I'll plan to add text to the GCM section of JWA during the current round of edits pointing this out.  David McGrew was also going to get me some text about constraints on GCM initialization vector values.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, March 28, 2013 7:02 PM
To: [email-masked]
Subject: [jose] FW: GCM nonce reuse question

Jim

From: David McGrew (mcgrew) [mailto:[email-masked]]
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: GCM nonce reuse question

Hi Jim,

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: GCM nonce reuse question

David,

In doing a write up I became worried about a security property of the GCM encryption mode in the way that the JOSE group is currently using it.

There are known problems with not having a unique set of values for IVs and Key pairings.  Do these problems apply to having a different set of auxiliary data as well as the plain text?

Yes.  The security issues are summarized in http://tools.ietf.org/html/rfc5116#section-5.1.1  but apparently they are not described generally enough.   They should read "plaintext or associated data values".

Recipient #1 authentication tag = GCM(Key, Recipient #1 data, nonce, plain text)
Recipient #2 authentication tag = GCM(Key, Recipient #2 data, nonce, plain text)

As the key, nonce and plain text are fixed it would produce the same encrypted text value but different authentication tags.

Can't do that.   Each invocation of the encryption operation needs a distinct nonce, unless all of the encryption operation inputs are identical.

David

Jim

---

From: Mike Jones <[email-masked]>
Date: Fri, 29 Mar 2013 02:06:44 +0000

-- Mike

Jim

Hi Jim,

David,

David

Jim

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Mar 2013 22:54:24 -0400

[trimmed CFRG, since we're talking about JOSE now]

Out of curiosity, what text are you planning to add?

As I read David's response, he is saying that GCM is unusable with multiple
recipients, because multiple header values are fed into GCM with the same
nonce.

Outlawing GCM is not an acceptable outcome.

Instead, we should fix the underlying issue.  Namely, we should make the
header value the same for all recipients.  Or, even better, remove the
header from the AAD field.

Imagine a world in which the JOSE header is not input as AAD to GCM (i.e.,
it receives no integrity protection).  Instead, we provide an actual "AAD
field" that contains the value for that field in the AEAD computation:

OLD: header.key.iv.ciphertext.mac
NEW: header.key.iv.aad.ciphertext.mac

That world is simpler to write code for (since you don't have to keep the
encoded header around), supports more applications (since you can actually
use the AAD field), and the problems with GCM do not exist.  Let's create
that world!

--Richard

On Thu, Mar 28, 2013 at 10:06 PM, Mike Jones <[email-masked]>wrote:

>  I’ll plan to add text to the GCM section of JWA during the current round
> of edits pointing this out.  David McGrew was also going to get me some
> text about constraints on GCM initialization vector values.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Jim Schaad
> *Sent:* Thursday, March 28, 2013 7:02 PM
> *To:* [email-masked]
> *Subject:* [jose] FW: GCM nonce reuse question****
>
> ** **
>
> For those people not on the CFRG list –****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* David McGrew (mcgrew) [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Thursday, March 28, 2013 4:15 AM
> *To:* Jim Schaad
> *Cc:* [email-masked]
> *Subject:* Re: GCM nonce reuse question****
>
> ** **
>
> Hi Jim,****
>
> ** **
>
> *From: *Jim Schaad <[email-masked]>
> *Date: *Wednesday, March 27, 2013 6:43 PM
> *To: *David McGrew <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *GCM nonce reuse question****
>
> ** **
>
>  David,****
>
>  ****
>
> encryption mode in the way that the JOSE group is currently using it.****
>
>  ****
>
> There are known problems with not having a unique set of values for IVs
> and Key pairings.  Do these problems apply to having a different set of
> auxiliary data as well as the plain text?****
>
>  ****
>
>  ** **
>
> data values".****
> ** **
>  Specifically the current way that GCM mode is being used in JOSE is****
>
>  ****
>
> text)****
> text)****
>  ****
> encrypted text value but different authentication tags.****
>
>  ****
>
>  ** **
>
> ****
> ** **
> Many thanks for calling this out, Jim.****
>
> ** **
>
> David****
>
> ** **
>
>  Jim****
>
>  ****
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>