Re: [Cfrg] GCM nonce reuse question

[Mike Jones <[e-mail]>]

Actually, I was about to ask a similar question.  It's actually my assumption that it likely OK to perform multiple draft-mcgrew-aead-aes-cbc-hmac-sha2 operations where the Plaintext, Initialization Vector, and Key inputs are constant and the Additional Associated Data varies.  My reasoning is as follows...

The Authentication Tag outputs are the result of HMAC-SHA-2 operations over a combination of the AAD and Ciphertext using the HMAC Key.  For there to be a problem with the above, there would have to be a problem with using the same HMAC key on multiple distinct inputs.  But for there to be a problem with using the same HMAC key on multiple distinct inputs, I believe that effectively rests on whether there's a problem using the underlying hash function on multiple inputs.  Which if true, would mean that the cryptographic hash function doesn't have the desired cryptographic properties in the first place.

I'll readily admit that there could easily be a flaw in my chain of logic.  But on the surface of it, it seems like draft-mcgrew-aead-aes-cbc-hmac-sha2 operations should be OK in the multiple recipients case in a way that GCM isn't.

Thoughts?

                                                            -- Mike

From: John Bradley [mailto:[e-mail]]
Sent: Tuesday, April 02, 2013 7:41 AM
To: David McGrew (mcgrew)
Cc: Mike Jones; Jim Schaad; [e-mail]
Subject: Re: GCM nonce reuse question

David,

For draft-mcgrew-aead-aes-cbc-hmac-sha2 is the issue the same for using the same MAC_KEY, ENC_KEY  , IV  and plaintext with different AEAD.

I am guessing no good can come of that, but is it a known problem?

The other question is if doing the same thing but making the MAC_KEY different, while keeping the same ENC_KEY  for each AEAD avoids the problem?

The question comes up when trying to use encryption to multiple recipients where you are trying to use the same IV and ENC_KEY but allow for integrity protecting the algorithm identifier and other data that may be different for each recipient.

I expect that the simple solution of not integrity protecting the algorithm and key_id for the key wrapping and allowing RSA-OAEP to be replaced with RSA1_5 or other alg substitution attacks is no longer a recommended practice.

Perhaps using the AEAD to integrity protect the envelope information is something that only really works in the single recipient case, and some other method is needed for multiple recipients.

Thanks
John B.

On 2013-04-02, at 10:32 AM, "David McGrew (mcgrew)" <[e-mail]<mailto:[e-mail]>> wrote:


Hi Mike,

From: Mike Jones <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 1, 2013 8:54 PM
To: David McGrew <[e-mail]<mailto:[e-mail]>>, Jim Schaad <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, John Bradley <[e-mail]<mailto:[e-mail]>>
Subject: RE: GCM nonce reuse question

Hi David,

In reading this thread and http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it's OK, however if the usage is:

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

where nonce #1 and nonce #2 are guaranteed to be distinct?  Am I reading things correctly in that regard?

Yes, that looks good.

David


                                                                Thanks,
                                                                -- Mike

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of David McGrew (mcgrew)
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Cfrg] 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