Re: [Cfrg] GCM nonce reuse question

John Bradley <ve7jtb@ve7jtb.com> Tue, 02 April 2013 14:41 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C5021F8AC2 for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 07:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.66
X-Spam-Level:
X-Spam-Status: No, score=0.66 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2ROQYXxK8e3 for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 07:41:44 -0700 (PDT)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id ED7B821F8AB2 for <cfrg@irtf.org>; Tue, 2 Apr 2013 07:41:37 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id u28so201857qcs.22 for <cfrg@irtf.org>; Tue, 02 Apr 2013 07:41:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=RCrVP949C4VgjvMzAPrLuunJS755rwXoRERrXZEBAiQ=; b=JOIO6LOCco9in9KrIHnJUbhh3Ykak9UlOseY5BJCxLM4alDq4flDhbwRld1IxtDkVz an2rpqB3PCOlggoFjDk5xE2kplGJwLLEqx/YWgTWi2sAvNTSlbuc/TUoAbbANfOAsuHJ B6KRBpxsCV07g74QBCWlu59IK3B7AUak72fPgtS904I9R9DIqQydV+GQzhQ5BFEwHBN1 C8S1W3SV0lDYrmV1xfOOfkY+mJXklTPZlKHbC5s1QfLKCkWXB2WkOssNUfBYcmSYydXi EfmdXLx+z1COST9EmF084BVtigZdlRFvWARJjLOUYazKHgRXhulylgrq2h+rU3xEs/B7 DPIg==
X-Received: by 10.49.49.72 with SMTP id s8mr17720232qen.54.1364913697225; Tue, 02 Apr 2013 07:41:37 -0700 (PDT)
Received: from [192.168.1.34] (190-20-47-140.baf.movistar.cl. [190.20.47.140]) by mx.google.com with ESMTPS id bt19sm2374307qab.0.2013.04.02.07.41.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 07:41:35 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_7F565EC6-FB0A-4B76-AF26-A3A3F4A657F8"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183F0C52@xmb-rcd-x04.cisco.com>
Date: Tue, 02 Apr 2013 11:41:21 -0300
Message-Id: <9DF44126-18A2-4C28-A470-B3B2DB4A48A3@ve7jtb.com>
References: <747787E65E3FBD4E93F0EB2F14DB556B183F0C52@xmb-rcd-x04.cisco.com>
To: "David McGrew (mcgrew)" <mcgrew@cisco.com>
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQnf4mPJOwd+HJMxvJl4ulzQt1LNH+r0Lhkl9dsOgHy9sqTi13W9wZ0oIScaW8x+wo9fXkij
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Jim Schaad <jimsch@augustcellars.com>
Subject: Re: [Cfrg] GCM nonce reuse question
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 14:41:45 -0000

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
>>>