Re: [Cfrg] GCM nonce reuse question

"David McGrew (mcgrew)" <mcgrew@cisco.com> Tue, 02 April 2013 13:32 UTC

Return-Path: <mcgrew@cisco.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 3F61B21F8714 for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 06:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.998
X-Spam-Level:
X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 ODNKfXd+OWNw for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 06:32:17 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0721F8738 for <cfrg@irtf.org>; Tue, 2 Apr 2013 06:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16087; q=dns/txt; s=iport; t=1364909537; x=1366119137; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Y382Nv968upCSlcKks3PF36gNKGB6o0eIHdk5vkw4hg=; b=ZoYwFzsSm2qhgdF//A7eqpFimOy1IKdhrVBwxu/NMaXYvMheAyq5KivT GnJDxW8eNy79ORFYc9mWYh1RpS+PcNIYi+PuH8LPdGWu/bNSOseQIn59u b3SwcuTTB9Uu4Y206iUZ1bPlG87yHgguIyTKB2QhDBKjUhI7yb5qzPP8i k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwGAEfdWlGtJV2Z/2dsb2JhbABDgkN4hgGxBQGGXYFfgQMWdIIfAQEBBC1MEgEIDgMDAQEBCx05FAkIAQEEAQ0FCIgMDLE4kBCJEoVnDRMGCwYBgl9hA5gKj2yDC4Io
X-IronPort-AV: E=Sophos; i="4.87,393,1363132800"; d="scan'208,217"; a="194083160"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 02 Apr 2013 13:32:16 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r32DWGYH011618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 13:32:16 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 08:32:16 -0500
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Mike Jones <Michael.Jones@microsoft.com>, Jim Schaad <jimsch@augustcellars.com>
Thread-Topic: GCM nonce reuse question
Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AAONxSwAAHM3xgA==
Date: Tue, 02 Apr 2013 13:32:15 +0000
Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183F0C52@xmb-rcd-x04.cisco.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.117.10.227]
Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B183F0C52xmbrcdx04ciscoc_"
MIME-Version: 1.0
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 13:32:18 -0000

Hi Mike,

From: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Date: Monday, April 1, 2013 8:54 PM
To: David McGrew <mcgrew@cisco.com<mailto:mcgrew@cisco.com>>, Jim Schaad <jimsch@augustcellars.com<mailto:jimsch@augustcellars.com>>
Cc: "cfrg@irtf.org<mailto:cfrg@irtf.org>" <cfrg@irtf.org<mailto:cfrg@irtf.org>>, John Bradley <ve7jtb@ve7jtb.com<mailto: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> [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<mailto: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