Re: [jose] FW: GCM nonce reuse question

[Vijay Bharadwaj <[e-mail]>]

I was reading the JWE draft today for different reasons, and came here to point out exactly this issue. It was not clear to me why there were multiple headers and integrity values.

Also, it seems to me the header in JWE is defined in a way that is suboptimal for the multiple recipient case. It mixes parameters related to the encryption of payload with CMK (of which you only need one) with parameters related to the encryption of the CMK with the recipient's key (of which you need one per encrypted key). Why not refactor these to look more like CMS? In other words:

Array of recipients, where each is: {alg: <alg>, <recipient identifier such as jwk>, <encrypted CMK>}
Header: <parameters related to compression and CMK encryption, including IV>
Ciphertext: <encoded ciphertext>
Integrity_value: <encoded authentication tag with recipients and header as AAD>

Putting the integrity check at the end reduces the amount of buffering in the implementation that produces the message.

Thoughts?

From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Thursday, March 28, 2013 7:54 PM
To: Mike Jones
Cc: Jim Schaad; [e-mail]; [e-mail]
Subject: Re: [jose] FW: GCM nonce reuse question

[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 <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Jim Schaad
Sent: Thursday, March 28, 2013 7:02 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [jose] FW: GCM nonce reuse question

For those people not on the CFRG list -

Jim


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

Hi Jim,

From: Jim Schaad <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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


_______________________________________________
jose mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jose