Re: [Cfrg] GCM nonce reuse question

[Richard Barnes <[e-mail]>]

The countermeasure you mention is for timing attacks in general against PKCS#1 v1.5.  It doesn't have anything to do with integrity protection of the header.

The hunt for a concrete security benefit continues...

--Richard



On Apr 2, 2013, at 3:57 PM, John Bradley <[e-mail]> wrote:

> Richard,
> 
> The integrity check of the header is effective if as mentioned in the subsequent message in that thread http://www.ietf.org/mail-archive/web/jose/current/msg01909.html you implement the counter measure 
> recommended for  RSA1_5  in https://tools.ietf.org/rfc/rfc3218.txt  continuing with a random CMK will cause the integrity check to fail and stop the oracle.
> 
> Richard is correct that there are two views on this, one where integrity protecting the envelope is good security and prevents against some known and perhaps unknown attacks (harder to prove), and others who see multiple recipients of the same encrypted body as a more important use case than the integrity protection.
> 
> Some of us are trying to find a way to accommodate both. 
> 
> The opinion of the CFRG on the value or non-value of integrity protecting the envelope information might be informative, though I think the last time we tried that the recommendation was for integrity protection, though at the time the trade off wasn't as clear.
> 
> Regards
> John B.
> 
> On 2013-04-02, at 4:05 PM, Richard Barnes <[e-mail]> wrote:
> 
>> John,
>> 
>> I don't think you've really answered Russ's question.  You've provided a *historical* reason, but not a *technical* reason why JOSE doesn't follow the same approach as CMS.
>> 
>> 
>> On Apr 2, 2013, at 1:59 PM, John Bradley <[e-mail]> wrote:
>> 
>>> Russ,
>>> 
>>> We are close to those approaches.  However nether of those address using the Additional Authenticated Data(AAD).  They mention that it exists as an input but nothing more.
>>> 
>>> A difference between JOSE and CMS is that CMS allows non AEAD block ciphers, where JOSE requires all block cyphers to be AEAD.
>> 
>>> That in theory allows us to use the AAD to integrity protect the envelope information including the identifier for the key wrap or key agreement.
>> 
>> The only reason JOSE has this requirement is because the header has to be integrity-protected.  So this is circular reasoning.
>> 
>> 
>>> In CMS the recipient-info values are not normally integrity protected.   
>>> 
>>> This tends to lead to a long discussion about if there is a real requirement to integrity protect them.  
>>> 
>>> In JOSE we decided to integrity protect the recipient-info values to prevent things like backwards computability attacks.  
>> 
>> The author of the backward-compatibility attack paper himself has said on the JOSE list that header integrity protection does not prevent BC attacks.
>> """
>> ... it does not matter, if he modifies an existing
>> secure object or creates a totally new object encrypted with an insecure
>> algorithm and appends it to the document.
>> """
>> <http://www.ietf.org/mail-archive/web/jose/current/msg01881.html>
>> 
>> Do you have some other reason for integrity-protecting the recipient-info?  
>> 
>> 
>>> This works just fine for one recipient but presents a problem using GCM for multiple recipients if the AAD is used to protect the recipient-info values.
>>> 
>>> That is the readers digest explanation on why those RFC are not sufficient on there own to answer the question of multiple recipients with integrity protected recipient-info.
>>> 
>>> I expect some people to chime in that we don't need to integrity protect recipient-info.
>> 
>> <chime/>
>> 
>> --Richard
>> 
>> 
>> 
>> 
>> 
>>> 
>>> Regards
>>> John B.
>>> 
>>> On 2013-04-02, at 1:12 PM, Russ Housley <[e-mail]> wrote:
>>> 
>>>> Jim:
>>>> 
>>>> RFC 5084 and RFC 6476 both show approaches to the use of authenticated encryption with CMS.  Is there some reason that JOSE is not following one of these approaches?
>>>> 
>>>> Russ
>>>> 
>>>> 
>>>> On Apr 2, 2013, at 11:59 AM, John Bradley wrote:
>>>> 
>>>>> Jim,
>>>>> 
>>>>> I don't think Mike was proposing that as a solution, but rather an attempt to characterize the issue.
>>>>> 
>>>>> Yes changing the nonce per recipient would cause the cypher text produced by GCM to change per recipient and need to be repeated, making it an array of JWE effectively, and not really anyones idea of encrypting to multiple recipients.
>>>>> 
>>>>> In a later email I asked David if we have the same or similar issue with his AES-CBC+HMAC. 
>>>>> 
>>>>> Perhaps and I think it is too early to go there, perhaps not all encryption algorithms are equally well suited to using with multiple recipients.
>>>>> 
>>>>> John B.
>>>>> 
>>>>> On 2013-04-02, at 12:48 PM, "Jim Schaad" <[e-mail]> wrote:
>>>>> 
>>>>>> Mike,
>>>>>> 
>>>>>> I will note that this is not going to be considered an acceptable solution for the JOSE group.  You don’t really want to increase the size of the message by n*base64 encoding where in is the number of recipients.
>>>>>> 
>>>>>> Jim
>>>>>> 
>>>>>> 
>>>>>> From: Mike Jones [mailto:[e-mail]] 
>>>>>> Sent: Monday, April 01, 2013 5:55 PM
>>>>>> To: David McGrew (mcgrew); Jim Schaad
>>>>>> Cc: [e-mail]; John Bradley
>>>>>> 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?
>>>>>> 
>>>>>>                                                               Thanks,
>>>>>>                                                               -- Mike
>>>>>> 
>>>>>> From: [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]
>>>>>> Subject: Re: [Cfrg] GCM nonce reuse question
>>>>>> 
>>>>>> Hi Jim,
>>>>>> 
>>>>>> From: Jim Schaad <[e-mail]>
>>>>>> Date: Wednesday, March 27, 2013 6:43 PM
>>>>>> To: David McGrew <[e-mail]>
>>>>>> Cc: "[e-mail]" <[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
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Cfrg mailing list
>>>>> [e-mail]
>>>>> http://www.irtf.org/mailman/listinfo/cfrg
>>>> 
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>> [e-mail]
>>>> http://www.irtf.org/mailman/listinfo/cfrg
>>> 
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> http://www.irtf.org/mailman/listinfo/cfrg
>> 
>