Re: [Cfrg] GCM nonce reuse question

John Bradley <ve7jtb@ve7jtb.com> Tue, 02 April 2013 15:59 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 C6C2121F8BD7 for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 08:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.169
X-Spam-Level:
X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=1.829, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-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 R3F3570sJ4g9 for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 08:59:41 -0700 (PDT)
Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id B083021F8576 for <cfrg@irtf.org>; Tue, 2 Apr 2013 08:59:40 -0700 (PDT)
Received: by mail-qe0-f53.google.com with SMTP id q19so302402qeb.26 for <cfrg@irtf.org>; Tue, 02 Apr 2013 08:59:40 -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=Y9kcBxZn7fiMMTv3uTaLMNhJnAkbgOcoeZ2Q752XpEs=; b=M4B/PnK/8YVzdpGBLhk5CDySaZouhxfrs0CvhyGi2Rb5AHEVhPy4h8kqCxCOVndDUh /AZ4GlQ47tCLkqkJ69aJV7KeJ/MCedvWuZOx9LWxFplAqPm1aCMFmsoc0ZEdcRwsDmoO OuALWRAPb3BcYH0tsxAWWFZGntApCn4ktwIlcVAe+ZYuJLF3rLjxLNTSd7BmqKqrM3mQ Gad9oyywrRFf8OuyZe115VKg3xJzjQyQ7mdL8L2O0tyb0lNQA2WTzALrmLcMnQMYnLW6 NtRscEDYOklQrm3BgC+XDY/Fs7gSdHAgOEKrsa8xCv7r7zhvXptDTWVp85jNkia5oqut IavA==
X-Received: by 10.224.86.206 with SMTP id t14mr2563337qal.90.1364918380159; Tue, 02 Apr 2013 08:59:40 -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 bt19sm2733086qab.0.2013.04.02.08.59.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 08:59:38 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_C5A5160E-B47B-42F3-A5A0-815C8A8AF963"; 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: <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com>
Date: Tue, 02 Apr 2013 12:59:07 -0300
Message-Id: <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com>
References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com> <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com>
To: Jim Schaad <jimsch@augustcellars.com>
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQkSGwNi/H9I5xw6wnP7ubxuLH7ihhlsCJerZ6GZAAf1elxKbXweUeptVbxVphlPHqkSuaSh
Cc: "'David McGrew (mcgrew)'" <mcgrew@cisco.com>, 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 15:59:42 -0000

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" <jimsch@augustcellars.com> 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:Michael.Jones@microsoft.com] 
> Sent: Monday, April 01, 2013 5:55 PM
> To: David McGrew (mcgrew); Jim Schaad
> Cc: cfrg@irtf.org; 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: 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
>