IETF Logo Mail Archive

Re: [Cfrg] GCM nonce reuse question

Mike Jones <Michael.Jones@microsoft.com> Tue, 02 April 2013 01:01 UTC

Return-Path: <Michael.Jones@microsoft.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 D8EF811E8119 for <cfrg@ietfa.amsl.com>; Mon, 1 Apr 2013 18:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6]
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 BAizAvV2GRoD for <cfrg@ietfa.amsl.com>; Mon, 1 Apr 2013 18:01:06 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07511E80F8 for <cfrg@irtf.org>; Mon, 1 Apr 2013 18:01:06 -0700 (PDT)
Received: from BN1BFFO11FD016.protection.gbl (10.58.52.201) by BN1AFFO11HUB028.protection.gbl (10.58.52.138) with Microsoft SMTP Server (TLS) id 15.0.664.0; Tue, 2 Apr 2013 00:55:30 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD016.mail.protection.outlook.com (10.58.53.76) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Tue, 2 Apr 2013 00:55:34 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 2 Apr 2013 00:54:58 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "David McGrew (mcgrew)" <mcgrew@cisco.com>, Jim Schaad <jimsch@augustcellars.com>
Thread-Topic: GCM nonce reuse question
Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AAONxSwA=
Date: Tue, 02 Apr 2013 00:54:57 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com>
In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.71]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675A0978TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(66654001)(164054002)(52604002)(199002)(189002)(54356001)(81342001)(53806001)(66066001)(31966008)(80022001)(65816001)(51856001)(33656001)(69226001)(47736001)(49866001)(54316002)(71186001)(512954001)(16236675001)(16297215001)(55846006)(56776001)(16406001)(4396001)(56816002)(77982001)(47446002)(50986001)(5343655001)(59766001)(5343635001)(76482001)(74502001)(63696002)(20776003)(15202345001)(47976001)(46102001)(74662001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB028; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 08041D247D
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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 01:01:08 -0000

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: 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<mailto:jimsch@augustcellars.com>>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisco.com<mailto:mcgrew@cisco.com>>
Cc: "cfrg@irtf.org<mailto:cfrg@irtf.org>" <cfrg@irtf.org<mailto: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

v2.23.0 | Report a Bug | By Email