Re: [Cfrg] GCM nonce reuse question

Without having done any real analysis, I think that your conclusion is correct, i.e., that IV re-use in draft-mcgrew-aead-aes-cbc-hmac-sha2 is similar to IV re-use in CBC.

However, I'm not sure what good that information is.  JOSE still has to support GCM.

--Richard

On Apr 2, 2013, at 11:00 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> 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:ve7jtb@ve7jtb.com] 
> Sent: Tuesday, April 02, 2013 7:41 AM
> To: David McGrew (mcgrew)
> Cc: Mike Jones; Jim Schaad; cfrg@irtf.org
> 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)" <mcgrew@cisco.com> wrote:
> 
> 
> Hi Mike,
>  
> From: Mike Jones <Michael.Jones@microsoft.com>
> Date: Monday, April 1, 2013 8:54 PM
> To: David McGrew <mcgrew@cisco.com>, Jim Schaad <jimsch@augustcellars.com>
> Cc: "cfrg@irtf.org" <cfrg@irtf.org>, John Bradley <ve7jtb@ve7jtb.com>
> 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: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
> Sent: Thursday, March 28, 2013 4:15 AM
> To: Jim Schaad
> Cc: cfrg@irtf.org
> Subject: Re: [Cfrg] GCM nonce reuse question
>  
> Hi Jim,
>  
> From: Jim Schaad <jimsch@augustcellars.com>
> Date: Wednesday, March 27, 2013 6:43 PM
> To: David McGrew <mcgrew@cisco.com>
> Cc: "cfrg@irtf.org" <cfrg@irtf.org>
> 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
>  
>  
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg