IETF Logo Mail Archive

Re: [Cfrg] GCM nonce reuse question

John Bradley <ve7jtb@ve7jtb.com> Tue, 02 April 2013 20:09 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 EC9AA21F8E04 for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 13:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.384
X-Spam-Level:
X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Go-N-yLqTYCA for <cfrg@ietfa.amsl.com>; Tue, 2 Apr 2013 13:09:32 -0700 (PDT)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1788721F8D3A for <cfrg@irtf.org>; Tue, 2 Apr 2013 13:09:31 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id bs12so477187qab.18 for <cfrg@irtf.org>; Tue, 02 Apr 2013 13:09:31 -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=I8m/LG7GkWusYo8NB/hfGMR/2jlPhTCxWq10tUBM2Ng=; b=Capv5B9elHMBatP1l0Qw2XGNWbBFbbs2Vfvk5iaEK+9Ru2ZGC3iRD8MVakXCf+2any vkdTNSqaHuyRIkzNM3lQPJ1uyAE+yLL8s9IjLJKiiWj5jr4eJs73j29P3sHqT8Rk2bAg FRmDIzM9OqMzLL5AKTKcdHEY4OqElrnokc4Em2KTzzmHFV4NMg0ONcI5UFyOWFmFX5Bb GsJ41oq90kRt+hMdQFn37d/3dzG/zsJCS4plGgWF++3sMq23mtydJuMD4EPCBSGoyWuo eDKUU6oYdwK4Ov2RejORAje8oJCPUDK9Ben8aU6QBXQau6wpNxG/upmScZOfxJHO5mi4 MJ1A==
X-Received: by 10.229.117.202 with SMTP id s10mr3326120qcq.64.1364933371327; Tue, 02 Apr 2013 13:09:31 -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 he6sm3903857qab.1.2013.04.02.13.09.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 13:09:29 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_7CBDF288-95BD-4F54-8A06-28379093DE60"; 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: <489782CF-0C9F-4DFE-A82D-087247209933@vigilsec.com>
Date: Tue, 02 Apr 2013 17:09:20 -0300
Message-Id: <42BC368C-9EEC-4D4E-A0FD-14FC236FD191@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> <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> <6BDAB42A-B894-40E7-ADB9-4DB4337A73EE@vigilsec.com> <3727A8A4-FA6E-4EC2-859C-C1C40E98108E@ve7jtb.com> <489782CF-0C9F-4DFE-A82D-087247209933@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQnOSLd8V7cktIynm5+MIU1IUIfDi6yGewtTGI80MCYmAIdvE1kozu/u5IexN+RwCTAs6lPH
Cc: IRTF CFRG <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 20:09:33 -0000

Russ,

The concern is not that the client will accept the token but that altering the algorithms gives an attacker additional ways to use the client as an oracle.
In JOSE JWE the envelope is also extensible so may contain other information that if changed might confuse the client.   I seem to recall that additional envelope information is possible in CMS but uncommon in practice.

Locking down the envelope is a possibility, however the work group just decided to allow additional elements to be ignored by default going in the other direction.

I expect Richard to plug a two envelope solution at this point:)

Regards
John B.

On 2013-04-02, at 4:53 PM, Russ Housley <housley@vigilsec.com> wrote:

> John:
> 
>> In CMS the recipient-info values are not normally integrity protected.
> 
> Indeed.  If the things that are carried here are altered, then one of two things happens: (1) a value needed to compute the proper key is altered, which prevents the decrypt from working at all; or (2) a value for the recipient to locate their portion of the recipient information is altered, which prevents the intended recipient from decrypting the content.  In either case, the recipient is not fooled into accepting anything that is surprising to the sender.
> 
> Russ

v2.23.0 | Report a Bug | By Email