IETF Logo Mail Archive

Re: [Cfrg] GCM nonce reuse question

"David McGrew (mcgrew)" <mcgrew@cisco.com> Thu, 28 March 2013 11:14 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 DACED21F861F for <cfrg@ietfa.amsl.com>; Thu, 28 Mar 2013 04:14:55 -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 UPCV641JqCCr for <cfrg@ietfa.amsl.com>; Thu, 28 Mar 2013 04:14:55 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E921F84F5 for <cfrg@irtf.org>; Thu, 28 Mar 2013 04:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8056; q=dns/txt; s=iport; t=1364469295; x=1365678895; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ByqF1rQmP0NY9rDkf5x4SvKuyhy0u5glFhNc9s7dTfE=; b=hmipPx7BYoh0xojNiJZAFuRODlXe5GXjLzyqrd3xrKMsl9UbkCGGmMef LSaA9ZdTPFE02lnBvc7yMdk+FJfD4lqpG7v0E0LUXXd+tuYQQLvFcfyfG jRmGt16juIpMniGI9aYC8cba2FDAh0/tO/TKfCbLZMB5EJkmsMu1sDNJK c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsAFAI8kVFGtJV2b/2dsb2JhbABDgkN3tjoBiCqBAxZ0gh8BAQEELUwSAQgRAwECCx05FAkIAQEEDgUIiAwMvmGJBYViIAYLB4JfYQOYBo9ogwuCKA
X-IronPort-AV: E=Sophos; i="4.84,925,1355097600"; d="scan'208,217"; a="192450707"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 28 Mar 2013 11:14:52 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2SBEpwY028783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Mar 2013 11:14:51 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 28 Mar 2013 06:14:51 -0500
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Jim Schaad <jimsch@augustcellars.com>
Thread-Topic: GCM nonce reuse question
Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0A
Date: Thu, 28 Mar 2013 11:14:50 +0000
Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com>
In-Reply-To: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.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_747787E65E3FBD4E93F0EB2F14DB556B183EF2E3xmbrcdx04ciscoc_"
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: Thu, 28 Mar 2013 11:14:56 -0000

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