From paul.hoffman@vpnc.org Mon Apr 1 16:18:37 2013 Return-Path: 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 E100821E8127 for ; Mon, 1 Apr 2013 16:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 w3kAotjZvRoz for ; Mon, 1 Apr 2013 16:18:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3EABC21E8119 for ; Mon, 1 Apr 2013 16:18:36 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r31NIZA6066722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 1 Apr 2013 16:18:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Apr 2013 16:18:34 -0700 References: To: "cfrg@irtf.org CFRG" Message-Id: <22392F50-A37E-4738-AD2B-2DE109C5DE0B@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [Cfrg] Fwd: [IPsec] WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:18:37 -0000 [[ CFRG: There was a brief presentation on this in Orlando. The IPsecME = WG could really use some good cryptography review of this document. = Please send all comments to the IPsecME WG mailing list = (ipsec@ietf.org). Thanks! ]] Begin forwarded message: > From: Paul Hoffman > Subject: [IPsec] WG Last Call for draft-ietf-ipsecme-dh-checks > Date: April 1, 2013 4:17:18 PM PDT > To: IPsecme WG >=20 > Greetings. This is the start of the WG Last Call for = draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on = April 15. The current draft is available at = http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 >=20 > Given that this will be a Standards Track document, it is important = for it to be reviewed by as many people as possible. Possible results of = individual reviewing the document are: >=20 > - "Looks fine, please publish" >=20 > - "Looks fine, here are some comments" >=20 > - "Has some problems, here they are" >=20 > - Other things of that sort >=20 > Many people on this mailing list are IPsec implementers but are mostly = or completely silent on the mailing list. If you are one of those = people, doing a WG Last Call review is a good way to participate = usefully in the WG. Please strongly consider (a) reading the current = draft and (b) sending a message to the list with your short or long = review. If there are too few reviews on this document, we could get = pushback from the IESG about the document. >=20 > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From Michael.Jones@microsoft.com Mon Apr 1 18:01:07 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: "David McGrew (mcgrew)" , Jim Schaad Thread-Topic: GCM nonce reuse question Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AAONxSwA= Date: Tue, 2 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 01:01:08 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675A0978TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, In reading this thread and http://tools.ietf.org/html/draft-mcgrew-iv-gen-0= 2, I believe that it's OK, however if the usage is: (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D GCM(Key, Rec= ipient #1 data, nonce #1, plain text) (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D GCM(Key, Rec= ipient #2 data, nonce #2, plain text) where nonce #1 and nonce #2 are guaranteed to be distinct? Am I reading th= ings correctly in that regard? Thanks, -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Dav= id 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 = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption 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 auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#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 =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim --_000_4E1F6AAD24975D4BA5B1680429673943675A0978TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

In reading this thread= and http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it= 217;s OK, however if the usage is:

 

(Recipient #1 ciphertext= , Recipient #1 authentication tag) =3D GCM(Key, Recipient #1 data, nonce #1= , plain text)

(Recipient #2 ciphertext= , Recipient #2 authentication tag) =3D GCM(Key, Recipient #2 data, nonce #2= , plain text)

 

where nonce #1 and non= ce #2 are guaranteed to be distinct?  Am I reading things correctly in= that regard?

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thanks,=

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

From: cfrg-bou= nces@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,=

&n= bsp;

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisc= o.com>
Cc: "cfrg@irtf.org" &= lt;cfrg@irtf.org>
Subject: GCM nonce reuse question

&n= bsp;

David,=

 =

In doing a write up I be= came worried about a security property of the GCM encryption mode in the wa= y 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?

 =

&n= bsp;

Yes. &n= bsp;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 da= ta values".

&n= bsp;

Specifically the current= way that GCM mode is being used in JOSE is

 =

Recipient #1 authenticat= ion tag =3D GCM(Key, Recipient #1 data, nonce, plain text)

Recipient #2 authenticat= ion tag =3D GCM(Key, Recipient #2 data, nonce, plain text)

 =

As the key, nonce and pl= ain text are fixed it would produce the same encrypted text value but diffe= rent authentication tags.

 =

&n= bsp;

Can't d= o that.   Each invocation of the encryption operation needs a distinct= nonce, unless all of the encryption operation inputs are identical.

&n= bsp;

Many th= anks for calling this out, Jim.

&n= bsp;

David

&n= bsp;

Jim

 =

--_000_4E1F6AAD24975D4BA5B1680429673943675A0978TK5EX14MBXC283r_-- From mcgrew@cisco.com Tue Apr 2 06:32:18 2013 Return-Path: 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 ; 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 ; 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 ; 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)" To: Mike Jones , Jim Schaad Thread-Topic: GCM nonce reuse question Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AAONxSwAAHM3xgA== Date: Tue, 2 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:32:18 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B183F0C52xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mike, From: Mike Jones > Date: Monday, April 1, 2013 8:54 PM To: David 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-0= 2, I believe that it=92s OK, however if the usage is: (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D GCM(Key, Rec= ipient #1 data, nonce #1, plain text) (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D GCM(Key, Rec= ipient #2 data, nonce #2, plain text) where nonce #1 and nonce #2 are guaranteed to be distinct? Am I reading th= ings correctly in that regard? Yes, that looks good. David Thanks, -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@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 = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption 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 auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#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 =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim --_000_747787E65E3FBD4E93F0EB2F14DB556B183F0C52xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <308837E31F92C74582A6EF6BA05A9900@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Mike,

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Monday, April 1, 2013 8:54 PM=
To: David McGrew <mcgrew@cisco.com>, Jim Schaad <jimsch@augustcellars.com>
Cc: "cfrg@irtf.org" <cfrg@i= rtf.org>, John Bradley <ve7j= tb@ve7jtb.com>
Subject: RE: GCM nonce reuse questi= on

Hi David,

 

In reading this thread= and http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92= s OK, however if the usage is:

 

(Recipient #1 ciphertext= , Recipient #1 authentication tag) =3D GCM(Key, Recipient #1 data, nonce #1= , plain text)

(Recipient #2 ciphertext= , Recipient #2 authentication tag) =3D GCM(Key, Recipient #2 data, nonce #2= , plain text)

 

where nonce #1 and non= ce #2 are guaranteed to be distinct?  Am I reading things correctly in= that regard?

Yes, that looks good.

David

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thanks,=

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- 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,=

&n= bsp;

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisc= o.com>
Cc: "cfrg@irtf.org" &= lt;cfrg@irtf.org>
Subject: GCM nonce reuse question

&n= bsp;

David,=

 =

In doing a write up I be= came worried about a security property of the GCM encryption mode in the wa= y 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?

 =

&n= bsp;

Yes. &n= bsp;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 da= ta values".

&n= bsp;

Specifically the current= way that GCM mode is being used in JOSE is

 =

Recipient #1 authenticat= ion tag =3D GCM(Key, Recipient #1 data, nonce, plain text)

Recipient #2 authenticat= ion tag =3D GCM(Key, Recipient #2 data, nonce, plain text)

 =

As the key, nonce and pl= ain text are fixed it would produce the same encrypted text value but diffe= rent authentication tags.

 =

&n= bsp;

Can't d= o that.   Each invocation of the encryption operation needs a distinct= nonce, unless all of the encryption operation inputs are identical.

&n= bsp;

Many th= anks for calling this out, Jim.

&n= bsp;

David

&n= bsp;

Jim

 =

--_000_747787E65E3FBD4E93F0EB2F14DB556B183F0C52xmbrcdx04ciscoc_-- From ve7jtb@ve7jtb.com Tue Apr 2 07:41:45 2013 Return-Path: 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 97C5021F8AC2 for ; Tue, 2 Apr 2013 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.66 X-Spam-Level: X-Spam-Status: No, score=0.66 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 V2ROQYXxK8e3 for ; Tue, 2 Apr 2013 07:41:44 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id ED7B821F8AB2 for ; Tue, 2 Apr 2013 07:41:37 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id u28so201857qcs.22 for ; Tue, 02 Apr 2013 07:41:37 -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=RCrVP949C4VgjvMzAPrLuunJS755rwXoRERrXZEBAiQ=; b=JOIO6LOCco9in9KrIHnJUbhh3Ykak9UlOseY5BJCxLM4alDq4flDhbwRld1IxtDkVz an2rpqB3PCOlggoFjDk5xE2kplGJwLLEqx/YWgTWi2sAvNTSlbuc/TUoAbbANfOAsuHJ B6KRBpxsCV07g74QBCWlu59IK3B7AUak72fPgtS904I9R9DIqQydV+GQzhQ5BFEwHBN1 C8S1W3SV0lDYrmV1xfOOfkY+mJXklTPZlKHbC5s1QfLKCkWXB2WkOssNUfBYcmSYydXi EfmdXLx+z1COST9EmF084BVtigZdlRFvWARJjLOUYazKHgRXhulylgrq2h+rU3xEs/B7 DPIg== X-Received: by 10.49.49.72 with SMTP id s8mr17720232qen.54.1364913697225; Tue, 02 Apr 2013 07:41:37 -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 bt19sm2374307qab.0.2013.04.02.07.41.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 07:41:35 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7F565EC6-FB0A-4B76-AF26-A3A3F4A657F8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183F0C52@xmb-rcd-x04.cisco.com> Date: Tue, 2 Apr 2013 11:41:21 -0300 Message-Id: <9DF44126-18A2-4C28-A470-B3B2DB4A48A3@ve7jtb.com> References: <747787E65E3FBD4E93F0EB2F14DB556B183F0C52@xmb-rcd-x04.cisco.com> To: "David McGrew (mcgrew)" X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnf4mPJOwd+HJMxvJl4ulzQt1LNH+r0Lhkl9dsOgHy9sqTi13W9wZ0oIScaW8x+wo9fXkij Cc: "cfrg@irtf.org" , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:41:45 -0000 --Apple-Mail=_7F565EC6-FB0A-4B76-AF26-A3A3F4A657F8 Content-Type: multipart/alternative; boundary="Apple-Mail=_3DE8146B-2CC6-40D8-82E7-D78950E06BDB" --Apple-Mail=_3DE8146B-2CC6-40D8-82E7-D78950E06BDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 David, For draft-mcgrew-aead-aes-cbc-hmac-sha2 is the issue the same for using = the same MAC_KEY, ENC_KEY , IV and plaintext with different AEAD. I am guessing no good can come of that, but is it a known problem? The other question is if doing the same thing but making the MAC_KEY = different, while keeping the same ENC_KEY for each AEAD avoids the = problem? The question comes up when trying to use encryption to multiple = recipients where you are trying to use the same IV and ENC_KEY but allow = for integrity protecting the algorithm identifier and other data that = may be different for each recipient. I expect that the simple solution of not integrity protecting the = algorithm and key_id for the key wrapping and allowing RSA-OAEP to be = replaced with RSA1_5 or other alg substitution attacks is no longer a = recommended practice. =20 Perhaps using the AEAD to integrity protect the envelope information is = something that only really works in the single recipient case, and some = other method is needed for multiple recipients. Thanks=20 John B. On 2013-04-02, at 10:32 AM, "David McGrew (mcgrew)" = wrote: > Hi Mike, >=20 > From: Mike Jones > Date: Monday, April 1, 2013 8:54 PM > To: David McGrew , Jim Schaad = > Cc: "cfrg@irtf.org" , John Bradley > Subject: RE: GCM nonce reuse question >=20 >> Hi David, >> =20 >> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >> =20 >> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >> =20 >> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >=20 >=20 > Yes, that looks good. >=20 > David >=20 >> =20 >> = Thanks, >> -- = Mike >> =20 >> 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 >> =20 >> Hi Jim, >> =20 >> From: Jim Schaad >> Date: Wednesday, March 27, 2013 6:43 PM >> To: David McGrew >> Cc: "cfrg@irtf.org" >> Subject: GCM nonce reuse question >> =20 >>> David, >>> =20 >>> 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. >>> =20 >>> 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? >>> =20 >> =20 >> 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". >> =20 >>> Specifically the current way that GCM mode is being used in JOSE is >>> =20 >>> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >>> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >>> =20 >>> As the key, nonce and plain text are fixed it would produce the same = encrypted text value but different authentication tags. >>> =20 >> =20 >> Can't do that. Each invocation of the encryption operation needs a = distinct nonce, unless all of the encryption operation inputs are = identical. >> =20 >> Many thanks for calling this out, Jim. >> =20 >> David >> =20 >>> Jim >>> =20 --Apple-Mail=_3DE8146B-2CC6-40D8-82E7-D78950E06BDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 mcgrew@cisco.com> = wrote:
Hi Mike,


Hi David,
 
In reading this thread = and http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that = it=92s OK, however if the usage is:
 
(Recipient #1 ciphertext, Recipient = #1 authentication tag) =3D GCM(Key, Recipient #1 data, nonce #1, plain = text)
(Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = 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

 
        &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;      Thanks,
        &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;      -- 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><= br> 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.iet= f.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 =3D = GCM(Key, Recipient #1 data, nonce, plain = text)
Recipient #2 authentication tag =3D 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.
Jim
 

= --Apple-Mail=_3DE8146B-2CC6-40D8-82E7-D78950E06BDB-- --Apple-Mail=_7F565EC6-FB0A-4B76-AF26-A3A3F4A657F8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDAyMTQ0MTI0WjAjBgkqhkiG9w0BCQQxFgQUphYHf+GT BPWJ/adf3L2CiDnuqVYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAa8WPqkFolkB8gzWwNZayGsVz1M4x9WmenTAmomMy Kq5c6JvDg4Mb90JdG5ZOT5HeEdUugHdfU7sOtTakB/JDJUlAN00uo7GG6a85DygtIq+VJaWLnHFy gDM5mxRKjNHntjEGlo7Q6jQZDx7Kpf8fKUraDx/pyYXLG+HEkajJuEsB+MCZBV5mfv42pIn84VlD J4yfxxyYoD5GS/bzwNTu3cnD+gCkIdhLjbvLu3rftOEtsx17rQFJxlbTmlTTiJnZpkjDV5DK13w1 CUUh1RIngSv15i5Y7lgtmTY4O8HFcTRaHTEwMON8kxB/bfObpwKJ6tGI2wmrkL+hUYK/Uref5AAA AAAAAA== --Apple-Mail=_7F565EC6-FB0A-4B76-AF26-A3A3F4A657F8-- From Michael.Jones@microsoft.com Tue Apr 2 08:00:46 2013 Return-Path: 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 0E0F721F8652 for ; Tue, 2 Apr 2013 08:00:46 -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 pvou3S8Jhx-e for ; Tue, 2 Apr 2013 08:00:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 33B0F21F8AE8 for ; Tue, 2 Apr 2013 08:00:40 -0700 (PDT) Received: from BL2FFO11FD010.protection.gbl (10.173.161.201) by BL2FFO11HUB009.protection.gbl (10.173.161.111) with Microsoft SMTP Server (TLS) id 15.0.664.0; Tue, 2 Apr 2013 15:00:33 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Tue, 2 Apr 2013 15:00:32 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Tue, 2 Apr 2013 15:00:24 +0000 From: Mike Jones To: "David McGrew (mcgrew)" Thread-Topic: GCM nonce reuse question Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AAONxSwAAHM3xgAAAVAuAAAAxzlA= Date: Tue, 2 Apr 2013 15:00:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675A60AB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <747787E65E3FBD4E93F0EB2F14DB556B183F0C52@xmb-rcd-x04.cisco.com> <9DF44126-18A2-4C28-A470-B3B2DB4A48A3@ve7jtb.com> In-Reply-To: <9DF44126-18A2-4C28-A470-B3B2DB4A48A3@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675A60ABTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(164054002)(189002)(377424002)(66654001)(377454001)(52604002)(24454001)(47736001)(50986001)(71186001)(59766001)(54356001)(5343655001)(55846006)(47976001)(49866001)(80022001)(5343635001)(31966008)(77982001)(63696002)(20776003)(65816001)(512954001)(16297215001)(66066001)(79102001)(76482001)(33656001)(46102001)(51856001)(16236675001)(56776001)(16406001)(56816002)(54316002)(15202345001)(81342001)(74502001)(69226001)(74662001)(47446002)(4396001)(44976002)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB009; H:TK5EX14HUBC101.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" , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:00:46 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675A60ABTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, I was about to ask a similar question. It's actually my assumpti= on that it likely OK to perform multiple draft-mcgrew-aead-aes-cbc-hmac-sha= 2 operations where the Plaintext, Initialization Vector, and Key inputs are= constant and the Additional Associated Data varies. My reasoning is as fo= llows... The Authentication Tag outputs are the result of HMAC-SHA-2 operations over= a combination of the AAD and Ciphertext using the HMAC Key. For there to = be a problem with the above, there would have to be a problem with using th= e same HMAC key on multiple distinct inputs. But for there to be a problem= with using the same HMAC key on multiple distinct inputs, I believe that e= ffectively rests on whether there's a problem using the underlying hash fun= ction on multiple inputs. Which if true, would mean that the cryptographic= hash function doesn't have the desired cryptographic properties in the fir= st place. I'll readily admit that there could easily be a flaw in my chain of logic. = But on the surface of it, it seems like draft-mcgrew-aead-aes-cbc-hmac-sha= 2 operations should be OK in the multiple recipients case in a way that GCM= isn't. Thoughts? -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Tuesday, April 02, 2013 7:41 AM To: David McGrew (mcgrew) Cc: Mike Jones; Jim Schaad; cfrg@irtf.org Subject: Re: GCM nonce reuse question David, For draft-mcgrew-aead-aes-cbc-hmac-sha2 is the issue the same for using the= same MAC_KEY, ENC_KEY , IV and plaintext with different AEAD. I am guessing no good can come of that, but is it a known problem? The other question is if doing the same thing but making the MAC_KEY differ= ent, while keeping the same ENC_KEY for each AEAD avoids the problem? The question comes up when trying to use encryption to multiple recipients = where you are trying to use the same IV and ENC_KEY but allow for integrity= protecting the algorithm identifier and other data that may be different f= or each recipient. I expect that the simple solution of not integrity protecting the algorithm= and key_id for the key wrapping and allowing RSA-OAEP to be replaced with = RSA1_5 or other alg substitution attacks is no longer a recommended practic= e. Perhaps using the AEAD to integrity protect the envelope information is som= ething that only really works in the single recipient case, and some other = method is needed for multiple recipients. Thanks John B. On 2013-04-02, at 10:32 AM, "David McGrew (mcgrew)" > wrote: Hi Mike, From: Mike Jones > Date: Monday, April 1, 2013 8:54 PM To: David 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-0= 2, I believe that it's OK, however if the usage is: (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D GCM(Key, Rec= ipient #1 data, nonce #1, plain text) (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D GCM(Key, Rec= ipient #2 data, nonce #2, plain text) where nonce #1 and nonce #2 are guaranteed to be distinct? Am I reading th= ings correctly in that regard? Yes, that looks good. David Thanks, -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@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 = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption 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 auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#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 =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim --_000_4E1F6AAD24975D4BA5B1680429673943675A60ABTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, I was about = to ask a similar question.  It’s actually my assumption that it = likely OK to perform multiple draft-mcgrew-aead-aes-cbc-hmac-sha2 operation= s where the Plaintext, Initialization Vector, and Key inputs are constant and the Additional Associated Data varies.  M= y reasoning is as follows…

 

The Authentication Tag= outputs are the result of HMAC-SHA-2 operations over a combination of the = AAD and Ciphertext using the HMAC Key.  For there to be a problem with= the above, there would have to be a problem with using the same HMAC key on multiple distinct inputs.  But for th= ere to be a problem with using the same HMAC key on multiple distinct input= s, I believe that effectively rests on whether there’s a problem usin= g the underlying hash function on multiple inputs.  Which if true, would mean that the cryptographic hash functi= on doesn’t have the desired cryptographic properties in the first pla= ce.

 

I’ll readily adm= it that there could easily be a flaw in my chain of logic.  But on the= surface of it, it seems like draft-mcgrew-aead-aes-cbc-hmac-sha2 operation= s should be OK in the multiple recipients case in a way that GCM isn’t.

 

Thoughts?

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

 

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, April 02, 2013 7:41 AM
To: David McGrew (mcgrew)
Cc: Mike Jones; Jim Schaad; cfrg@irtf.org
Subject: Re: GCM nonce reuse question

 

David,

 

For draft-mcgrew-aead-aes-cbc-hmac-sha2 is the = issue the same for using the same MAC_KEY, ENC_KEY  , IV  and pla= intext with different AEAD.

 

I am guessing no good can come of that, but is it a = known problem?

 

The other question is if doing the same thing but ma= king the MAC_KEY different, while keeping the same ENC_KEY  for each A= EAD avoids the problem?

 

The question comes up when trying to use encryption = to multiple recipients where you are trying to use the same IV and ENC_KEY = but allow for integrity protecting the algorithm identifier and other data = that may be different for each recipient.

 

I expect that the simple solution of not integrity p= rotecting the algorithm and key_id for the key wrapping and allowing R= SA-OAEP to be replaced with RSA1_5 or other alg substitution attacks i= s no longer a recommended practice.   

 

Perhaps using the AEAD to integrity protect the enve= lope information is something that only really works in the single recipien= t case, and some other method is needed for multiple recipients.=

 

Thanks 

John B.

 

On 2013-04-02, at 10:32 AM, "David McGrew (mcgr= ew)" <mcgrew@cisco.com> = wrote:



Hi Mike,=

 

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Monday, April 1, 2013 8:54 PM
To: David McGrew <mcgrew@cisc= o.com>, Jim Schaad <j= imsch@augustcellars.com>
Cc: "cfrg@irtf.org" &= lt;cfrg@irtf.org>, John Bradley <= ;ve7jtb@ve7jtb.com>
Subject: RE: GCM nonce reuse question

 

Hi David,<= /o:p>

 

In reading this thread= and http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it= 217;s OK, however if the usage is:

 

(Recipient #1 ciphertext, Recipient #1 authenticatio= n tag) =3D GCM(Key, Recipient #1 data, nonce #1, plain text)

(Recipient #2 ciphertext, Recipient #2 authenticatio= n tag) =3D GCM(Key, Recipient #2 data, nonce #2, plain text)

 

where nonce #1 and non= ce #2 are guaranteed to be distinct?  Am I reading things correctly in= that regard?

 

Yes, that looks goo= d.

 

David

 

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thanks,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- 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,=

 <= /o:p>

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisc= o.com>
Cc: "cfrg@irtf.org" &= lt;cfrg@irtf.org>
Subject: GCM nonce reuse question

 <= /o:p>

David,

 

In doing a write up I became worried about a securit= y property of the GCM encryption mode in the way that the JOSE group is cur= rently using it.

 

There are known problems with not having a unique se= t of values for IVs and Key pairings.  Do these problems apply to havi= ng a different set of auxiliary data as well as the plain text?<= /p>

 

 <= /o:p>

Yes.  The secu= rity issues are summarized in http://tools.ietf.org/html/rfc5116#section-5.1.1&n= bsp; but apparently they are not described generally enough.   They should read "plaintext or associated data values&= quot;.

 <= /o:p>

Specifically the current way that GCM mode is being = used in JOSE is

 

Recipient #1 authentication tag =3D GCM(Key, Recipie= nt #1 data, nonce, plain text)

Recipient #2 authentication tag =3D GCM(Key, Recipie= nt #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.

 

 <= /o:p>

Can't do that. &nbs= p; Each invocation of the encryption operation needs a distinct nonce, unle= ss all of the encryption operation inputs are identical.<= /p>

 <= /o:p>

Many thanks for cal= ling this out, Jim.

 <= /o:p>

David

 <= /o:p>

Jim

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943675A60ABTK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Tue Apr 2 08:59:42 2013 Return-Path: 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 ; 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 ; 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 ; Tue, 2 Apr 2013 08:59:40 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id q19so302402qeb.26 for ; 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 In-Reply-To: <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com> Date: Tue, 2 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" X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkSGwNi/H9I5xw6wnP7ubxuLH7ihhlsCJerZ6GZAAf1elxKbXweUeptVbxVphlPHqkSuaSh Cc: "'David McGrew \(mcgrew\)'" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:59:42 -0000 --Apple-Mail=_C5A5160E-B47B-42F3-A5A0-815C8A8AF963 Content-Type: multipart/alternative; boundary="Apple-Mail=_D89EAB72-CFB3-499E-9D92-5FC8B49A14BB" --Apple-Mail=_D89EAB72-CFB3-499E-9D92-5FC8B49A14BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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.=20 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" = wrote: > Mike, > =20 > I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. > =20 > Jim > =20 > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > 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 > =20 > Hi David, > =20 > In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: > =20 > (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) > (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) > =20 > where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? > =20 > = Thanks, > -- = Mike > =20 > 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 > =20 > Hi Jim, > =20 > From: Jim Schaad > Date: Wednesday, March 27, 2013 6:43 PM > To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question > =20 > David, > =20 > 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. > =20 > 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? > =20 > =20 > 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". > =20 > Specifically the current way that GCM mode is being used in JOSE is > =20 > Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, = plain text) > Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, = plain text) > =20 > As the key, nonce and plain text are fixed it would produce the same = encrypted text value but different authentication tags. > =20 > =20 > Can't do that. Each invocation of the encryption operation needs a = distinct nonce, unless all of the encryption operation inputs are = identical. > =20 > Many thanks for calling this out, Jim. > =20 > David > =20 > Jim > =20 --Apple-Mail=_D89EAB72-CFB3-499E-9D92-5FC8B49A14BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
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:

 
I will note that this is not going = to be considered an acceptable solution for the JOSE group.  You = don=92t really want to increase the size of the message by n*base64 = encoding where in is the number of = recipients.
 
 
 
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,
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,
 
 
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?
Recipient #1 authentication tag = =3D GCM(Key, Recipient #1 data, nonce, plain = text)
Recipient #2 authentication tag =3D 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.
 

 


= --Apple-Mail=_D89EAB72-CFB3-499E-9D92-5FC8B49A14BB-- --Apple-Mail=_C5A5160E-B47B-42F3-A5A0-815C8A8AF963 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDAyMTU1OTA3WjAjBgkqhkiG9w0BCQQxFgQUSLmoLhcO KC9z6G3J640UazQs1MwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAonZIao3gCeWZB+Sxhrk6YCdaMRCvv+YSzO61GVH3 Adc7ze8/EKfOgSE+khz2+PKw0w7w8TQH1rMQ9E5AzHoThGNJvuhJiTxtwBPPoU0tfsEoZQ3yVKEK 6nU0f6Kl6cVbeJ8LMpA+m1CXV/SxO35rNxbRGsR4yzPsI9ivbkleB5GJfaIcReseDiAGHifx6xE/ rGpiMrF2/7iJj4wsI1rDql1WizMAiwQP7p3BgnGu2emXnEX+AFeTkNQpRZIHFoWcZv0YVOJIaqJz RJoSYcm7aw0kVCUqhsiXmqiVZ5niSlkvq4vTDhQxQQhIHnrzgtIgHLGzTIA4/LuYKk6Pf6iWeQAA AAAAAA== --Apple-Mail=_C5A5160E-B47B-42F3-A5A0-815C8A8AF963-- From housley@vigilsec.com Tue Apr 2 09:12:12 2013 Return-Path: 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 C598021F8D35 for ; Tue, 2 Apr 2013 09:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 f9d2DibRH1NW for ; Tue, 2 Apr 2013 09:12:11 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1D21F8D33 for ; Tue, 2 Apr 2013 09:12:11 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 00B72F2406E; Tue, 2 Apr 2013 12:12:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id q8JWDSAVI31v; Tue, 2 Apr 2013 12:12:08 -0400 (EDT) Received: from [192.168.2.100] (pool-108-28-60-169.washdc.fios.verizon.net [108.28.60.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3745BF24076; Tue, 2 Apr 2013 12:12:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-22-64866469 From: Russ Housley In-Reply-To: <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> Date: Tue, 2 Apr 2013 12:12:02 -0400 Message-Id: <6BDAB42A-B894-40E7-ADB9-4DB4337A73EE@vigilsec.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> To: Jim Schaad X-Mailer: Apple Mail (2.1085) Cc: IRTF CFRG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:12:12 -0000 --Apple-Mail-22-64866469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jim: RFC 5084 and RFC 6476 both show approaches to the use of authenticated = encryption with CMS. Is there some reason that JOSE is not following = one of these approaches? Russ On Apr 2, 2013, at 11:59 AM, John Bradley wrote: > Jim, >=20 > I don't think Mike was proposing that as a solution, but rather an = attempt to characterize the issue. >=20 > 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. >=20 > In a later email I asked David if we have the same or similar issue = with his AES-CBC+HMAC.=20 >=20 > 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. >=20 > John B. >=20 > On 2013-04-02, at 12:48 PM, "Jim Schaad" = wrote: >=20 >> Mike, >> =20 >> I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. >> =20 >> Jim >> =20 >> =20 >> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >> 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 >> =20 >> Hi David, >> =20 >> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >> =20 >> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >> =20 >> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >> =20 >> = Thanks, >> -- = Mike >> =20 >> 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 >> =20 >> Hi Jim, >> =20 >> From: Jim Schaad >> Date: Wednesday, March 27, 2013 6:43 PM >> To: David McGrew >> Cc: "cfrg@irtf.org" >> Subject: GCM nonce reuse question >> =20 >> David, >> =20 >> 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. >> =20 >> 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? >> =20 >> =20 >> 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". >> =20 >> Specifically the current way that GCM mode is being used in JOSE is >> =20 >> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >> =20 >> As the key, nonce and plain text are fixed it would produce the same = encrypted text value but different authentication tags. >> =20 >> =20 >> Can't do that. Each invocation of the encryption operation needs a = distinct nonce, unless all of the encryption operation inputs are = identical. >> =20 >> Many thanks for calling this out, Jim. >> =20 >> David >> =20 >> Jim >> =20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-22-64866469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
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.


 
I will note that this is not going = to be considered an acceptable solution for the JOSE group.  You = don=92t really want to increase the size of the message by n*base64 = encoding where in is the number of = recipients.
 
 
 
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,
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,
 
 
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?
Recipient #1 authentication tag = =3D GCM(Key, Recipient #1 data, nonce, plain = text)
Recipient #2 authentication tag =3D 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.
 

 


_______________________________________________
Cfr= g mailing list
Cfrg@irtf.org
http://www.irtf.org/mai= lman/listinfo/cfrg

= --Apple-Mail-22-64866469-- From rbarnes@bbn.com Tue Apr 2 10:55:36 2013 Return-Path: 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 A224A21F8CEB; Tue, 2 Apr 2013 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, 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 q5loGLYFqlEd; Tue, 2 Apr 2013 10:55:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BFE4721F8CE9; Tue, 2 Apr 2013 10:55:35 -0700 (PDT) Received: from ros-dhcp192-1-51-16.bbn.com ([192.1.51.16]:49983) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN5Qb-000PYb-Bi; Tue, 02 Apr 2013 13:55:25 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Richard Barnes In-Reply-To: <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> Date: Tue, 2 Apr 2013 13:55:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.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> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: "David McGrew \(mcgrew\)" , cfrg@irtf.org, "jose@ietf.org" , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:55:36 -0000 [re-added JOSE, since we're talking design now] On Apr 2, 2013, at 11:59 AM, John Bradley wrote: > Jim, >=20 > I don't think Mike was proposing that as a solution, but rather an = attempt to characterize the issue. >=20 > 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. >=20 > In a later email I asked David if we have the same or similar issue = with his AES-CBC+HMAC.=20 >=20 > 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. This is the wrong conclusion. GCM is suited just fine to multiple = recipients, as it's use with CMS (AuthEnvelopedData) shows.=20 The problem here is JWE, specifically the fact that the header (with = per-recipient data) is covered by the integrity check. If you remove = the per-recipient data from the integrity check, then this problem goes = away. In that case, there is only one invocation of GCM (not one per = recipient), so there's no problem. So the choice that JOSE faces is from the following options: Option 0. Outlaw GCM for multiple recipients. COST: GCM Option 1. Keep per-recipient info under integrity check, and require a = fresh nonce for each recipient COST: Removes all savings in the multiple recipient case=20 BENEFIT: Doesn't break backward compatibility with current, = single-recipient JWE Option 2. Remove per-recipient info from integrity check COST: Breaks backward compatibility with current, single-recipient JWE BENEFIT: Increases savings in multiple-recipient case (since no = per-recipient integrity check value) Option 0 is clearly not acceptable. So basically, this is a choice = about how much we want to let deployed code keep us from sensible = architecture. To me, the choice is clear. Changing code is minor, short-term pain. = Getting architecture wrong is major, long-term pain. Let's do option = (2). --Richard >=20 > John B. >=20 > On 2013-04-02, at 12:48 PM, "Jim Schaad" = wrote: >=20 >> Mike, >> =20 >> I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. >> =20 >> Jim >> =20 >> =20 >> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >> 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 >> =20 >> Hi David, >> =20 >> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >> =20 >> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >> =20 >> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >> =20 >> = Thanks, >> -- = Mike >> =20 >> 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 >> =20 >> Hi Jim, >> =20 >> From: Jim Schaad >> Date: Wednesday, March 27, 2013 6:43 PM >> To: David McGrew >> Cc: "cfrg@irtf.org" >> Subject: GCM nonce reuse question >> =20 >> David, >> =20 >> 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. >> =20 >> 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? >> =20 >> =20 >> 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". >> =20 >> Specifically the current way that GCM mode is being used in JOSE is >> =20 >> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >> =20 >> As the key, nonce and plain text are fixed it would produce the same = encrypted text value but different authentication tags. >> =20 >> =20 >> Can't do that. Each invocation of the encryption operation needs a = distinct nonce, unless all of the encryption operation inputs are = identical. >> =20 >> Many thanks for calling this out, Jim. >> =20 >> David >> =20 >> Jim >> =20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From ve7jtb@ve7jtb.com Tue Apr 2 11:00:04 2013 Return-Path: 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 D957621F8C85 for ; Tue, 2 Apr 2013 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 k1lWzrQBHUw1 for ; Tue, 2 Apr 2013 11:00:03 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6006C21F8C83 for ; Tue, 2 Apr 2013 11:00:03 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id vb8so614421obc.38 for ; Tue, 02 Apr 2013 11:00:03 -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=wm4xSR39OGBXfQg1RPQ3f2Z5Mo2WJO2H3NxF3xHR/oQ=; b=ZkP7T7v0bgKf/OtSpmu3GWDjpI9Pw4aFNjMygZvCu9oNEbBpHpLRS1g8oDrEHw5lUR rejNwouqzkbwrz+i5rMqCkL6oq0SChwjB/LRmPeY6Wk6iM3Si6las3jGkwyOj7BSHORi zPsgLylxry/43SySswFQ9V9kFR1Glyw466PMQDHZfqs5x7PJxRC8rg5erl3bcyFwqaYK wD5pbebHo/4kxq3cCuuQuOe1P5Qm3k7AbpChtLv0TX5BHg6L9FjddxTatd4KXtjC53Xt 3L1MIPIyjFQ3UN4vmEdy9N3DKx8ZFTYarE5S4CRY03XN84Jdryn5lM3Bk7V6egHfuyTz UL4w== X-Received: by 10.182.56.134 with SMTP id a6mr5978000obq.29.1364925602881; Tue, 02 Apr 2013 11:00:02 -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 a3sm451404oee.8.2013.04.02.10.59.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 11:00:00 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E2657797-12F1-40EF-91D0-EE629AAB6D32"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <6BDAB42A-B894-40E7-ADB9-4DB4337A73EE@vigilsec.com> Date: Tue, 2 Apr 2013 14:59:51 -0300 Message-Id: <3727A8A4-FA6E-4EC2-859C-C1C40E98108E@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> To: Russ Housley X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkpo9tbxvLibVjno5PvMm6H5f3Kl21841fZVUk1xGVLpr25avdr+3RbvGC7DrQC8NA6yUtD Cc: IRTF CFRG , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:00:05 -0000 --Apple-Mail=_E2657797-12F1-40EF-91D0-EE629AAB6D32 Content-Type: multipart/alternative; boundary="Apple-Mail=_F88C1F68-71D5-4D20-AA95-EE47BA1D402A" --Apple-Mail=_F88C1F68-71D5-4D20-AA95-EE47BA1D402A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Russ, We are close to those approaches. However nether of those address using = the Additional Authenticated Data(AAD). They mention that it exists as = an input but nothing more. A difference between JOSE and CMS is that CMS allows non AEAD block = ciphers, where JOSE requires all block cyphers to be AEAD. That in theory allows us to use the AAD to integrity protect the = envelope information including the identifier for the key wrap or key = agreement. In CMS the recipient-info values are not normally integrity protected. =20= This tends to lead to a long discussion about if there is a real = requirement to integrity protect them. =20 In JOSE we decided to integrity protect the recipient-info values to = prevent things like backwards computability attacks. =20 This works just fine for one recipient but presents a problem using GCM = for multiple recipients if the AAD is used to protect the recipient-info = values. That is the readers digest explanation on why those RFC are not = sufficient on there own to answer the question of multiple recipients = with integrity protected recipient-info. I expect some people to chime in that we don't need to integrity protect = recipient-info. Regards John B. On 2013-04-02, at 1:12 PM, Russ Housley wrote: > Jim: >=20 > RFC 5084 and RFC 6476 both show approaches to the use of authenticated = encryption with CMS. Is there some reason that JOSE is not following = one of these approaches? >=20 > Russ >=20 >=20 > On Apr 2, 2013, at 11:59 AM, John Bradley wrote: >=20 >> Jim, >>=20 >> I don't think Mike was proposing that as a solution, but rather an = attempt to characterize the issue. >>=20 >> 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. >>=20 >> In a later email I asked David if we have the same or similar issue = with his AES-CBC+HMAC.=20 >>=20 >> 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. >>=20 >> John B. >>=20 >> On 2013-04-02, at 12:48 PM, "Jim Schaad" = wrote: >>=20 >>> Mike, >>> =20 >>> I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. >>> =20 >>> Jim >>> =20 >>> =20 >>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >>> 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 >>> =20 >>> Hi David, >>> =20 >>> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >>> =20 >>> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >>> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >>> =20 >>> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >>> =20 >>> = Thanks, >>> -- = Mike >>> =20 >>> 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 >>> =20 >>> Hi Jim, >>> =20 >>> From: Jim Schaad >>> Date: Wednesday, March 27, 2013 6:43 PM >>> To: David McGrew >>> Cc: "cfrg@irtf.org" >>> Subject: GCM nonce reuse question >>> =20 >>> David, >>> =20 >>> 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. >>> =20 >>> 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? >>> =20 >>> =20 >>> 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". >>> =20 >>> Specifically the current way that GCM mode is being used in JOSE is >>> =20 >>> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >>> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >>> =20 >>> As the key, nonce and plain text are fixed it would produce the same = encrypted text value but different authentication tags. >>> =20 >>> =20 >>> Can't do that. Each invocation of the encryption operation needs a = distinct nonce, unless all of the encryption operation inputs are = identical. >>> =20 >>> Many thanks for calling this out, Jim. >>> =20 >>> David >>> =20 >>> Jim >>> =20 >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_F88C1F68-71D5-4D20-AA95-EE47BA1D402A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 housley@vigilsec.com> = wrote:
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:

 
I will note that this is not going = to be considered an acceptable solution for the JOSE group.  You = don=92t really want to increase the size of the message by n*base64 = encoding where in is the number of = recipients.
 
 
 
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,
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,
 
 
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?
Recipient #1 authentication tag = =3D GCM(Key, Recipient #1 data, nonce, plain = text)

 


_______________________________________________
Cfr= g mailing list
Cfrg@irtf.org
http://www.irtf.org/mai= lman/listinfo/cfrg

_______= ________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mai= lman/listinfo/cfrg

= --Apple-Mail=_F88C1F68-71D5-4D20-AA95-EE47BA1D402A-- --Apple-Mail=_E2657797-12F1-40EF-91D0-EE629AAB6D32 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDAyMTc1OTUxWjAjBgkqhkiG9w0BCQQxFgQUmUoN3OWF xb1F5ehCZm04xc3EYgAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEArMX2Z2JRrPv/D+GxKDor250CjKTUGuwi8PP6S0Yg aRW91zwCGp0Do162igtybMijc+N+CO9mxZRwN+zs3tPs0OCTUGxmmV7z04atJ5T8LATBP0GkMiKM /uZIoyUPH5tg+W5Q3LPmpqEEKffIy4DXB381pARWeSbhb8+24/iobAS8VM6oekAKoPn/Cxl66uau fxmGrTNZfY/cguQJjf9jRh2Kt/8yb4I28N7ukze6QL4t4hZTfDrZX0657I4btEM69xL9YuFhEFtH JbnfmFEuE/GG3C4Bt30jPE/z8KDON94bh8nYQSUp08ckXf/9eePnDmT2OIM2tuF5Ls1bT0OW0QAA AAAAAA== --Apple-Mail=_E2657797-12F1-40EF-91D0-EE629AAB6D32-- From rbarnes@bbn.com Tue Apr 2 12:05:40 2013 Return-Path: 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 3592821F8E6E for ; Tue, 2 Apr 2013 12:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, 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 V4SPwg9pZlJv for ; Tue, 2 Apr 2013 12:05:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4782C21F8E69 for ; Tue, 2 Apr 2013 12:05:39 -0700 (PDT) Received: from ros-dhcp192-1-51-16.bbn.com ([192.1.51.16]:50271) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN6WW-000JFr-BA; Tue, 02 Apr 2013 15:05:36 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Richard Barnes In-Reply-To: <3727A8A4-FA6E-4EC2-859C-C1C40E98108E@ve7jtb.com> Date: Tue, 2 Apr 2013 15:05:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B54035F-CEA5-4433-BD4E-8D1E0FAB2E21@bbn.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> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: IRTF CFRG , Russ Housley , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:05:40 -0000 John, I don't think you've really answered Russ's question. You've provided a = *historical* reason, but not a *technical* reason why JOSE doesn't = follow the same approach as CMS. On Apr 2, 2013, at 1:59 PM, John Bradley wrote: > Russ, >=20 > We are close to those approaches. However nether of those address = using the Additional Authenticated Data(AAD). They mention that it = exists as an input but nothing more. >=20 > A difference between JOSE and CMS is that CMS allows non AEAD block = ciphers, where JOSE requires all block cyphers to be AEAD. > That in theory allows us to use the AAD to integrity protect the = envelope information including the identifier for the key wrap or key = agreement. The only reason JOSE has this requirement is because the header has to = be integrity-protected. So this is circular reasoning. > In CMS the recipient-info values are not normally integrity protected. = =20 >=20 > This tends to lead to a long discussion about if there is a real = requirement to integrity protect them. =20 >=20 > In JOSE we decided to integrity protect the recipient-info values to = prevent things like backwards computability attacks. =20 The author of the backward-compatibility attack paper himself has said = on the JOSE list that header integrity protection does not prevent BC = attacks. """ ... it does not matter, if he modifies an existing secure object or creates a totally new object encrypted with an insecure algorithm and appends it to the document. """ Do you have some other reason for integrity-protecting the = recipient-info? =20 > This works just fine for one recipient but presents a problem using = GCM for multiple recipients if the AAD is used to protect the = recipient-info values. >=20 > That is the readers digest explanation on why those RFC are not = sufficient on there own to answer the question of multiple recipients = with integrity protected recipient-info. >=20 > I expect some people to chime in that we don't need to integrity = protect recipient-info. --Richard >=20 > Regards > John B. >=20 > On 2013-04-02, at 1:12 PM, Russ Housley wrote: >=20 >> Jim: >>=20 >> RFC 5084 and RFC 6476 both show approaches to the use of = authenticated encryption with CMS. Is there some reason that JOSE is = not following one of these approaches? >>=20 >> Russ >>=20 >>=20 >> On Apr 2, 2013, at 11:59 AM, John Bradley wrote: >>=20 >>> Jim, >>>=20 >>> I don't think Mike was proposing that as a solution, but rather an = attempt to characterize the issue. >>>=20 >>> 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. >>>=20 >>> In a later email I asked David if we have the same or similar issue = with his AES-CBC+HMAC.=20 >>>=20 >>> 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. >>>=20 >>> John B. >>>=20 >>> On 2013-04-02, at 12:48 PM, "Jim Schaad" = wrote: >>>=20 >>>> Mike, >>>> =20 >>>> I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. >>>> =20 >>>> Jim >>>> =20 >>>> =20 >>>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >>>> 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 >>>> =20 >>>> Hi David, >>>> =20 >>>> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >>>> =20 >>>> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >>>> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >>>> =20 >>>> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >>>> =20 >>>> = Thanks, >>>> -- = Mike >>>> =20 >>>> 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 >>>> =20 >>>> Hi Jim, >>>> =20 >>>> From: Jim Schaad >>>> Date: Wednesday, March 27, 2013 6:43 PM >>>> To: David McGrew >>>> Cc: "cfrg@irtf.org" >>>> Subject: GCM nonce reuse question >>>> =20 >>>> David, >>>> =20 >>>> 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. >>>> =20 >>>> 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? >>>> =20 >>>> =20 >>>> 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". >>>> =20 >>>> Specifically the current way that GCM mode is being used in JOSE is >>>> =20 >>>> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >>>> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >>>> =20 >>>> As the key, nonce and plain text are fixed it would produce the = same encrypted text value but different authentication tags. >>>> =20 >>>> =20 >>>> Can't do that. Each invocation of the encryption operation needs = a distinct nonce, unless all of the encryption operation inputs are = identical. >>>> =20 >>>> Many thanks for calling this out, Jim. >>>> =20 >>>> David >>>> =20 >>>> Jim >>>> =20 >>>=20 >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From housley@vigilsec.com Tue Apr 2 12:53:08 2013 Return-Path: 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 D5BDF21F8C0C for ; Tue, 2 Apr 2013 12:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yUmlcN6S71hs for ; Tue, 2 Apr 2013 12:53:08 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 525C121F8BEA for ; Tue, 2 Apr 2013 12:53:08 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1E912F24076; Tue, 2 Apr 2013 15:53:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id QaQ-cpuabIIp; Tue, 2 Apr 2013 15:53:03 -0400 (EDT) Received: from [192.168.2.100] (pool-108-28-60-169.washdc.fios.verizon.net [108.28.60.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 057A6F24077; Tue, 2 Apr 2013 15:53:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-32-78127876 From: Russ Housley In-Reply-To: <3727A8A4-FA6E-4EC2-859C-C1C40E98108E@ve7jtb.com> Date: Tue, 2 Apr 2013 15:53:04 -0400 Message-Id: <489782CF-0C9F-4DFE-A82D-087247209933@vigilsec.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> To: John Bradley X-Mailer: Apple Mail (2.1085) Cc: IRTF CFRG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:53:08 -0000 --Apple-Mail-32-78127876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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= --Apple-Mail-32-78127876 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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
= --Apple-Mail-32-78127876-- From ve7jtb@ve7jtb.com Tue Apr 2 12:57:29 2013 Return-Path: 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 C372221F8DD4 for ; Tue, 2 Apr 2013 12:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=1.220, BAYES_00=-2.599, 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 knQK6z-ucPuw for ; Tue, 2 Apr 2013 12:57:29 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id B39CF21F8DD0 for ; Tue, 2 Apr 2013 12:57:28 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id b4so455859qen.18 for ; Tue, 02 Apr 2013 12:57:24 -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=bKp3JoUlyV1GJ1eZ6VPZSM7E2ddL8xlNmZ7At/eJLvo=; b=TaR/T51/1gN9sbnzabfakWKRNiBRQk83nbBtWfXs/kxi8ZO+dvAr3rFeGAIRBl8KUA TOJHpa1lKHeTZdOBp7jHpGoSg0TkKOaC1XgoPyaBwC1DHRiUIHwC96OvpFFOlBdzlRc/ 7/DZMAPLh6bAig0Pq5s/hiiYmv9Jox4vaFYfKsxn1yqXeblJVYIPfKM6TcxZ/YM43HTJ GzZrQI5cwxI+651I2E0QKKdDOhyRJtBs6cWl0DZ/n1jx9d5oaxHGfwGz2GqTx+VCsDtT CYM38/RqhQOzILVpJMe1vWZhACclb9UWXHG4xY7kOCz11G/H6SQ2sgYk0M3et1gylvk5 346g== X-Received: by 10.229.60.196 with SMTP id q4mr3154338qch.85.1364932644235; Tue, 02 Apr 2013 12:57:24 -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 g6sm3786799qav.6.2013.04.02.12.57.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 12:57:22 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2D953691-1769-424E-9015-7084503F43CE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <1B54035F-CEA5-4433-BD4E-8D1E0FAB2E21@bbn.com> Date: Tue, 2 Apr 2013 16:57:13 -0300 Message-Id: <05B9BB4F-9FCF-41F8-963C-CFE6826756E3@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> <1B54035F-CEA5-4433-BD4E-8D1E0FAB2E21@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkmsEOxn8D/X2xdKhNQnXT+1GAazH0dDd3yUmbBczpwaxYvLQZmfeEpkL3fSlFr4pQruul1 Cc: IRTF CFRG , Russ Housley , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:57:29 -0000 --Apple-Mail=_2D953691-1769-424E-9015-7084503F43CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Richard, The integrity check of the header is effective if as mentioned in the = subsequent message in that thread = http://www.ietf.org/mail-archive/web/jose/current/msg01909.html you = implement the counter measure=20 recommended for RSA1_5 in https://tools.ietf.org/rfc/rfc3218.txt = continuing with a random CMK will cause the integrity check to fail and = stop the oracle. Richard is correct that there are two views on this, one where integrity = protecting the envelope is good security and prevents against some known = and perhaps unknown attacks (harder to prove), and others who see = multiple recipients of the same encrypted body as a more important use = case than the integrity protection. Some of us are trying to find a way to accommodate both.=20 The opinion of the CFRG on the value or non-value of integrity = protecting the envelope information might be informative, though I think = the last time we tried that the recommendation was for integrity = protection, though at the time the trade off wasn't as clear. Regards John B. On 2013-04-02, at 4:05 PM, Richard Barnes wrote: > John, >=20 > I don't think you've really answered Russ's question. You've provided = a *historical* reason, but not a *technical* reason why JOSE doesn't = follow the same approach as CMS. >=20 >=20 > On Apr 2, 2013, at 1:59 PM, John Bradley wrote: >=20 >> Russ, >>=20 >> We are close to those approaches. However nether of those address = using the Additional Authenticated Data(AAD). They mention that it = exists as an input but nothing more. >>=20 >> A difference between JOSE and CMS is that CMS allows non AEAD block = ciphers, where JOSE requires all block cyphers to be AEAD. >=20 >> That in theory allows us to use the AAD to integrity protect the = envelope information including the identifier for the key wrap or key = agreement. >=20 > The only reason JOSE has this requirement is because the header has to = be integrity-protected. So this is circular reasoning. >=20 >=20 >> In CMS the recipient-info values are not normally integrity = protected. =20 >>=20 >> This tends to lead to a long discussion about if there is a real = requirement to integrity protect them. =20 >>=20 >> In JOSE we decided to integrity protect the recipient-info values to = prevent things like backwards computability attacks. =20 >=20 > The author of the backward-compatibility attack paper himself has said = on the JOSE list that header integrity protection does not prevent BC = attacks. > """ > ... it does not matter, if he modifies an existing > secure object or creates a totally new object encrypted with an = insecure > algorithm and appends it to the document. > """ > >=20 > Do you have some other reason for integrity-protecting the = recipient-info? =20 >=20 >=20 >> This works just fine for one recipient but presents a problem using = GCM for multiple recipients if the AAD is used to protect the = recipient-info values. >>=20 >> That is the readers digest explanation on why those RFC are not = sufficient on there own to answer the question of multiple recipients = with integrity protected recipient-info. >>=20 >> I expect some people to chime in that we don't need to integrity = protect recipient-info. >=20 > >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >>=20 >> Regards >> John B. >>=20 >> On 2013-04-02, at 1:12 PM, Russ Housley wrote: >>=20 >>> Jim: >>>=20 >>> RFC 5084 and RFC 6476 both show approaches to the use of = authenticated encryption with CMS. Is there some reason that JOSE is = not following one of these approaches? >>>=20 >>> Russ >>>=20 >>>=20 >>> On Apr 2, 2013, at 11:59 AM, John Bradley wrote: >>>=20 >>>> Jim, >>>>=20 >>>> I don't think Mike was proposing that as a solution, but rather an = attempt to characterize the issue. >>>>=20 >>>> 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. >>>>=20 >>>> In a later email I asked David if we have the same or similar issue = with his AES-CBC+HMAC.=20 >>>>=20 >>>> 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. >>>>=20 >>>> John B. >>>>=20 >>>> On 2013-04-02, at 12:48 PM, "Jim Schaad" = wrote: >>>>=20 >>>>> Mike, >>>>>=20 >>>>> I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >>>>> 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 >>>>>=20 >>>>> Hi David, >>>>>=20 >>>>> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >>>>>=20 >>>>> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >>>>> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >>>>>=20 >>>>> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >>>>>=20 >>>>> = Thanks, >>>>> -- = Mike >>>>>=20 >>>>> 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 >>>>>=20 >>>>> Hi Jim, >>>>>=20 >>>>> From: Jim Schaad >>>>> Date: Wednesday, March 27, 2013 6:43 PM >>>>> To: David McGrew >>>>> Cc: "cfrg@irtf.org" >>>>> Subject: GCM nonce reuse question >>>>>=20 >>>>> David, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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? >>>>>=20 >>>>>=20 >>>>> 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". >>>>>=20 >>>>> Specifically the current way that GCM mode is being used in JOSE = is >>>>>=20 >>>>> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >>>>> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >>>>>=20 >>>>> As the key, nonce and plain text are fixed it would produce the = same encrypted text value but different authentication tags. >>>>>=20 >>>>>=20 >>>>> Can't do that. Each invocation of the encryption operation needs = a distinct nonce, unless all of the encryption operation inputs are = identical. >>>>>=20 >>>>> Many thanks for calling this out, Jim. >>>>>=20 >>>>> David >>>>>=20 >>>>> Jim >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> http://www.irtf.org/mailman/listinfo/cfrg >>>=20 >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 --Apple-Mail=_2D953691-1769-424E-9015-7084503F43CE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDAyMTk1NzE0WjAjBgkqhkiG9w0BCQQxFgQUhMJf8w0J XdpTpRgX0UKhM3HqzIIwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAaCQgQkOLnoTIGjSB67F3A4E4GOXAgc2eDiCSROLy Y8hP54nQKDHjVhp5IntW1y72xj1iRzeslN/Yn2hyHHuBqM5sBqNjkSNA9YfMI6mYIUNgKX5RYGnV pDFh5PchsR8fRSkkQra3o8sYPQpM1GBfBN2BeWyQanvw6VTSMkBKKyzsVge/pJpmH4Fw2WX/5bT6 tCrzcdRkugdJA4V75pGZ4LnDEJDgFmLV7AbSL+ZpRDreJHzJhshs+0/6GWL9LQ26nengmzqNCj3v b5JW+Cv+L1cfP2aNW6fS6nieR9a4vb+tE8q7KGGYUVVJoxef0rkRq/Zt2ucpHcYr7odztWsejQAA AAAAAA== --Apple-Mail=_2D953691-1769-424E-9015-7084503F43CE-- From ve7jtb@ve7jtb.com Tue Apr 2 13:09:33 2013 Return-Path: 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 ; 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 ; 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 ; Tue, 2 Apr 2013 13:09:31 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bs12so477187qab.18 for ; 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 In-Reply-To: <489782CF-0C9F-4DFE-A82D-087247209933@vigilsec.com> Date: Tue, 2 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 X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnOSLd8V7cktIynm5+MIU1IUIfDi6yGewtTGI80MCYmAIdvE1kozu/u5IexN+RwCTAs6lPH Cc: IRTF CFRG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:09:33 -0000 --Apple-Mail=_7CBDF288-95BD-4F54-8A06-28379093DE60 Content-Type: multipart/alternative; boundary="Apple-Mail=_7C54BED8-45F5-423E-8AF8-E0FB14C2CB55" --Apple-Mail=_7C54BED8-45F5-423E-8AF8-E0FB14C2CB55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 wrote: > John: >=20 >> In CMS the recipient-info values are not normally integrity = protected. >=20 > 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. >=20 > Russ --Apple-Mail=_7C54BED8-45F5-423E-8AF8-E0FB14C2CB55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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

= --Apple-Mail=_7C54BED8-45F5-423E-8AF8-E0FB14C2CB55-- --Apple-Mail=_7CBDF288-95BD-4F54-8A06-28379093DE60 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDAyMjAwOTIxWjAjBgkqhkiG9w0BCQQxFgQUiyMiomW8 e7dV5OvJf4g/53dscVYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAHmFnaybJF62MRVX1FWBasxJY/zr9Spki23AK5s5l 8WRpZ9biE+DaJipU+JUXOU+GjtvRR1B7ZBzi1evngcmuMng32J6y5CdJxcT7UIZmn4gbDTNWMrLZ O6EFTCxFtvtmOawTYqP5t1Y1AvvjUQAKx5zGiNOexQ9b2jLwxoCy+N9hsL/gqmBKtWguE8S5LUYR kzSVoWaPWWM/XSldky3TzCgLoPZxCpYlyDOVbmbcTM4dsgCvULnE8qYOjHxdiVAjH2HYwy+YdugP Fu/UIhhB9Pw17QjeR98fEwmnjdGzyAaX2q2kXResZtVR3n0tNri8s8BH+ohGB61Ue5+PCswm1wAA AAAAAA== --Apple-Mail=_7CBDF288-95BD-4F54-8A06-28379093DE60-- From rbarnes@bbn.com Tue Apr 2 13:22:43 2013 Return-Path: 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 1204321F8DAC for ; Tue, 2 Apr 2013 13:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.849 X-Spam-Level: X-Spam-Status: No, score=-104.849 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_VISIT=2.3, RCVD_IN_DNSWL_MED=-4, 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 5fAKr+Ra1re4 for ; Tue, 2 Apr 2013 13:22:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7275221F8D26 for ; Tue, 2 Apr 2013 13:22:41 -0700 (PDT) Received: from ros-dhcp192-1-51-16.bbn.com ([192.1.51.16]:51107) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN7j5-000L64-Fy; Tue, 02 Apr 2013 16:22:39 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Richard Barnes In-Reply-To: <05B9BB4F-9FCF-41F8-963C-CFE6826756E3@ve7jtb.com> Date: Tue, 2 Apr 2013 16:22:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5954576B-383E-4928-9FE7-3422FC174C83@bbn.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> <1B54035F-CEA5-4433-BD4E-8D1E0FAB2E21@bbn.com> <05B9BB4F-9FCF-41F8-963C-CFE6826756E3@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: IRTF CFRG , Russ Housley , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:22:43 -0000 The countermeasure you mention is for timing attacks in general against = PKCS#1 v1.5. It doesn't have anything to do with integrity protection = of the header. The hunt for a concrete security benefit continues... --Richard On Apr 2, 2013, at 3:57 PM, John Bradley wrote: > Richard, >=20 > The integrity check of the header is effective if as mentioned in the = subsequent message in that thread = http://www.ietf.org/mail-archive/web/jose/current/msg01909.html you = implement the counter measure=20 > recommended for RSA1_5 in https://tools.ietf.org/rfc/rfc3218.txt = continuing with a random CMK will cause the integrity check to fail and = stop the oracle. >=20 > Richard is correct that there are two views on this, one where = integrity protecting the envelope is good security and prevents against = some known and perhaps unknown attacks (harder to prove), and others who = see multiple recipients of the same encrypted body as a more important = use case than the integrity protection. >=20 > Some of us are trying to find a way to accommodate both.=20 >=20 > The opinion of the CFRG on the value or non-value of integrity = protecting the envelope information might be informative, though I think = the last time we tried that the recommendation was for integrity = protection, though at the time the trade off wasn't as clear. >=20 > Regards > John B. >=20 > On 2013-04-02, at 4:05 PM, Richard Barnes wrote: >=20 >> John, >>=20 >> I don't think you've really answered Russ's question. You've = provided a *historical* reason, but not a *technical* reason why JOSE = doesn't follow the same approach as CMS. >>=20 >>=20 >> On Apr 2, 2013, at 1:59 PM, John Bradley wrote: >>=20 >>> Russ, >>>=20 >>> We are close to those approaches. However nether of those address = using the Additional Authenticated Data(AAD). They mention that it = exists as an input but nothing more. >>>=20 >>> A difference between JOSE and CMS is that CMS allows non AEAD block = ciphers, where JOSE requires all block cyphers to be AEAD. >>=20 >>> That in theory allows us to use the AAD to integrity protect the = envelope information including the identifier for the key wrap or key = agreement. >>=20 >> The only reason JOSE has this requirement is because the header has = to be integrity-protected. So this is circular reasoning. >>=20 >>=20 >>> In CMS the recipient-info values are not normally integrity = protected. =20 >>>=20 >>> This tends to lead to a long discussion about if there is a real = requirement to integrity protect them. =20 >>>=20 >>> In JOSE we decided to integrity protect the recipient-info values to = prevent things like backwards computability attacks. =20 >>=20 >> The author of the backward-compatibility attack paper himself has = said on the JOSE list that header integrity protection does not prevent = BC attacks. >> """ >> ... it does not matter, if he modifies an existing >> secure object or creates a totally new object encrypted with an = insecure >> algorithm and appends it to the document. >> """ >> >>=20 >> Do you have some other reason for integrity-protecting the = recipient-info? =20 >>=20 >>=20 >>> This works just fine for one recipient but presents a problem using = GCM for multiple recipients if the AAD is used to protect the = recipient-info values. >>>=20 >>> That is the readers digest explanation on why those RFC are not = sufficient on there own to answer the question of multiple recipients = with integrity protected recipient-info. >>>=20 >>> I expect some people to chime in that we don't need to integrity = protect recipient-info. >>=20 >> >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Regards >>> John B. >>>=20 >>> On 2013-04-02, at 1:12 PM, Russ Housley = wrote: >>>=20 >>>> Jim: >>>>=20 >>>> RFC 5084 and RFC 6476 both show approaches to the use of = authenticated encryption with CMS. Is there some reason that JOSE is = not following one of these approaches? >>>>=20 >>>> Russ >>>>=20 >>>>=20 >>>> On Apr 2, 2013, at 11:59 AM, John Bradley wrote: >>>>=20 >>>>> Jim, >>>>>=20 >>>>> I don't think Mike was proposing that as a solution, but rather an = attempt to characterize the issue. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> In a later email I asked David if we have the same or similar = issue with his AES-CBC+HMAC.=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On 2013-04-02, at 12:48 PM, "Jim Schaad" = wrote: >>>>>=20 >>>>>> Mike, >>>>>>=20 >>>>>> I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>>=20 >>>>>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >>>>>> 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 >>>>>>=20 >>>>>> Hi David, >>>>>>=20 >>>>>> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >>>>>>=20 >>>>>> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >>>>>> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >>>>>>=20 >>>>>> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >>>>>>=20 >>>>>> = Thanks, >>>>>> -- = Mike >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> Hi Jim, >>>>>>=20 >>>>>> From: Jim Schaad >>>>>> Date: Wednesday, March 27, 2013 6:43 PM >>>>>> To: David McGrew >>>>>> Cc: "cfrg@irtf.org" >>>>>> Subject: GCM nonce reuse question >>>>>>=20 >>>>>> David, >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>>>=20 >>>>>> 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". >>>>>>=20 >>>>>> Specifically the current way that GCM mode is being used in JOSE = is >>>>>>=20 >>>>>> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >>>>>> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >>>>>>=20 >>>>>> As the key, nonce and plain text are fixed it would produce the = same encrypted text value but different authentication tags. >>>>>>=20 >>>>>>=20 >>>>>> Can't do that. Each invocation of the encryption operation = needs a distinct nonce, unless all of the encryption operation inputs = are identical. >>>>>>=20 >>>>>> Many thanks for calling this out, Jim. >>>>>>=20 >>>>>> David >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Cfrg mailing list >>>>> Cfrg@irtf.org >>>>> http://www.irtf.org/mailman/listinfo/cfrg >>>>=20 >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> http://www.irtf.org/mailman/listinfo/cfrg >>>=20 >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >>=20 >=20 From rbarnes@bbn.com Tue Apr 2 13:39:50 2013 Return-Path: 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 9E0C021F8CA1 for ; Tue, 2 Apr 2013 13:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.616 X-Spam-Level: X-Spam-Status: No, score=-105.616 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, 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 3D7rg0JQg2kA for ; Tue, 2 Apr 2013 13:39:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C568221F862A for ; Tue, 2 Apr 2013 13:39:49 -0700 (PDT) Received: from ros-dhcp192-1-51-16.bbn.com ([192.1.51.16]:51162) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN7zg-000LV6-0d; Tue, 02 Apr 2013 16:39:48 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Richard Barnes In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675A60AB@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 2 Apr 2013 16:39:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B183F0C52@xmb-rcd-x04.cisco.com> <9DF44126-18A2-4C28-A470-B3B2DB4A48A3@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943675A60AB@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: "David McGrew \(mcgrew\)" , "cfrg@irtf.org" , Jim Schaad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:39:50 -0000 Without having done any real analysis, I think that your conclusion is = correct, i.e., that IV re-use in draft-mcgrew-aead-aes-cbc-hmac-sha2 is = similar to IV re-use in CBC. However, I'm not sure what good that information is. JOSE still has to = support GCM. --Richard On Apr 2, 2013, at 11:00 AM, Mike Jones = wrote: > Actually, I was about to ask a similar question. It=92s actually my = assumption that it likely OK to perform multiple = draft-mcgrew-aead-aes-cbc-hmac-sha2 operations where the Plaintext, = Initialization Vector, and Key inputs are constant and the Additional = Associated Data varies. My reasoning is as follows=85 > =20 > The Authentication Tag outputs are the result of HMAC-SHA-2 operations = over a combination of the AAD and Ciphertext using the HMAC Key. For = there to be a problem with the above, there would have to be a problem = with using the same HMAC key on multiple distinct inputs. But for there = to be a problem with using the same HMAC key on multiple distinct = inputs, I believe that effectively rests on whether there=92s a problem = using the underlying hash function on multiple inputs. Which if true, = would mean that the cryptographic hash function doesn=92t have the = desired cryptographic properties in the first place. > =20 > I=92ll readily admit that there could easily be a flaw in my chain of = logic. But on the surface of it, it seems like = draft-mcgrew-aead-aes-cbc-hmac-sha2 operations should be OK in the = multiple recipients case in a way that GCM isn=92t. > =20 > Thoughts? > =20 > -- Mike > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Tuesday, April 02, 2013 7:41 AM > To: David McGrew (mcgrew) > Cc: Mike Jones; Jim Schaad; cfrg@irtf.org > Subject: Re: GCM nonce reuse question > =20 > David, > =20 > For draft-mcgrew-aead-aes-cbc-hmac-sha2 is the issue the same for = using the same MAC_KEY, ENC_KEY , IV and plaintext with different = AEAD. > =20 > I am guessing no good can come of that, but is it a known problem? > =20 > The other question is if doing the same thing but making the MAC_KEY = different, while keeping the same ENC_KEY for each AEAD avoids the = problem? > =20 > The question comes up when trying to use encryption to multiple = recipients where you are trying to use the same IV and ENC_KEY but allow = for integrity protecting the algorithm identifier and other data that = may be different for each recipient. > =20 > I expect that the simple solution of not integrity protecting the = algorithm and key_id for the key wrapping and allowing RSA-OAEP to be = replaced with RSA1_5 or other alg substitution attacks is no longer a = recommended practice. =20 > =20 > Perhaps using the AEAD to integrity protect the envelope information = is something that only really works in the single recipient case, and = some other method is needed for multiple recipients. > =20 > Thanks=20 > John B. > =20 > On 2013-04-02, at 10:32 AM, "David McGrew (mcgrew)" = wrote: >=20 >=20 > Hi Mike, > =20 > From: Mike Jones > Date: Monday, April 1, 2013 8:54 PM > To: David McGrew , Jim Schaad = > Cc: "cfrg@irtf.org" , John Bradley > Subject: RE: GCM nonce reuse question > =20 > Hi David, > =20 > In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: > =20 > (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) > (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) > =20 > where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? > =20 > Yes, that looks good. > =20 > David > =20 > =20 > = Thanks, > -- = Mike > =20 > 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 > =20 > Hi Jim, > =20 > From: Jim Schaad > Date: Wednesday, March 27, 2013 6:43 PM > To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question > =20 > David, > =20 > 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. > =20 > 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? > =20 > =20 > 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". > =20 > Specifically the current way that GCM mode is being used in JOSE is > =20 > Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, = plain text) > Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, = plain text) > =20 > As the key, nonce and plain text are fixed it would produce the same = encrypted text value but different authentication tags. > =20 > =20 > Can't do that. Each invocation of the encryption operation needs a = distinct nonce, unless all of the encryption operation inputs are = identical. > =20 > Many thanks for calling this out, Jim. > =20 > David > =20 > Jim > =20 > =20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From ietf@augustcellars.com Wed Apr 3 23:26:22 2013 Return-Path: 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 D393C21F95F4 for ; Wed, 3 Apr 2013 23:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 I20t+l1bXhQj for ; Wed, 3 Apr 2013 23:26:21 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A28BB21F95F0 for ; Wed, 3 Apr 2013 23:26:21 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 11ACE38EA7 for ; Wed, 3 Apr 2013 23:26:21 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 3 Apr 2013 23:25:44 -0700 Message-ID: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4w8b10meAP4tSuRQOj77FabgFZww== Content-Language: en-us Subject: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 06:26:23 -0000 Request for Information The JOSE working group is having an internal argument about the need to protect the various header information in an encrypted or signed message. The quick question is which algorithm information and algorithm parameters need to be included in integrity portion of the signature or encryption operation in order to protect those parameters. There are a couple of theoretical attacks that can be launched against various algorithms that then require protection an example of such a parameter is the IV for the AES-CBC/HMAC algorithm that has been proposed. In this case the IV is protected by the algorithm itself and therefore does not need to be externally protected by the JOSE data structures. In RFC 6211, there is a new CMS attribute that was defined for protection of the signature algorithm as I felt there was a potential attack that could be exploited. Looking at the RSA v1.5 signature algorithm, one cannot change the hash algorithm as the hash algorithm is encoded as part of the padding for the signature Looking at the RSA PSS signature, there is the possibility that a hash algorithm of the same length could be substituted unless external restrictions are applied. Thus one could potentially substitute a RIPEMD-160 hash on the content for a SHA-1 hash. As long as the hashes match and there is no externally applied restriction that the hash algorithm used to build the PSS internals is same as the content hash then it would verify. It is unclear if there is an attack that involves multiple hash algorithms that is better than a birthday attack on a single algorithm as I don't know if this has ever been studied. CMS also defined an attribute that can be included in the signature computation for specifying a certificate that is to be used in the validation of the signature on the CMS object. I.e. where to get the public key and the base restrictions for that are imposed on that public key by the certificate issuer. Questions that we would like to see discussed: 1. For signature operations, what parameters related to the signature algorithm and what parameters related to a key need to be protected by the signature operation to prevent real and theoretical attacks on JOSE signed structures. We would like to get the real and theoretical attacks separated with a weight on the theoretical attacks for the potential to become real. 2. For MAC operations, what parameters related to the MAC algorithm and what parameters related to the key need to be protected by the MAC operation to prevent real and theoretical attacks on a JOSE MAC structure. 3. For key management operations (how the content encryption key is given to the recipient), what parameters related to the algorithms need to be protected as part of the AEAD algorithm. 4. For content encryption, what parameter related to the AEAD algorithm need to be protected by the AEAD algorithm (and are not already protected) need to be included. Is there any benefit in double protecting parameters such as the IV in case a new AEAD algorithm does not directly protect that value. Looking at the key to be protected, we don't care if the recipient cannot find the correct key or misinterprets what the key identifier is. What we want to make sure is that an attacker would be unable to change the recipients interpretation of what key is to be used and still get a successful validation. Jim Schaad JOSE Co-Chair From kmigoe@nsa.gov Thu Apr 4 07:48:16 2013 Return-Path: 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 BB18421F850F for ; Thu, 4 Apr 2013 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pa4Fbjs44gnL for ; Thu, 4 Apr 2013 07:48:15 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id A566421F9425 for ; Thu, 4 Apr 2013 07:48:08 -0700 (PDT) X-TM-IMSS-Message-ID: <34f4e8a20026cad6@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 34f4e8a20026cad6 ; Thu, 4 Apr 2013 10:49:26 -0400 Received: from MSMR-GH1-UEA09.corp.nsa.gov (10.215.224.12) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 4 Apr 2013 10:47:42 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA09.corp.nsa.gov ([10.215.224.12]) with mapi id 14.01.0289.001; Thu, 4 Apr 2013 10:47:42 -0400 From: "Igoe, Kevin M." To: 'Jim Schaad' , "cfrg@irtf.org" Thread-Topic: [Cfrg] What Algorithm information needs to be authenticated? Thread-Index: Ac4w8b10meAP4tSuRQOj77FabgFZwwAPrVJA Date: Thu, 4 Apr 2013 14:47:41 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA8B6AF16B@MSMR-GH1-UEA03.corp.nsa.gov> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> In-Reply-To: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:48:16 -0000 OK CFRG, Jim has given us 4 concrete issues to address. 1. For signature operations, what parameters related to the signature algo= rithm and what parameters related to a key need to be protected by the sign= ature operation to prevent real and theoretical attacks on JOSE signed structures. We would like to get the real and theoretical attacks separated with a weight on the theoretical attacks for the potential to bec= ome real. 2. For MAC operations, what parameters related to the MAC algorithm and wh= at parameters related to the key need to be protected by the MAC operation = to prevent real and theoretical attacks on a JOSE MAC structure. 3. For key management operations (how the content encryption key is given = to the recipient), what parameters related to the algorithms need to be pro= tected as part of the AEAD algorithm. 4. For content encryption, what parameter related to the AEAD algorithm ne= ed to be protected by the AEAD algorithm (and are not already protected) ne= ed to be included. Is there any benefit in double protecting parameters su= ch as the IV in case a new AEAD algorithm does not directly protect that va= lue. - A residual risk common to all of these is proper storage of secret keys. While outside the scope of JOSE, I believe this should be called out in t= he security section as an issue implementers must address.) - Proper protection of the secret signing keys is a very real issue. - With MACs, since the integrity keys are shorter lived than the signing ke= ys, the risk level is (in most applications) much lower than with digital signatures. - ECDSA depends upon a random input k provided by the signer. This input=20 should be uniformly distributed in the range [1, q], where q is the size of the cryptographic subgroup of the curve (a prime). NIST has good guidance on this. One of their DRBGs makes a good tool for forming= =20 k. Thankfully NIST has thought long and hard about these issues. We need= to=20 point folks at the proper NIST special pubs. Additional non-NIST referenc= es=20 would be a very welcome! =20 - MACs don't provide non-repudiation since more than one person has the integrity key. If non-repudiation is required (typically only needed if legal culpability might become an issue), a true signature should be used. - OK folks, does anyone have an argument as to why authentication of the=20 AEAD IVs is required to address a concrete security issue? I've been=20 mulling this over & haven't come up with one yet. Keep in mind that one of the use cases for JOSE is the W3C web cryptography API, so there are likely to use this in the future to build JOSE based applications=20 beyond what we are currently envisioning. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Jim Schaad > Sent: Thursday, April 04, 2013 2:26 AM > To: cfrg@irtf.org > Subject: [Cfrg] What Algorithm information needs to be authenticated? >=20 > Request for Information >=20 > The JOSE working group is having an internal argument about the need to > protect the various header information in an encrypted or signed > message. > The quick question is which algorithm information and algorithm > parameters > need to be included in integrity portion of the signature or encryption > operation in order to protect those parameters. >=20 > There are a couple of theoretical attacks that can be launched against > various algorithms that then require protection an example of such a > parameter is the IV for the AES-CBC/HMAC algorithm that has been > proposed. > In this case the IV is protected by the algorithm itself and therefore > does > not need to be externally protected by the JOSE data structures. >=20 > In RFC 6211, there is a new CMS attribute that was defined for > protection of > the signature algorithm as I felt there was a potential attack that > could be > exploited. >=20 > Looking at the RSA v1.5 signature algorithm, one cannot change the hash > algorithm as the hash algorithm is encoded as part of the padding for > the > signature >=20 > Looking at the RSA PSS signature, there is the possibility that a hash > algorithm of the same length could be substituted unless external > restrictions are applied. Thus one could potentially substitute a > RIPEMD-160 hash on the content for a SHA-1 hash. As long as the > hashes > match and there is no externally applied restriction that the hash > algorithm > used to build the PSS internals is same as the content hash then it > would > verify. It is unclear if there is an attack that involves multiple > hash > algorithms that is better than a birthday attack on a single algorithm > as I > don't know if this has ever been studied. >=20 > CMS also defined an attribute that can be included in the signature > computation for specifying a certificate that is to be used in the > validation of the signature on the CMS object. I.e. where to get the > public > key and the base restrictions for that are imposed on that public key > by the > certificate issuer. >=20 > Questions that we would like to see discussed: >=20 > 1. For signature operations, what parameters related to the signature > algorithm and what parameters related to a key need to be protected by > the > signature operation to prevent real and theoretical attacks on JOSE > signed > structures. We would like to get the real and theoretical attacks > separated with a weight on the theoretical attacks for the potential to > become real. >=20 > 2. For MAC operations, what parameters related to the MAC algorithm > and > what parameters related to the key need to be protected by the MAC > operation > to prevent real and theoretical attacks on a JOSE MAC structure. >=20 > 3. For key management operations (how the content encryption key is > given > to the recipient), what parameters related to the algorithms need to be > protected as part of the AEAD algorithm. >=20 > 4. For content encryption, what parameter related to the AEAD > algorithm > need to be protected by the AEAD algorithm (and are not already > protected) > need to be included. Is there any benefit in double protecting > parameters > such as the IV in case a new AEAD algorithm does not directly protect > that > value. >=20 > Looking at the key to be protected, we don't care if the recipient > cannot > find the correct key or misinterprets what the key identifier is. What > we > want to make sure is that an attacker would be unable to change the > recipients interpretation of what key is to be used and still get a > successful validation. >=20 > Jim Schaad > JOSE Co-Chair >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From kmigoe@nsa.gov Thu Apr 4 09:12:47 2013 Return-Path: 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 AE4DD21F9644 for ; Thu, 4 Apr 2013 09:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 AzeHsYQ9ep9Z for ; Thu, 4 Apr 2013 09:12:47 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id BE74521F9643 for ; Thu, 4 Apr 2013 09:12:46 -0700 (PDT) X-TM-IMSS-Message-ID: <3542c4520026e98d@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 3542c4520026e98d ; Thu, 4 Apr 2013 12:14:29 -0400 Received: from MSMR-GH1-UEA01.corp.nsa.gov (10.215.225.4) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 4 Apr 2013 12:12:45 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA01.corp.nsa.gov ([10.215.225.4]) with mapi id 14.01.0289.001; Thu, 4 Apr 2013 12:12:44 -0400 From: "Igoe, Kevin M." To: "cfrg@irtf.org" Thread-Topic: Dragonfly Thread-Index: Ac4xTz0UvgMuKP4qQOKypz6VBELHhg== Date: Thu, 4 Apr 2013 16:12:43 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA8CBBEE62@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBEE62MSMRGH1UEA03cor_" MIME-Version: 1.0 Subject: [Cfrg] Dragonfly X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:12:47 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBEE62MSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd look to put out a Last Call on Dan Harkin's Dragonfly, draft-irtf-cfrg-dragonfly-01. The design looks mature, it addresses a real need, and no one has raised any issues. Feel free to speak up and share your insights with the mailing list. ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov | of thinking we used when we created them." | - Albert Einstein - ----------------+-------------------------------------------------- --_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBEE62MSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I’d look to put out a Last Call on Dan Harkin’s Dragonfly,=
            draft-irtf-cfrg-dragonfly-01.
The design looks mature, it addresses a real need, and no one has
raised any issues.  Feel free to speak up and share your insights=
with the mailing list.
&nbs= p;
 
----------------+-------------------------= -------------------------
Kevin M. Igoe   | "We can't sol= ve problems by using the same kind
kmigoe@nsa.gov  | of thinking we used whe= n we created them."
       &nbs= p;        |     = ;         - Albert Einstein -
----------------+-------------------------= -------------------------
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBEE62MSMRGH1UEA03cor_-- From kmigoe@nsa.gov Thu Apr 4 09:44:22 2013 Return-Path: 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 5DF6621F8D52 for ; Thu, 4 Apr 2013 09:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9Igu5dzf5Q3A for ; Thu, 4 Apr 2013 09:44:21 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF3F21F8E4C for ; Thu, 4 Apr 2013 09:44:20 -0700 (PDT) X-TM-IMSS-Message-ID: <5927ec4900293a5a@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 5927ec4900293a5a ; Thu, 4 Apr 2013 12:43:21 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov (10.215.228.141) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 4 Apr 2013 12:44:19 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) with mapi id 14.01.0289.001; Thu, 4 Apr 2013 12:44:18 -0400 From: "Igoe, Kevin M." To: "cfrg@irtf.org" Thread-Topic: [Cfrg] request for comments: ZSS Short Signature Scheme for SS and BN Curves Thread-Index: Ac4lkatAl+acAzUUTfqTMjf28qdPGABju82wAousCJA= Date: Thu, 4 Apr 2013 16:44:16 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA8CBBFE8A@MSMR-GH1-UEA03.corp.nsa.gov> References: <04920BD67C651C469D0387704CD7692A74B0844B94@21ct-exg07.21technologies.com> In-Reply-To: <04920BD67C651C469D0387704CD7692A74B0844B94@21ct-exg07.21technologies.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBFE8AMSMRGH1UEA03cor_" MIME-Version: 1.0 Cc: "mcgrew@cisco.com" Subject: Re: [Cfrg] request for comments: ZSS Short Signature Scheme for SS and BN Curves X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:44:22 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBFE8AMSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've read over these drafts and find them interesting. They use the ZSS Sh= ort Signature proposed by Zhang, Safavi-Naini and Susilo in 2004, so the basic system has survived= 9 years of scrutiny. It utilizes the mathematics that underpins identity based encryption, alon= g the lines explored by Sakai and Kasahara. Note: I am a connoisseur of paring based cryptography, but not an expert. = (A connoisseur can treat such esoterica as Weil reciprocity (which is where I got stuck) as being a= miracle and move on, an expert cannot. Being a connoisseur is far, far easier than being an expert.= ) I believe this is worthy of consideration by the CFRG. The underlying math= ematics is based on deep results by some of the greatest 20th century mathematicians, so we can safe= ly take that as being sound. The devil, as always, is in the implementation details. From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Lau= ra Hitt Sent: Friday, March 22, 2013 1:27 PM To: cfrg@irtf.org Subject: [Cfrg] request for comments: ZSS Short Signature Scheme for SS and= BN Curves I have recently submitted (as an Individual) two I-Ds and would greatly app= reciate any comments you are able to offer. They pertain to the ZSS short = signature scheme from bilinear pairings on supersingular elliptic curves an= d on Barreto-Naerhig elliptic curves. http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zss-00.txt http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zssbn-00.txt Thank you! Laura Hitt --_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBFE8AMSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve read over t= hese drafts and find them interesting.  They use the ZSS Short Signatu= re proposed

by Zhang, Safavi-Naini= and Susilo in 2004, so the basic system has survived 9 years of scrutiny.<= o:p>

It  utilizes the = mathematics that underpins identity based encryption, along the lines explo= red by

Sakai and Kasahara.

 

Note: I am a connoisse= ur of paring based cryptography, but not an expert.   (A connoiss= eur can treat

such  esoterica a= s Weil reciprocity (which is where I got stuck) as being a miracle and move= on, an

expert cannot. Being a= connoisseur is far, far easier than being an expert.)

 

I believe this is wort= hy of consideration by the CFRG.  The underlying mathematics is based = on deep

results by some of the= greatest 20th century mathematicians, so we can safely take tha= t as being sound.

 The devil, as al= ways, is in the implementation details.

 

 

From: cfrg-bou= nces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Laura Hitt
Sent: Friday, March 22, 2013 1:27 PM
To: cfrg@irtf.org
Subject: [Cfrg] request for comments: ZSS Short Signature Scheme for= SS and BN Curves

 

<my apologies if this w= as sent twice, I saw strange behavior on my end, so thought I’d try a= gain.>

 

I have recently submitted (as an Individual) two I-D= s and would greatly appreciate any comments you are able to offer.  Th= ey pertain to the ZSS short signature scheme from bilinear pairings on supe= rsingular elliptic curves and on Barreto-Naerhig elliptic curves.

 

http://www.ietf.org/internet-drafts/draft-irtf-cfrg-= zss-00.txt

http://www.ietf.org/internet-drafts/draft-irtf-cfr= g-zssbn-00.txt

 

Thank you!
Laura Hitt

 

 

 

--_000_3C4AAD4B5304AB44A6BA85173B4675CA8CBBFE8AMSMRGH1UEA03cor_-- From ietf@augustcellars.com Thu Apr 4 10:03:52 2013 Return-Path: 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 9B84B21F8CDF for ; Thu, 4 Apr 2013 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lqvRX4Cd1qZ5 for ; Thu, 4 Apr 2013 10:03:51 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id B707C21F8BF0 for ; Thu, 4 Apr 2013 10:03:51 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0E3142CA42; Thu, 4 Apr 2013 10:03:50 -0700 (PDT) From: "Jim Schaad" To: "'Igoe, Kevin M.'" , References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <3C4AAD4B5304AB44A6BA85173B4675CA8B6AF16B@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA8B6AF16B@MSMR-GH1-UEA03.corp.nsa.gov> Date: Thu, 4 Apr 2013 10:03:13 -0700 Message-ID: <011501ce3156$4bcdf3a0$e369dae0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGRAM9+6rStRPMOE8tz/T1luTFCLQKz4c9BmSsKXkA= Content-Language: en-us Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:03:52 -0000 Kevin, > -----Original Message----- > From: Igoe, Kevin M. [mailto:kmigoe@nsa.gov] > Sent: Thursday, April 04, 2013 7:48 AM > To: 'Jim Schaad'; cfrg@irtf.org > Subject: RE: [Cfrg] What Algorithm information needs to be authenticated? > > OK CFRG, Jim has given us 4 concrete issues to address. > > > 1. For signature operations, what parameters related to the signature > algorithm and what parameters related to a key need to be protected by the > signature operation to prevent real and theoretical attacks on JOSE signed > structures. We would like to get the real and theoretical attacks > separated with a weight on the theoretical attacks for the potential to become > real. > > 2. For MAC operations, what parameters related to the MAC algorithm and > what parameters related to the key need to be protected by the MAC > operation to prevent real and theoretical attacks on a JOSE MAC structure. > > 3. For key management operations (how the content encryption key is given > to the recipient), what parameters related to the algorithms need to be > protected as part of the AEAD algorithm. > > 4. For content encryption, what parameter related to the AEAD algorithm > need to be protected by the AEAD algorithm (and are not already protected) > need to be included. Is there any benefit in double protecting parameters > such as the IV in case a new AEAD algorithm does not directly protect that > value. > > - A residual risk common to all of these is proper storage of secret keys. > While outside the scope of JOSE, I believe this should be called out in the > security section as an issue implementers must address.) > - Proper protection of the secret signing keys is a very real issue. I agree that both of the previous issues should be addressed as security considerations. I can check but I already believe they are. > - With MACs, since the integrity keys are shorter lived than the signing keys, > the risk level is (in most applications) much lower than with digital > signatures. I wish this was a true statement. I have seen a number of circumstances where MAC keys are in long lived situations on the order of years. Places such as routers, RADIUS servers and so forth. Thus while we can hope they are shorter lived I don't believe that we can make that as an assumption. > > - ECDSA depends upon a random input k provided by the signer. This input > should be uniformly distributed in the range [1, q], where q is > the size of the cryptographic subgroup of the curve (a prime). NIST has > good guidance on this. One of their DRBGs makes a good tool for forming > k. Thankfully NIST has thought long and hard about these issues. We need to > point folks at the proper NIST special pubs. Additional non-NIST references > would be a very welcome! > > - MACs don't provide non-repudiation since more than one person has the > integrity key. If non-repudiation is required (typically only needed > if legal culpability might become an issue), a true signature should be > used. I prefer the term data-origin rather than non-repudiation since I know what that the former means but don't know what the latter means as a technical term. This term has been argued about for the last 15 years on the PKIX mailing list and I don't want to get into that here. > > - OK folks, does anyone have an argument as to why authentication of the > AEAD IVs is required to address a concrete security issue? I've been > mulling this over & haven't come up with one yet. Keep in mind that one > of the use cases for JOSE is the W3C web cryptography API, so there > are likely to use this in the future to build JOSE based applications > beyond what we are currently envisioning. Are you talking about inside of the algorithm or outside of the algorithm for doing the authentication? In the case of the CBC/HMAC AEAD algorithm, as the authentication is computed on the encrypted text you cannot know if the unencrypted text is the correct text without knowing that the IV is also correct. You end up with about a 1 in 256 chance of decrypting the message and getting the correct padding with the wrong IV and then assuming that the resulting plain text is what was sent when it isn't. Jim > > > > -----Original Message----- > > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > > Of Jim Schaad > > Sent: Thursday, April 04, 2013 2:26 AM > > To: cfrg@irtf.org > > Subject: [Cfrg] What Algorithm information needs to be authenticated? > > > > Request for Information > > > > The JOSE working group is having an internal argument about the need > > to protect the various header information in an encrypted or signed > > message. > > The quick question is which algorithm information and algorithm > > parameters need to be included in integrity portion of the signature > > or encryption operation in order to protect those parameters. > > > > There are a couple of theoretical attacks that can be launched against > > various algorithms that then require protection an example of such a > > parameter is the IV for the AES-CBC/HMAC algorithm that has been > > proposed. > > In this case the IV is protected by the algorithm itself and therefore > > does not need to be externally protected by the JOSE data structures. > > > > In RFC 6211, there is a new CMS attribute that was defined for > > protection of the signature algorithm as I felt there was a potential > > attack that could be exploited. > > > > Looking at the RSA v1.5 signature algorithm, one cannot change the > > hash algorithm as the hash algorithm is encoded as part of the padding > > for the signature > > > > Looking at the RSA PSS signature, there is the possibility that a hash > > algorithm of the same length could be substituted unless external > > restrictions are applied. Thus one could potentially substitute a > > RIPEMD-160 hash on the content for a SHA-1 hash. As long as the > > hashes > > match and there is no externally applied restriction that the hash > > algorithm used to build the PSS internals is same as the content hash > > then it would verify. It is unclear if there is an attack that > > involves multiple hash algorithms that is better than a birthday > > attack on a single algorithm as I don't know if this has ever been > > studied. > > > > CMS also defined an attribute that can be included in the signature > > computation for specifying a certificate that is to be used in the > > validation of the signature on the CMS object. I.e. where to get the > > public key and the base restrictions for that are imposed on that > > public key by the certificate issuer. > > > > Questions that we would like to see discussed: > > > > 1. For signature operations, what parameters related to the signature > > algorithm and what parameters related to a key need to be protected by > > the signature operation to prevent real and theoretical attacks on > > JOSE signed > > structures. We would like to get the real and theoretical attacks > > separated with a weight on the theoretical attacks for the potential > > to become real. > > > > 2. For MAC operations, what parameters related to the MAC algorithm > > and what parameters related to the key need to be protected by the MAC > > operation to prevent real and theoretical attacks on a JOSE MAC > > structure. > > > > 3. For key management operations (how the content encryption key is > > given to the recipient), what parameters related to the algorithms > > need to be protected as part of the AEAD algorithm. > > > > 4. For content encryption, what parameter related to the AEAD > > algorithm need to be protected by the AEAD algorithm (and are not > > already > > protected) > > need to be included. Is there any benefit in double protecting > > parameters such as the IV in case a new AEAD algorithm does not > > directly protect that value. > > > > Looking at the key to be protected, we don't care if the recipient > > cannot find the correct key or misinterprets what the key identifier > > is. What we want to make sure is that an attacker would be unable to > > change the recipients interpretation of what key is to be used and > > still get a successful validation. > > > > Jim Schaad > > JOSE Co-Chair > > > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg From kmigoe@nsa.gov Thu Apr 4 10:14:56 2013 Return-Path: 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 5E9B221F90A1 for ; Thu, 4 Apr 2013 10:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Kz4U7vVvGT+e for ; Thu, 4 Apr 2013 10:14:55 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 234C921F8F22 for ; Thu, 4 Apr 2013 10:14:54 -0700 (PDT) X-TM-IMSS-Message-ID: <59438e6200294500@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 59438e6200294500 ; Thu, 4 Apr 2013 13:13:32 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov (10.215.228.141) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 4 Apr 2013 13:13:54 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) with mapi id 14.01.0289.001; Thu, 4 Apr 2013 13:14:29 -0400 From: "Igoe, Kevin M." To: 'Jim Schaad' , "cfrg@irtf.org" Thread-Topic: [Cfrg] What Algorithm information needs to be authenticated? Thread-Index: Ac4w8b10meAP4tSuRQOj77FabgFZwwAPrVJAABHXwIAACBu7AA== Date: Thu, 4 Apr 2013 17:14:28 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA8CBC1EDF@MSMR-GH1-UEA03.corp.nsa.gov> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <3C4AAD4B5304AB44A6BA85173B4675CA8B6AF16B@MSMR-GH1-UEA03.corp.nsa.gov> <011501ce3156$4bcdf3a0$e369dae0$@augustcellars.com> In-Reply-To: <011501ce3156$4bcdf3a0$e369dae0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:14:56 -0000 Jim Schaad wrote: > > - With MACs, since the integrity keys are shorter lived than the > signing > keys, > > the risk level is (in most applications) much lower than with > digital > > signatures. >=20 > I wish this was a true statement. I have seen a number of > circumstances > where MAC keys are in long lived situations on the order of years. > Places > such as routers, RADIUS servers and so forth. Thus while we can hope > they > are shorter lived I don't believe that we can make that as an > assumption. > Sigh! Sadly, ! expect you are right. Getting people to have proper=20 cryptographic "hygene" is harder than getting my kids to brush their teeth every night. > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Thursday, April 04, 2013 1:03 PM > To: Igoe, Kevin M.; cfrg@irtf.org > Subject: RE: [Cfrg] What Algorithm information needs to be > authenticated? >=20 > Kevin, >=20 > > -----Original Message----- > > From: Igoe, Kevin M. [mailto:kmigoe@nsa.gov] > > Sent: Thursday, April 04, 2013 7:48 AM > > To: 'Jim Schaad'; cfrg@irtf.org > > Subject: RE: [Cfrg] What Algorithm information needs to be > authenticated? > > > > OK CFRG, Jim has given us 4 concrete issues to address. > > > > > > 1. For signature operations, what parameters related to the > signature > > algorithm and what parameters related to a key need to be protected > by the > > signature operation to prevent real and theoretical attacks on JOSE > signed > > structures. We would like to get the real and theoretical attacks > > separated with a weight on the theoretical attacks for the potential > to > become > > real. > > > > 2. For MAC operations, what parameters related to the MAC algorithm > and > > what parameters related to the key need to be protected by the MAC > > operation to prevent real and theoretical attacks on a JOSE MAC > structure. > > > > 3. For key management operations (how the content encryption key is > given > > to the recipient), what parameters related to the algorithms need to > be > > protected as part of the AEAD algorithm. > > > > 4. For content encryption, what parameter related to the AEAD > algorithm > > need to be protected by the AEAD algorithm (and are not already > protected) > > need to be included. Is there any benefit in double protecting > parameters > > such as the IV in case a new AEAD algorithm does not directly protect > that > > value. > > > > - A residual risk common to all of these is proper storage of secret > keys. > > While outside the scope of JOSE, I believe this should be called > out in > the > > security section as an issue implementers must address.) > > - Proper protection of the secret signing keys is a very real issue. >=20 > I agree that both of the previous issues should be addressed as > security > considerations. I can check but I already believe they are. >=20 > > - With MACs, since the integrity keys are shorter lived than the > signing > keys, > > the risk level is (in most applications) much lower than with > digital > > signatures. >=20 > I wish this was a true statement. I have seen a number of > circumstances > where MAC keys are in long lived situations on the order of years. > Places > such as routers, RADIUS servers and so forth. Thus while we can hope > they > are shorter lived I don't believe that we can make that as an > assumption. >=20 > > > > - ECDSA depends upon a random input k provided by the signer. This > input > > should be uniformly distributed in the range [1, q], where q is > > the size of the cryptographic subgroup of the curve (a prime). > NIST has > > good guidance on this. One of their DRBGs makes a good tool for > forming > > k. Thankfully NIST has thought long and hard about these issues. > We > need to > > point folks at the proper NIST special pubs. Additional non-NIST > references > > would be a very welcome! > > > > - MACs don't provide non-repudiation since more than one person has > the > > integrity key. If non-repudiation is required (typically only > needed > > if legal culpability might become an issue), a true signature > should be > > used. >=20 > I prefer the term data-origin rather than non-repudiation since I know > what > that the former means but don't know what the latter means as a > technical > term. This term has been argued about for the last 15 years on the > PKIX > mailing list and I don't want to get into that here. >=20 > > > > - OK folks, does anyone have an argument as to why authentication of > the > > AEAD IVs is required to address a concrete security issue? I've > been > > mulling this over & haven't come up with one yet. Keep in mind that > one > > of the use cases for JOSE is the W3C web cryptography API, so there > > are likely to use this in the future to build JOSE based > applications > > beyond what we are currently envisioning. >=20 > Are you talking about inside of the algorithm or outside of the > algorithm > for doing the authentication? In the case of the CBC/HMAC AEAD > algorithm, > as the authentication is computed on the encrypted text you cannot know > if > the unencrypted text is the correct text without knowing that the IV is > also > correct. You end up with about a 1 in 256 chance of decrypting the > message > and getting the correct padding with the wrong IV and then assuming > that the > resulting plain text is what was sent when it isn't. >=20 > Jim >=20 > > > > > > > -----Original Message----- > > > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On > Behalf > > > Of Jim Schaad > > > Sent: Thursday, April 04, 2013 2:26 AM > > > To: cfrg@irtf.org > > > Subject: [Cfrg] What Algorithm information needs to be > authenticated? > > > > > > Request for Information > > > > > > The JOSE working group is having an internal argument about the > need > > > to protect the various header information in an encrypted or signed > > > message. > > > The quick question is which algorithm information and algorithm > > > parameters need to be included in integrity portion of the > signature > > > or encryption operation in order to protect those parameters. > > > > > > There are a couple of theoretical attacks that can be launched > against > > > various algorithms that then require protection an example of such > a > > > parameter is the IV for the AES-CBC/HMAC algorithm that has been > > > proposed. > > > In this case the IV is protected by the algorithm itself and > therefore > > > does not need to be externally protected by the JOSE data > structures. > > > > > > In RFC 6211, there is a new CMS attribute that was defined for > > > protection of the signature algorithm as I felt there was a > potential > > > attack that could be exploited. > > > > > > Looking at the RSA v1.5 signature algorithm, one cannot change the > > > hash algorithm as the hash algorithm is encoded as part of the > padding > > > for the signature > > > > > > Looking at the RSA PSS signature, there is the possibility that a > hash > > > algorithm of the same length could be substituted unless external > > > restrictions are applied. Thus one could potentially substitute a > > > RIPEMD-160 hash on the content for a SHA-1 hash. As long as the > > > hashes > > > match and there is no externally applied restriction that the hash > > > algorithm used to build the PSS internals is same as the content > hash > > > then it would verify. It is unclear if there is an attack that > > > involves multiple hash algorithms that is better than a birthday > > > attack on a single algorithm as I don't know if this has ever been > > > studied. > > > > > > CMS also defined an attribute that can be included in the signature > > > computation for specifying a certificate that is to be used in the > > > validation of the signature on the CMS object. I.e. where to get > the > > > public key and the base restrictions for that are imposed on that > > > public key by the certificate issuer. > > > > > > Questions that we would like to see discussed: > > > > > > 1. For signature operations, what parameters related to the > signature > > > algorithm and what parameters related to a key need to be protected > by > > > the signature operation to prevent real and theoretical attacks on > > > JOSE signed > > > structures. We would like to get the real and theoretical attacks > > > separated with a weight on the theoretical attacks for the > potential > > > to become real. > > > > > > 2. For MAC operations, what parameters related to the MAC > algorithm > > > and what parameters related to the key need to be protected by the > MAC > > > operation to prevent real and theoretical attacks on a JOSE MAC > > > structure. > > > > > > 3. For key management operations (how the content encryption key > is > > > given to the recipient), what parameters related to the algorithms > > > need to be protected as part of the AEAD algorithm. > > > > > > 4. For content encryption, what parameter related to the AEAD > > > algorithm need to be protected by the AEAD algorithm (and are not > > > already > > > protected) > > > need to be included. Is there any benefit in double protecting > > > parameters such as the IV in case a new AEAD algorithm does not > > > directly protect that value. > > > > > > Looking at the key to be protected, we don't care if the recipient > > > cannot find the correct key or misinterprets what the key > identifier > > > is. What we want to make sure is that an attacker would be unable > to > > > change the recipients interpretation of what key is to be used and > > > still get a successful validation. > > > > > > Jim Schaad > > > JOSE Co-Chair > > > > > > > > > _______________________________________________ > > > Cfrg mailing list > > > Cfrg@irtf.org > > > http://www.irtf.org/mailman/listinfo/cfrg From rbarnes@bbn.com Thu Apr 4 12:01:38 2013 Return-Path: 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 71EF521F96F4 for ; Thu, 4 Apr 2013 12:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 1+QH0LTGGuoK for ; Thu, 4 Apr 2013 12:01:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 443D821F96B6 for ; Thu, 4 Apr 2013 12:01:35 -0700 (PDT) Received: from dhcp33-085-080.bbn.com ([128.33.85.80]:62749) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UNpPf-000KwC-WD; Thu, 04 Apr 2013 15:01:32 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Richard Barnes In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA8CBC1EDF@MSMR-GH1-UEA03.corp.nsa.gov> Date: Thu, 4 Apr 2013 15:01:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <3C4AAD4B5304AB44A6BA85173B4675CA8B6AF16B@MSMR-GH1-UEA03.corp.nsa.gov> <011501ce3156$4bcdf3a0$e369dae0$@augustcellars.com> <3C4AAD4B5304AB44A6BA85173B4675CA8CBC1EDF@MSMR-GH1-UEA03.corp.nsa.gov> To: "Igoe, Kevin M." X-Mailer: Apple Mail (2.1503) Cc: 'Jim Schaad' , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 19:01:38 -0000 On Apr 4, 2013, at 1:14 PM, "Igoe, Kevin M." wrote: > Jim Schaad wrote: >>> - With MACs, since the integrity keys are shorter lived than the >> signing >> keys, >>> the risk level is (in most applications) much lower than with >> digital >>> signatures. >>=20 >> I wish this was a true statement. I have seen a number of >> circumstances >> where MAC keys are in long lived situations on the order of years. >> Places >> such as routers, RADIUS servers and so forth. Thus while we can hope >> they >> are shorter lived I don't believe that we can make that as an >> assumption. >>=20 >=20 > Sigh! Sadly, ! expect you are right. Getting people to have proper=20 > cryptographic "hygene" is harder than getting my kids to brush their > teeth every night. The current JOSE specs, however, encourage bad habits: Unlike CMS, they = don't provide a mechanism for using ephemeral MAC keys. So that is one helpful piece of feedback. We need to add better ways to = manage MAC keys. --Richard >=20 >> -----Original Message----- >> From: Jim Schaad [mailto:ietf@augustcellars.com] >> Sent: Thursday, April 04, 2013 1:03 PM >> To: Igoe, Kevin M.; cfrg@irtf.org >> Subject: RE: [Cfrg] What Algorithm information needs to be >> authenticated? >>=20 >> Kevin, >>=20 >>> -----Original Message----- >>> From: Igoe, Kevin M. [mailto:kmigoe@nsa.gov] >>> Sent: Thursday, April 04, 2013 7:48 AM >>> To: 'Jim Schaad'; cfrg@irtf.org >>> Subject: RE: [Cfrg] What Algorithm information needs to be >> authenticated? >>>=20 >>> OK CFRG, Jim has given us 4 concrete issues to address. >>>=20 >>>=20 >>> 1. For signature operations, what parameters related to the >> signature >>> algorithm and what parameters related to a key need to be protected >> by the >>> signature operation to prevent real and theoretical attacks on JOSE >> signed >>> structures. We would like to get the real and theoretical attacks >>> separated with a weight on the theoretical attacks for the potential >> to >> become >>> real. >>>=20 >>> 2. For MAC operations, what parameters related to the MAC algorithm >> and >>> what parameters related to the key need to be protected by the MAC >>> operation to prevent real and theoretical attacks on a JOSE MAC >> structure. >>>=20 >>> 3. For key management operations (how the content encryption key is >> given >>> to the recipient), what parameters related to the algorithms need to >> be >>> protected as part of the AEAD algorithm. >>>=20 >>> 4. For content encryption, what parameter related to the AEAD >> algorithm >>> need to be protected by the AEAD algorithm (and are not already >> protected) >>> need to be included. Is there any benefit in double protecting >> parameters >>> such as the IV in case a new AEAD algorithm does not directly = protect >> that >>> value. >>>=20 >>> - A residual risk common to all of these is proper storage of secret >> keys. >>> While outside the scope of JOSE, I believe this should be called >> out in >> the >>> security section as an issue implementers must address.) >>> - Proper protection of the secret signing keys is a very real issue. >>=20 >> I agree that both of the previous issues should be addressed as >> security >> considerations. I can check but I already believe they are. >>=20 >>> - With MACs, since the integrity keys are shorter lived than the >> signing >> keys, >>> the risk level is (in most applications) much lower than with >> digital >>> signatures. >>=20 >> I wish this was a true statement. I have seen a number of >> circumstances >> where MAC keys are in long lived situations on the order of years. >> Places >> such as routers, RADIUS servers and so forth. Thus while we can hope >> they >> are shorter lived I don't believe that we can make that as an >> assumption. >>=20 >>>=20 >>> - ECDSA depends upon a random input k provided by the signer. This >> input >>> should be uniformly distributed in the range [1, q], where q is >>> the size of the cryptographic subgroup of the curve (a prime). >> NIST has >>> good guidance on this. One of their DRBGs makes a good tool for >> forming >>> k. Thankfully NIST has thought long and hard about these issues. >> We >> need to >>> point folks at the proper NIST special pubs. Additional non-NIST >> references >>> would be a very welcome! >>>=20 >>> - MACs don't provide non-repudiation since more than one person has >> the >>> integrity key. If non-repudiation is required (typically only >> needed >>> if legal culpability might become an issue), a true signature >> should be >>> used. >>=20 >> I prefer the term data-origin rather than non-repudiation since I = know >> what >> that the former means but don't know what the latter means as a >> technical >> term. This term has been argued about for the last 15 years on the >> PKIX >> mailing list and I don't want to get into that here. >>=20 >>>=20 >>> - OK folks, does anyone have an argument as to why authentication of >> the >>> AEAD IVs is required to address a concrete security issue? I've >> been >>> mulling this over & haven't come up with one yet. Keep in mind that >> one >>> of the use cases for JOSE is the W3C web cryptography API, so there >>> are likely to use this in the future to build JOSE based >> applications >>> beyond what we are currently envisioning. >>=20 >> Are you talking about inside of the algorithm or outside of the >> algorithm >> for doing the authentication? In the case of the CBC/HMAC AEAD >> algorithm, >> as the authentication is computed on the encrypted text you cannot = know >> if >> the unencrypted text is the correct text without knowing that the IV = is >> also >> correct. You end up with about a 1 in 256 chance of decrypting the >> message >> and getting the correct padding with the wrong IV and then assuming >> that the >> resulting plain text is what was sent when it isn't. >>=20 >> Jim >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On >> Behalf >>>> Of Jim Schaad >>>> Sent: Thursday, April 04, 2013 2:26 AM >>>> To: cfrg@irtf.org >>>> Subject: [Cfrg] What Algorithm information needs to be >> authenticated? >>>>=20 >>>> Request for Information >>>>=20 >>>> The JOSE working group is having an internal argument about the >> need >>>> to protect the various header information in an encrypted or signed >>>> message. >>>> The quick question is which algorithm information and algorithm >>>> parameters need to be included in integrity portion of the >> signature >>>> or encryption operation in order to protect those parameters. >>>>=20 >>>> There are a couple of theoretical attacks that can be launched >> against >>>> various algorithms that then require protection an example of such >> a >>>> parameter is the IV for the AES-CBC/HMAC algorithm that has been >>>> proposed. >>>> In this case the IV is protected by the algorithm itself and >> therefore >>>> does not need to be externally protected by the JOSE data >> structures. >>>>=20 >>>> In RFC 6211, there is a new CMS attribute that was defined for >>>> protection of the signature algorithm as I felt there was a >> potential >>>> attack that could be exploited. >>>>=20 >>>> Looking at the RSA v1.5 signature algorithm, one cannot change the >>>> hash algorithm as the hash algorithm is encoded as part of the >> padding >>>> for the signature >>>>=20 >>>> Looking at the RSA PSS signature, there is the possibility that a >> hash >>>> algorithm of the same length could be substituted unless external >>>> restrictions are applied. Thus one could potentially substitute a >>>> RIPEMD-160 hash on the content for a SHA-1 hash. As long as the >>>> hashes >>>> match and there is no externally applied restriction that the hash >>>> algorithm used to build the PSS internals is same as the content >> hash >>>> then it would verify. It is unclear if there is an attack that >>>> involves multiple hash algorithms that is better than a birthday >>>> attack on a single algorithm as I don't know if this has ever been >>>> studied. >>>>=20 >>>> CMS also defined an attribute that can be included in the signature >>>> computation for specifying a certificate that is to be used in the >>>> validation of the signature on the CMS object. I.e. where to get >> the >>>> public key and the base restrictions for that are imposed on that >>>> public key by the certificate issuer. >>>>=20 >>>> Questions that we would like to see discussed: >>>>=20 >>>> 1. For signature operations, what parameters related to the >> signature >>>> algorithm and what parameters related to a key need to be protected >> by >>>> the signature operation to prevent real and theoretical attacks on >>>> JOSE signed >>>> structures. We would like to get the real and theoretical attacks >>>> separated with a weight on the theoretical attacks for the >> potential >>>> to become real. >>>>=20 >>>> 2. For MAC operations, what parameters related to the MAC >> algorithm >>>> and what parameters related to the key need to be protected by the >> MAC >>>> operation to prevent real and theoretical attacks on a JOSE MAC >>>> structure. >>>>=20 >>>> 3. For key management operations (how the content encryption key >> is >>>> given to the recipient), what parameters related to the algorithms >>>> need to be protected as part of the AEAD algorithm. >>>>=20 >>>> 4. For content encryption, what parameter related to the AEAD >>>> algorithm need to be protected by the AEAD algorithm (and are not >>>> already >>>> protected) >>>> need to be included. Is there any benefit in double protecting >>>> parameters such as the IV in case a new AEAD algorithm does not >>>> directly protect that value. >>>>=20 >>>> Looking at the key to be protected, we don't care if the recipient >>>> cannot find the correct key or misinterprets what the key >> identifier >>>> is. What we want to make sure is that an attacker would be unable >> to >>>> change the recipients interpretation of what key is to be used and >>>> still get a successful validation. >>>>=20 >>>> Jim Schaad >>>> JOSE Co-Chair >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From internet-drafts@ietf.org Thu Apr 4 13:52:10 2013 Return-Path: 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 E057A21F93EC; Thu, 4 Apr 2013 13:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, 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 G1P4nrM-DOwt; Thu, 4 Apr 2013 13:52:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6C921F93C5; Thu, 4 Apr 2013 13:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130404205210.32115.23132.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 13:52:10 -0700 Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-ocb-01.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:52:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Crypto Forum Research Group Working Group= of the IETF. Title : The OCB Authenticated-Encryption Algorithm Author(s) : Ted Krovetz Phillip Rogaway Filename : draft-irtf-cfrg-ocb-01.txt Pages : 17 Date : 2013-04-04 Abstract: This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides privacy and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-ocb There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-cfrg-ocb-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-cfrg-ocb-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=38078c4907=dbrown@certicom.com Fri Apr 5 08:48:13 2013 Return-Path: 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 9478421F9850 for ; Fri, 5 Apr 2013 08:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 jz--0hJgaVwX for ; Fri, 5 Apr 2013 08:48:11 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id EE0B121F980B for ; Fri, 5 Apr 2013 08:48:10 -0700 (PDT) X-AuditID: 0a41282f-b7f1a6d0000054a3-2e-515ef232ef04 Received: from XCT103CNC.rim.net (smtp-pop.rim.net [10.65.161.203]) by mhs060cnc.rim.net (SBG) with SMTP id 9E.EE.21667.232FE515; Fri, 5 Apr 2013 10:48:03 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.02.0328.009; Fri, 5 Apr 2013 11:48:02 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: IETF's secure messaging v public-key encryption Thread-Index: Ac4yFPPtfKFxsQ9USvOVB6D3EGsogQ== Date: Fri, 5 Apr 2013 15:48:01 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513CC9E@XMB111CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBJsWRmVeSWpSXmKPExsXC5bjwtK7xp7hAg+bvjBbdPw4yOTB6TN54 mC2AMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mRsu7iIqeDDRMaK189XszYwnm1m7GLk5JAQMJF4+uoMlC0mceHeerYu Ri4OIYGVjBK9M1tYQRJCAhsZJfbdKwOx2QRUJe4fPcfcxcjBISKgLPH5owRIWFjAQuLdggtM EGFbiV9feUHCIgJ6EvsWHWIDsVkEVCQ+7n8BtopXwE3i7qoHYDajgKzE7rPXmUBsZgFxiVtP 5jNBnCMi8fDiaTYIW1Ti5eN/rBC2osTeZ0eZQM5kFuhklJgxfRUrxFBBiZMzn7BMYBSahWTW LGR1s5DUzQK6lVkgV2LqQxuIeh2JBbs/sUHY2hLLFr5mhrHPHHjMhCmuI7H50k4WCFtRoq1z NtSupYwS6648YIEp2vH1IFzRlO6H7AsYeVcxCuZmFBuYGSTnJesVZebq5aWWbGIEpyMN/R2M b99bHGIU4GBU4uENeRYXKMSaWFZcmXuIUQVoxqMNqy8wSrHk5eelKonwyj4HSvOmJFZWpRbl xxeV5qQWH2LMAYb1RGYp7uR8YArNK4k3NjCgmKMkzvtbODpQSCAdmHazU1MLUotg1jFxcB5i lODgkhIpBibP1KLE0pKMeFCKjy8GJnmpBkanhYZ79r1rLg1UmXKsMfKTgPXtN1K5nE4VnLwC W9/IGD126Upwuh54/k/ISWbz8kPP1qi++LCtQ3e7w9YJLg4iuxsu251RWvVMaruS1g+19cea nnz2PPihTn1JJr80l+i2Ry5yhcmWnxsMFrG9ff/+9TPTjvSQH9skNQyv1K40uiDkwc+8jFOJ pTgj0VCLuag4EQDAnzvfuwMAAA== Subject: [Cfrg] IETF's secure messaging v public-key encryption X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:48:13 -0000 --_004_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear CFRG list: Some IETF protocols, including CMS (and perhaps JOSE), offer schemes that ar= e essentially public-key encryption: they protect a conveyed message from an= unauthenticated (cryptographically anonymous) sender (**) to a recipient wi= th a public key, with the wrinkle that they also permit multiple recipients= (sharing a common "wrapped" key). Although the sender has no authenticated key, the sender still applies a MAC= to the message. This application of a MAC has been called "authenticated"= (with respect to whoever has the MAC key) in some places. It has also been= called "integrity-protection" in other places. Past versions of CMS message encryption did not apply the MAC. Consequently,= the integrity of an encrypted message was not protected. It seems that the purpose of the MACing corresponds closely to the cryptogra= phers' notion of "non-malleability" (NM) goal public-key encryption schemes.= (If I recall correctly, NM-CCA2 has been proven equivalent to IND-CCA2.) Questions: 1) Do the existing and proposed IETF public-key message encryption methods m= eet the cryptographer's benchmark of IND-CCA2 security? How important is tha= t to meet these goals? Can (or have) these cryptographer's security goals b= e proven for the specific CMS methods? 2) What is the best terminology to use in IETF? How important is terminolog= y? Should the existing IETF terminology be amended? 3) What is the right formal definition when multiple recipients are involved= ? I seek your answers, but here are my tentative answers: 1) The current proposals provide IND-CCA2. It would be very hard to prove t= his (*). It is important to provide at least IND-CCA1 security, but CCA2 is= never really necessary. 2) "Non-malleability" is the best terminology for many general users, at lea= st from my experience. Standard terminology is important, for mutual underst= anding, and accident avoidance. The term "authenticated" should either remo= ved when the sender does not use an authenticated key, or else change the te= rm to "recipient-authenticated" (compare TLS and server authentication versu= s client authentication...). 3) The security definitions should be nearly the same for multiple recipient= s (which share a common symmetric key). (*) Shoup [ISO 18033-2] introduced the KEM-DEM approach to hybrid PKE scheme= s, which may be highly useful for describing, and proving things about, the= CMS methods. I vaguely recall some research done in this area. (**) In a separate message, I will discuss schemes in which the sender can a= lso be authenticated by means of an authenticated key (but does not sign). Best regards, Daniel Brown Research In Motion Limited [cid:image001.gif@01CE31F0.30D41300] --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dear CFRG list:

 

Some IETF protocols, including CMS (and perhaps JOSE)= , offer schemes that are essentially public-key encryption: they protect a c= onveyed message from an unauthenticated (cryptographically anonymous) sender= (**) to a recipient with a public key, with the wrinkle that they also permit multiple recipients (sharing a= common "wrapped" key).

 

Although the sender has no authenticated key, the sen= der still applies a MAC to the message.  This application of a MAC has= been called "authenticated" (with respect to whoever has the MAC= key) in some places. It has also been called "integrity-protection&quo= t; in other places.

 

Past versions of CMS message encryption did not apply= the MAC. Consequently, the integrity of an encrypted message was not protec= ted.

 

It seems that the purpose of the MACing corresponds c= losely to the cryptographers’ notion of "non-malleability" (= NM) goal public-key encryption schemes.  (If I recall correctly, NM-CCA= 2 has been proven equivalent to IND-CCA2.)

 

Questions:

 

1) Do the existing and proposed IETF public-key messa= ge encryption methods meet the cryptographer's benchmark of IND-CCA2 securit= y? How important is that to meet these goals?  Can (or have) these cryp= tographer’s security goals be proven for the specific CMS methods?

 

2) What is the best terminology to use in IETF? = How important is terminology?  Should the existing IETF terminology be= amended?

 

3) What is the right formal definition when multiple= recipients are involved?

 

I seek your answers, but here are my tentative answer= s:

 

1) The current proposals provide IND-CCA2.  It w= ould be very hard to prove this (*).  It is important to provide at lea= st IND-CCA1 security, but CCA2 is never really necessary.

 

2) "Non-malleability" is the best terminolo= gy for many general users, at least from my experience. Standard terminology= is important, for mutual understanding, and accident avoidance.  The t= erm "authenticated" should either removed when the sender does not use an authenticated key, or else change the term to &q= uot;recipient-authenticated" (compare TLS and server authentication ver= sus client authentication...).

 

3) The security definitions should be nearly the same= for multiple recipients (which share a common symmetric key).

 

(*) Shoup [ISO 18033-2] introduced the KEM-DEM approa= ch to hybrid PKE schemes, which may be highly useful for describing, and pro= ving things about, the CMS methods.  I vaguely recall some research don= e in this area.

 

(**) In a separate message, I will discuss schemes in= which the sender can also be authenticated by means of an authenticated key= (but does not sign).

 

Best regards,

 

Dani= el Brown

Res= earch In Motion Limited

 <= /p>

 <= /p>

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2577; creation-date="Fri, 05 Apr 2013 15:24:52 GMT"; modification-date="Fri, 05 Apr 2013 15:24:52 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhjQAiANUAAF5bXMrJydjX1zIvMF5bW+Xl5fLx8UE9PsvKyvPy8np3eJSTkzIvL5WTlMvK ycrKybCvr4eFhk9MTV5cXJSSk6KhoEI+PoeGhmtqaXp4eOTk5KOhoa+urmxqab68vUE9PZWTk727 vHp3d2xqauTl5LCvrtjY19nY2FBNTdnY16KgoKOhoE9MTL28vK+vrvPy8WtpaTIuLzEuL11bW4iG hkI9Pr68vIiGh09NTSMfHyQgICMfICQfIP///wAAAAAAACH/C1hNUCBEYXRhWE1QPD94cGFja2V0 IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4 bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAg NjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpy ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxu czpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIg eG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IFdpbmRvd3MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6QTk5QzA5MUNFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiIHhtcE1NOkRv Y3VtZW50SUQ9InhtcC5kaWQ6QTk5QzA5MURFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiPiA8eG1w TU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpBOTlDMDkxQUVCQTExMUUw ODg5NkE4RjE2QUVGODNGMSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpBOTlDMDkxQkVCQTEx MUUwODg5NkE4RjE2QUVGODNGMSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6 eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk 4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayr qqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNy cXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5 ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEA ACH5BAAAAAAALAAAAACNACIAAAb/wJ5wSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89o 7oYwAQA8wgsBQOgI0vh8D6Db8XgDQn88OjwdeohmO4uLDD0Cg3+HiZRgAn6EORw9Kn08OQN3Ag8B AXdFpAgIpQ+nQyelBVsODgEJRwIItaUBDpVDBrWrGkIFugEIt3s5zDoRRZk8O54HLUMWfQ9aBn45 skY4hNLSoA2/UMyDAEQBOdLTjH8BPQY5hQZaD4UfSIv2hX925DBHSYQ0HQcgCEGxiIeEOwHG5dih gEiFaQPcABggDkMPD58ObFmgI8ekIgim6Zgz4QOzHY4oSfAEkx6jQodCEJgDYIEy/yEY3HkUYkCC tHUUpI1gp4BAjgMzSqDMYPQABoVDJvShIMTEiJ0AFLjjNwQDvCEFRBi1AMNXEQMUwN4psIEOgDYX iHigMwHfkXGLRAYoJDBHxSUHFlUgAsCPR608FguJ4AdgnwxDLhDCdNQvA3mPBkzkwaGDtJM9LhSS IQTC6NE8DgsRINrejgQQYryTEJjIgT8ikAwWx8BFj6SYDohChsDvkAQCdVRAFmIEIR0hesSY5lZz ST8CP5noscDd5nfOehT4nuAEAx06BiDo8aGQggCkKC/iWgKg+T47LFDMAPB9YgECAf0RwSc8DLHB JwM499YDtWhTDH6mDJGYedYMEf9RdJ/Ak8MNPWhQiA5CmPgHAbIkYIEfARQAHgMbBNDAdzoY4ME0 ByDAgDvK9fCCJwH9s8NSCXD0FBwCoPBHTAoQMgAIpgDwhwwc2OKODrIYMIAfBFlhQCQ7rDMEBfCQ s9kGrfUhQTGrxBgABBmAF0AGJTHgSgWjBRCBOxyVJIEyCAA0ziDP9HDRRN/0kEAfOmjzZWRCkHCi KwdMNF8Di1ggBU9h4fMheMENYeUOB7TxpSe+qKaDbCRE8FtDABnwYg40oORAMo2F6I5zCxDCwAwA fBDQDotNsOVBlTFDiz0NtrkDC4z9wYEG0/DQ4RMapCONOQ18Ep8CEjIwjQpDkPD/5Q6H8CFda+mY ly0/zcyDBGDjYNUDAZ9gJsQLLEjjKb+fMPNSQA5ssIiZPfzJQ6JCNGDPAgr4wfATHhDmh4BKYCuQ Kz1kMNEEPXQjynUHLODBAxdM5NE72R2RQkADGLUDAUNMqq+iheSwB3wo0MHTBHOQECUPYQIwkVRD VFDIi36A7ARlf+TAAAlLpLQIEQWYywMAl3wixAI8+pWAuTmgm2kOJAtxQmUUcNCIAOv9MV8PDLqS AAt+OGKWYeyUcseGMeP9x3geAuiHbFAIQEspPyURtgUUULAABqtG5oA4xIQLSAgJlGBBiPMZdJQN K3zpTgoRlHQYAdOYWfACIFDM/9HiPXAAX4AkFFDnIhA86s43JhRcBHSeDBC5GDVg0k1AKJT4hycR Jbjl1ur9yCBsec2kwyY9PNBnD2KFB94fA3wz63WbvfnAk0Os8MfFQigZ4BkCeL2ZHyMoM8H064hS ZeLTkCFA4DOG4kGpCuaKXq0jATPJlkBuloIhCOA359nBoHoQrh3AYAgV40FeijABP4gEDQaAQAMa sIAGbKBR9FiAG9jUAxcIjQIGoN0CGlWACLiBABmwVwFqxzEhpKABIMBhayiARBYijggGWAFPRmAc IYRghXfrQQmQKLW65QAO5wijGGCnA/qJ8Yz5CM8J0MjGLXxgEYxroxynwAEIwRRwjnh8ggCQIbU8 +vGPgAykIPMYBAA7 --_004_810C31990B57ED40B2062BA10D43FBF513CC9EXMB111CNCrimnet_-- From kmigoe@nsa.gov Fri Apr 5 09:14:58 2013 Return-Path: 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 9218721F9828 for ; Fri, 5 Apr 2013 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] 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 5mJUF8zufmH5 for ; Fri, 5 Apr 2013 09:14:58 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3521F9810 for ; Fri, 5 Apr 2013 09:14:57 -0700 (PDT) X-TM-IMSS-Message-ID: <3a6b0fed00000d4f@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 3a6b0fed00000d4f ; Fri, 5 Apr 2013 12:16:36 -0400 Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 5 Apr 2013 12:14:54 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.01.0289.001; Fri, 5 Apr 2013 12:14:53 -0400 From: "Igoe, Kevin M." To: "cfrg@irtf.org" Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-ocb-01.txt Thread-Index: AQHOMXZMi5/1qrHSIkq1MEecd8BuD5jHx+iA Date: Fri, 5 Apr 2013 16:14:52 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA8CD84D97@MSMR-GH1-UEA03.corp.nsa.gov> References: <20130404205210.32115.23132.idtracker@ietfa.amsl.com> In-Reply-To: <20130404205210.32115.23132.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.224.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-ocb-01.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:14:58 -0000 This is the draft we approved in Orlando. The -00 draft aged off before we could move it up the publishing chain, whence the new version (plus it makes a few minor corrections). > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, April 04, 2013 4:52 PM > To: i-d-announce@ietf.org > Cc: cfrg@ietf.org > Subject: [Cfrg] I-D Action: draft-irtf-cfrg-ocb-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Crypto Forum Research Group Working > Group of the IETF. >=20 > Title : The OCB Authenticated-Encryption Algorithm > Author(s) : Ted Krovetz > Phillip Rogaway > Filename : draft-irtf-cfrg-ocb-01.txt > Pages : 17 > Date : 2013-04-04 >=20 > Abstract: > This document specifies OCB, a shared-key blockcipher-based > encryption scheme that provides privacy and authenticity for > plaintexts and authenticity for associated data. This document is a > product of the Crypto Forum Research Group (CFRG). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-cfrg-ocb >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-irtf-cfrg-ocb-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-cfrg-ocb-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From Kenny.Paterson@rhul.ac.uk Fri Apr 5 10:41:56 2013 Return-Path: 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 EC1C621F9847 for ; Fri, 5 Apr 2013 10:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 C+oE2B0uVSdL for ; Fri, 5 Apr 2013 10:41:56 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 003B021F9800 for ; Fri, 5 Apr 2013 10:41:55 -0700 (PDT) Received: from mail153-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE034.bigfish.com (10.243.66.99) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Apr 2013 17:41:55 +0000 Received: from mail153-co1 (localhost [127.0.0.1]) by mail153-co1-R.bigfish.com (Postfix) with ESMTP id 337878002D6; Fri, 5 Apr 2013 17:41:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.108; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB02.cc.rhul.local; RD:exch-hub02.rhul.ac.uk; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zz98dIc89bhc857hdb82hdbf2izz1f42h1fc6h1ee6h1de0h1d18h1fdah1202h1e76h1d1ah1d2ahzz17326ah18c673h8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1155h) Received: from mail153-co1 (localhost.localdomain [127.0.0.1]) by mail153-co1 (MessageSwitch) id 1365183713267794_7788; Fri, 5 Apr 2013 17:41:53 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.251]) by mail153-co1.bigfish.com (Postfix) with ESMTP id 3F12EA40043; Fri, 5 Apr 2013 17:41:53 +0000 (UTC) Received: from EXCH-HUB02.cc.rhul.local (134.219.208.108) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Apr 2013 17:41:52 +0000 Received: from EXCH-MB01.cc.rhul.local ([169.254.3.31]) by EXCH-HUB02.cc.rhul.local ([2002:86db:d06c::86db:d06c]) with mapi id 14.02.0328.009; Fri, 5 Apr 2013 18:41:50 +0100 From: "Paterson, Kenny" To: Dan Brown Thread-Topic: [Cfrg] IETF's secure messaging v public-key encryption Thread-Index: Ac4yFPPtfKFxsQ9USvOVB6D3EGsogQAB5SGA Date: Fri, 5 Apr 2013 17:41:50 +0000 Message-ID: References: <810C31990B57ED40B2062BA10D43FBF513CC9E@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF513CC9E@XMB111CNC.rim.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E493FE1B65A8447DB68479E2A4DB91B6rhulacuk_" MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] IETF's secure messaging v public-key encryption X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 17:41:57 -0000 --_000_E493FE1B65A8447DB68479E2A4DB91B6rhulacuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGFuLA0KDQpVbmRlciBpdGVtIDMgb24geW91ciBsaXN0LCB0aGVyZSBpcyBhIG5pY2UgcGFwZXIN CmJ5IE5pZ2VsIFNtYXJ0IGF0IFNDTiAyMDA0LiBUaGlzIGdpdmVzDQpzZWN1cml0eSBtb2RlbHMg YW5kIGNvbnN0cnVjdGlvbnMgZm9yDQptdWx0aS1yZWNpcGllbnQgS0VNcywgYmFzaWNhbGx5IHdo YXQgeW91DQphcmUgYWZ0ZXIuDQoNClRoZXJlIGlzIHJlbGF0ZWQgd29yayBvbg0KcmFuZG9tbmVz cyByZXVzZSBpbiBwdWJsaWMga2V5IGVuY3J5cHRpb24NCihwcm9iYWJseSByZWZlcmVuY2VkIGlu IE5pZ2VsJ3MgcGFwZXIpLg0KDQpCcm9hZGNhc3QgZW5jcnlwdGlvbiBpcyB5ZXQgYW5vdGhlciBy ZWxhdGVkDQooeWV0IGRpc3RpbmN0KSB0b3BpYy4NCg0KQ2FuIHlvdSBwcm92aWRlIHBvaW50ZXJz IHRvIHRoZSBjbXMvSm9zZQ0Kc2NoZW1lcyB5b3UgYXJlIGludGVyZXN0ZWQgaW4gYW5hbHlzaW5n Pw0KDQpSZWdhcmRzLA0KDQpLZW5ueQ0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIDUgQXBy IDIwMTMsIGF0IDE2OjQ4LCAiRGFuIEJyb3duIiA8ZGJyb3duQGNlcnRpY29tLmNvbTxtYWlsdG86 ZGJyb3duQGNlcnRpY29tLmNvbT4+IHdyb3RlOg0KDQpEZWFyIENGUkcgbGlzdDoNCg0KU29tZSBJ RVRGIHByb3RvY29scywgaW5jbHVkaW5nIENNUyAoYW5kIHBlcmhhcHMgSk9TRSksIG9mZmVyIHNj aGVtZXMgdGhhdCBhcmUgZXNzZW50aWFsbHkgcHVibGljLWtleSBlbmNyeXB0aW9uOiB0aGV5IHBy b3RlY3QgYSBjb252ZXllZCBtZXNzYWdlIGZyb20gYW4gdW5hdXRoZW50aWNhdGVkIChjcnlwdG9n cmFwaGljYWxseSBhbm9ueW1vdXMpIHNlbmRlciAoKiopIHRvIGEgcmVjaXBpZW50IHdpdGggYSBw dWJsaWMga2V5LCB3aXRoIHRoZSB3cmlua2xlIHRoYXQgdGhleSBhbHNvIHBlcm1pdCBtdWx0aXBs ZSByZWNpcGllbnRzIChzaGFyaW5nIGEgY29tbW9uICJ3cmFwcGVkIiBrZXkpLg0KDQpBbHRob3Vn aCB0aGUgc2VuZGVyIGhhcyBubyBhdXRoZW50aWNhdGVkIGtleSwgdGhlIHNlbmRlciBzdGlsbCBh cHBsaWVzIGEgTUFDIHRvIHRoZSBtZXNzYWdlLiAgVGhpcyBhcHBsaWNhdGlvbiBvZiBhIE1BQyBo YXMgYmVlbiBjYWxsZWQgImF1dGhlbnRpY2F0ZWQiICh3aXRoIHJlc3BlY3QgdG8gd2hvZXZlciBo YXMgdGhlIE1BQyBrZXkpIGluIHNvbWUgcGxhY2VzLiBJdCBoYXMgYWxzbyBiZWVuIGNhbGxlZCAi aW50ZWdyaXR5LXByb3RlY3Rpb24iIGluIG90aGVyIHBsYWNlcy4NCg0KUGFzdCB2ZXJzaW9ucyBv ZiBDTVMgbWVzc2FnZSBlbmNyeXB0aW9uIGRpZCBub3QgYXBwbHkgdGhlIE1BQy4gQ29uc2VxdWVu dGx5LCB0aGUgaW50ZWdyaXR5IG9mIGFuIGVuY3J5cHRlZCBtZXNzYWdlIHdhcyBub3QgcHJvdGVj dGVkLg0KDQpJdCBzZWVtcyB0aGF0IHRoZSBwdXJwb3NlIG9mIHRoZSBNQUNpbmcgY29ycmVzcG9u ZHMgY2xvc2VseSB0byB0aGUgY3J5cHRvZ3JhcGhlcnPigJkgbm90aW9uIG9mICJub24tbWFsbGVh YmlsaXR5IiAoTk0pIGdvYWwgcHVibGljLWtleSBlbmNyeXB0aW9uIHNjaGVtZXMuICAoSWYgSSBy ZWNhbGwgY29ycmVjdGx5LCBOTS1DQ0EyIGhhcyBiZWVuIHByb3ZlbiBlcXVpdmFsZW50IHRvIElO RC1DQ0EyLikNCg0KUXVlc3Rpb25zOg0KDQoxKSBEbyB0aGUgZXhpc3RpbmcgYW5kIHByb3Bvc2Vk IElFVEYgcHVibGljLWtleSBtZXNzYWdlIGVuY3J5cHRpb24gbWV0aG9kcyBtZWV0IHRoZSBjcnlw dG9ncmFwaGVyJ3MgYmVuY2htYXJrIG9mIElORC1DQ0EyIHNlY3VyaXR5PyBIb3cgaW1wb3J0YW50 IGlzIHRoYXQgdG8gbWVldCB0aGVzZSBnb2Fscz8gIENhbiAob3IgaGF2ZSkgdGhlc2UgY3J5cHRv Z3JhcGhlcuKAmXMgc2VjdXJpdHkgZ29hbHMgYmUgcHJvdmVuIGZvciB0aGUgc3BlY2lmaWMgQ01T IG1ldGhvZHM/DQoNCjIpIFdoYXQgaXMgdGhlIGJlc3QgdGVybWlub2xvZ3kgdG8gdXNlIGluIElF VEY/ICBIb3cgaW1wb3J0YW50IGlzIHRlcm1pbm9sb2d5PyAgU2hvdWxkIHRoZSBleGlzdGluZyBJ RVRGIHRlcm1pbm9sb2d5IGJlIGFtZW5kZWQ/DQoNCjMpIFdoYXQgaXMgdGhlIHJpZ2h0IGZvcm1h bCBkZWZpbml0aW9uIHdoZW4gbXVsdGlwbGUgcmVjaXBpZW50cyBhcmUgaW52b2x2ZWQ/DQoNCkkg c2VlayB5b3VyIGFuc3dlcnMsIGJ1dCBoZXJlIGFyZSBteSB0ZW50YXRpdmUgYW5zd2VyczoNCg0K MSkgVGhlIGN1cnJlbnQgcHJvcG9zYWxzIHByb3ZpZGUgSU5ELUNDQTIuICBJdCB3b3VsZCBiZSB2 ZXJ5IGhhcmQgdG8gcHJvdmUgdGhpcyAoKikuICBJdCBpcyBpbXBvcnRhbnQgdG8gcHJvdmlkZSBh dCBsZWFzdCBJTkQtQ0NBMSBzZWN1cml0eSwgYnV0IENDQTIgaXMgbmV2ZXIgcmVhbGx5IG5lY2Vz c2FyeS4NCg0KMikgIk5vbi1tYWxsZWFiaWxpdHkiIGlzIHRoZSBiZXN0IHRlcm1pbm9sb2d5IGZv ciBtYW55IGdlbmVyYWwgdXNlcnMsIGF0IGxlYXN0IGZyb20gbXkgZXhwZXJpZW5jZS4gU3RhbmRh cmQgdGVybWlub2xvZ3kgaXMgaW1wb3J0YW50LCBmb3IgbXV0dWFsIHVuZGVyc3RhbmRpbmcsIGFu ZCBhY2NpZGVudCBhdm9pZGFuY2UuICBUaGUgdGVybSAiYXV0aGVudGljYXRlZCIgc2hvdWxkIGVp dGhlciByZW1vdmVkIHdoZW4gdGhlIHNlbmRlciBkb2VzIG5vdCB1c2UgYW4gYXV0aGVudGljYXRl ZCBrZXksIG9yIGVsc2UgY2hhbmdlIHRoZSB0ZXJtIHRvICJyZWNpcGllbnQtYXV0aGVudGljYXRl ZCIgKGNvbXBhcmUgVExTIGFuZCBzZXJ2ZXIgYXV0aGVudGljYXRpb24gdmVyc3VzIGNsaWVudCBh dXRoZW50aWNhdGlvbi4uLikuDQoNCjMpIFRoZSBzZWN1cml0eSBkZWZpbml0aW9ucyBzaG91bGQg YmUgbmVhcmx5IHRoZSBzYW1lIGZvciBtdWx0aXBsZSByZWNpcGllbnRzICh3aGljaCBzaGFyZSBh IGNvbW1vbiBzeW1tZXRyaWMga2V5KS4NCg0KKCopIFNob3VwIFtJU08gMTgwMzMtMl0gaW50cm9k dWNlZCB0aGUgS0VNLURFTSBhcHByb2FjaCB0byBoeWJyaWQgUEtFIHNjaGVtZXMsIHdoaWNoIG1h eSBiZSBoaWdobHkgdXNlZnVsIGZvciBkZXNjcmliaW5nLCBhbmQgcHJvdmluZyB0aGluZ3MgYWJv dXQsIHRoZSBDTVMgbWV0aG9kcy4gIEkgdmFndWVseSByZWNhbGwgc29tZSByZXNlYXJjaCBkb25l IGluIHRoaXMgYXJlYS4NCg0KKCoqKSBJbiBhIHNlcGFyYXRlIG1lc3NhZ2UsIEkgd2lsbCBkaXNj dXNzIHNjaGVtZXMgaW4gd2hpY2ggdGhlIHNlbmRlciBjYW4gYWxzbyBiZSBhdXRoZW50aWNhdGVk IGJ5IG1lYW5zIG9mIGFuIGF1dGhlbnRpY2F0ZWQga2V5IChidXQgZG9lcyBub3Qgc2lnbikuDQoN CkJlc3QgcmVnYXJkcywNCg0KRGFuaWVsIEJyb3duDQoNClJlc2VhcmNoIEluIE1vdGlvbiBMaW1p dGVkDQoNCg0KDQoNCjxpbWFnZTAwMS5naWY+DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJh bnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlh bCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBw cml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNl IG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJl Y2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24g YnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Q2ZyZyBtYWlsaW5nIGxpc3QNCkNmcmdAaXJ0Zi5vcmc8bWFpbHRvOkNmcmdAaXJ0Zi5vcmc+DQpo dHRwOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0K --_000_E493FE1B65A8447DB68479E2A4DB91B6rhulacuk_ Content-Type: text/html; charset="utf-8" Content-ID: <3BB325913553844DB136771323A392AC@rhul.ac.uk> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiPg0KPGRpdj5EYW4sPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5VbmRlciBpdGVt IDMgb24geW91ciBsaXN0LCB0aGVyZSBpcyBhIG5pY2UgcGFwZXImbmJzcDs8L2Rpdj4NCjxkaXY+ YnkgTmlnZWwgU21hcnQgYXQgU0NOIDIwMDQuIFRoaXMgZ2l2ZXMmbmJzcDs8L2Rpdj4NCjxkaXY+ c2VjdXJpdHkgbW9kZWxzIGFuZCBjb25zdHJ1Y3Rpb25zIGZvcjwvZGl2Pg0KPGRpdj5tdWx0aS1y ZWNpcGllbnQgS0VNcywgYmFzaWNhbGx5IHdoYXQgeW91Jm5ic3A7PC9kaXY+DQo8ZGl2PmFyZSBh ZnRlci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIHJlbGF0ZWQgd29y ayBvbjwvZGl2Pg0KPGRpdj5yYW5kb21uZXNzIHJldXNlIGluIHB1YmxpYyBrZXkgZW5jcnlwdGlv bjwvZGl2Pg0KPGRpdj4ocHJvYmFibHkgcmVmZXJlbmNlZCBpbiBOaWdlbCdzIHBhcGVyKS48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJyb2FkY2FzdCBlbmNyeXB0aW9uIGlzIHlldCBh bm90aGVyIHJlbGF0ZWQ8L2Rpdj4NCjxkaXY+KHlldCBkaXN0aW5jdCkgdG9waWMuICZuYnNwOyZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2FuIHlvdSBwcm92aWRlIHBvaW50 ZXJzIHRvIHRoZSBjbXMvSm9zZTwvZGl2Pg0KPGRpdj5zY2hlbWVzIHlvdSBhcmUgaW50ZXJlc3Rl ZCBpbiBhbmFseXNpbmc/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+S2Vubnk8YnI+DQo8YnI+DQpTZW50IGZyb20g bXkgaVBob25lPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIDUgQXByIDIwMTMsIGF0IDE2OjQ4LCAmcXVv dDtEYW4gQnJvd24mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkYnJvd25AY2VydGljb20uY29t Ij5kYnJvd25AY2VydGljb20uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2PjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgQ0ZSRyBsaXN0OjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIElFVEYgcHJvdG9jb2xzLCBpbmNsdWRpbmcgQ01TIChh bmQgcGVyaGFwcyBKT1NFKSwgb2ZmZXIgc2NoZW1lcyB0aGF0IGFyZSBlc3NlbnRpYWxseSBwdWJs aWMta2V5IGVuY3J5cHRpb246IHRoZXkgcHJvdGVjdCBhIGNvbnZleWVkIG1lc3NhZ2UgZnJvbSBh biB1bmF1dGhlbnRpY2F0ZWQgKGNyeXB0b2dyYXBoaWNhbGx5IGFub255bW91cykgc2VuZGVyICgq KikgdG8gYSByZWNpcGllbnQgd2l0aCBhIHB1YmxpYw0KIGtleSwgd2l0aCB0aGUgd3JpbmtsZSB0 aGF0IHRoZXkgYWxzbyBwZXJtaXQgbXVsdGlwbGUgcmVjaXBpZW50cyAoc2hhcmluZyBhIGNvbW1v biAmcXVvdDt3cmFwcGVkJnF1b3Q7IGtleSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdGhv dWdoIHRoZSBzZW5kZXIgaGFzIG5vIGF1dGhlbnRpY2F0ZWQga2V5LCB0aGUgc2VuZGVyIHN0aWxs IGFwcGxpZXMgYSBNQUMgdG8gdGhlIG1lc3NhZ2UuJm5ic3A7IFRoaXMgYXBwbGljYXRpb24gb2Yg YSBNQUMgaGFzIGJlZW4gY2FsbGVkICZxdW90O2F1dGhlbnRpY2F0ZWQmcXVvdDsgKHdpdGggcmVz cGVjdCB0byB3aG9ldmVyIGhhcyB0aGUgTUFDIGtleSkgaW4gc29tZSBwbGFjZXMuIEl0IGhhcyBh bHNvIGJlZW4gY2FsbGVkICZxdW90O2ludGVncml0eS1wcm90ZWN0aW9uJnF1b3Q7DQogaW4gb3Ro ZXIgcGxhY2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXN0IHZlcnNpb25zIG9mIENNUyBt ZXNzYWdlIGVuY3J5cHRpb24gZGlkIG5vdCBhcHBseSB0aGUgTUFDLiBDb25zZXF1ZW50bHksIHRo ZSBpbnRlZ3JpdHkgb2YgYW4gZW5jcnlwdGVkIG1lc3NhZ2Ugd2FzIG5vdCBwcm90ZWN0ZWQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIHRoYXQgdGhlIHB1cnBvc2Ugb2YgdGhlIE1B Q2luZyBjb3JyZXNwb25kcyBjbG9zZWx5IHRvIHRoZSBjcnlwdG9ncmFwaGVyc+KAmSBub3Rpb24g b2YgJnF1b3Q7bm9uLW1hbGxlYWJpbGl0eSZxdW90OyAoTk0pIGdvYWwgcHVibGljLWtleSBlbmNy eXB0aW9uIHNjaGVtZXMuJm5ic3A7IChJZiBJIHJlY2FsbCBjb3JyZWN0bHksIE5NLUNDQTIgaGFz IGJlZW4gcHJvdmVuIGVxdWl2YWxlbnQgdG8gSU5ELUNDQTIuKTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5RdWVzdGlvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIERvIHRoZSBleGlzdGlu ZyBhbmQgcHJvcG9zZWQgSUVURiBwdWJsaWMta2V5IG1lc3NhZ2UgZW5jcnlwdGlvbiBtZXRob2Rz IG1lZXQgdGhlIGNyeXB0b2dyYXBoZXIncyBiZW5jaG1hcmsgb2YgSU5ELUNDQTIgc2VjdXJpdHk/ IEhvdyBpbXBvcnRhbnQgaXMgdGhhdCB0byBtZWV0IHRoZXNlIGdvYWxzPyZuYnNwOyBDYW4gKG9y IGhhdmUpIHRoZXNlIGNyeXB0b2dyYXBoZXLigJlzIHNlY3VyaXR5IGdvYWxzIGJlIHByb3Zlbg0K IGZvciB0aGUgc3BlY2lmaWMgQ01TIG1ldGhvZHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIp IFdoYXQgaXMgdGhlIGJlc3QgdGVybWlub2xvZ3kgdG8gdXNlIGluIElFVEY/Jm5ic3A7IEhvdyBp bXBvcnRhbnQgaXMgdGVybWlub2xvZ3k/Jm5ic3A7IFNob3VsZCB0aGUgZXhpc3RpbmcgSUVURiB0 ZXJtaW5vbG9neSBiZSBhbWVuZGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBXaGF0IGlz IHRoZSByaWdodCBmb3JtYWwgZGVmaW5pdGlvbiB3aGVuIG11bHRpcGxlIHJlY2lwaWVudHMgYXJl IGludm9sdmVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZWsgeW91ciBhbnN3ZXJzLCBi dXQgaGVyZSBhcmUgbXkgdGVudGF0aXZlIGFuc3dlcnM6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjEpIFRoZSBjdXJyZW50IHByb3Bvc2FscyBwcm92aWRlIElORC1DQ0EyLiZuYnNwOyBJdCB3b3Vs ZCBiZSB2ZXJ5IGhhcmQgdG8gcHJvdmUgdGhpcyAoKikuJm5ic3A7IEl0IGlzIGltcG9ydGFudCB0 byBwcm92aWRlIGF0IGxlYXN0IElORC1DQ0ExIHNlY3VyaXR5LCBidXQgQ0NBMiBpcyBuZXZlciBy ZWFsbHkgbmVjZXNzYXJ5Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpICZxdW90O05vbi1t YWxsZWFiaWxpdHkmcXVvdDsgaXMgdGhlIGJlc3QgdGVybWlub2xvZ3kgZm9yIG1hbnkgZ2VuZXJh bCB1c2VycywgYXQgbGVhc3QgZnJvbSBteSBleHBlcmllbmNlLiBTdGFuZGFyZCB0ZXJtaW5vbG9n eSBpcyBpbXBvcnRhbnQsIGZvciBtdXR1YWwgdW5kZXJzdGFuZGluZywgYW5kIGFjY2lkZW50IGF2 b2lkYW5jZS4mbmJzcDsgVGhlIHRlcm0gJnF1b3Q7YXV0aGVudGljYXRlZCZxdW90OyBzaG91bGQg ZWl0aGVyIHJlbW92ZWQgd2hlbg0KIHRoZSBzZW5kZXIgZG9lcyBub3QgdXNlIGFuIGF1dGhlbnRp Y2F0ZWQga2V5LCBvciBlbHNlIGNoYW5nZSB0aGUgdGVybSB0byAmcXVvdDtyZWNpcGllbnQtYXV0 aGVudGljYXRlZCZxdW90OyAoY29tcGFyZSBUTFMgYW5kIHNlcnZlciBhdXRoZW50aWNhdGlvbiB2 ZXJzdXMgY2xpZW50IGF1dGhlbnRpY2F0aW9uLi4uKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MykgVGhlIHNlY3VyaXR5IGRlZmluaXRpb25zIHNob3VsZCBiZSBuZWFybHkgdGhlIHNhbWUgZm9y IG11bHRpcGxlIHJlY2lwaWVudHMgKHdoaWNoIHNoYXJlIGEgY29tbW9uIHN5bW1ldHJpYyBrZXkp LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oKikgU2hvdXAgW0lTTyAxODAzMy0yXSBpbnRyb2R1 Y2VkIHRoZSBLRU0tREVNIGFwcHJvYWNoIHRvIGh5YnJpZCBQS0Ugc2NoZW1lcywgd2hpY2ggbWF5 IGJlIGhpZ2hseSB1c2VmdWwgZm9yIGRlc2NyaWJpbmcsIGFuZCBwcm92aW5nIHRoaW5ncyBhYm91 dCwgdGhlIENNUyBtZXRob2RzLiZuYnNwOyBJIHZhZ3VlbHkgcmVjYWxsIHNvbWUgcmVzZWFyY2gg ZG9uZSBpbiB0aGlzIGFyZWEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigqKikgSW4gYSBzZXBh cmF0ZSBtZXNzYWdlLCBJIHdpbGwgZGlzY3VzcyBzY2hlbWVzIGluIHdoaWNoIHRoZSBzZW5kZXIg Y2FuIGFsc28gYmUgYXV0aGVudGljYXRlZCBieSBtZWFucyBvZiBhbiBhdXRoZW50aWNhdGVkIGtl eSAoYnV0IGRvZXMgbm90IHNpZ24pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNp bmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNjAwIiBzdHlsZT0id2lkdGg6NS4waW4iPg0K PHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMi40cHQgMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDo5LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EYW5pZWwgQnJvd248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6My4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3M0JDIj5SZXNlYXJjaCBJbiBNb3Rpb24gTGlt aXRlZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OztkaXNwbGF5Om5v bmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i NjAwIiBzdHlsZT0id2lkdGg6NS4waW4iPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OztkaXNwbGF5 Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNjAwIiBzdHlsZT0id2lkdGg6NS4waW4iPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjcuOHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jmx0O2ltYWdlMDAxLmdpZiZndDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iNjAwIiBzdHlsZT0id2lkdGg6NS4waW47cGFkZGluZzo3 LjhwdCAwaW4gMGluIDBpbiI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAo aW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBv dGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5m b3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0KIGJ5IGFueW9uZSBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBs eSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lz dGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9m IHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRo b3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIDwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPkNmcmcgbWFpbGluZyBsaXN0 PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpDZnJnQGlydGYub3JnIj5DZnJnQGly dGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlydGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2ZyZyI+aHR0cDovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Nmcmc8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_E493FE1B65A8447DB68479E2A4DB91B6rhulacuk_-- From prvs=08079e3072=dbrown@certicom.com Fri Apr 5 11:40:08 2013 Return-Path: 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 D256E21F9814 for ; Fri, 5 Apr 2013 11:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[AWL=1.908, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 5lTlDZFjDi+5 for ; Fri, 5 Apr 2013 11:40:07 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3754221F9804 for ; Fri, 5 Apr 2013 11:40:05 -0700 (PDT) X-AuditID: 0a412830-b7f2f6d000007c2a-8e-515f1a762409 Received: from XCT107CNC.rim.net (xct107cnc.rim.net [10.65.161.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 5B.56.31786.67A1F515; Fri, 5 Apr 2013 13:39:50 -0500 (CDT) Received: from XCT116CNC.rim.net (10.65.161.216) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 5 Apr 2013 14:39:50 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT116CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Fri, 5 Apr 2013 14:39:49 -0400 From: Dan Brown To: "'Paterson, Kenny'" Thread-Topic: [Cfrg] IETF's secure messaging v public-key encryption Thread-Index: Ac4yFPPtfKFxsQ9USvOVB6D3EGsogQAB5SGAAAN9wFA= Date: Fri, 5 Apr 2013 18:39:49 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513CD93@XMB111CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF513CC9E@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF513CD93XMB111CNCrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLKsWRmVeSWpSXmKPExsXC5bjwvG6ZVHygwaWbphbdPw4yWXTdOcnq wOQxeeNhNo8vr1exBTBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejANdkxkLOpqZKt7f/8bSwLjoD2MXIyeHhICJxKSd 61ggbDGJC/fWs3UxcnEICbQzSSw7vpERwlnBKDH3z3lmCGc2o8S7hk1g7WwCqhL3j55jBrFF BIwl7i+7zwRiMwsoSyxafwLMFhZwlvj+6yATRI2LxIdHF4F6OYBsK4kvV0tATBYBFYkZ52tB TF4BN4mHe51BioUEqiQeL5nDDhLmFLCTeHoDLMwoICux++x1qD3iEreezGeCOF9AYsme88wQ tqjEy8f/WCFsRYm9z45C1edKzJhzBqyGV0BQ4uTMJywQqxQkrlzfxzKBUXwWkrGzkLTMQtIy C+giZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUTA3o9jAzDA5L1mvKDNXLy+1ZBMj OAlpGOxgfP/e4hCjAAejEg9vC3d8oBBrYllxZe4hRgkOZiURXtnncYFCvCmJlVWpRfnxRaU5 qcWHGIOAoTaRWYo7OR+YIPNK4o0NDIjkKInz/haODhQSSAcmw+zU1ILUIpihTBycIEu5pESK gSkttSixtCQjHpR444uBqVeqgTFbpiTL6r1mt29D6Y2WPbWukwy+H91r8i8mQLPE/NxP+ZUB nTfZmVdm3pxhN6H/3I9CjWNtVqE+OWxNL4++3aW+TS7UL2CqwSYhRptVWb23ZXZfYUpksg9e lDRD+MDH54tqtsYnrq6SMTuk13BoYut/J6EPJx+lylydLc2cOrG08KAg2w6rNiWW4oxEQy3m ouJEAF2oiWKQAwAA Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] IETF's secure messaging v public-key encryption X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 18:40:09 -0000 --_000_810C31990B57ED40B2062BA10D43FBF513CD93XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 S2VubnksDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJlZmVyZW5jZSB0byB0aGUgU21hcnQgcGFw ZXIsIEkgd2lsbCBsb29rIGZvciBpdC4NCg0KSGVyZSBhcmUgdGhlIHJlbGV2YW50IElFVEYg ZG9jdW1lbnRzOg0KDQpDTVM6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MDgz ICh3aGVuIGtleSBtYW5hZ2VtZW50ID0ga2V5IHRyYW5zcG9ydCBvciBlcGhlbWVyYWwga2V5 IGFncmVlbWVudCkNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY0NzYgKGFzIGFi b3ZlKQ0KDQpKT1NFOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1q b3NlLWpzb24td2ViLWVuY3J5cHRpb24tMDggKHNpbWlsYXIgdG8gYWJvdmUpDQoNClRoZXJl IG1heSBiZSBvdGhlciBJRVRGIGRvY3VtZW50cyB0aGF0IGRvIHNvbWV0aGluZyBzaW1pbGFy Lg0KDQpUaGFua3MsDQoNCkRhbg0KDQpGcm9tOiBjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgW21h aWx0bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXRlcnNvbiwgS2Vu bnkNClNlbnQ6IEZyaWRheSwgQXByaWwgMDUsIDIwMTMgMTo0MiBQTQ0KVG86IERhbiBCcm93 bg0KQ2M6IGNmcmdAaXJ0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ2ZyZ10gSUVURidzIHNlY3Vy ZSBtZXNzYWdpbmcgdiBwdWJsaWMta2V5IGVuY3J5cHRpb24NCg0KRGFuLA0KDQpVbmRlciBp dGVtIDMgb24geW91ciBsaXN0LCB0aGVyZSBpcyBhIG5pY2UgcGFwZXINCmJ5IE5pZ2VsIFNt YXJ0IGF0IFNDTiAyMDA0LiBUaGlzIGdpdmVzDQpzZWN1cml0eSBtb2RlbHMgYW5kIGNvbnN0 cnVjdGlvbnMgZm9yDQptdWx0aS1yZWNpcGllbnQgS0VNcywgYmFzaWNhbGx5IHdoYXQgeW91 DQphcmUgYWZ0ZXIuDQoNClRoZXJlIGlzIHJlbGF0ZWQgd29yayBvbg0KcmFuZG9tbmVzcyBy ZXVzZSBpbiBwdWJsaWMga2V5IGVuY3J5cHRpb24NCihwcm9iYWJseSByZWZlcmVuY2VkIGlu IE5pZ2VsJ3MgcGFwZXIpLg0KDQpCcm9hZGNhc3QgZW5jcnlwdGlvbiBpcyB5ZXQgYW5vdGhl ciByZWxhdGVkDQooeWV0IGRpc3RpbmN0KSB0b3BpYy4NCg0KQ2FuIHlvdSBwcm92aWRlIHBv aW50ZXJzIHRvIHRoZSBjbXMvSm9zZQ0Kc2NoZW1lcyB5b3UgYXJlIGludGVyZXN0ZWQgaW4g YW5hbHlzaW5nPw0KDQpSZWdhcmRzLA0KDQpLZW5ueQ0KDQpTZW50IGZyb20gbXkgaVBob25l DQoNCk9uIDUgQXByIDIwMTMsIGF0IDE2OjQ4LCAiRGFuIEJyb3duIiA8ZGJyb3duQGNlcnRp Y29tLmNvbTxtYWlsdG86ZGJyb3duQGNlcnRpY29tLmNvbT4+IHdyb3RlOg0KRGVhciBDRlJH IGxpc3Q6DQoNClNvbWUgSUVURiBwcm90b2NvbHMsIGluY2x1ZGluZyBDTVMgKGFuZCBwZXJo YXBzIEpPU0UpLCBvZmZlciBzY2hlbWVzIHRoYXQgYXJlIGVzc2VudGlhbGx5IHB1YmxpYy1r ZXkgZW5jcnlwdGlvbjogdGhleSBwcm90ZWN0IGEgY29udmV5ZWQgbWVzc2FnZSBmcm9tIGFu IHVuYXV0aGVudGljYXRlZCAoY3J5cHRvZ3JhcGhpY2FsbHkgYW5vbnltb3VzKSBzZW5kZXIg KCoqKSB0byBhIHJlY2lwaWVudCB3aXRoIGEgcHVibGljIGtleSwgd2l0aCB0aGUgd3Jpbmts ZSB0aGF0IHRoZXkgYWxzbyBwZXJtaXQgbXVsdGlwbGUgcmVjaXBpZW50cyAoc2hhcmluZyBh IGNvbW1vbiAid3JhcHBlZCIga2V5KS4NCg0KQWx0aG91Z2ggdGhlIHNlbmRlciBoYXMgbm8g YXV0aGVudGljYXRlZCBrZXksIHRoZSBzZW5kZXIgc3RpbGwgYXBwbGllcyBhIE1BQyB0byB0 aGUgbWVzc2FnZS4gIFRoaXMgYXBwbGljYXRpb24gb2YgYSBNQUMgaGFzIGJlZW4gY2FsbGVk ICJhdXRoZW50aWNhdGVkIiAod2l0aCByZXNwZWN0IHRvIHdob2V2ZXIgaGFzIHRoZSBNQUMg a2V5KSBpbiBzb21lIHBsYWNlcy4gSXQgaGFzIGFsc28gYmVlbiBjYWxsZWQgImludGVncml0 eS1wcm90ZWN0aW9uIiBpbiBvdGhlciBwbGFjZXMuDQoNClBhc3QgdmVyc2lvbnMgb2YgQ01T IG1lc3NhZ2UgZW5jcnlwdGlvbiBkaWQgbm90IGFwcGx5IHRoZSBNQUMuIENvbnNlcXVlbnRs eSwgdGhlIGludGVncml0eSBvZiBhbiBlbmNyeXB0ZWQgbWVzc2FnZSB3YXMgbm90IHByb3Rl Y3RlZC4NCg0KSXQgc2VlbXMgdGhhdCB0aGUgcHVycG9zZSBvZiB0aGUgTUFDaW5nIGNvcnJl c3BvbmRzIGNsb3NlbHkgdG8gdGhlIGNyeXB0b2dyYXBoZXJz4oCZIG5vdGlvbiBvZiAibm9u LW1hbGxlYWJpbGl0eSIgKE5NKSBnb2FsIHB1YmxpYy1rZXkgZW5jcnlwdGlvbiBzY2hlbWVz LiAgKElmIEkgcmVjYWxsIGNvcnJlY3RseSwgTk0tQ0NBMiBoYXMgYmVlbiBwcm92ZW4gZXF1 aXZhbGVudCB0byBJTkQtQ0NBMi4pDQoNClF1ZXN0aW9uczoNCg0KMSkgRG8gdGhlIGV4aXN0 aW5nIGFuZCBwcm9wb3NlZCBJRVRGIHB1YmxpYy1rZXkgbWVzc2FnZSBlbmNyeXB0aW9uIG1l dGhvZHMgbWVldCB0aGUgY3J5cHRvZ3JhcGhlcidzIGJlbmNobWFyayBvZiBJTkQtQ0NBMiBz ZWN1cml0eT8gSG93IGltcG9ydGFudCBpcyB0aGF0IHRvIG1lZXQgdGhlc2UgZ29hbHM/ICBD YW4gKG9yIGhhdmUpIHRoZXNlIGNyeXB0b2dyYXBoZXLigJlzIHNlY3VyaXR5IGdvYWxzIGJl IHByb3ZlbiBmb3IgdGhlIHNwZWNpZmljIENNUyBtZXRob2RzPw0KDQoyKSBXaGF0IGlzIHRo ZSBiZXN0IHRlcm1pbm9sb2d5IHRvIHVzZSBpbiBJRVRGPyAgSG93IGltcG9ydGFudCBpcyB0 ZXJtaW5vbG9neT8gIFNob3VsZCB0aGUgZXhpc3RpbmcgSUVURiB0ZXJtaW5vbG9neSBiZSBh bWVuZGVkPw0KDQozKSBXaGF0IGlzIHRoZSByaWdodCBmb3JtYWwgZGVmaW5pdGlvbiB3aGVu IG11bHRpcGxlIHJlY2lwaWVudHMgYXJlIGludm9sdmVkPw0KDQpJIHNlZWsgeW91ciBhbnN3 ZXJzLCBidXQgaGVyZSBhcmUgbXkgdGVudGF0aXZlIGFuc3dlcnM6DQoNCjEpIFRoZSBjdXJy ZW50IHByb3Bvc2FscyBwcm92aWRlIElORC1DQ0EyLiAgSXQgd291bGQgYmUgdmVyeSBoYXJk IHRvIHByb3ZlIHRoaXMgKCopLiAgSXQgaXMgaW1wb3J0YW50IHRvIHByb3ZpZGUgYXQgbGVh c3QgSU5ELUNDQTEgc2VjdXJpdHksIGJ1dCBDQ0EyIGlzIG5ldmVyIHJlYWxseSBuZWNlc3Nh cnkuDQoNCjIpICJOb24tbWFsbGVhYmlsaXR5IiBpcyB0aGUgYmVzdCB0ZXJtaW5vbG9neSBm b3IgbWFueSBnZW5lcmFsIHVzZXJzLCBhdCBsZWFzdCBmcm9tIG15IGV4cGVyaWVuY2UuIFN0 YW5kYXJkIHRlcm1pbm9sb2d5IGlzIGltcG9ydGFudCwgZm9yIG11dHVhbCB1bmRlcnN0YW5k aW5nLCBhbmQgYWNjaWRlbnQgYXZvaWRhbmNlLiAgVGhlIHRlcm0gImF1dGhlbnRpY2F0ZWQi IHNob3VsZCBlaXRoZXIgcmVtb3ZlZCB3aGVuIHRoZSBzZW5kZXIgZG9lcyBub3QgdXNlIGFu IGF1dGhlbnRpY2F0ZWQga2V5LCBvciBlbHNlIGNoYW5nZSB0aGUgdGVybSB0byAicmVjaXBp ZW50LWF1dGhlbnRpY2F0ZWQiIChjb21wYXJlIFRMUyBhbmQgc2VydmVyIGF1dGhlbnRpY2F0 aW9uIHZlcnN1cyBjbGllbnQgYXV0aGVudGljYXRpb24uLi4pLg0KDQozKSBUaGUgc2VjdXJp dHkgZGVmaW5pdGlvbnMgc2hvdWxkIGJlIG5lYXJseSB0aGUgc2FtZSBmb3IgbXVsdGlwbGUg cmVjaXBpZW50cyAod2hpY2ggc2hhcmUgYSBjb21tb24gc3ltbWV0cmljIGtleSkuDQoNCigq KSBTaG91cCBbSVNPIDE4MDMzLTJdIGludHJvZHVjZWQgdGhlIEtFTS1ERU0gYXBwcm9hY2gg dG8gaHlicmlkIFBLRSBzY2hlbWVzLCB3aGljaCBtYXkgYmUgaGlnaGx5IHVzZWZ1bCBmb3Ig ZGVzY3JpYmluZywgYW5kIHByb3ZpbmcgdGhpbmdzIGFib3V0LCB0aGUgQ01TIG1ldGhvZHMu ICBJIHZhZ3VlbHkgcmVjYWxsIHNvbWUgcmVzZWFyY2ggZG9uZSBpbiB0aGlzIGFyZWEuDQoN CigqKikgSW4gYSBzZXBhcmF0ZSBtZXNzYWdlLCBJIHdpbGwgZGlzY3VzcyBzY2hlbWVzIGlu IHdoaWNoIHRoZSBzZW5kZXIgY2FuIGFsc28gYmUgYXV0aGVudGljYXRlZCBieSBtZWFucyBv ZiBhbiBhdXRoZW50aWNhdGVkIGtleSAoYnV0IGRvZXMgbm90IHNpZ24pLg0KDQpCZXN0IHJl Z2FyZHMsDQoNCkRhbmllbCBCcm93bg0KDQpSZXNlYXJjaCBJbiBNb3Rpb24gTGltaXRlZA0K DQoNCg0KDQo8aW1hZ2UwMDEuZ2lmPg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIHRy YW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcg bWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFw cGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1h dGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBy ZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlv dXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBp cyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNmcmcgbWFpbGluZyBsaXN0DQpD ZnJnQGlydGYub3JnPG1haWx0bzpDZnJnQGlydGYub3JnPg0KaHR0cDovL3d3dy5pcnRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIHRyYW5z bWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0 ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxp Y2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlv bi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBs eSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0 aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBu b3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K --_000_810C31990B57ED40B2062BA10D43FBF513CD93XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMt MTFkMS1BMkEzLTAwQUEwMEMxNDg4MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206cm93c2V0IiB4bWxuczp6PSIjUm93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpwdWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6Yz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9uZW50OnNwcmVhZHNoZWV0IiB4bWxu czpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9kYyIgeG1sbnM6b2E9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHhtbG5zOmh0 bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5zOnE9Imh0dHA6Ly9z Y2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9Imh0dHA6Ly9t aWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRBVjoiIHht bG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5zOm10 PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNl bC8yMDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNw YWNlLnhzZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJl cG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAx L1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRzLyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMu b3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIw MDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5t aWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3Zj0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4 bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1s Zm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVy PSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxp dHkvMjAwNiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2Uv MjAwNC8xMi9vbW1sIiB4bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1h dHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8v bWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0 dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBl cyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uv c2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRlTGlicmFyeS8iIHhtbG5zOnNwc2w9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1NoYXJlUG9pbnRQb3J0YWxTZXJ2 ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8 c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktlbm55LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhbmsgeW91IGZvciB0aGUgcmVmZXJlbmNlIHRvIHRoZSBTbWFydCBwYXBlciwgSSB3 aWxsIGxvb2sgZm9yIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVyZSBhcmUgdGhl IHJlbGV2YW50IElFVEYgZG9jdW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q01T Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUwODMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzUwODM8L2E+ICh3aGVuIGtleSBtYW5hZ2VtZW50ID0ga2V5IHRyYW5zcG9ydCBv ciBlcGhlbWVyYWwga2V5IGFncmVlbWVudCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQ3NiI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQ3NjwvYT4gKGFzIGFib3ZlKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Sk9TRTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMDgiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA4PC9hPiAoc2ltaWxh ciB0bw0KIGFib3ZlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgbWF5IGJlIG90 aGVyIElFVEYgZG9jdW1lbnRzIHRoYXQgZG8gc29tZXRoaW5nIHNpbWlsYXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBjZnJnLWJvdW5j ZXNAaXJ0Zi5vcmcgW21haWx0bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlBhdGVyc29uLCBLZW5ueTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFw cmlsIDA1LCAyMDEzIDE6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IERhbiBCcm93bjxicj4NCjxi PkNjOjwvYj4gY2ZyZ0BpcnRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Nmcmdd IElFVEYncyBzZWN1cmUgbWVzc2FnaW5nIHYgcHVibGljLWtleSBlbmNyeXB0aW9uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRh biw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VW5kZXIgaXRlbSAzIG9uIHlvdXIgbGlzdCwgdGhlcmUgaXMgYSBuaWNlIHBhcGVy Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ieSBOaWdlbCBTbWFydCBhdCBTQ04gMjAwNC4gVGhpcyBnaXZlcyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VjdXJp dHkgbW9kZWxzIGFuZCBjb25zdHJ1Y3Rpb25zIGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bXVsdGktcmVjaXBpZW50IEtFTXMsIGJh c2ljYWxseSB3aGF0IHlvdSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YXJlIGFmdGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyByZWxhdGVkIHdv cmsgb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnJhbmRvbW5lc3MgcmV1c2UgaW4gcHVibGljIGtleSBlbmNyeXB0aW9uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4ocHJvYmFibHkg cmVmZXJlbmNlZCBpbiBOaWdlbCdzIHBhcGVyKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJvYWRjYXN0IGVuY3J5cHRpb24g aXMgeWV0IGFub3RoZXIgcmVsYXRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KHlldCBkaXN0aW5jdCkgdG9waWMuICZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DYW4geW91IHByb3ZpZGUgcG9pbnRlcnMgdG8gdGhlIGNtcy9Kb3NlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zY2hlbWVzIHlv dSBhcmUgaW50ZXJlc3RlZCBpbiBhbmFseXNpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbm55PGJy Pg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpPbiA1IEFwciAyMDEzLCBhdCAxNjo0OCwgJnF1b3Q7RGFuIEJyb3duJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86ZGJyb3duQGNlcnRpY29tLmNvbSI+ZGJyb3duQGNlcnRp Y29tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFyIENGUkcgbGlzdDo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvbWUgSUVURiBwcm90b2Nv bHMsIGluY2x1ZGluZyBDTVMgKGFuZCBwZXJoYXBzIEpPU0UpLCBvZmZlciBzY2hlbWVzIHRo YXQgYXJlIGVzc2VudGlhbGx5IHB1YmxpYy1rZXkgZW5jcnlwdGlvbjogdGhleSBwcm90ZWN0 IGEgY29udmV5ZWQgbWVzc2FnZSBmcm9tIGFuIHVuYXV0aGVudGljYXRlZCAoY3J5cHRvZ3Jh cGhpY2FsbHkNCiBhbm9ueW1vdXMpIHNlbmRlciAoKiopIHRvIGEgcmVjaXBpZW50IHdpdGgg YSBwdWJsaWMga2V5LCB3aXRoIHRoZSB3cmlua2xlIHRoYXQgdGhleSBhbHNvIHBlcm1pdCBt dWx0aXBsZSByZWNpcGllbnRzIChzaGFyaW5nIGEgY29tbW9uICZxdW90O3dyYXBwZWQmcXVv dDsga2V5KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsdGhvdWdo IHRoZSBzZW5kZXIgaGFzIG5vIGF1dGhlbnRpY2F0ZWQga2V5LCB0aGUgc2VuZGVyIHN0aWxs IGFwcGxpZXMgYSBNQUMgdG8gdGhlIG1lc3NhZ2UuJm5ic3A7IFRoaXMgYXBwbGljYXRpb24g b2YgYSBNQUMgaGFzIGJlZW4gY2FsbGVkICZxdW90O2F1dGhlbnRpY2F0ZWQmcXVvdDsgKHdp dGggcmVzcGVjdCB0byB3aG9ldmVyDQogaGFzIHRoZSBNQUMga2V5KSBpbiBzb21lIHBsYWNl cy4gSXQgaGFzIGFsc28gYmVlbiBjYWxsZWQgJnF1b3Q7aW50ZWdyaXR5LXByb3RlY3Rpb24m cXVvdDsgaW4gb3RoZXIgcGxhY2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+UGFzdCB2ZXJzaW9ucyBvZiBDTVMgbWVzc2FnZSBlbmNyeXB0aW9uIGRpZCBub3Qg YXBwbHkgdGhlIE1BQy4gQ29uc2VxdWVudGx5LCB0aGUgaW50ZWdyaXR5IG9mIGFuIGVuY3J5 cHRlZCBtZXNzYWdlIHdhcyBub3QgcHJvdGVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SXQgc2VlbXMgdGhhdCB0aGUgcHVycG9zZSBvZiB0aGUgTUFDaW5n IGNvcnJlc3BvbmRzIGNsb3NlbHkgdG8gdGhlIGNyeXB0b2dyYXBoZXJz4oCZIG5vdGlvbiBv ZiAmcXVvdDtub24tbWFsbGVhYmlsaXR5JnF1b3Q7IChOTSkgZ29hbCBwdWJsaWMta2V5IGVu Y3J5cHRpb24gc2NoZW1lcy4mbmJzcDsgKElmIEkgcmVjYWxsIGNvcnJlY3RseSwNCiBOTS1D Q0EyIGhhcyBiZWVuIHByb3ZlbiBlcXVpdmFsZW50IHRvIElORC1DQ0EyLik8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjEpIERvIHRoZSBleGlzdGluZyBhbmQgcHJvcG9zZWQg SUVURiBwdWJsaWMta2V5IG1lc3NhZ2UgZW5jcnlwdGlvbiBtZXRob2RzIG1lZXQgdGhlIGNy eXB0b2dyYXBoZXIncyBiZW5jaG1hcmsgb2YgSU5ELUNDQTIgc2VjdXJpdHk/IEhvdyBpbXBv cnRhbnQgaXMgdGhhdCB0byBtZWV0IHRoZXNlIGdvYWxzPyZuYnNwOyBDYW4NCiAob3IgaGF2 ZSkgdGhlc2UgY3J5cHRvZ3JhcGhlcuKAmXMgc2VjdXJpdHkgZ29hbHMgYmUgcHJvdmVuIGZv ciB0aGUgc3BlY2lmaWMgQ01TIG1ldGhvZHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4yKSBXaGF0IGlzIHRoZSBiZXN0IHRlcm1pbm9sb2d5IHRvIHVzZSBpbiBJ RVRGPyZuYnNwOyBIb3cgaW1wb3J0YW50IGlzIHRlcm1pbm9sb2d5PyZuYnNwOyBTaG91bGQg dGhlIGV4aXN0aW5nIElFVEYgdGVybWlub2xvZ3kgYmUgYW1lbmRlZD88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMpIFdoYXQgaXMgdGhlIHJpZ2h0IGZvcm1hbCBk ZWZpbml0aW9uIHdoZW4gbXVsdGlwbGUgcmVjaXBpZW50cyBhcmUgaW52b2x2ZWQ/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHNlZWsgeW91ciBhbnN3ZXJzLCBi dXQgaGVyZSBhcmUgbXkgdGVudGF0aXZlIGFuc3dlcnM6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4xKSBUaGUgY3VycmVudCBwcm9wb3NhbHMgcHJvdmlkZSBJTkQt Q0NBMi4mbmJzcDsgSXQgd291bGQgYmUgdmVyeSBoYXJkIHRvIHByb3ZlIHRoaXMgKCopLiZu YnNwOyBJdCBpcyBpbXBvcnRhbnQgdG8gcHJvdmlkZSBhdCBsZWFzdCBJTkQtQ0NBMSBzZWN1 cml0eSwgYnV0IENDQTIgaXMgbmV2ZXIgcmVhbGx5IG5lY2Vzc2FyeS4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MikgJnF1b3Q7Tm9uLW1hbGxlYWJpbGl0eSZx dW90OyBpcyB0aGUgYmVzdCB0ZXJtaW5vbG9neSBmb3IgbWFueSBnZW5lcmFsIHVzZXJzLCBh dCBsZWFzdCBmcm9tIG15IGV4cGVyaWVuY2UuIFN0YW5kYXJkIHRlcm1pbm9sb2d5IGlzIGlt cG9ydGFudCwgZm9yIG11dHVhbCB1bmRlcnN0YW5kaW5nLCBhbmQgYWNjaWRlbnQgYXZvaWRh bmNlLiZuYnNwOw0KIFRoZSB0ZXJtICZxdW90O2F1dGhlbnRpY2F0ZWQmcXVvdDsgc2hvdWxk IGVpdGhlciByZW1vdmVkIHdoZW4gdGhlIHNlbmRlciBkb2VzIG5vdCB1c2UgYW4gYXV0aGVu dGljYXRlZCBrZXksIG9yIGVsc2UgY2hhbmdlIHRoZSB0ZXJtIHRvICZxdW90O3JlY2lwaWVu dC1hdXRoZW50aWNhdGVkJnF1b3Q7IChjb21wYXJlIFRMUyBhbmQgc2VydmVyIGF1dGhlbnRp Y2F0aW9uIHZlcnN1cyBjbGllbnQgYXV0aGVudGljYXRpb24uLi4pLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MykgVGhlIHNlY3VyaXR5IGRlZmluaXRpb25zIHNo b3VsZCBiZSBuZWFybHkgdGhlIHNhbWUgZm9yIG11bHRpcGxlIHJlY2lwaWVudHMgKHdoaWNo IHNoYXJlIGEgY29tbW9uIHN5bW1ldHJpYyBrZXkpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+KCopIFNob3VwIFtJU08gMTgwMzMtMl0gaW50cm9kdWNlZCB0aGUg S0VNLURFTSBhcHByb2FjaCB0byBoeWJyaWQgUEtFIHNjaGVtZXMsIHdoaWNoIG1heSBiZSBo aWdobHkgdXNlZnVsIGZvciBkZXNjcmliaW5nLCBhbmQgcHJvdmluZyB0aGluZ3MgYWJvdXQs IHRoZSBDTVMgbWV0aG9kcy4mbmJzcDsgSSB2YWd1ZWx5IHJlY2FsbA0KIHNvbWUgcmVzZWFy Y2ggZG9uZSBpbiB0aGlzIGFyZWEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4oKiopIEluIGEgc2VwYXJhdGUgbWVzc2FnZSwgSSB3aWxsIGRpc2N1c3Mgc2NoZW1l cyBpbiB3aGljaCB0aGUgc2VuZGVyIGNhbiBhbHNvIGJlIGF1dGhlbnRpY2F0ZWQgYnkgbWVh bnMgb2YgYW4gYXV0aGVudGljYXRlZCBrZXkgKGJ1dCBkb2VzIG5vdCBzaWduKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjYwMCIgc3R5bGU9IndpZHRoOjUuMGluIj4N Cjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDIuNHB0IDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6OS4wcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EYW5pZWwgQnJvd248L3NwYW4+ PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDA3M0JDIj5SZXNlYXJjaCBJbiBNb3Rpb24gTGltaXRl ZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjYwMCIgc3R5bGU9IndpZHRoOjUuMGluIj4NCjx0Ym9k eT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI2MDAiIHN0 eWxlPSJ3aWR0aDo1LjBpbiI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6 Ny44cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7aW1h Z2UwMDEuZ2lmJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQg d2lkdGg9IjYwMCIgc3R5bGU9IndpZHRoOjUuMGluO3BhZGRpbmc6Ny44cHQgMGluIDBpbiAw aW4iPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjxicj4NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNs dWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3Jt YXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0 ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxl Z2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9m IHRoaXMgaW5mb3JtYXRpb24NCiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJh bnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNl LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlz IHRyYW5zbWlzc2lvbg0KIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9y aXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDZnJnIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDZnJnQGlydGYub3JnIj5DZnJnQGlydGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jZnJnIj5odHRwOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5n IGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9u LCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5 IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyks IG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlz IGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGll bnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Np b24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNt aXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQg bWF5IGJlIHVubGF3ZnVsLg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_810C31990B57ED40B2062BA10D43FBF513CD93XMB111CNCrimnet_-- From prvs=680709395d=dbrown@certicom.com Fri Apr 5 13:53:08 2013 Return-Path: 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 0961521F8D8C for ; Fri, 5 Apr 2013 13:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.736 X-Spam-Level: X-Spam-Status: No, score=-3.736 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 5xqtWd33ffnO for ; Fri, 5 Apr 2013 13:53:04 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id C58CA21F8F0F for ; Fri, 5 Apr 2013 13:53:02 -0700 (PDT) X-AuditID: 0a41282f-b7f1a6d0000054a3-d8-515f39a3fe49 Received: from XCT107CNC.rim.net (xct107cnc.rim.net [10.65.161.207]) by mhs060cnc.rim.net (SBG) with SMTP id DB.0A.21667.3A93F515; Fri, 5 Apr 2013 15:52:51 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.02.0328.009; Fri, 5 Apr 2013 16:52:51 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: IETF's message authentication (1-pass) w/o signatures ... Thread-Index: Ac4yP4l8Eiozrl0aT4WptSFmBwrnQA== Date: Fri, 5 Apr 2013 20:52:51 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513CF51@XMB111CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBJsWRmVeSWpSXmKPExsXC5bjwvO5iy/hAg7+3TSy6fxxkcmD0mLzx MFsAY1QDo01SYklZcGZ6nr6dTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZllicqWCS2Zxck5i Zm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV8gz2 17WwMLXUNVSy003o5MlY9DahYOscxor9m+YyNjAu62HsYuTkkBAwkehpe8sKYYtJXLi3nq2L kYtDSGAVo8SBG5uYIJwtjBKvtkxgAaliE1CVuH/0HHMXIweHiICyxOePEiBhYQEnidZHm5lA bBEBd4nJM74zQ9h6Et8XX2AHsVkEVCQufpoFFucVcJN42b0DrJ5RQFZi99nrYDazgLjErSfz mSAOEpF4ePE0G4QtKvHy8T+oQxUl9j47ClXfySjxcb8MxExBiZMzn7BMYBSahWTULCRls5CU QcRzJZ7dmMoIYetILNj9iQ3C1pZYtvA1M4x95sBjJkxxHYnNl3ZCzVGUaOucDVTDBWQvBQbX /064oTenz4ArmtL9kH0BI+8qRsHcjGIDM4PkvGS9osxcvbzUkk2M4HSkob+D8e17i0OMAhyM Sjy8HqrxgUKsiWXFlbmHGFWAZjzasPoCoxRLXn5eqpIIr+zzuEAh3pTEyqrUovz4otKc1OJD jDnAoJ7ILMWdnA9MoXkl8cYGBhRzlMR5fwtHBwoJpAPTbnZqakFqEcw6Jg7OQ4wSHFxSIsXA 5JlalFhakhEPSvHxxcAkL9XAyBx/d4OEyNPeUO9F3I8WFTwQOsmYXBu8uvfa7sIHz/VMAvdI qXxXZjCWk58RvP7jhmirnSa8bJtKFsQfO9rxSOvvlrJ/7Gennr2fY/ooR+kEz6yaf9ebd5rt Ohea+W+CVdD8Y4XmafmCTW4ivELCUt8Y102sT5itejPf6drNPfd7YtbLl63fpcRSnJFoqMVc VJwIAFLM23e7AwAA Subject: [Cfrg] IETF's message authentication (1-pass) w/o signatures ... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 20:53:08 -0000 --_004_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear CFRG list: Some IETF messaging protocols, including CMS (and perhaps JOSE) offer messag= ing protocols in which both the sender and the recipient have authenticated= keys (public keys, shared symmetric keys, or passwords) and the message is= authenticated (and possibly also encrypted), but not signed in the usual se= nse of a public-key signature. Questions: 1. What benefits does this form of recipient-specific sender authentication= have over signing? In particular, is the main benefit adding non-malleabil= ity (integrity protection (***)) to encryption (*)? 2. What is the best cryptographic research defining formal security definiti= ons for this kind of operation? 3. How do the current IETF designs fare under these cryptographic research g= oals? 4. Suppose a message has multiple recipients, one of whom is malicious. Sho= uld a malicious recipient be allowed to manipulate the message? Should a ma= licious recipient be allowed to generate a new "authenticated" message from= the sender with a different recipient list, in particular, including only a= single honest recipient (**)? If these features are allowed, should it be= called "authentication"? I seek your answers, but provide my tentative answers: 1. Two benefits: (a) signatures have less plausible deniability, and (b) sig= natures have constant authentication cost per recipient, whereas recipient-s= pecific authentication has a cost proportional to the number of recipients (= which may be one way to resist spam). A parallel (but not necessarily a ben= efit): TLS offers, optionally, client authentication without a client signat= ure on every (or even any) message, which presumably has benefits. So, the= benefit is much greater than adding non-malleability (aka integrity protect= ion). 2. I recall some work done on designated verifiers, but I think that is slig= htly different and trickier functionality. My rather bad IACR eprint on den= iable authentication does not qualify. 3. The security should be okay in the single recipient case, but it would ha= rd to prove for most schemes. The security of the current CMS methods are n= ot so good in the multiple recipient case. 4. Probably not. Definitely not (because how would an honest recipient deter= mine previous messages). Definitely not. (*) (*) I've been told that the purpose of the CMS "authentication" methods is a= ctually only to provide non-malleable (aka integrity protection) -- but not= in those exact words -- and that for true sender authentication, one should= use signatures instead. I've also been told that the term "authentication"= only applies to whoever has the MAC key. I translate this into an alternat= ive answer to 4 which is not my own: 4' Definitely yes. Probably yes. Yes. (**) This seems possible for the current CMS methods. My opinion is that be= nefits of recipient-specific authentication are sufficient to take some coun= termeasures against this possibility. (***) I now see, after writing most of this, that JOSE includes signatures u= nder the term "integrity protection", which seems to conflict with how I (an= d I think others too) have used this term use to describe the non-malleabili= ty property of PKE. I really think that the terminology should be resolved. Best regards, Daniel Brown Research In Motion Limited [cid:image001.gif@01CE321B.88331D00] --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dear CFRG list:

 

Some IETF messaging protocols, including CMS (and per= haps JOSE) offer messaging protocols in which both the sender and the recipi= ent have authenticated keys (public keys, shared symmetric keys, or password= s) and the message is authenticated (and possibly also encrypted), but not signed in the usual sense of a publi= c-key signature.

 

Questions:

 

1. What benefits does this form of recipient-specific= sender authentication have over signing?  In particular, is the main b= enefit adding non-malleability (integrity protection (***)) to encryption (*= )?

 

2. What is the best cryptographic research defining f= ormal security definitions for this kind of operation?

 

3. How do the current IETF designs fare under these c= ryptographic research goals?

 

4. Suppose a message has multiple recipients, one of= whom is malicious.  Should a malicious recipient be allowed to manipul= ate the message?  Should a malicious recipient be allowed to generate a= new "authenticated" message from the sender with a different recipient list, in particular, including only a single hon= est recipient (**)?  If these features are allowed, should it be called= "authentication"?

 

I seek your answers, but provide my tentative answers= :

 

1. Two benefits: (a) signatures have less plausible d= eniability, and (b) signatures have constant authentication cost per recipie= nt, whereas recipient-specific authentication has a cost proportional to the= number of recipients (which may be one way to resist spam).  A parallel (but not necessarily a benefit= ): TLS offers, optionally, client authentication without a client signature= on every (or even any) message, which presumably has benefits.  So, th= e benefit is much greater than adding non-malleability (aka integrity protection).

 

2. I recall some work done on designated verifiers, b= ut I think that is slightly different and trickier functionality.  My r= ather bad IACR eprint on deniable authentication does not qualify.

 

3. The security should be okay in the single recipien= t case, but it would hard to prove for most schemes.  The security of t= he current CMS methods are not so good in the multiple recipient case.<= /o:p>

 

4. Probably not. Definitely not (because how would an= honest recipient determine previous messages). Definitely not. (*)

 

(*) I've been told that the purpose of the CMS "= authentication" methods is actually only to provide non-malleable (aka= integrity protection) -- but not in those exact words -- and that for true= sender authentication, one should use signatures instead.  I’ve also been told that the term "authentication= " only applies to whoever has the MAC key.  I translate this into= an alternative answer to 4 which is not my own:

 

4'  Definitely yes. Probably yes. Yes.

 

(**) This seems possible for the current CMS methods.=   My opinion is that benefits of recipient-specific authentication are= sufficient to take some countermeasures against this possibility.

 

(***) I now see, after writing most of this, that JOS= E includes signatures under the term "integrity protection", which= seems to conflict with how I (and I think others too) have used this term u= se to describe the non-malleability property of PKE.  I really think that the terminology should be resolved.<= /o:p>

 

Best regards,

 

Dani= el Brown

Res= earch In Motion Limited

 <= /p>

 <= /p>

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2577; creation-date="Fri, 05 Apr 2013 20:35:07 GMT"; modification-date="Fri, 05 Apr 2013 20:35:07 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhjQAiANUAAF5bXMrJydjX1zIvMF5bW+Xl5fLx8UE9PsvKyvPy8np3eJSTkzIvL5WTlMvK ycrKybCvr4eFhk9MTV5cXJSSk6KhoEI+PoeGhmtqaXp4eOTk5KOhoa+urmxqab68vUE9PZWTk727 vHp3d2xqauTl5LCvrtjY19nY2FBNTdnY16KgoKOhoE9MTL28vK+vrvPy8WtpaTIuLzEuL11bW4iG hkI9Pr68vIiGh09NTSMfHyQgICMfICQfIP///wAAAAAAACH/C1hNUCBEYXRhWE1QPD94cGFja2V0 IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4 bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAg NjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpy ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxu czpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIg eG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IFdpbmRvd3MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6QTk5QzA5MUNFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiIHhtcE1NOkRv Y3VtZW50SUQ9InhtcC5kaWQ6QTk5QzA5MURFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiPiA8eG1w TU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpBOTlDMDkxQUVCQTExMUUw ODg5NkE4RjE2QUVGODNGMSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpBOTlDMDkxQkVCQTEx MUUwODg5NkE4RjE2QUVGODNGMSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6 eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk 4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayr qqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNy cXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5 ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEA ACH5BAAAAAAALAAAAACNACIAAAb/wJ5wSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89o 7oYwAQA8wgsBQOgI0vh8D6Db8XgDQn88OjwdeohmO4uLDD0Cg3+HiZRgAn6EORw9Kn08OQN3Ag8B AXdFpAgIpQ+nQyelBVsODgEJRwIItaUBDpVDBrWrGkIFugEIt3s5zDoRRZk8O54HLUMWfQ9aBn45 skY4hNLSoA2/UMyDAEQBOdLTjH8BPQY5hQZaD4UfSIv2hX925DBHSYQ0HQcgCEGxiIeEOwHG5dih gEiFaQPcABggDkMPD58ObFmgI8ekIgim6Zgz4QOzHY4oSfAEkx6jQodCEJgDYIEy/yEY3HkUYkCC tHUUpI1gp4BAjgMzSqDMYPQABoVDJvShIMTEiJ0AFLjjNwQDvCEFRBi1AMNXEQMUwN4psIEOgDYX iHigMwHfkXGLRAYoJDBHxSUHFlUgAsCPR608FguJ4AdgnwxDLhDCdNQvA3mPBkzkwaGDtJM9LhSS IQTC6NE8DgsRINrejgQQYryTEJjIgT8ikAwWx8BFj6SYDohChsDvkAQCdVRAFmIEIR0hesSY5lZz ST8CP5noscDd5nfOehT4nuAEAx06BiDo8aGQggCkKC/iWgKg+T47LFDMAPB9YgECAf0RwSc8DLHB JwM499YDtWhTDH6mDJGYedYMEf9RdJ/Ak8MNPWhQiA5CmPgHAbIkYIEfARQAHgMbBNDAdzoY4ME0 ByDAgDvK9fCCJwH9s8NSCXD0FBwCoPBHTAoQMgAIpgDwhwwc2OKODrIYMIAfBFlhQCQ7rDMEBfCQ s9kGrfUhQTGrxBgABBmAF0AGJTHgSgWjBRCBOxyVJIEyCAA0ziDP9HDRRN/0kEAfOmjzZWRCkHCi KwdMNF8Di1ggBU9h4fMheMENYeUOB7TxpSe+qKaDbCRE8FtDABnwYg40oORAMo2F6I5zCxDCwAwA fBDQDotNsOVBlTFDiz0NtrkDC4z9wYEG0/DQ4RMapCONOQ18Ep8CEjIwjQpDkPD/5Q6H8CFda+mY ly0/zcyDBGDjYNUDAZ9gJsQLLEjjKb+fMPNSQA5ssIiZPfzJQ6JCNGDPAgr4wfATHhDmh4BKYCuQ Kz1kMNEEPXQjynUHLODBAxdM5NE72R2RQkADGLUDAUNMqq+iheSwB3wo0MHTBHOQECUPYQIwkVRD VFDIi36A7ARlf+TAAAlLpLQIEQWYywMAl3wixAI8+pWAuTmgm2kOJAtxQmUUcNCIAOv9MV8PDLqS AAt+OGKWYeyUcseGMeP9x3geAuiHbFAIQEspPyURtgUUULAABqtG5oA4xIQLSAgJlGBBiPMZdJQN K3zpTgoRlHQYAdOYWfACIFDM/9HiPXAAX4AkFFDnIhA86s43JhRcBHSeDBC5GDVg0k1AKJT4hycR Jbjl1ur9yCBsec2kwyY9PNBnD2KFB94fA3wz63WbvfnAk0Os8MfFQigZ4BkCeL2ZHyMoM8H064hS ZeLTkCFA4DOG4kGpCuaKXq0jATPJlkBuloIhCOA359nBoHoQrh3AYAgV40FeijABP4gEDQaAQAMa sIAGbKBR9FiAG9jUAxcIjQIGoN0CGlWACLiBABmwVwFqxzEhpKABIMBhayiARBYijggGWAFPRmAc IYRghXfrQQmQKLW65QAO5wijGGCnA/qJ8Yz5CM8J0MjGLXxgEYxroxynwAEIwRRwjnh8ggCQIbU8 +vGPgAykIPMYBAA7 --_004_810C31990B57ED40B2062BA10D43FBF513CF51XMB111CNCrimnet_-- From rbarnes@bbn.com Fri Apr 5 14:46:48 2013 Return-Path: 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 E93F421F98B5 for ; Fri, 5 Apr 2013 14:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2wFuVYfzNtYJ for ; Fri, 5 Apr 2013 14:46:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C67921F9891 for ; Fri, 5 Apr 2013 14:46:47 -0700 (PDT) Received: from [128.89.255.18] (port=49232) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UOET7-0005ll-Li; Fri, 05 Apr 2013 17:46:45 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Richard Barnes In-Reply-To: Date: Fri, 5 Apr 2013 17:46:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <3C4AAD4B5304AB44A6BA85173B4675CA8B6AF16B@MSMR-GH1-UEA03.corp.nsa.gov> <011501ce3156$4bcdf3a0$e369dae0$@augustcellars.com> <3C4AAD4B5304AB44A6BA85173B4675CA8CBC1EDF@MSMR-GH1-UEA03.corp.nsa.gov> To: "Igoe, Kevin M." X-Mailer: Apple Mail (2.1503) Cc: 'Jim Schaad' , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 21:46:49 -0000 On Apr 4, 2013, at 3:01 PM, Richard Barnes wrote: >=20 > On Apr 4, 2013, at 1:14 PM, "Igoe, Kevin M." wrote: >=20 >> Jim Schaad wrote: >>>> - With MACs, since the integrity keys are shorter lived than the >>> signing >>> keys, >>>> the risk level is (in most applications) much lower than with >>> digital >>>> signatures. >>>=20 >>> I wish this was a true statement. I have seen a number of >>> circumstances >>> where MAC keys are in long lived situations on the order of years. >>> Places >>> such as routers, RADIUS servers and so forth. Thus while we can = hope >>> they >>> are shorter lived I don't believe that we can make that as an >>> assumption. >>>=20 >>=20 >> Sigh! Sadly, ! expect you are right. Getting people to have proper=20= >> cryptographic "hygene" is harder than getting my kids to brush their >> teeth every night. >=20 > The current JOSE specs, however, encourage bad habits: Unlike CMS, = they don't provide a mechanism for using ephemeral MAC keys. >=20 > So that is one helpful piece of feedback. We need to add better ways = to manage MAC keys. >=20 > --Richard To make sure CFRG has the proper context: That last sentence should be = read as my opinion, not something binding on the JOSE working group. =20 What is clear here is that one of the two following things has to = happen: 1. Extend the JOSE format to support short-lived MAC keys (like CMS = AuthenticatedData), or 2. Add security considerations to the JOSE documents requiring that = JOSE-using applications ensure that MAC keys are short-lived. It is my strong personal opinion that (1) is the correct answer, since = (2) relies on unspecified mechanisms to ensure the security of the = protocol. However, in the past, the JOSE WG has had a consensus call = before on (1) and decided against it, so (2) seems the more likely = course. --Richard >=20 >=20 >=20 >>=20 >>> -----Original Message----- >>> From: Jim Schaad [mailto:ietf@augustcellars.com] >>> Sent: Thursday, April 04, 2013 1:03 PM >>> To: Igoe, Kevin M.; cfrg@irtf.org >>> Subject: RE: [Cfrg] What Algorithm information needs to be >>> authenticated? >>>=20 >>> Kevin, >>>=20 >>>> -----Original Message----- >>>> From: Igoe, Kevin M. [mailto:kmigoe@nsa.gov] >>>> Sent: Thursday, April 04, 2013 7:48 AM >>>> To: 'Jim Schaad'; cfrg@irtf.org >>>> Subject: RE: [Cfrg] What Algorithm information needs to be >>> authenticated? >>>>=20 >>>> OK CFRG, Jim has given us 4 concrete issues to address. >>>>=20 >>>>=20 >>>> 1. For signature operations, what parameters related to the >>> signature >>>> algorithm and what parameters related to a key need to be protected >>> by the >>>> signature operation to prevent real and theoretical attacks on JOSE >>> signed >>>> structures. We would like to get the real and theoretical attacks >>>> separated with a weight on the theoretical attacks for the = potential >>> to >>> become >>>> real. >>>>=20 >>>> 2. For MAC operations, what parameters related to the MAC = algorithm >>> and >>>> what parameters related to the key need to be protected by the MAC >>>> operation to prevent real and theoretical attacks on a JOSE MAC >>> structure. >>>>=20 >>>> 3. For key management operations (how the content encryption key = is >>> given >>>> to the recipient), what parameters related to the algorithms need = to >>> be >>>> protected as part of the AEAD algorithm. >>>>=20 >>>> 4. For content encryption, what parameter related to the AEAD >>> algorithm >>>> need to be protected by the AEAD algorithm (and are not already >>> protected) >>>> need to be included. Is there any benefit in double protecting >>> parameters >>>> such as the IV in case a new AEAD algorithm does not directly = protect >>> that >>>> value. >>>>=20 >>>> - A residual risk common to all of these is proper storage of = secret >>> keys. >>>> While outside the scope of JOSE, I believe this should be called >>> out in >>> the >>>> security section as an issue implementers must address.) >>>> - Proper protection of the secret signing keys is a very real = issue. >>>=20 >>> I agree that both of the previous issues should be addressed as >>> security >>> considerations. I can check but I already believe they are. >>>=20 >>>> - With MACs, since the integrity keys are shorter lived than the >>> signing >>> keys, >>>> the risk level is (in most applications) much lower than with >>> digital >>>> signatures. >>>=20 >>> I wish this was a true statement. I have seen a number of >>> circumstances >>> where MAC keys are in long lived situations on the order of years. >>> Places >>> such as routers, RADIUS servers and so forth. Thus while we can = hope >>> they >>> are shorter lived I don't believe that we can make that as an >>> assumption. >>>=20 >>>>=20 >>>> - ECDSA depends upon a random input k provided by the signer. This >>> input >>>> should be uniformly distributed in the range [1, q], where q is >>>> the size of the cryptographic subgroup of the curve (a prime). >>> NIST has >>>> good guidance on this. One of their DRBGs makes a good tool for >>> forming >>>> k. Thankfully NIST has thought long and hard about these issues. >>> We >>> need to >>>> point folks at the proper NIST special pubs. Additional non-NIST >>> references >>>> would be a very welcome! >>>>=20 >>>> - MACs don't provide non-repudiation since more than one person has >>> the >>>> integrity key. If non-repudiation is required (typically only >>> needed >>>> if legal culpability might become an issue), a true signature >>> should be >>>> used. >>>=20 >>> I prefer the term data-origin rather than non-repudiation since I = know >>> what >>> that the former means but don't know what the latter means as a >>> technical >>> term. This term has been argued about for the last 15 years on the >>> PKIX >>> mailing list and I don't want to get into that here. >>>=20 >>>>=20 >>>> - OK folks, does anyone have an argument as to why authentication = of >>> the >>>> AEAD IVs is required to address a concrete security issue? I've >>> been >>>> mulling this over & haven't come up with one yet. Keep in mind that >>> one >>>> of the use cases for JOSE is the W3C web cryptography API, so there >>>> are likely to use this in the future to build JOSE based >>> applications >>>> beyond what we are currently envisioning. >>>=20 >>> Are you talking about inside of the algorithm or outside of the >>> algorithm >>> for doing the authentication? In the case of the CBC/HMAC AEAD >>> algorithm, >>> as the authentication is computed on the encrypted text you cannot = know >>> if >>> the unencrypted text is the correct text without knowing that the IV = is >>> also >>> correct. You end up with about a 1 in 256 chance of decrypting the >>> message >>> and getting the correct padding with the wrong IV and then assuming >>> that the >>> resulting plain text is what was sent when it isn't. >>>=20 >>> Jim >>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On >>> Behalf >>>>> Of Jim Schaad >>>>> Sent: Thursday, April 04, 2013 2:26 AM >>>>> To: cfrg@irtf.org >>>>> Subject: [Cfrg] What Algorithm information needs to be >>> authenticated? >>>>>=20 >>>>> Request for Information >>>>>=20 >>>>> The JOSE working group is having an internal argument about the >>> need >>>>> to protect the various header information in an encrypted or = signed >>>>> message. >>>>> The quick question is which algorithm information and algorithm >>>>> parameters need to be included in integrity portion of the >>> signature >>>>> or encryption operation in order to protect those parameters. >>>>>=20 >>>>> There are a couple of theoretical attacks that can be launched >>> against >>>>> various algorithms that then require protection an example of such >>> a >>>>> parameter is the IV for the AES-CBC/HMAC algorithm that has been >>>>> proposed. >>>>> In this case the IV is protected by the algorithm itself and >>> therefore >>>>> does not need to be externally protected by the JOSE data >>> structures. >>>>>=20 >>>>> In RFC 6211, there is a new CMS attribute that was defined for >>>>> protection of the signature algorithm as I felt there was a >>> potential >>>>> attack that could be exploited. >>>>>=20 >>>>> Looking at the RSA v1.5 signature algorithm, one cannot change the >>>>> hash algorithm as the hash algorithm is encoded as part of the >>> padding >>>>> for the signature >>>>>=20 >>>>> Looking at the RSA PSS signature, there is the possibility that a >>> hash >>>>> algorithm of the same length could be substituted unless external >>>>> restrictions are applied. Thus one could potentially substitute a >>>>> RIPEMD-160 hash on the content for a SHA-1 hash. As long as the >>>>> hashes >>>>> match and there is no externally applied restriction that the hash >>>>> algorithm used to build the PSS internals is same as the content >>> hash >>>>> then it would verify. It is unclear if there is an attack that >>>>> involves multiple hash algorithms that is better than a birthday >>>>> attack on a single algorithm as I don't know if this has ever been >>>>> studied. >>>>>=20 >>>>> CMS also defined an attribute that can be included in the = signature >>>>> computation for specifying a certificate that is to be used in the >>>>> validation of the signature on the CMS object. I.e. where to get >>> the >>>>> public key and the base restrictions for that are imposed on that >>>>> public key by the certificate issuer. >>>>>=20 >>>>> Questions that we would like to see discussed: >>>>>=20 >>>>> 1. For signature operations, what parameters related to the >>> signature >>>>> algorithm and what parameters related to a key need to be = protected >>> by >>>>> the signature operation to prevent real and theoretical attacks on >>>>> JOSE signed >>>>> structures. We would like to get the real and theoretical = attacks >>>>> separated with a weight on the theoretical attacks for the >>> potential >>>>> to become real. >>>>>=20 >>>>> 2. For MAC operations, what parameters related to the MAC >>> algorithm >>>>> and what parameters related to the key need to be protected by the >>> MAC >>>>> operation to prevent real and theoretical attacks on a JOSE MAC >>>>> structure. >>>>>=20 >>>>> 3. For key management operations (how the content encryption key >>> is >>>>> given to the recipient), what parameters related to the algorithms >>>>> need to be protected as part of the AEAD algorithm. >>>>>=20 >>>>> 4. For content encryption, what parameter related to the AEAD >>>>> algorithm need to be protected by the AEAD algorithm (and are not >>>>> already >>>>> protected) >>>>> need to be included. Is there any benefit in double protecting >>>>> parameters such as the IV in case a new AEAD algorithm does not >>>>> directly protect that value. >>>>>=20 >>>>> Looking at the key to be protected, we don't care if the recipient >>>>> cannot find the correct key or misinterprets what the key >>> identifier >>>>> is. What we want to make sure is that an attacker would be unable >>> to >>>>> change the recipients interpretation of what key is to be used and >>>>> still get a successful validation. >>>>>=20 >>>>> Jim Schaad >>>>> JOSE Co-Chair >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Cfrg mailing list >>>>> Cfrg@irtf.org >>>>> http://www.irtf.org/mailman/listinfo/cfrg >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From benlaurie@gmail.com Fri Apr 5 14:56:24 2013 Return-Path: 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 0718521F98A4 for ; Fri, 5 Apr 2013 14:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 R9OUlPZHPnn5 for ; Fri, 5 Apr 2013 14:56:23 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 557EB21F98A1 for ; Fri, 5 Apr 2013 14:56:23 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id v28so1833572qcm.10 for ; Fri, 05 Apr 2013 14:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jM3ErjodHh2f1jN3bvmZX07dh8psd0JrOVQpriFwzDg=; b=Pt8RB33jsh16cJXbY4oq62dYCxbutEfmU5V3Eu3zwRohd0oRcEjq65W/HMdeLY9IVZ U3ZPVyjjUt9hFb/lTsExOFGk0NE5lPPUjgMX9zIfS164Yqe7KfJ6Np6QFZocnpx62VRi T8tw0CzYcCVE2qvJdXex6HxYhxVi/vkqRpIjOaxCU16ilFQM1PP93ITqPXwUteogISrp pl9Y/jtRnrw3FI/DlDS3GHP98QeBAvs1cGdGq2B3FNq50+zq2h3uBUYO6VlPCxjKTXIs pzvWZWXf04Q0HcoOqapGr3qxTE7rhXhWrm+8bmLf21+43XxU5IgLloLTEp3Z/BEmKeDA ekrQ== MIME-Version: 1.0 X-Received: by 10.229.21.74 with SMTP id i10mr2612726qcb.117.1365198982786; Fri, 05 Apr 2013 14:56:22 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.127.111 with HTTP; Fri, 5 Apr 2013 14:56:22 -0700 (PDT) In-Reply-To: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> Date: Fri, 5 Apr 2013 22:56:22 +0100 X-Google-Sender-Auth: Jb8yW6irj0uxMiw6xpgM0U4ofow Message-ID: From: Ben Laurie To: Jim Schaad Content-Type: text/plain; charset=ISO-8859-1 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 21:56:24 -0000 On 4 April 2013 07:25, Jim Schaad wrote: > Request for Information > > The JOSE working group is having an internal argument about the need to > protect the various header information in an encrypted or signed message. > The quick question is which algorithm information and algorithm parameters > need to be included in integrity portion of the signature or encryption > operation in order to protect those parameters. > > There are a couple of theoretical attacks that can be launched against > various algorithms that then require protection an example of such a > parameter is the IV for the AES-CBC/HMAC algorithm that has been proposed. > In this case the IV is protected by the algorithm itself and therefore does > not need to be externally protected by the JOSE data structures. > > In RFC 6211, there is a new CMS attribute that was defined for protection of > the signature algorithm as I felt there was a potential attack that could be > exploited. > > Looking at the RSA v1.5 signature algorithm, one cannot change the hash > algorithm as the hash algorithm is encoded as part of the padding for the > signature > > Looking at the RSA PSS signature, there is the possibility that a hash > algorithm of the same length could be substituted unless external > restrictions are applied. Thus one could potentially substitute a > RIPEMD-160 hash on the content for a SHA-1 hash. As long as the hashes > match and there is no externally applied restriction that the hash algorithm > used to build the PSS internals is same as the content hash then it would > verify. It is unclear if there is an attack that involves multiple hash > algorithms that is better than a birthday attack on a single algorithm as I > don't know if this has ever been studied. > > CMS also defined an attribute that can be included in the signature > computation for specifying a certificate that is to be used in the > validation of the signature on the CMS object. I.e. where to get the public > key and the base restrictions for that are imposed on that public key by the > certificate issuer. > > Questions that we would like to see discussed: > > 1. For signature operations, what parameters related to the signature > algorithm and what parameters related to a key need to be protected by the > signature operation to prevent real and theoretical attacks on JOSE signed > structures. We would like to get the real and theoretical attacks > separated with a weight on the theoretical attacks for the potential to > become real. > > 2. For MAC operations, what parameters related to the MAC algorithm and > what parameters related to the key need to be protected by the MAC operation > to prevent real and theoretical attacks on a JOSE MAC structure. > > 3. For key management operations (how the content encryption key is given > to the recipient), what parameters related to the algorithms need to be > protected as part of the AEAD algorithm. > > 4. For content encryption, what parameter related to the AEAD algorithm > need to be protected by the AEAD algorithm (and are not already protected) > need to be included. Is there any benefit in double protecting parameters > such as the IV in case a new AEAD algorithm does not directly protect that > value. Why even discuss these? What is wrong with the answer "all parameters should be protected"? > Looking at the key to be protected, we don't care if the recipient cannot > find the correct key or misinterprets what the key identifier is. What we > want to make sure is that an attacker would be unable to change the > recipients interpretation of what key is to be used and still get a > successful validation. > > Jim Schaad > JOSE Co-Chair > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From benlaurie@gmail.com Fri Apr 5 15:02:36 2013 Return-Path: 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 8CE7821F98D2 for ; Fri, 5 Apr 2013 15:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FCUQhoNURbDE for ; Fri, 5 Apr 2013 15:02:35 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5345F21F98AD for ; Fri, 5 Apr 2013 15:02:35 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id s14so2305444qeb.13 for ; Fri, 05 Apr 2013 15:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MRjWFme0bbTU/L+VQN5/+y24QoOryrfJ+zAcOp/ZatY=; b=C8AAN9cKk6GiA4ZhPgQqism2kCiAo+6xJfgv0RxN2YZFxIrVyrychwcEH5lKi/nm4G ihKCpKhhxqXMn5r4Fi+cpvJQfxdtNbSQqFG/g/8uISgvtd5iUMij7jT9fzpxLAuXMdn5 kC3sJ/fQULJclqGee0d+74RMbKF3HFngZNfcMuz3jwGIvtI4kLfrH8aoHaSJx/TEc09Q 84FeFCyfOQWK5s+j7JSH4P0C+5D8q7O3rBAxNNsnjgxCHS3beDA6qMX7K7kSO+7aE0N+ S3Gf2zgapwnQYrzqis/xieL5oNpHDUdGo0+uA6U6DqisCV8RkcE5dLd76zMxz0nO3p/6 Z6eg== MIME-Version: 1.0 X-Received: by 10.49.48.43 with SMTP id i11mr11392883qen.65.1365199354902; Fri, 05 Apr 2013 15:02:34 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.127.111 with HTTP; Fri, 5 Apr 2013 15:02:34 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 23:02:34 +0100 X-Google-Sender-Auth: WqdNfCv3CmHcxzk0qtZrtxM0HJQ Message-ID: From: Ben Laurie To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:02:36 -0000 On 5 April 2013 23:00, Mike Jones wrote: > Indeed, "all parameters should be protected" is the security posture taken in the current JOSE specifications. Some want to change that. OK. Why? From Michael.Jones@microsoft.com Fri Apr 5 15:03:00 2013 Return-Path: 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 06F1821F98E0 for ; Fri, 5 Apr 2013 15:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 nnh5al-H4z4l for ; Fri, 5 Apr 2013 15:02:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0185821F98AD for ; Fri, 5 Apr 2013 15:02:58 -0700 (PDT) Received: from BY2FFO11FD015.protection.gbl (10.1.15.202) by BY2FFO11HUB029.protection.gbl (10.1.14.114) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 5 Apr 2013 22:00:32 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 5 Apr 2013 22:00:32 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Fri, 5 Apr 2013 22:00:29 +0000 From: Mike Jones To: Ben Laurie , Jim Schaad Thread-Topic: [Cfrg] What Algorithm information needs to be authenticated? Thread-Index: Ac4w8b10meAP4tSuRQOj77FabgFZwwBVqt8AAAAQoGA= Date: Fri, 5 Apr 2013 22:00:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(51704002)(377454001)(24454001)(80022001)(69226001)(51856001)(63696002)(79102001)(5343655001)(23726001)(59766001)(74662001)(20776003)(65816001)(47776003)(54356001)(55846006)(50986001)(53806001)(15202345001)(81342001)(50466001)(74502001)(33656001)(46102001)(77982001)(49866001)(56776001)(76482001)(81542001)(47736001)(5343635001)(46406002)(44976002)(66066001)(47446002)(31966008)(4396001)(56816002)(47976001)(16406001)(54316002)(563064005); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB029; H:TK5EX14HUBC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08076ABC99 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:03:00 -0000 > Why even discuss these? What is wrong with the answer "all parameters sho= uld be protected"? Indeed, "all parameters should be protected" is the security posture taken = in the current JOSE specifications. Some want to change that. -- Mike -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Ben= Laurie Sent: Friday, April 05, 2013 2:56 PM To: Jim Schaad Cc: cfrg@irtf.org Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? On 4 April 2013 07:25, Jim Schaad wrote: > Request for Information > > The JOSE working group is having an internal argument about the need=20 > to protect the various header information in an encrypted or signed messa= ge. > The quick question is which algorithm information and algorithm=20 > parameters need to be included in integrity portion of the signature=20 > or encryption operation in order to protect those parameters. > > There are a couple of theoretical attacks that can be launched against=20 > various algorithms that then require protection an example of such a=20 > parameter is the IV for the AES-CBC/HMAC algorithm that has been proposed= . > In this case the IV is protected by the algorithm itself and therefore=20 > does not need to be externally protected by the JOSE data structures. > > In RFC 6211, there is a new CMS attribute that was defined for=20 > protection of the signature algorithm as I felt there was a potential=20 > attack that could be exploited. > > Looking at the RSA v1.5 signature algorithm, one cannot change the=20 > hash algorithm as the hash algorithm is encoded as part of the padding=20 > for the signature > > Looking at the RSA PSS signature, there is the possibility that a hash=20 > algorithm of the same length could be substituted unless external=20 > restrictions are applied. Thus one could potentially substitute a > RIPEMD-160 hash on the content for a SHA-1 hash. As long as the hashes > match and there is no externally applied restriction that the hash=20 > algorithm used to build the PSS internals is same as the content hash=20 > then it would verify. It is unclear if there is an attack that=20 > involves multiple hash algorithms that is better than a birthday=20 > attack on a single algorithm as I don't know if this has ever been studie= d. > > CMS also defined an attribute that can be included in the signature=20 > computation for specifying a certificate that is to be used in the=20 > validation of the signature on the CMS object. I.e. where to get the=20 > public key and the base restrictions for that are imposed on that=20 > public key by the certificate issuer. > > Questions that we would like to see discussed: > > 1. For signature operations, what parameters related to the signature=20 > algorithm and what parameters related to a key need to be protected by=20 > the signature operation to prevent real and theoretical attacks on JOSE s= igned > structures. We would like to get the real and theoretical attacks > separated with a weight on the theoretical attacks for the potential=20 > to become real. > > 2. For MAC operations, what parameters related to the MAC algorithm=20 > and what parameters related to the key need to be protected by the MAC=20 > operation to prevent real and theoretical attacks on a JOSE MAC structure= . > > 3. For key management operations (how the content encryption key is=20 > given to the recipient), what parameters related to the algorithms=20 > need to be protected as part of the AEAD algorithm. > > 4. For content encryption, what parameter related to the AEAD=20 > algorithm need to be protected by the AEAD algorithm (and are not=20 > already protected) need to be included. Is there any benefit in=20 > double protecting parameters such as the IV in case a new AEAD=20 > algorithm does not directly protect that value. Why even discuss these? What is wrong with the answer "all parameters shoul= d be protected"? > Looking at the key to be protected, we don't care if the recipient=20 > cannot find the correct key or misinterprets what the key identifier=20 > is. What we want to make sure is that an attacker would be unable to=20 > change the recipients interpretation of what key is to be used and=20 > still get a successful validation. > > Jim Schaad > JOSE Co-Chair > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From rlb@ipv.sx Fri Apr 5 15:17:12 2013 Return-Path: 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 D559B21F9900 for ; Fri, 5 Apr 2013 15:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LoeZ4ZPlFb53 for ; Fri, 5 Apr 2013 15:17:11 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1AF21F98FE for ; Fri, 5 Apr 2013 15:17:11 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id f4so4474505oah.28 for ; Fri, 05 Apr 2013 15:17:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Ai8kXWXT66q91e0c3EPVXpZ3Xg7hlWWQYxAs+IU8aLo=; b=WaJJNbQVBBB+Z9lZiyorIZCDzjJ7Pz2jojvp5xvw3ikSrPNLnoIpzrHp5M2GgycFn4 x8lw5mbrAEUdEcuwLk/Sg+SpxFkfROh/YoqSX+g6qwCZ4/S6tzZrET90Fh0t7luvBskj tiiGJDRLqD6J5V5XEVpaYAixolArq95aHchxBXYb/Ubyy8GQfljoIF3upB59N93vOqb4 vQCfpad0lnR84PyoHBcZBg2hLi1m3go9mLsB52I8cS0ja9zD89IEjtgpHbZBu1DVK09N sGpUgRVcgu1rKg9Eq1qjmYZ8Wg7sD5kAnCBaD+92fuT/1hpzAyWJ7VHsZ+4EtM2a4b1h v7aw== MIME-Version: 1.0 X-Received: by 10.182.27.40 with SMTP id q8mr9486112obg.100.1365200230849; Fri, 05 Apr 2013 15:17:10 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 5 Apr 2013 15:17:10 -0700 (PDT) X-Originating-IP: [128.89.255.18] In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 18:17:10 -0400 Message-ID: From: Richard Barnes To: Ben Laurie Content-Type: multipart/alternative; boundary=089e01229762cf038304d9a47280 X-Gm-Message-State: ALoCoQm4ppjTLDo+nM3VFjc6ixvIVPhlV7vf/KLQwmQbNqYj3HhQs31uC+Nx7cIpRxz7oRi+2r3B Cc: "cfrg@irtf.org" , Jim Schaad Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:17:12 -0000 --089e01229762cf038304d9a47280 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: > On 5 April 2013 23:00, Mike Jones wrote: > > Indeed, "all parameters should be protected" is the security posture > taken in the current JOSE specifications. Some want to change that. > > OK. Why? > > Is that "Why are all parameters protected?" or "Why do some people want to change that"? --Richard --089e01229762cf038304d9a47280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben@links.org> wrote= :
On 5 April 2013 23:00, Mike Jones <Michael.Jones@microsoft.com> wrote:
> Indeed, "all parameters should be protected" is the security= posture taken in the current JOSE specifications. =A0Some want to change t= hat.

OK. Why?

<= br>
Is that "Why are all parameters protected?" or &quo= t;Why do some people want to change that"?

--= Richard=A0
--089e01229762cf038304d9a47280-- From benlaurie@gmail.com Fri Apr 5 15:18:10 2013 Return-Path: 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 74BB221F8F6C for ; Fri, 5 Apr 2013 15:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 6f09sGTeGfo9 for ; Fri, 5 Apr 2013 15:18:10 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8CD21F98FE for ; Fri, 5 Apr 2013 15:18:09 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id d42so594374qca.15 for ; Fri, 05 Apr 2013 15:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WOxU1+gmFqIJYSeJgOoTmf72UxyDTMxsutsD3akUhN4=; b=IxMoPaAQXC0ddKtRje9laJEGdLdn14v6AM37kOdhHGwLWeTUl0Z04x4+8EK5m853LL /c+QTRE/sx6k04VhyJgydbIgjcb/82F8rfcQ4OfrLAZvLD/FqGAHFVTN7v28EbTv8S6H pRXrxeuVrxk+Bw2Q6fKE859EEabUKHtvPXUu9iQl9c2oXqF86PT31fgmYd3/ftXHeMXP ItDksx6VvHxW4W8DtzeRhUgKF9Ybc1/PGflB36sqarwrQnUUKXWWBhkytBUeaRzLrqMU +ThhNq8xYwqsjU+1+eULamGZ5QLGfTOfBXlU7FL96O+K7PHuy/12PQF6HjSbSIXGZ/AN HA8w== MIME-Version: 1.0 X-Received: by 10.224.134.199 with SMTP id k7mr23530qat.51.1365200287872; Fri, 05 Apr 2013 15:18:07 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.127.111 with HTTP; Fri, 5 Apr 2013 15:18:07 -0700 (PDT) In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 23:18:07 +0100 X-Google-Sender-Auth: CVriDD6wvxvV3qn5OWxDUZyX5gs Message-ID: From: Ben Laurie To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: "cfrg@irtf.org" , Jim Schaad Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:18:10 -0000 On 5 April 2013 23:17, Richard Barnes wrote: > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: >> >> On 5 April 2013 23:00, Mike Jones wrote: >> > Indeed, "all parameters should be protected" is the security posture >> > taken in the current JOSE specifications. Some want to change that. >> >> OK. Why? >> > > Is that "Why are all parameters protected?" or "Why do some people want to > change that"? The latter. > > --Richard From rlb@ipv.sx Fri Apr 5 15:32:12 2013 Return-Path: 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 9834E21F9834 for ; Fri, 5 Apr 2013 15:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FsGJHLaSU+HZ for ; Fri, 5 Apr 2013 15:32:11 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59021F97C0 for ; Fri, 5 Apr 2013 15:32:11 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so4534774oag.33 for ; Fri, 05 Apr 2013 15:32:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5LEemhRftKU86dh0wzCe/ETxT65l1TPfzHm/L7lhXTo=; b=AYHYrmXwwREzNvwCryWuUXzlbjuI6jWWDoePFP34jydrXu4DXYQtUAu7YXyY5MnEz0 vYtMCXJhbpQCfxiDOHQ4kM1uAl0Fz0SpGX2TzTAtgkhfjDKZjkGtxcvTmy3A427VzFpo 1HF6r5IvtYvmzXB2dCBKDeXk3QQCAYsi67oSTsn7yiKR1HTdMGk5WVDij5obxChhz8oS bRJexiw7QylmUyERRnsQ3OES8JXBX0668nSFaMKL7PyMXl3QHIGXWz+q/wa0aDH+GTY0 texEgwCaHzbdQETJGm/oSF4FodNsiT9NbRKRVU8O1Ljs+ue3e/HIhXRDy+XOA/preipV C1Qg== MIME-Version: 1.0 X-Received: by 10.182.27.40 with SMTP id q8mr9515801obg.100.1365201130734; Fri, 05 Apr 2013 15:32:10 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 5 Apr 2013 15:32:10 -0700 (PDT) X-Originating-IP: [128.89.255.18] In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 18:32:10 -0400 Message-ID: From: Richard Barnes To: Ben Laurie Content-Type: multipart/alternative; boundary=089e01229762721b9c04d9a4a8c9 X-Gm-Message-State: ALoCoQmuGx8S4vp61yXQPLDH5ddriozpUoU1+T2qMvxYX3o1DZ7DfEuShpqv6q4RA/e30xPEhCRH Cc: "cfrg@irtf.org" , Jim Schaad Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:32:12 -0000 --089e01229762721b9c04d9a4a8c9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: > On 5 April 2013 23:17, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: > >> > >> On 5 April 2013 23:00, Mike Jones wrote: > >> > Indeed, "all parameters should be protected" is the security posture > >> > taken in the current JOSE specifications. Some want to change that. > >> > >> OK. Why? > >> > > > > Is that "Why are all parameters protected?" or "Why do some people want > to > > change that"? > > The latter. > I'll summarize in the following points: 1. The protection reduces the utility of the protocol. 2. The protection increases the complexity of the protocol. 3. The protection does not appear to actually prevent any attacks. 4. The protection introduces some new vulnerabilities (or at least unacceptable trade-offs). 5. If you still want it, despite the above, it is trivial to implement over the top. (In light of point (3), the word "protection" should be read with appropriate irony herinafter.) Further details: 1. The protection reduces the utility of the protocol. The protection of security parameters in JWE is accomplished by placing the parameters in the AAD input to an AEAD algorithm (i.e., the data that are authenticated, but not encrypted). This means that the AAD field cannot be used for any other purpose, ruling out any use case that requires this capability. 2. The protection increases the complexity of the protocol. If the protection were not present, then the recipient of an object could simply read the parameters and use them to process the object. However, because the processing requires the serialized parameters as input, one needs to keep around both the serialized and the parsed forms of the parameters. The need for the serialization of the parameters to be fixed also prevents a natural JSON representation (since JSON is not canonical). 3. The protection does not appear to actually prevent any attacks. Russ summarized this nicely on CFRG a few days ago: 4. The protection introduces some new vulnerabilities. Efficiently encrypting an object for multiple recipients is a major use case for JOSE. With the parameters as AAD, this causes re-use of nonces in GCM, which is clearly a problem. Avoiding nonce re-use removes all efficiency gains for the multiple recipient case. 5. If you still want it, despite the above, it is trivial to implement over the top. Just put a hash of the parameters within the authenticated content. (I would even be happy to define a standard mechanism for doing this.) Hope that helps, --Richard --089e01229762721b9c04d9a4a8c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie <ben@links.org> wrote= :
On 5 April 2013 23:17, Richard Barn= es <rlb@ipv.sx> wrote:
> On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben@links.org> wrote:
>>
>> On 5 April 2013 23:00, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> > Indeed, "all parameters should be protected" is the= security posture
>> > taken in the current JOSE specifications. =A0Some want to cha= nge that.
>>
>> OK. Why?
>>
>
> Is that "Why are all parameters protected?" or "Why do = some people want to
> change that"?

The latter.

I'll summar= ize in the following points:
1. The protection reduces the utilit= y of the protocol.=A0
2. The protection increases the complexity = of the protocol.
3. The protection does not appear to actually prevent any attacks.
4. The protection introduces some new vulnerabilities (or at least u= nacceptable trade-offs).
5. If you still want it, despite the abo= ve, it is trivial to implement over the top.

(In light of point (3), the word "protection"= should be read with appropriate irony herinafter.)

Further details:

1. The protection reduces the u= tility of the protocol.=A0

The protection of security parameters in JWE is accompl= ished by placing the parameters in the AAD input to an AEAD algorithm (i.e.= , the data that are authenticated, but not encrypted). =A0This means that t= he AAD field cannot be used for any other purpose, ruling out any use case = that requires this capability.


2. The protection increases the com= plexity of the protocol.

If the protection were no= t present, then the recipient of an object could simply read the parameters= and use them to process the object. =A0However, because the processing req= uires the serialized parameters as input, one needs to keep around both the= serialized and the parsed forms of the parameters. =A0The need for the ser= ialization of the parameters to be fixed also prevents a natural JSON repre= sentation (since JSON is not canonical).


3. The protection does not appear to act= ually prevent any attacks.

Russ summarized this ni= cely on CFRG a few days ago:


4. The protection introduces some new vu= lnerabilities.

Efficiently encrypting an object fo= r multiple recipients is a major use case for JOSE. =A0With the parameters = as AAD, this causes re-use of nonces in GCM, which is clearly a problem. = =A0Avoiding nonce re-use removes all efficiency gains for the multiple reci= pient case.





--089e01229762721b9c04d9a4a8c9-- From ve7jtb@ve7jtb.com Fri Apr 5 15:57:18 2013 Return-Path: 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 6B5D821F9922 for ; Fri, 5 Apr 2013 15:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.703 X-Spam-Level: X-Spam-Status: No, score=0.703 tagged_above=-999 required=5 tests=[AWL=-2.390, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.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 r3ftv2dUkqGK for ; Fri, 5 Apr 2013 15:57:17 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6128721F991F for ; Fri, 5 Apr 2013 15:57:17 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id z12so684327yhz.6 for ; Fri, 05 Apr 2013 15:57:16 -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=G3fl19fD6XEb86ufSe726c/UoHpfOAjb6kZENXnF12A=; b=b8OKwNjPbdmH3mrVjivdw4GBzrMlh2pbj3nJwfbmLtrDLkki4AylGLNkq0E0PIbsvr Ew4Yfyjl9sDu8gqLMmYndNwOIPYphylQi2ZAc87QKTl5xBDeTB9ur7VGhzEfedORQVg8 Yr4Li5Ns+CoUni5jgNRo0D3ySjc9sNpDk13A1+ucRLj4oBRXtZAxmVNgi2BFz8y3BhHi KNHK+fOm4W3f+KYtpVC2ebXRoH1XkuJus401hlFEVf0J1Cbbbo46JumYqkm8f0ZIoppu UGFJBo2CEYSS5NjmHSPDMPGGV7V5B4yCm44ManLInJZPJ+N7oVdaKxPdh7CNKom1QEcU ZzSA== X-Received: by 10.236.130.75 with SMTP id j51mr7739724yhi.141.1365202636796; Fri, 05 Apr 2013 15:57:16 -0700 (PDT) Received: from [192.168.1.210] (190-20-19-94.baf.movistar.cl. [190.20.19.94]) by mx.google.com with ESMTPS id d49sm9814076yhc.27.2013.04.05.15.57.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 15:57:15 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8447A28A-52F9-42AE-A62A-8FF21DC22655"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Fri, 5 Apr 2013 19:56:31 -0300 Message-Id: <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk7bOO9XL2JLlGN1IGgxBdoP4WrIHJMyfZf7VyRyDZtsF128PeblwETiwH8DFzZECYJCfYQ Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:57:18 -0000 --Apple-Mail=_8447A28A-52F9-42AE-A62A-8FF21DC22655 Content-Type: multipart/alternative; boundary="Apple-Mail=_D14BDCD7-1217-46AE-8EBE-C4D473CCAD2B" --Apple-Mail=_D14BDCD7-1217-46AE-8EBE-C4D473CCAD2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I took Russe's as being confirmation of why he believes CMS doesn't need = to protect it's recipient-info. One thing to note is that the JWE version of recipient info is = extensible by WG decision. =20 Some of those extensions are security related and benefit from integrity = protection. On point 3, while on the face of it integrity protecting the algorithm = information doesn't stop the key wrap alg from being changed before it = is used, with proper care all such tampering with the JWE can be = reported as a single failure. Continuing with decrypting the body and = generating a integrity error at the end has some benefit in discouraging = timing attacks. One of the reasons we decided to integrity protect the header was based = on Ben's original advice. We may not know all of the possible future = attacks, so better to be safe. I agree that Richard has a point with GCM and some possible = serializations. Personally I would rather find a way to do it with a = single GCM tag and keep the integrity protection. On point 1 I think that is a bit overplayed. JWE doesn't specify how to = serialize an additional AAD , and if you needed to it could be added as = an element to the envelope. I think that can be dealt with. The bottom line is we are supporting only AEAD algorithms. Putting = the envelope in the AAD to integrity protect it is not a huge = complication. John B. On 2013-04-05, at 7:32 PM, Richard Barnes wrote: > On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: > On 5 April 2013 23:17, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: > >> > >> On 5 April 2013 23:00, Mike Jones = wrote: > >> > Indeed, "all parameters should be protected" is the security = posture > >> > taken in the current JOSE specifications. Some want to change = that. > >> > >> OK. Why? > >> > > > > Is that "Why are all parameters protected?" or "Why do some people = want to > > change that"? >=20 > The latter. >=20 > I'll summarize in the following points: > 1. The protection reduces the utility of the protocol.=20 > 2. The protection increases the complexity of the protocol. > 3. The protection does not appear to actually prevent any attacks. > 4. The protection introduces some new vulnerabilities (or at least = unacceptable trade-offs). > 5. If you still want it, despite the above, it is trivial to implement = over the top. >=20 > (In light of point (3), the word "protection" should be read with = appropriate irony herinafter.) >=20 > Further details: >=20 > 1. The protection reduces the utility of the protocol.=20 >=20 > The protection of security parameters in JWE is accomplished by = placing the parameters in the AAD input to an AEAD algorithm (i.e., the = data that are authenticated, but not encrypted). This means that the = AAD field cannot be used for any other purpose, ruling out any use case = that requires this capability. >=20 >=20 > 2. The protection increases the complexity of the protocol. >=20 > If the protection were not present, then the recipient of an object = could simply read the parameters and use them to process the object. = However, because the processing requires the serialized parameters as = input, one needs to keep around both the serialized and the parsed forms = of the parameters. The need for the serialization of the parameters to = be fixed also prevents a natural JSON representation (since JSON is not = canonical). >=20 >=20 > 3. The protection does not appear to actually prevent any attacks. >=20 > Russ summarized this nicely on CFRG a few days ago: > >=20 >=20 > 4. The protection introduces some new vulnerabilities. >=20 > Efficiently encrypting an object for multiple recipients is a major = use case for JOSE. With the parameters as AAD, this causes re-use of = nonces in GCM, which is clearly a problem. Avoiding nonce re-use = removes all efficiency gains for the multiple recipient case. > >=20 >=20 > 5. If you still want it, despite the above, it is trivial to implement = over the top. >=20 > Just put a hash of the parameters within the authenticated content. = (I would even be happy to define a standard mechanism for doing this.) >=20 >=20 > Hope that helps, > --Richard >=20 > =20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_D14BDCD7-1217-46AE-8EBE-C4D473CCAD2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = took Russe's as being confirmation of why he believes CMS doesn't need = to protect it's recipient-info.

One thing to note is = that the JWE version of recipient info is extensible by WG decision. =  
Some of those extensions are security related and = benefit from integrity protection.

On point 3, =  while on the face of it integrity protecting the algorithm = information doesn't stop the key wrap alg from being changed before it = is used, with proper care all such tampering with the JWE can be = reported as a single failure.   Continuing with decrypting the body = and generating a integrity error at the end has some benefit in = discouraging timing attacks.

One of the reasons = we decided to integrity protect the header was based on Ben's original = advice.  We may not know all of the possible future attacks, so = better to be safe.

I agree that Richard has a = point with GCM and some possible serializations.  Personally I = would rather find a way to do it with a single GCM tag and keep the = integrity protection.

On point 1 I think that = is a bit overplayed.  JWE doesn't specify how to serialize an = additional AAD , and if you needed to it could be added as an element to = the envelope.
I think that can be dealt = with.

The bottom line is we are supporting only = AEAD algorithms.    Putting the envelope in the AAD to = integrity protect it is not a huge = complication.

John = B.



On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie <ben@links.org> wrote:
On 5 April 2013 23:17, Richard = Barnes <rlb@ipv.sx> wrote:
> On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben@links.org> wrote:
>>
>> On 5 April 2013 23:00, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> > Indeed, "all parameters should be protected" is the = security posture
>> > taken in the current JOSE specifications.  Some want = to change that.
>>
>> OK. Why?
>>
>
> Is that "Why are all parameters protected?" or "Why do some people = want to
> change that"?

The latter.

3. The protection does not appear to actually prevent any = attacks.
4. The protection introduces some new vulnerabilities = (or at least unacceptable trade-offs).
5. If you still want = it, despite the above, it is trivial to implement over the top.

(In light of point (3), the word "protection" should = be read with appropriate irony = herinafter.)

Further = details:

1. The protection reduces the utility = of the protocol. 

The protection of security parameters in JWE is = accomplished by placing the parameters in the AAD input to an AEAD = algorithm (i.e., the data that are authenticated, but not encrypted). =  This means that the AAD field cannot be used for any other = purpose, ruling out any use case that requires this capability.


2. The protection increases the = complexity of the protocol.

If the protection = were not present, then the recipient of an object could simply read the = parameters and use them to process the object.  However, because = the processing requires the serialized parameters as input, one needs to = keep around both the serialized and the parsed forms of the parameters. =  The need for the serialization of the parameters to be fixed also = prevents a natural JSON representation (since JSON is not = canonical).


3. The protection does not appear to = actually prevent any attacks.

Russ summarized = this nicely on CFRG a few days ago:
<h= ttp://www.ietf.org/mail-archive/web/cfrg/current/msg03376.html>


4. The protection introduces some new = vulnerabilities.

Efficiently encrypting an = object for multiple recipients is a major use case for JOSE.  With = the parameters as AAD, this causes re-use of nonces in GCM, which is = clearly a problem.  Avoiding nonce re-use removes all efficiency = gains for the multiple recipient case.
<h= ttp://www.ietf.org/mail-archive/web/cfrg/current/msg03373.html>


5. If you still want it, despite = the above, it is trivial to implement over the top.

Just put a hash of the parameters within the = authenticated content.  (I would even be happy to define a standard = mechanism for doing this.)


Hope = that helps,
--Richard

 
_______________________________________________
Cfrg mailing = list
Cfrg@irtf.org
http://www.irtf.org/mai= lman/listinfo/cfrg

= --Apple-Mail=_D14BDCD7-1217-46AE-8EBE-C4D473CCAD2B-- --Apple-Mail=_8447A28A-52F9-42AE-A62A-8FF21DC22655 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDA1MjI1NjMyWjAjBgkqhkiG9w0BCQQxFgQU7daQzX28 rWwhw/V3ljsAPfyhscYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAefKPx4mzrmzbx2XL8IlnTl4ywdBHM4tSy03Yy6Sc vrfnSGy2lKxo4MjvVKrmEouLoipqj164SG0HIMv269u77kGOXP+CTD9S0OOGEVvU0MFltqCJbnxN DbrBmUFefCtK139rAOxZ8tK2DW1g3UggjDstzn/RoergoYb68guTgqTT1ArP/E3QFt6JrxpWhXXA NfACDkXUuAwPSak1hIVfC+eh/3Q7OYNAeOb588qfiXJ0aP1nUBZDuskH6gosTOxi6OYD4lrrvSMu iped3utrpFCDxfuK/R2Iw09OBhgWPZSW/0gdIA/6Fne5ubjplREFmWCPD9kmWw93k5zeWk32xAAA AAAAAA== --Apple-Mail=_8447A28A-52F9-42AE-A62A-8FF21DC22655-- From rlb@ipv.sx Fri Apr 5 16:03:03 2013 Return-Path: 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 8B7A721F98FF for ; Fri, 5 Apr 2013 16:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 fqwlMM10PjNR for ; Fri, 5 Apr 2013 16:03:02 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 21E4421F98F2 for ; Fri, 5 Apr 2013 16:03:02 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so4514947oag.5 for ; Fri, 05 Apr 2013 16:03:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=0IEj4n4z3BuDy/my5XGdOl9BSYLd6ViTGF6YGGfU/dE=; b=CQrE57rF9bIq657UGr+SoyOZs42LzPgZBliuBNu6lqKuaEt9ahfTkh0BWH02YtpDOC PwTQm21rts/8CVmfURGmEMrVDrmlV9RXQNO9aGLLuGaGUxRwTSyyrUdw1av+EhpRAj2D 3wwHVLYTdAczY2RjQXXQ/haH/mUf5AUZ2Nzm/vJylHR/b37WeU+rcyuY3AMvkKpAZtzo vzwXa4E2hK8FzqEzflsdg5YXX/Owfv7D+0fBKxPKKS8V3hSQ24CjUebS4q55HA6gPDXx KQo9PIevo8C29KdnQHj2CVeQ63e2wIhicaJLFgYCfjnieu3MvWaXcDLkl4KuVZ6MRrEC SlOQ== MIME-Version: 1.0 X-Received: by 10.60.85.35 with SMTP id e3mr9680001oez.117.1365202981648; Fri, 05 Apr 2013 16:03:01 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 5 Apr 2013 16:03:01 -0700 (PDT) X-Originating-IP: [128.89.255.18] In-Reply-To: <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> Date: Fri, 5 Apr 2013 19:03:01 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=089e0111be00c4dac904d9a5164a X-Gm-Message-State: ALoCoQkEBxg1GMqxeOdT+5+k5XDMQHbEil9V85Xakw/DOGCI+K4UGtAHGwUjSV2t1nCNeW9vY/yV Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 23:03:03 -0000 --089e0111be00c4dac904d9a5164a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 5, 2013 at 6:56 PM, John Bradley wrote: > I took Russe's as being confirmation of why he believes CMS doesn't need > to protect it's recipient-info. > > One thing to note is that the JWE version of recipient info is extensible > by WG decision. > Some of those extensions are security related and benefit from integrity > protection. > Then you should put them in an integrity protected object. CMS EnvelopedData does have extensible attributes. In fact, they are explicitly called "unprotectedAttrs"! EnvelopedData ::= SEQUENCE { version CMSVersion, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientInfos RecipientInfos, encryptedContentInfo EncryptedContentInfo, unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } So extensibility is not a difference here. > On point 3, while on the face of it integrity protecting the algorithm > information doesn't stop the key wrap alg from being changed before it is > used, with proper care all such tampering with the JWE can be reported as a > single failure. Continuing with decrypting the body and generating a > integrity error at the end has some benefit in discouraging timing attacks. > That is true whether the parameters / header are integrity protected or not. > One of the reasons we decided to integrity protect the header was based on > Ben's original advice. We may not know all of the possible future attacks, > so better to be safe. > The point of Russ's message is that there's not actually any additional safety here. > I agree that Richard has a point with GCM and some possible > serializations. Personally I would rather find a way to do it with a > single GCM tag and keep the integrity protection. > If you want to achieve that objective, then you need to at least remove per-recipient parameters from the integrity protection. > On point 1 I think that is a bit overplayed. JWE doesn't specify how to > serialize an additional AAD , and if you needed to it could be added as an > element to the envelope. > I think that can be dealt with. > > The bottom line is we are supporting only AEAD algorithms. Putting the > envelope in the AAD to integrity protect it is not a huge complication. > But the fact that there is no clear benefit to it means that it should at most be optional. --Richard > > John B. > > > On 2013-04-05, at 7:32 PM, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: > >> On 5 April 2013 23:17, Richard Barnes wrote: >> > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: >> >> >> >> On 5 April 2013 23:00, Mike Jones wrote: >> >> > Indeed, "all parameters should be protected" is the security posture >> >> > taken in the current JOSE specifications. Some want to change that. >> >> >> >> OK. Why? >> >> >> > >> > Is that "Why are all parameters protected?" or "Why do some people want >> to >> > change that"? >> >> The latter. >> > > I'll summarize in the following points: > 1. The protection reduces the utility of the protocol. > 2. The protection increases the complexity of the protocol. > 3. The protection does not appear to actually prevent any attacks. > 4. The protection introduces some new vulnerabilities (or at least > unacceptable trade-offs). > 5. If you still want it, despite the above, it is trivial to implement > over the top. > > (In light of point (3), the word "protection" should be read with > appropriate irony herinafter.) > > Further details: > > 1. The protection reduces the utility of the protocol. > > The protection of security parameters in JWE is accomplished by placing > the parameters in the AAD input to an AEAD algorithm (i.e., the data that > are authenticated, but not encrypted). This means that the AAD field > cannot be used for any other purpose, ruling out any use case that requires > this capability. > > > 2. The protection increases the complexity of the protocol. > > If the protection were not present, then the recipient of an object could > simply read the parameters and use them to process the object. However, > because the processing requires the serialized parameters as input, one > needs to keep around both the serialized and the parsed forms of the > parameters. The need for the serialization of the parameters to be fixed > also prevents a natural JSON representation (since JSON is not canonical). > > > 3. The protection does not appear to actually prevent any attacks. > > Russ summarized this nicely on CFRG a few days ago: > > > > 4. The protection introduces some new vulnerabilities. > > Efficiently encrypting an object for multiple recipients is a major use > case for JOSE. With the parameters as AAD, this causes re-use of nonces in > GCM, which is clearly a problem. Avoiding nonce re-use removes all > efficiency gains for the multiple recipient case. > > > > 5. If you still want it, despite the above, it is trivial to implement > over the top. > > Just put a hash of the parameters within the authenticated content. (I > would even be happy to define a standard mechanism for doing this.) > > > Hope that helps, > --Richard > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > --089e0111be00c4dac904d9a5164a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2013 at 6:56 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I took Russe's as being confirmatio= n of why he believes CMS doesn't need to protect it's recipient-inf= o.

One thing to note is that the JWE version of recipien= t info is extensible by WG decision. =A0
Some of those extensions are security related and benefit from integri= ty protection.

Then you should = put them in an integrity protected object.

CMS Env= elopedData does have extensible attributes. =A0In fact, they are explicitly= called "unprotectedAttrs"!

EnvelopedData ::=3D SEQUENCE {
=A0 =A0 = =A0 =A0 version CMSVersion,
=A0 =A0 =A0 =A0 originatorInfo [0] IM= PLICIT OriginatorInfo OPTIONAL,
=A0 =A0 =A0 =A0 recipientInfos Re= cipientInfos,
=A0 =A0 =A0 =A0 encryptedContentInfo EncryptedContentInfo,
=A0 = =A0 =A0 =A0 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }<= /div>

So extensibility is not a difference here.

=A0
On point 3, =A0while on the face of it integrity protecting the = algorithm information doesn't stop the key wrap alg from being changed = before it is used, with proper care all such tampering with the JWE can be = reported as a single failure. =A0 Continuing with decrypting the body and g= enerating a integrity error at the end has some benefit in discouraging tim= ing attacks.

That is true whether the parameters = / header are integrity protected or not. =A0

=A0
One of the reasons we decided to i= ntegrity protect the header was based on Ben's original advice. =A0We m= ay not know all of the possible future attacks, so better to be safe.

The point of Russ's message is t= hat there's not actually any additional safety here.

=A0
I agree that Richard has a point w= ith GCM and some possible serializations. =A0Personally I would rather find= a way to do it with a single GCM tag and keep the integrity protection.

If you want to achieve that objectiv= e, then you need to at least remove per-recipient parameters from the integ= rity protection.=A0

=A0
On point 1 I think that is a bit o= verplayed. =A0JWE doesn't specify how to serialize an additional AAD , = and if you needed to it could be added as an element to the envelope.
I think that can be dealt with.

The bottom li= ne is we are supporting only AEAD algorithms. =A0 =A0Putting the envelope i= n the AAD to integrity protect it is not a huge complication.

But the fact that there is no clear benefit to it means= that it should at most be optional.

--Richard


=A0

John B.
<= br>

On 2013-04-05, at 7:32 P= M, Richard Barnes <rlb@i= pv.sx> wrote:

On Fri, Ap= r 5, 2013 at 6:18 PM, Ben Laurie <ben@links.org> wrote:
On 5 April 2013 23:17, Richard Barnes <rlb@ipv.sx> wrote:
> On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben@links.org> wrote:
>>
>> On 5 April 2013 23:00, Mike Jones <Michael.Jones@microsoft.com> wr= ote:
>> > Indeed, "all parameters should be protected" is the= security posture
>> > taken in the current JOSE specifications. =A0Some want to cha= nge that.
>>
>> OK. Why?
>>
>
> Is that "Why are all parameters protected?" or "Why do = some people want to
> change that"?

The latter.

I'll summar= ize in the following points:
1. The protection reduces the utilit= y of the protocol.=A0
2. The protection increases the complexity = of the protocol.
3. The protection does not appear to actually prevent any attacks.
4. The protection introduces some new vulnerabilities (or at least u= nacceptable trade-offs).
5. If you still want it, despite the abo= ve, it is trivial to implement over the top.

(In light of point (3), the word "protection"= should be read with appropriate irony herinafter.)

Further details:

1. The protection reduces the u= tility of the protocol.=A0

The protection of security parameters in JWE is accompl= ished by placing the parameters in the AAD input to an AEAD algorithm (i.e.= , the data that are authenticated, but not encrypted). =A0This means that t= he AAD field cannot be used for any other purpose, ruling out any use case = that requires this capability.


2. The protection increases the com= plexity of the protocol.

If the protection were no= t present, then the recipient of an object could simply read the parameters= and use them to process the object. =A0However, because the processing req= uires the serialized parameters as input, one needs to keep around both the= serialized and the parsed forms of the parameters. =A0The need for the ser= ialization of the parameters to be fixed also prevents a natural JSON repre= sentation (since JSON is not canonical).


3. The protection does not appear to act= ually prevent any attacks.

Russ summarized this ni= cely on CFRG a few days ago:


4. The protection introduces some new vu= lnerabilities.

Efficiently encrypting an object fo= r multiple recipients is a major use case for JOSE. =A0With the parameters = as AAD, this causes re-use of nonces in GCM, which is clearly a problem. = =A0Avoiding nonce re-use removes all efficiency gains for the multiple reci= pient case.


5. If you = still want it, despite the above, it is trivial to implement over the top.<= /div>

Just put a hash of the parameters within the auth= enticated content. =A0(I would even be happy to define a standard mechanism= for doing this.)


Hope that helps,<= /div>
--Richard

=A0
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://ww= w.irtf.org/mailman/listinfo/cfrg


--089e0111be00c4dac904d9a5164a-- From ve7jtb@ve7jtb.com Fri Apr 5 16:21:11 2013 Return-Path: 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 D9E2421F9516 for ; Fri, 5 Apr 2013 16:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=1.254, 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 uH+Ky4wrEW-k for ; Fri, 5 Apr 2013 16:21:10 -0700 (PDT) Received: from mail-gh0-f177.google.com (mail-gh0-f177.google.com [209.85.160.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74321F93DA for ; Fri, 5 Apr 2013 16:21:05 -0700 (PDT) Received: by mail-gh0-f177.google.com with SMTP id g22so692512ghb.8 for ; Fri, 05 Apr 2013 16:21:04 -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=A50ThHkij3h8RVK5iBR8OdkeNTcpCh37PgHCpF3lbFs=; b=VCjXg4xaehc3/Xf+k0Ox0Su6HXL7hQFw9XUj6uQSUPbVB6MoUx4kQ4t/yiNoj5szCy 5qr3loMNFZPwgYv6tWo6xCMIxJwcaCHtSk5OZ0Njxlp0jeJyq12twwTdvAtnBKjhZbTj mlQD/nnw0i/pd7axePeEUpjhFf8VsS0CBWwlr27jSCO2GwZvYGu+j2gY/Ko6f/7/PzeY gSA7pY3ppBQ7tTyhlCI4QE2TAbh2gAlQ4SCN9owqwwVXnucJBRivSchAIC+UD/Vvj2e6 XwNCVQAlpK9Nlo5zX4ytWm2y8Z3i0tD5dD+Eh8PAz8V+Z96AgyWDL2R90U4JFr+7eInl ogfQ== X-Received: by 10.236.128.34 with SMTP id e22mr7758556yhi.11.1365204064804; Fri, 05 Apr 2013 16:21:04 -0700 (PDT) Received: from [192.168.1.210] (190-20-19-94.baf.movistar.cl. [190.20.19.94]) by mx.google.com with ESMTPS id y5sm11830968yhd.3.2013.04.05.16.20.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 16:21:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D068EC85-D370-4E3B-AD61-133CA4CB3EF0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Fri, 5 Apr 2013 20:20:11 -0300 Message-Id: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlNWRwIGtgxrF5brpDh6Jc0v/BPwakpkLLn1tkhIJqttJ3FhzmRfdcAuLdjvVNnbkkOcOAa Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 23:21:12 -0000 --Apple-Mail=_D068EC85-D370-4E3B-AD61-133CA4CB3EF0 Content-Type: multipart/alternative; boundary="Apple-Mail=_2E1A6E91-E9DE-423E-9FC9-CEB76F44CDDB" --Apple-Mail=_2E1A6E91-E9DE-423E-9FC9-CEB76F44CDDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Richard, I think it was Jim that pointed out RFC 6211 "Cryptographic Message = Syntax (CMS) Algorithm Identifier Protection Attribute" adds a new CMS = parameter to protect the algorithm identifier in CMS. =20 The existence of RFC 6211 makes me feel lees alone in my opinion on the = value of integrity protecting recipient info. There are downsides for multiple recipients. I would rather work = through that than throw out integrity protectin for recipiant info.=20 I may be in the minority on that we will have to see. =20 I hope that the Cfrg can provide some wisdom on this as the two of us = could argue this for a long time without getting to conclusion as it is = hard to absolutely prove either side of the argument.=20 Regards John B. On 2013-04-05, at 8:03 PM, Richard Barnes wrote: > On Fri, Apr 5, 2013 at 6:56 PM, John Bradley = wrote: > I took Russe's as being confirmation of why he believes CMS doesn't = need to protect it's recipient-info. >=20 > One thing to note is that the JWE version of recipient info is = extensible by WG decision. =20 > Some of those extensions are security related and benefit from = integrity protection. >=20 > Then you should put them in an integrity protected object. >=20 > CMS EnvelopedData does have extensible attributes. In fact, they are = explicitly called "unprotectedAttrs"! >=20 > EnvelopedData ::=3D SEQUENCE { > version CMSVersion, > originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, > recipientInfos RecipientInfos, > encryptedContentInfo EncryptedContentInfo, > unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } >=20 > So extensibility is not a difference here. >=20 > =20 > On point 3, while on the face of it integrity protecting the = algorithm information doesn't stop the key wrap alg from being changed = before it is used, with proper care all such tampering with the JWE can = be reported as a single failure. Continuing with decrypting the body = and generating a integrity error at the end has some benefit in = discouraging timing attacks. >=20 > That is true whether the parameters / header are integrity protected = or not. =20 >=20 > =20 > One of the reasons we decided to integrity protect the header was = based on Ben's original advice. We may not know all of the possible = future attacks, so better to be safe. >=20 > The point of Russ's message is that there's not actually any = additional safety here. >=20 > =20 > I agree that Richard has a point with GCM and some possible = serializations. Personally I would rather find a way to do it with a = single GCM tag and keep the integrity protection. >=20 > If you want to achieve that objective, then you need to at least = remove per-recipient parameters from the integrity protection.=20 >=20 > =20 > On point 1 I think that is a bit overplayed. JWE doesn't specify how = to serialize an additional AAD , and if you needed to it could be added = as an element to the envelope. > I think that can be dealt with. >=20 > The bottom line is we are supporting only AEAD algorithms. Putting = the envelope in the AAD to integrity protect it is not a huge = complication. >=20 > But the fact that there is no clear benefit to it means that it should = at most be optional. >=20 > --Richard >=20 >=20 > =20 >=20 > John B. >=20 >=20 > On 2013-04-05, at 7:32 PM, Richard Barnes wrote: >=20 >> On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: >> On 5 April 2013 23:17, Richard Barnes wrote: >> > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: >> >> >> >> On 5 April 2013 23:00, Mike Jones = wrote: >> >> > Indeed, "all parameters should be protected" is the security = posture >> >> > taken in the current JOSE specifications. Some want to change = that. >> >> >> >> OK. Why? >> >> >> > >> > Is that "Why are all parameters protected?" or "Why do some people = want to >> > change that"? >>=20 >> The latter. >>=20 >> I'll summarize in the following points: >> 1. The protection reduces the utility of the protocol.=20 >> 2. The protection increases the complexity of the protocol. >> 3. The protection does not appear to actually prevent any attacks. >> 4. The protection introduces some new vulnerabilities (or at least = unacceptable trade-offs). >> 5. If you still want it, despite the above, it is trivial to = implement over the top. >>=20 >> (In light of point (3), the word "protection" should be read with = appropriate irony herinafter.) >>=20 >> Further details: >>=20 >> 1. The protection reduces the utility of the protocol.=20 >>=20 >> The protection of security parameters in JWE is accomplished by = placing the parameters in the AAD input to an AEAD algorithm (i.e., the = data that are authenticated, but not encrypted). This means that the = AAD field cannot be used for any other purpose, ruling out any use case = that requires this capability. >>=20 >>=20 >> 2. The protection increases the complexity of the protocol. >>=20 >> If the protection were not present, then the recipient of an object = could simply read the parameters and use them to process the object. = However, because the processing requires the serialized parameters as = input, one needs to keep around both the serialized and the parsed forms = of the parameters. The need for the serialization of the parameters to = be fixed also prevents a natural JSON representation (since JSON is not = canonical). >>=20 >>=20 >> 3. The protection does not appear to actually prevent any attacks. >>=20 >> Russ summarized this nicely on CFRG a few days ago: >> >>=20 >>=20 >> 4. The protection introduces some new vulnerabilities. >>=20 >> Efficiently encrypting an object for multiple recipients is a major = use case for JOSE. With the parameters as AAD, this causes re-use of = nonces in GCM, which is clearly a problem. Avoiding nonce re-use = removes all efficiency gains for the multiple recipient case. >> >>=20 >>=20 >> 5. If you still want it, despite the above, it is trivial to = implement over the top. >>=20 >> Just put a hash of the parameters within the authenticated content. = (I would even be happy to define a standard mechanism for doing this.) >>=20 >>=20 >> Hope that helps, >> --Richard >>=20 >> =20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 >=20 --Apple-Mail=_2E1A6E91-E9DE-423E-9FC9-CEB76F44CDDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Cryptographic Message Syntax (CMS) 

adds a new = CMS parameter to protect the algorithm identifier in CMS.   =  

The existence of RFC 6211 makes me feel lees = alone in my opinion on the value of integrity protecting recipient = info.

There are downsides for multiple = recipients.  I would rather work through that than throw out = integrity protectin for recipiant info. 

I = may be in the minority on that we will have to see. =   

I hope that the Cfrg can provide = some wisdom on this as the two of us could argue this for a long time = without getting to conclusion as it is hard to absolutely prove either = side of the = argument. 

Regards
John = B.


On 2013-04-05, at 8:03 PM, = Richard Barnes <rlb@ipv.sx> = wrote:

On Fri, Apr 5, 2013 at 6:56 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I took Russe's as being confirmation = of why he believes CMS doesn't need to protect it's = recipient-info.

One thing to note is that the JWE = version of recipient info is extensible by WG decision.  
Some of those extensions are security related and benefit from = integrity protection.

Then = you should put them in an integrity protected = object.

CMS EnvelopedData does have extensible = attributes.  In fact, they are explicitly called = "unprotectedAttrs"!

EnvelopedData ::=3D SEQUENCE {
  =       version CMSVersion,
      =   originatorInfo [0] IMPLICIT OriginatorInfo = OPTIONAL,
        recipientInfos = RecipientInfos,
        encryptedContentInfo = EncryptedContentInfo,
        = unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL = }

So extensibility is not a difference = here.

 
On point 3,  while on the face = of it integrity protecting the algorithm information doesn't stop the = key wrap alg from being changed before it is used, with proper care all = such tampering with the JWE can be reported as a single failure.   = Continuing with decrypting the body and generating a integrity error at = the end has some benefit in discouraging timing attacks.

That is true whether the = parameters / header are integrity protected or not. =  

 
One of the reasons we decided = to integrity protect the header was based on Ben's original advice. =  We may not know all of the possible future attacks, so better to = be safe.

The point of Russ's message is = that there's not actually any additional safety = here.

 
I agree that Richard has a = point with GCM and some possible serializations.  Personally I = would rather find a way to do it with a single GCM tag and keep the = integrity protection.

If you want to achieve that = objective, then you need to at least remove per-recipient parameters = from the integrity = protection. 

 
On point 1 I think that is a = bit overplayed.  JWE doesn't specify how to serialize an additional = AAD , and if you needed to it could be added as an element to the = envelope.
I think that can be dealt with.

The bottom = line is we are supporting only AEAD algorithms.    Putting the = envelope in the AAD to integrity protect it is not a huge = complication.

But the fact that there is no clear benefit to it = means that it should at most be = optional.

--Richard


=
 

John = B.


On = 2013-04-05, at 7:32 PM, Richard Barnes <rlb@ipv.sx> wrote:

On Fri, = Apr 5, 2013 at 6:18 PM, Ben Laurie <ben@links.org> wrote:
On 5 April 2013 23:17, Richard Barnes <rlb@ipv.sx> = wrote:
> On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben@links.org> = wrote:
>>
>> On 5 April 2013 23:00, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> > Indeed, "all parameters should be protected" is the = security posture
>> > taken in the current JOSE specifications.  Some want = to change that.
>>
>> OK. Why?
>>
>
> Is that "Why are all parameters protected?" or "Why do some people = want to
> change that"?

The latter.

I'll summarize in = the following points:
1. The protection reduces the utility of = the protocol. 
2. The protection increases the complexity = of the protocol.
3. The protection does not appear to actually prevent any = attacks.
4. The protection introduces some new vulnerabilities = (or at least unacceptable trade-offs).
5. If you still want = it, despite the above, it is trivial to implement over the top.

(In light of point (3), the word "protection" should = be read with appropriate irony = herinafter.)

Further = details:

1. The protection reduces the utility = of the protocol. 

The protection of security parameters in JWE is = accomplished by placing the parameters in the AAD input to an AEAD = algorithm (i.e., the data that are authenticated, but not encrypted). =  This means that the AAD field cannot be used for any other = purpose, ruling out any use case that requires this capability.


2. The protection increases the = complexity of the protocol.

If the protection = were not present, then the recipient of an object could simply read the = parameters and use them to process the object.  However, because = the processing requires the serialized parameters as input, one needs to = keep around both the serialized and the parsed forms of the parameters. =  The need for the serialization of the parameters to be fixed also = prevents a natural JSON representation (since JSON is not = canonical).


3. The protection does not appear to = actually prevent any attacks.

Russ summarized = this nicely on CFRG a few days ago:


4. The protection introduces some new = vulnerabilities.

Efficiently encrypting an = object for multiple recipients is a major use case for JOSE.  With = the parameters as AAD, this causes re-use of nonces in GCM, which is = clearly a problem.  Avoiding nonce re-use removes all efficiency = gains for the multiple recipient case.


5. If you still = want it, despite the above, it is trivial to implement over the = top.

Just put a hash of the parameters within the = authenticated content.  (I would even be happy to define a standard = mechanism for doing this.)


Hope = that helps,
=
--Richard

 
_______________________________________________
Cfrg mailing = list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg



= --Apple-Mail=_2E1A6E91-E9DE-423E-9FC9-CEB76F44CDDB-- --Apple-Mail=_D068EC85-D370-4E3B-AD61-133CA4CB3EF0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDA1MjMyMDExWjAjBgkqhkiG9w0BCQQxFgQUjkMsyfyW YVRt0oznotipvvehZoUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAq1eo9CtqYXH0a5g9CqahbuW04Aue1q0vUQA/SB5L Dmn/IStsgSdy8FohoC9hjE0N81e0TZnVViljIrHQor1rb2ymhpP6tOJ9TtcTErgBzSn+O95guSJZ Ry9qhLMTvc9p7ULQP7XFUwy073WrzUmEagrzZ9Kw/M+u7MQbZH2QQYXVG8HS4Q9Y4aoeZEXk8uuX rLUAkw06X+BebBWuQFIvsaQQhVehB2IysBkfAU3QOD09V9e0JYAJj+HxzEByn/o9YBmsjUXkOIU/ mD6BPxTlfUIxOl8zNAtFMAh3QIpXjhqF+uQlnjrMYxUEkooBYpJ9hx90Qmq004gZgPpXE3Q3cQAA AAAAAA== --Apple-Mail=_D068EC85-D370-4E3B-AD61-133CA4CB3EF0-- From rlb@ipv.sx Fri Apr 5 19:01:37 2013 Return-Path: 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 DAAE721F9797 for ; Fri, 5 Apr 2013 19:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2MS1yAqYM4rK for ; Fri, 5 Apr 2013 19:01:36 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id C17F021F9796 for ; Fri, 5 Apr 2013 19:01:36 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n12so4630929oag.13 for ; Fri, 05 Apr 2013 19:01:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xhSHNIcOCTIZK/G5SgCbDog7nBsmrQAurNrkxd4CUTQ=; b=W1JB9Z6Tes3PuWjabfd4maVwmKYLqiMg9Ymrw/I+TdQPUrkXF9lc1XSgsKjoo85KcN TB+1+azj4v+7BNF1mZO2XglXEQTd0mo1OyS0v1/QG0V1xZy/tFSGjnwvOPLzXlkebWE0 /lpre2B4NT9HEZy7Re5f2/MCcfH9P1hxi6IbJ8owIvYA5sYc0gvyW5sgPc3wwi9Xmzp4 qUC+19syV8Eagp6KoAcnndjZI1z0g2i9HvIWrk/oy922GdSwvYN8jOfVpXoD9vpFDM1E AgTu1oCedQG8OvuzCFq/JNlL0CpRTW3qiuyNsSrka5mbDkqGX0JHyGYn7Jqjtx7FvWkw BVuQ== MIME-Version: 1.0 X-Received: by 10.60.103.165 with SMTP id fx5mr10022521oeb.4.1365213696269; Fri, 05 Apr 2013 19:01:36 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 5 Apr 2013 19:01:36 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> Date: Fri, 5 Apr 2013 22:01:36 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=089e0112c40468f88304d9a79514 X-Gm-Message-State: ALoCoQnv3Y5lwuKX+nGr6/m4FtIf4NBRh4LT92AcyFIB7oAq4KDwI8gXnFvvrqadj4ETCNBpXTMP Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 02:01:38 -0000 --089e0112c40468f88304d9a79514 Content-Type: text/plain; charset=ISO-8859-1 Fair enough point that there are some signature schemes that are vulnerable to the attacks laid out in RFC 6211. I don't really see that as a reason to levy a requirement on other signature schemes, and on encrypted objects. It seems sufficient to have an optional protection that can be enabled for vulnerable algorithms. But I also agree with John that other peoples' perspectives are more important than ours, so I'll shut up now :) --Richard On Friday, April 5, 2013, John Bradley wrote: > Richard, > > I think it was Jim that pointed out RFC 6211 "Cryptographic Message > Syntax (CMS) Algorithm Identifier Protection Attribute" adds a new CMS > parameter to protect the algorithm identifier in CMS. > > The existence of RFC 6211 makes me feel lees alone in my opinion on the > value of integrity protecting recipient info. > > There are downsides for multiple recipients. I would rather work through > that than throw out integrity protectin for recipiant info. > > I may be in the minority on that we will have to see. > > I hope that the Cfrg can provide some wisdom on this as the two of us > could argue this for a long time without getting to conclusion as it is > hard to absolutely prove either side of the argument. > > Regards > John B. > > > On 2013-04-05, at 8:03 PM, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:56 PM, John Bradley wrote: > > I took Russe's as being confirmation of why he believes CMS doesn't need > to protect it's recipient-info. > > One thing to note is that the JWE version of recipient info is extensible > by WG decision. > Some of those extensions are security related and benefit from integrity > protection. > > > Then you should put them in an integrity protected object. > > CMS EnvelopedData does have extensible attributes. In fact, they are > explicitly called "unprotectedAttrs"! > > EnvelopedData ::= SEQUENCE { > version CMSVersion, > originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, > recipientInfos RecipientInfos, > encryptedContentInfo EncryptedContentInfo, > unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } > > So extensibility is not a difference here. > > > > On point 3, while on the face of it integrity protecting the algorithm > information doesn't stop the key wrap alg from being changed before it is > used, with proper care all such tampering with the JWE can be reported as a > single failure. Continuing with decrypting the body and generating a > integrity error at the end has some benefit in discouraging timing attacks. > > > That is true whether the parameters / header are integrity protected or > not. > > > > One of the reasons we decided to integrity protect the header was based on > Ben's original advice. We may not know all of the possible future attacks, > so better to be safe. > > > The point of Russ's message is that there's not actually any additional > safety here. > > > > I agree that Richard has a point with GCM and some possible > serializations. Personally I would rather find a way to do it with a > single GCM tag and keep the integrity protection. > > > If you want to achieve that objective, then you need to at least remove > per-recipient parameters from the integrity protection. > > > > On point 1 I think that is a bit overplayed. JWE doesn't specify how to > serialize an additional AAD , and if you needed to it could be added as an > element to the envelope. > I think that can be dealt with. > > The bottom line is we are supporting only AEAD algorithms. Putting the > envelope in the AAD to integrity protect it is not a huge complication. > > > But the fact that there is no clear benefit to it means that it should at > most be optional. > > --Richard > > > > > > John B. > > > On 2013-04-05, at 7:32 PM, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: > > On 5 April 2013 23:17, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie > > --089e0112c40468f88304d9a79514 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fair enough point that there are some signature schemes that are vulnerable= to the attacks laid out in RFC 6211. =A0I don't really see that as a r= eason to levy a requirement on other signature schemes, and on encrypted ob= jects. =A0It seems sufficient to have an optional protection that can be en= abled for vulnerable algorithms.=A0

But I also agree with John that other peoples' perspecti= ves are more important than ours, so I'll shut up now :)

=
--Richard



On Frida= y, April 5, 2013, John Bradley wrote:
Ric= hard,

I think it was Jim that pointed out=A0RFC 6211 &q= uot;Cryptogr= aphic Message Syntax (CMS)=A0

Algorithm Identifier Protection Attribute"=A0

adds a new CM= S parameter to protect the algorithm identifier in CMS. =A0 =A0

The existence of RFC 6211 makes me feel lees alone in my opinion on= the value of integrity protecting recipient info.

There are downsides for multiple recipients. =A0I would= rather work through that than throw out integrity protectin for recipiant = info.=A0

I may be in the minority on that we will = have to see. =A0=A0

I hope that the Cfrg can provide some wisdom on this as= the two of us could argue this for a long time without getting to conclusi= on as it is hard to absolutely prove either side of the argument.=A0

Regards
John B.


=
On 2013-04-05, at 8:03 PM, Richard Barnes <rlb@ipv.sx&g= t; wrote:

On Fri, Apr 5, 2013 at 6:56 PM= , John Bradley <ve7jtb@ve7jtb.com> wr= ote:
I took Russe's as being confirmatio= n of why he believes CMS doesn't need to protect it's recipient-inf= o.

One thing to note is that the JWE version of recipien= t info is extensible by WG decision. =A0
Some of those extensions are security related and benefit from integri= ty protection.

Then you should = put them in an integrity protected object.

CMS Env= elopedData does have extensible attributes. =A0In fact, they are explicitly= called "unprotectedAttrs"!

EnvelopedData ::=3D SEQUENCE {
=A0 =A0 = =A0 =A0 version CMSVersion,
=A0 =A0 =A0 =A0 originatorInfo [0] IM= PLICIT OriginatorInfo OPTIONAL,
=A0 =A0 =A0 =A0 recipientInfos Re= cipientInfos,
=A0 =A0 =A0 =A0 encryptedContentInfo EncryptedContentInfo,
=A0 = =A0 =A0 =A0 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }<= /div>

So extensibility is not a difference here.

=A0
On point 3,= =A0while on the face of it integrity protecting the algorithm information = doesn't stop the key wrap alg from being changed before it is used, wit= h proper care all such tampering with the JWE can be reported as a single f= ailure. =A0 Continuing with decrypting the body and generating a integrity = error at the end has some benefit in discouraging timing attacks.

That is true whether the parameters = / header are integrity protected or not. =A0

=A0
One of the reasons we decided to i= ntegrity protect the header was based on Ben's original advice. =A0We m= ay not know all of the possible future attacks, so better to be safe.

The point of Russ's message is t= hat there's not actually any additional safety here.

=A0
I agree that Richard has a point w= ith GCM and some possible serializations. =A0Personally I would rather find= a way to do it with a single GCM tag and keep the integrity protection.

If you want to achieve that objectiv= e, then you need to at least remove per-recipient parameters from the integ= rity protection.=A0

=A0
On point 1 I think that is a bit o= verplayed. =A0JWE doesn't specify how to serialize an additional AAD , = and if you needed to it could be added as an element to the envelope.
I think that can be dealt with.

The bottom li= ne is we are supporting only AEAD algorithms. =A0 =A0Putting the envelope i= n the AAD to integrity protect it is not a huge complication.

But the fact that there is no clear benefit to it means= that it should at most be optional.

--Richard


=A0

John B.
<= br>

On 2013-04-05, at 7:32 PM, Richard Ba= rnes <rlb@ipv.sx> wrote:

On Fri, Apr 5, 2013 at = 6:18 PM, Ben Laurie <ben@links.org> w= rote:
On 5 April 2013 23:17, Richard Barnes <rlb@ipv.sx> wrote:=
> On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben@links.org>= ;
--089e0112c40468f88304d9a79514-- From benlaurie@gmail.com Sat Apr 6 03:55:08 2013 Return-Path: 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 1F8BA21F8D0E for ; Sat, 6 Apr 2013 03:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] 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 YoQE11GMP4mH for ; Sat, 6 Apr 2013 03:55:07 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 509FD21F8CF0 for ; Sat, 6 Apr 2013 03:55:07 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id b12so1934339qca.4 for ; Sat, 06 Apr 2013 03:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xYk2muToPXHyXbQop8stZjvzQkkNsRd5T5ASlOsgY2U=; b=WmEs3LsIvcsx+dDE/eTHtv8L2+dEMdwH8maGwzBiQgNMY4JrNPJxw0Z2diCa4qpvsO UIQYHnWkZtFZA7F+P7RgmUh9aYH69Uxkz1rUnjHKkUBGBGrvUMAnFNsyQDc9RMDjyfLE TNsVhRcAIQ5T/kFUjvHzOTnW0LqHIr9oE6+8HWOsVkTzbGbWoMIVctcpZyqaIvXNX2Av 8VOONYt0oE63NGTocd5zdPDrkXiQiWTRTXVRrhQrT961+dNFseoMhrLRzH2Cx3W/cexg 6Gohz2yS2H+iB4WbXDz+JCJYZn2V9cAhbCLLUxRrOaNsHOQPKoRqaeBbSJiiP2nMXH1E nWPQ== MIME-Version: 1.0 X-Received: by 10.49.117.7 with SMTP id ka7mr12897937qeb.38.1365245706609; Sat, 06 Apr 2013 03:55:06 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.127.111 with HTTP; Sat, 6 Apr 2013 03:55:06 -0700 (PDT) In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 6 Apr 2013 11:55:06 +0100 X-Google-Sender-Auth: i6kiLplGjNysU9nZu4yvTBcBFQs Message-ID: From: Ben Laurie To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: "cfrg@irtf.org" , Jim Schaad Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 10:55:08 -0000 On 5 April 2013 23:32, Richard Barnes wrote: > On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: >> >> On 5 April 2013 23:17, Richard Barnes wrote: >> > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: >> >> >> >> On 5 April 2013 23:00, Mike Jones wrote: >> >> > Indeed, "all parameters should be protected" is the security posture >> >> > taken in the current JOSE specifications. Some want to change that. >> >> >> >> OK. Why? >> >> >> > >> > Is that "Why are all parameters protected?" or "Why do some people want >> > to >> > change that"? >> >> The latter. > > > I'll summarize in the following points: > 1. The protection reduces the utility of the protocol. > 2. The protection increases the complexity of the protocol. > 3. The protection does not appear to actually prevent any attacks. > 4. The protection introduces some new vulnerabilities (or at least > unacceptable trade-offs). > 5. If you still want it, despite the above, it is trivial to implement over > the top. > > (In light of point (3), the word "protection" should be read with > appropriate irony herinafter.) > > Further details: > > 1. The protection reduces the utility of the protocol. > > The protection of security parameters in JWE is accomplished by placing the > parameters in the AAD input to an AEAD algorithm (i.e., the data that are > authenticated, but not encrypted). This means that the AAD field cannot be > used for any other purpose, ruling out any use case that requires this > capability. That seems easy enough to fix, define the AAD input to be len(JWE stuff) + JWE stuff + other stuff. > 2. The protection increases the complexity of the protocol. > > If the protection were not present, then the recipient of an object could > simply read the parameters and use them to process the object. However, > because the processing requires the serialized parameters as input, one > needs to keep around both the serialized and the parsed forms of the > parameters. The need for the serialization of the parameters to be fixed > also prevents a natural JSON representation (since JSON is not canonical). Traditionally this has been fixed by not attempting to canonicalise or serialise the JSON but instead to b64 encode the JSON, however it happens to come out, and using that as the input for authentication. > 3. The protection does not appear to actually prevent any attacks. > > Russ summarized this nicely on CFRG a few days ago: > That is hardly an exhaustive analysis. > 4. The protection introduces some new vulnerabilities. > > Efficiently encrypting an object for multiple recipients is a major use case > for JOSE. With the parameters as AAD, this causes re-use of nonces in GCM, > which is clearly a problem. Avoiding nonce re-use removes all efficiency > gains for the multiple recipient case. > So what you mean is that integrity reduces efficiency (clearly you should not choose to compromise security, if security is your goal). I don't know enough about the protocols to propose a solution but would note that a common solution is to have the per-recipient part encrypt a key to the common part (which is the same key for everyone, of course), like multi-recipient PGP. Dunno if that helps in this case. > 5. If you still want it, despite the above, it is trivial to implement over > the top. > > Just put a hash of the parameters within the authenticated content. (I > would even be happy to define a standard mechanism for doing this.) If you want to get integrity by some mechanism other than AAD that's fine by me. > > > Hope that helps, > --Richard > > From benlaurie@gmail.com Sat Apr 6 03:57:02 2013 Return-Path: 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 83D1721F8D0E for ; Sat, 6 Apr 2013 03:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ymzMFC68RgvD for ; Sat, 6 Apr 2013 03:57:01 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7507621F8CF0 for ; Sat, 6 Apr 2013 03:57:01 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so2451421qeb.34 for ; Sat, 06 Apr 2013 03:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=b6l7yic4rVd+e1EairDwzBqweGFkqrJyCndcjxVKrOQ=; b=CjENVXzJNqnXs9iC1x+B+YuNcdF7TRft599fgOdxySu5Jm+58s3tMaNf9uSbLhznp6 zxvy1UkcaHwfnCtZS93wO0ZgrnbJAFn8m4Ft2LJjFDx1r9ZDm3NAQbloXhr3BFLLAtJT Qq3obkEvZEyb5p+csXKspzLoEXsuVLi4hjOi6KkuUvekadQCYHUZQT/hpdXY8zC3mpK+ jqixRA7/HdGR2McOIWYj/MuKSGWkPrviV+4Pw7lbyrL8CcUOiZL336/3kIrRGYdKFxIE KXYKn3KciRGL5fu0wrymNYZe713EPvaqpDVMEPdDq94GHNEzvUCYm/+eP2GTzjXYuTz4 SJhA== MIME-Version: 1.0 X-Received: by 10.49.48.43 with SMTP id i11mr12858613qen.65.1365245818939; Sat, 06 Apr 2013 03:56:58 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.127.111 with HTTP; Sat, 6 Apr 2013 03:56:58 -0700 (PDT) In-Reply-To: <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> Date: Sat, 6 Apr 2013 11:56:58 +0100 X-Google-Sender-Auth: vBAFM-9Ph_L-wrnOmvoKoLDryHs Message-ID: From: Ben Laurie To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 10:57:02 -0000 On 5 April 2013 23:56, John Bradley wrote: > I took Russe's as being confirmation of why he believes CMS doesn't need to > protect it's recipient-info. > > One thing to note is that the JWE version of recipient info is extensible by > WG decision. > Some of those extensions are security related and benefit from integrity > protection. > > On point 3, while on the face of it integrity protecting the algorithm > information doesn't stop the key wrap alg from being changed before it is > used, with proper care all such tampering with the JWE can be reported as a > single failure. Continuing with decrypting the body and generating a > integrity error at the end has some benefit in discouraging timing attacks. > > One of the reasons we decided to integrity protect the header was based on > Ben's original advice. We may not know all of the possible future attacks, > so better to be safe. Quite. A recurring pattern we see is that crypto mechanisms get pared down to the bare minimum. Which later turns out to be a little less then the minimum. Its time we resisted that temptation and started over-specifying crypto. > I agree that Richard has a point with GCM and some possible serializations. > Personally I would rather find a way to do it with a single GCM tag and keep > the integrity protection. > > On point 1 I think that is a bit overplayed. JWE doesn't specify how to > serialize an additional AAD , and if you needed to it could be added as an > element to the envelope. > I think that can be dealt with. > > The bottom line is we are supporting only AEAD algorithms. Putting the > envelope in the AAD to integrity protect it is not a huge complication. > > John B. > > > On 2013-04-05, at 7:32 PM, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: >> >> On 5 April 2013 23:17, Richard Barnes wrote: >> > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: >> >> >> >> On 5 April 2013 23:00, Mike Jones wrote: >> >> > Indeed, "all parameters should be protected" is the security posture >> >> > taken in the current JOSE specifications. Some want to change that. >> >> >> >> OK. Why? >> >> >> > >> > Is that "Why are all parameters protected?" or "Why do some people want >> > to >> > change that"? >> >> The latter. > > > I'll summarize in the following points: > 1. The protection reduces the utility of the protocol. > 2. The protection increases the complexity of the protocol. > 3. The protection does not appear to actually prevent any attacks. > 4. The protection introduces some new vulnerabilities (or at least > unacceptable trade-offs). > 5. If you still want it, despite the above, it is trivial to implement over > the top. > > (In light of point (3), the word "protection" should be read with > appropriate irony herinafter.) > > Further details: > > 1. The protection reduces the utility of the protocol. > > The protection of security parameters in JWE is accomplished by placing the > parameters in the AAD input to an AEAD algorithm (i.e., the data that are > authenticated, but not encrypted). This means that the AAD field cannot be > used for any other purpose, ruling out any use case that requires this > capability. > > > 2. The protection increases the complexity of the protocol. > > If the protection were not present, then the recipient of an object could > simply read the parameters and use them to process the object. However, > because the processing requires the serialized parameters as input, one > needs to keep around both the serialized and the parsed forms of the > parameters. The need for the serialization of the parameters to be fixed > also prevents a natural JSON representation (since JSON is not canonical). > > > 3. The protection does not appear to actually prevent any attacks. > > Russ summarized this nicely on CFRG a few days ago: > > > > 4. The protection introduces some new vulnerabilities. > > Efficiently encrypting an object for multiple recipients is a major use case > for JOSE. With the parameters as AAD, this causes re-use of nonces in GCM, > which is clearly a problem. Avoiding nonce re-use removes all efficiency > gains for the multiple recipient case. > > > > 5. If you still want it, despite the above, it is trivial to implement over > the top. > > Just put a hash of the parameters within the authenticated content. (I > would even be happy to define a standard mechanism for doing this.) > > > Hope that helps, > --Richard > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > From trevp@trevp.net Sat Apr 6 12:33:57 2013 Return-Path: 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 A4B2421F8533 for ; Sat, 6 Apr 2013 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=2.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 J43s44LdqdvN for ; Sat, 6 Apr 2013 12:33:56 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 67E7021F8522 for ; Sat, 6 Apr 2013 12:33:56 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so4647921wgh.25 for ; Sat, 06 Apr 2013 12:33:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=90uHCDHfn9h7AnsgTHkM5a1zGkTlzjvZBcUUHca8GOc=; b=CXT41KY0LyoIzgPoFoEy/x0OlZNkZ5jNsbsoo5ihFDGaJ/t2iBE0HFpZOLqZjx6DwN zy70L/u3AehAk6vjuAwnkWSGI7I8fSUBIvcrHG+9TJhr/TwPdDRQMMSkU0vOJr66eBwQ 8Z6bWO+e92wn6iEOTLLmjjtFw1R1soLUNvtLcl6PPB155IQPKllSMbEEaswK6ksCSeie oudgmGI/uYQMbjP2Profn6fl7kyJpWeBNNNsbxUwbzA/ebdiGtxTAhyJsuccfSI4yyVd sBunU7iC+ehYtukJYdPtBROmdiLN3UE17xUQWKCKAdaFSx2eTpKFZDBLEmcUWDfHb3JD kPWA== MIME-Version: 1.0 X-Received: by 10.180.105.99 with SMTP id gl3mr5332978wib.22.1365276835446; Sat, 06 Apr 2013 12:33:55 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Sat, 6 Apr 2013 12:33:55 -0700 (PDT) X-Originating-IP: [64.134.227.192] In-Reply-To: <810C31990B57ED40B2062BA10D43FBF513CF51@XMB111CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF513CF51@XMB111CNC.rim.net> Date: Sat, 6 Apr 2013 12:33:55 -0700 Message-ID: From: Trevor Perrin To: Dan Brown Content-Type: multipart/alternative; boundary=f46d04426d76cc1e1e04d9b648ac X-Gm-Message-State: ALoCoQkRQjnciSskC69+3OeANLBrDV4SstKElCk+dVuxHMb8/lJULdLRyVcXireo00BWTFHv+XhJ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] IETF's message authentication (1-pass) w/o signatures ... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 19:33:57 -0000 --f46d04426d76cc1e1e04d9b648ac Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 5, 2013 at 1:52 PM, Dan Brown wrote: > Dear CFRG list:**** > > ** ** > > Some IETF messaging protocols, including CMS (and perhaps JOSE) offer > messaging protocols in which both the sender and the recipient have > authenticated keys (public keys, shared symmetric keys, or passwords) and > the message is authenticated (and possibly also encrypted), but not signed > in the usual sense of a public-key signature.**** > > ** ** > > Questions:**** > > ** ** > > 1. What benefits does this form of recipient-specific sender > authentication have over signing? In particular, is the main benefit > adding non-malleability (integrity protection (***)) to encryption (*)?*** > * > > ** ** > > 2. What is the best cryptographic research defining formal security > definitions for this kind of operation? > IANAC, but I believe this paper is relevant to the public-key case, when messages have sender-authentication as well as encryption: Gorantla et al, "On the Connection between Signcryption and One-pass Key Establishment" http://eprint.iacr.org/2009/436 It discusses connections between: * The "signcryption" or "public-key authenticated encryption" notions that have grown from thinking about composing encryption and signing * The "one-pass key establishment" notions that have grown from thinking about DH key agreement (unified model, MQV etc.). As to the benefits of this, I suppose having a "signcryption" or "cryptobox" primitive can offer efficiency advantages, such as reduced computation or less bandwidth (e.g. a signature can be omitted). It also provides a nice "high-level" API, without having to worry about the details of composing (signing/authenticating) with encryption. NaCl and HOMQV seem like good examples: http://nacl.cr.yp.to/ http://eprint.iacr.org/2010/638 Trevor --f46d04426d76cc1e1e04d9b648ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 5, 2013 at 1:52 PM, Dan Brown <dbrown@certicom.com> wrote:

Dear CFRG list:

=A0

Some IETF messaging protocols, including CMS (and pe= rhaps JOSE) offer messaging protocols in which both the sender and the reci= pient have authenticated keys (public keys, shared symmetric keys, or passw= ords) and the message is authenticated (and possibly also encrypted), but not signed in the usual sense of a publ= ic-key signature.

=A0

Questions:

=A0

1. What benefits does this form of recipient-specifi= c sender authentication have over signing?=A0 In particular, is the main be= nefit adding non-malleability (integrity protection (***)) to encryption (*= )?

=A0

2. What is the best cryptographic research defining = formal security definitions for this kind of operation?


IANAC, but I believe this paper is releva= nt to the public-key case, when messages have sender-authentication as well= as encryption:

Gorantla et al, "On the Connection between Signcry= ption and One-pass Key Establishment"

It discusses connections between:
=A0* The "signcryptio= n" or "public-key authenticated encryption" notions that hav= e grown from thinking about composing encryption and signing
=A0*= The "one-pass key establishment" notions that have grown from th= inking about DH key agreement (unified model, MQV etc.).


As to the benefits of this, I supp= ose having a "signcryption" or "cryptobox" primitive ca= n offer efficiency advantages, such as reduced computation or less bandwidt= h (e.g. a signature can be omitted). =A0

It also provides a nice "high-level" API= , without having to worry about the details of composing (signing/authentic= ating) with encryption.

NaCl and HOMQV seem like g= ood examples:



Trevor

--f46d04426d76cc1e1e04d9b648ac-- From vf@vc.unity.net Fri Apr 5 16:32:56 2013 Return-Path: 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 DF31C21F98F5 for ; Fri, 5 Apr 2013 16:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 YwBvEGkOs8+A for ; Fri, 5 Apr 2013 16:32:56 -0700 (PDT) Received: from vc.unity.net (140-242.trifle.net [195.24.140.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC8221F98F4 for ; Fri, 5 Apr 2013 16:32:55 -0700 (PDT) Received: from vf by vc.unity.net with local (Exim 4.80) (envelope-from ) id 1UOG7p-0006YB-GZ; Sat, 06 Apr 2013 02:32:53 +0300 Date: Sat, 6 Apr 2013 02:32:53 +0300 From: Vadym Fedyukovych To: cfrg@irtf.org Message-ID: <20130405233253.GA16419@vc.unity.net> References: <810C31990B57ED40B2062BA10D43FBF513CF51@XMB111CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <810C31990B57ED40B2062BA10D43FBF513CF51@XMB111CNC.rim.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: vf@vc.unity.net X-SA-Exim-Scanned: No (on vc.unity.net); SAEximRunCond expanded to false Cc: Dan Brown Subject: Re: [Cfrg] IETF's message authentication (1-pass) w/o signatures ... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 14:05:17 -0000 On Fri, Apr 05, 2013 at 08:52:51PM +0000, Dan Brown wrote: > Dear CFRG list: > > Some IETF messaging protocols, including CMS (and perhaps JOSE) offer messaging protocols in which both the sender and the recipient have authenticated keys (public keys, shared symmetric keys, or passwords) and the message is authenticated (and possibly also encrypted), but not signed in the usual sense of a public-key signature. > > Questions: > > 1. What benefits does this form of recipient-specific sender authentication have over signing? In particular, is the main benefit adding non-malleability (integrity protection (***)) to encryption (*)? Messages going without signatures, but still admitting authentication, do have an application with a clear advantage over signatures: a threat model with a malicious recipient considering to disclosure the "fully" authenticated message to a third party. It is not "an empty set problem": one might happen to find a signed message, sent to a fiance or a spouse at that time, in a courtroom hearing divorce later. > 2. What is the best cryptographic research defining formal security definitions for this kind of operation? An applicable definition of a non-transferable proof of a theorem (like language membership) is zero knowledge (simulator algorithm). Unfortunately, "zero knowledge" is used rather liberally sometimes. > 3. How do the current IETF designs fare under these cryptographic research goals? It is unlikely such interactive systems were considered at IETF. > 4. Suppose a message has multiple recipients, one of whom is malicious. Should a malicious recipient be allowed to manipulate the message? Should a malicious recipient be allowed to generate a new "authenticated" message from the sender with a different recipient list, in particular, including only a single honest recipient (**)? If these features are allowed, should it be called "authentication"? Under "simulator" concept, ability of any possible verifier to produce a simulated transcript is the core idea, and this might be considered as manipulating a part of the message. > ... > Cfrg mailing list From rlb@ipv.sx Mon Apr 8 13:19:05 2013 Return-Path: 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 28C1921F8842 for ; Mon, 8 Apr 2013 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BPbwNXfnHeDF for ; Mon, 8 Apr 2013 13:19:04 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1E2221F871C for ; Mon, 8 Apr 2013 13:19:03 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so6683278oag.17 for ; Mon, 08 Apr 2013 13:19:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=465LASGQ5lXRDs4TbibZyYiLXAwoPhSAPVt55hzfhYA=; b=DTKb7Mz+KDENzHnJ7gCQp08KdGhvFtYY765hEzMyhSL7z/HeUimyY3sqWGzbr4ds5O JjuS51jLHrARxdToBEYreviNQJcSjILsMergq6GGbnV8lMrh139dMJTkIKFoEPIbh+eg ctWs4bcs9k3o2judRsKatsIO8SxcDzZu94Ik6x9jet6cOVc0/0YC28JnWm+FgED3T2JU N8MYXwjxyqyQ9WWaFz4deX0vEVGdtFLmfIp3OQjYEaeCcqlwMwH6Nljpa/XclOnAGG+Y uypoxp2DePguKOqYL4YRjd0X83fSllB25NOD4u9yb2hOdZo7COrbjpwEhBVLsAwsJxu3 98bQ== MIME-Version: 1.0 X-Received: by 10.60.103.165 with SMTP id fx5mr17045923oeb.4.1365452343466; Mon, 08 Apr 2013 13:19:03 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 8 Apr 2013 13:19:03 -0700 (PDT) X-Originating-IP: [128.89.255.60] In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 8 Apr 2013 16:19:03 -0400 Message-ID: From: Richard Barnes To: Ben Laurie Content-Type: multipart/alternative; boundary=089e0112c404e43a5904d9df2589 X-Gm-Message-State: ALoCoQlX63532Y+WQk1jB4481Oooyd7XbaCqCCsDVGGJHmfF4NZNcLVb8dLmUznuiHeRKS2lafQu Cc: "cfrg@irtf.org" , Jim Schaad Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:19:05 -0000 --089e0112c404e43a5904d9df2589 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 6, 2013 at 6:55 AM, Ben Laurie wrote: > On 5 April 2013 23:32, Richard Barnes wrote: > > On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie wrote: > >> > >> On 5 April 2013 23:17, Richard Barnes wrote: > >> > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie wrote: > >> >> > >> >> On 5 April 2013 23:00, Mike Jones > wrote: > >> >> > Indeed, "all parameters should be protected" is the security > posture > >> >> > taken in the current JOSE specifications. Some want to change > that. > >> >> > >> >> OK. Why? > >> >> > >> > > >> > Is that "Why are all parameters protected?" or "Why do some people > want > >> > to > >> > change that"? > >> > >> The latter. > > > > > > I'll summarize in the following points: > > 1. The protection reduces the utility of the protocol. > > 2. The protection increases the complexity of the protocol. > > 3. The protection does not appear to actually prevent any attacks. > > 4. The protection introduces some new vulnerabilities (or at least > > unacceptable trade-offs). > > 5. If you still want it, despite the above, it is trivial to implement > over > > the top. > > > > (In light of point (3), the word "protection" should be read with > > appropriate irony herinafter.) > > > > Further details: > > > > 1. The protection reduces the utility of the protocol. > > > > The protection of security parameters in JWE is accomplished by placing > the > > parameters in the AAD input to an AEAD algorithm (i.e., the data that are > > authenticated, but not encrypted). This means that the AAD field cannot > be > > used for any other purpose, ruling out any use case that requires this > > capability. > > That seems easy enough to fix, define the AAD input to be len(JWE > stuff) + JWE stuff + other stuff. Assuming you don't care about being ciphertext-compatible with anything else. Not sure if that's a requirement, but it seems like it could be a handy feature. > > 2. The protection increases the complexity of the protocol. > > > > If the protection were not present, then the recipient of an object could > > simply read the parameters and use them to process the object. However, > > because the processing requires the serialized parameters as input, one > > needs to keep around both the serialized and the parsed forms of the > > parameters. The need for the serialization of the parameters to be fixed > > also prevents a natural JSON representation (since JSON is not > canonical). > > Traditionally this has been fixed by not attempting to canonicalise or > serialise the JSON but instead to b64 encode the JSON, however it > happens to come out, and using that as the input for authentication. What you describe is precisely what JOSE does, and what creates the complexity. The parameters are Base64 encoded before inclusion in the AAD. The complexity is on the receiver end, when I have to decode the base64-encoded parameters, but also keep the encoded version around for inclusion as AAD. > > 3. The protection does not appear to actually prevent any attacks. > > > > Russ summarized this nicely on CFRG a few days ago: > > > > That is hardly an exhaustive analysis. That's not really a rebuttal. The point is that the only reason to add complexity is to achieve some security benefit. The only benefit that has been proposed so far is John's observation about RFC 6211, which makes more sense as an *optional* feature (see point 5), since most algorithms have no need of it. > > 4. The protection introduces some new vulnerabilities. > > > > Efficiently encrypting an object for multiple recipients is a major use > case > > for JOSE. With the parameters as AAD, this causes re-use of nonces in > GCM, > > which is clearly a problem. Avoiding nonce re-use removes all efficiency > > gains for the multiple recipient case. > > > > So what you mean is that integrity reduces efficiency (clearly you > should not choose to compromise security, if security is your goal). > > I don't know enough about the protocols to propose a solution but > would note that a common solution is to have the per-recipient part > encrypt a key to the common part (which is the same key for everyone, > of course), like multi-recipient PGP. Dunno if that helps in this > case. Let me expand a little on how integrity reduces efficiency. In particular, how integrity on per-recipient parameters reduces efficiency. A JOSE encrypted object (in the current format) comprises a logical 5-tuple (parameters, wrapped-key, iv, ciphertext, mac), where the integrity check ("mac") covers the first three entries. If you have multiple recipients, then then obviously, the wrapped-key values are going to be different per-recipient. (That of course means the integrity check values ("mac") will be different per recipient.) However, GCM forbids the re-use of a key/IV pair for two different plaintexts. So it's not OK to have: (ciphertext_1, mac_1) = gcm(key, iv, plaintext, parameters || wrapped-key_1 || iv) (ciphertext_2, mac_2) = gcm(key, iv, plaintext, parameters || wrapped-key_2 || iv) That means that the IV field has to be different per recipient as well. Finally, the parameters field includes per-recipient parameters, so it will also be different per recipient. In an ideal world, the only difference between two encrypted objects for different recipients would be in the wrapped keys (as is the case for CMS, even with RFC 6211). But to support GCM in the current JOSE specs, none of the five parts of the object can be the same. This removes all optimization from the multiple-recipient case. > > 5. If you still want it, despite the above, it is trivial to implement > over > > the top. > > > > Just put a hash of the parameters within the authenticated content. (I > > would even be happy to define a standard mechanism for doing this.) > > If you want to get integrity by some mechanism other than AAD that's fine > by me. > Certainly, you could have parameter integrity just by wrapping an encrypted object in a signed/MACed object. I would be happy enough if the current mechanism were made optional. --Richard --089e0112c404e43a5904d9df2589 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Apr 6, 2013 at 6:55 AM, Ben Laur= ie <ben@links.org> wrote:
On 5 April 2013 23:32, Richard Barn= es <rlb@ipv.sx> wrote:
> On Fri, Apr 5, 2013 at 6:18 PM, Ben Laurie <ben@links.org> wrote:
>>
>> On 5 April 2013 23:17, Richard Barnes <rlb@ipv.sx> wrote: >> > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben@links.org> wrote:
>> >>
>> >> On 5 April 2013 23:00, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> >> > Indeed, "all parameters should be protected&quo= t; is the security posture
>> >> > taken in the current JOSE specifications. =A0Some wa= nt to change that.
>> >>
>> >> OK. Why?
>> >>
>> >
>> > Is that "Why are all parameters protected?" or &quo= t;Why do some people want
>> > to
>> > change that"?
>>
>> The latter.
>
>
> I'll summarize in the following points:
> 1. The protection reduces the utility of the protocol.
> 2. The protection increases the complexity of the protocol.
> 3. The protection does not appear to actually prevent any attacks.
> 4. The protection introduces some new vulnerabilities (or at least
> unacceptable trade-offs).
> 5. If you still want it, despite the above, it is trivial to implement= over
> the top.
>
> (In light of point (3), the word "protection" should be read= with
> appropriate irony herinafter.)
>
> Further details:
>
> 1. The protection reduces the utility of the protocol.
>
> The protection of security parameters in JWE is accomplished by placin= g the
> parameters in the AAD input to an AEAD algorithm (i.e., the data that = are
> authenticated, but not encrypted). =A0This means that the AAD field ca= nnot be
> used for any other purpose, ruling out any use case that requires this=
> capability.

That seems easy enough to fix, define the AAD input to be len(J= WE
stuff) + JWE stuff + other stuff.

Assuming = you don't care about being ciphertext-compatible with anything else. = =A0Not sure if that's a requirement, but it seems like it could be a ha= ndy feature.

=A0
> 2. The protection increases the complexity of the protocol.
>
> If the protection were not present, then the recipient of an object co= uld
> simply read the parameters and use them to process the object. =A0Howe= ver,
> because the processing requires the serialized parameters as input, on= e
> needs to keep around both the serialized and the parsed forms of the > parameters. =A0The need for the serialization of the parameters to be = fixed
> also prevents a natural JSON representation (since JSON is not canonic= al).

Traditionally this has been fixed by not attempting to canonicalise o= r
serialise the JSON but instead to b64 encode the JSON, however it
happens to come out, and using that as the input for authentication.

What you describe is precisely what JOSE does, an= d what creates the complexity. =A0The parameters are Base64 encoded before = inclusion in the AAD. =A0The complexity is on the receiver end, when I have= to decode the base64-encoded parameters, but also keep the encoded version= around for inclusion as AAD.


=A0
=
> 3. The protection does not appear to actually prevent any attacks.
>
> Russ summarized this nicely on CFRG a few days ago:
> <http://www.ietf.org/mail-archive/web/cfrg/curre= nt/msg03376.html>

That is hardly an exhaustive analysis.

That's not really a rebuttal. =A0The point is that the only reason to= add complexity is to achieve some security benefit. =A0

The only benefit that has been proposed so far is John's observati= on about RFC 6211, which makes more sense as an *optional* feature (see poi= nt 5), since most algorithms have no need of it.

=A0
> 4. The protection introduces some new vulnerabilities.
>
> Efficiently encrypting an object for multiple recipients is a major us= e case
> for JOSE. =A0With the parameters as AAD, this causes re-use of nonces = in GCM,
> which is clearly a problem. =A0Avoiding nonce re-use removes all effic= iency
> gains for the multiple recipient case.
> <http://www.ietf.org/mail-archive/web/cfrg/curre= nt/msg03373.html>

So what you mean is that integrity reduces efficiency (clearly you should not choose to compromise security, if security is your goal).

I don't know enough about the protocols to propose a solution but
would note that a common solution is to have the per-recipient part
encrypt a key to the common part (which is the same key for everyone,
of course), like multi-recipient PGP. Dunno if that helps in this
case.

Let me expand a little on how integri= ty reduces efficiency. =A0In particular, how integrity on per-recipient par= ameters reduces efficiency.

A JOSE encrypted objec= t (in the current format) comprises a logical 5-tuple (parameters, wrapped-= key, iv, ciphertext, mac), where the integrity check ("mac") cove= rs the first three entries. =A0If you have multiple recipients, then then o= bviously, the wrapped-key values are going to be different per-recipient. = =A0(That of course means the integrity check values ("mac") will = be different per recipient.) =A0

However, GCM forbids the re-use of a key/IV pair for tw= o different plaintexts. =A0So it's not OK to have:
=A0 =A0(ci= phertext_1, mac_1) =3D gcm(key, iv, plaintext, parameters || wrapped-key_1 = || iv)
=A0 =A0(ciphertext_2, mac_2) =3D gcm(key, iv, plaintext, parameters ||= wrapped-key_2 || iv)
That means that the IV field has to be diff= erent per recipient as well. =A0Finally, the parameters field includes per-= recipient parameters, so it will also be different per recipient.

In an ideal world, the only difference between two encr= ypted objects for different recipients would be in the wrapped keys (as is = the case for CMS, even with RFC 6211). =A0But to support GCM in the current= JOSE specs, none of the five parts of the object can be the same. =A0This = removes all optimization from the multiple-recipient case.

=A0
> 5. If you still want it, despite the above, it is trivial to implement= over
> the top.
>
> Just put a hash of the parameters within the authenticated content. = =A0(I
> would even be happy to define a standard mechanism for doing this.)
If you want to get integrity by some mechanism other than AAD that= 9;s fine by me.

Certainly, you could ha= ve parameter integrity just by wrapping an encrypted object in a signed/MAC= ed object.

I would be happy enough if the current mechanism were m= ade optional.

--Richard

<= br>
--089e0112c404e43a5904d9df2589-- From rlb@ipv.sx Mon Apr 8 13:26:17 2013 Return-Path: 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 27FD321F8F06 for ; Mon, 8 Apr 2013 13:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 9JJeNpxS51Ih for ; Mon, 8 Apr 2013 13:26:16 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 32DF921F8D8F for ; Mon, 8 Apr 2013 13:26:13 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id f4so6754012oah.0 for ; Mon, 08 Apr 2013 13:26:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TFpsmLPhJOYULdkejgN+oOHqK/6AsVbCtmPk/VUIWEA=; b=avb1d45OWR6rI6Z5vgndc0UeP+cFTUGA4KSzcwAKdZD2wgnq5QhFHmxmKSr5wSzTJy b25gCEhqXVbTXU5KDV0BNHunMwslqajbbBtpHqn/Mg7WkNuthR3XORrMXUw4VrqAKQ8R jKNq4uZqwC4cTsMnZAZIX766z8sbRCVr9URC9qVS5/3piZ90jb7wEO6HgcGXOLOxZSv1 RfqLlu4RUkeW3SKG6qaz1l5I8Bvbpss0F0v1QluozQ+J9tQfzNqvV6hNt7MLHtlskuFc Zi6ydwt0wKcySdCh20hhERPGTJmbsqN3uO6kCb82/cDWJ9cuG0la1Z/2oJknYQONiXwD GWSg== MIME-Version: 1.0 X-Received: by 10.60.0.129 with SMTP id 1mr16287449oee.5.1365452773455; Mon, 08 Apr 2013 13:26:13 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 8 Apr 2013 13:26:13 -0700 (PDT) X-Originating-IP: [128.89.255.60] In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> Date: Mon, 8 Apr 2013 16:26:13 -0400 Message-ID: From: Richard Barnes To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8fb204868508ee04d9df3f52 X-Gm-Message-State: ALoCoQlt1/nZ/oYf5QN8Pug/RUjAdawtTL//5C9Hxjgg5mFZ3MaOqsia7cS5ii05IhFd22ijb/NU Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:26:17 -0000 --e89a8fb204868508ee04d9df3f52 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 6, 2013 at 6:56 AM, Ben Laurie wrote: > On 5 April 2013 23:56, John Bradley wrote: > > I took Russe's as being confirmation of why he believes CMS doesn't need > to > > protect it's recipient-info. > > > > One thing to note is that the JWE version of recipient info is > extensible by > > WG decision. > > Some of those extensions are security related and benefit from integrity > > protection. > > > > On point 3, while on the face of it integrity protecting the algorithm > > information doesn't stop the key wrap alg from being changed before it is > > used, with proper care all such tampering with the JWE can be reported > as a > > single failure. Continuing with decrypting the body and generating a > > integrity error at the end has some benefit in discouraging timing > attacks. > > > > One of the reasons we decided to integrity protect the header was based > on > > Ben's original advice. We may not know all of the possible future > attacks, > > so better to be safe. > > Quite. A recurring pattern we see is that crypto mechanisms get pared > down to the bare minimum. Which later turns out to be a little less > then the minimum. Its time we resisted that temptation and started > over-specifying crypto. So it's better to do DES twice than just once, right [1]? Or double-ROT13? :) Seriously, if we're going to design cryptographic security mechanisms, we should know what problem we're trying to solve. It is easy in this space to do more work for no benefit. --Richard [1] --e89a8fb204868508ee04d9df3f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Apr 6, 2013 at 6:56 AM, Ben Laurie <ben@links.org> wrote= :
On 5 April 2013 23:56, John Bradley <ve7jtb@ve7jtb.com> wrote:
> I took Russe's as being confirmation of why he believes CMS doesn&= #39;t need to
> protect it's recipient-info.
>
> One thing to note is that the JWE version of recipient info is extensi= ble by
> WG decision.
> Some of those extensions are security related and benefit from integri= ty
> protection.
>
> On point 3, =A0while on the face of it integrity protecting the algori= thm
> information doesn't stop the key wrap alg from being changed befor= e it is
> used, with proper care all such tampering with the JWE can be reported= as a
> single failure. =A0 Continuing with decrypting the body and generating= a
> integrity error at the end has some benefit in discouraging timing att= acks.
>
> One of the reasons we decided to integrity protect the header was base= d on
> Ben's original advice. =A0We may not know all of the possible futu= re attacks,
> so better to be safe.

Quite. A recurring pattern we see is that crypto mechanisms get pared=
down to the bare minimum. Which later turns out to be a little less
then the minimum. Its time we resisted that temptation and started
over-specifying crypto.

So it's better = to do DES twice than just once, right [1]? =A0Or double-ROT13? =A0:)
<= div>
Seriously, if we're going to design cryptographic se= curity mechanisms, we should know what problem we're trying to solve. = =A0It is easy in this space to do more work for no benefit.

--Richard



--e89a8fb204868508ee04d9df3f52-- From benlaurie@gmail.com Wed Apr 10 02:54:16 2013 Return-Path: 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 B532F21F9346 for ; Wed, 10 Apr 2013 02:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 0x0F2Chzed+b for ; Wed, 10 Apr 2013 02:54:16 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id C65BA21F90A9 for ; Wed, 10 Apr 2013 02:54:09 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id u28so109399qcs.8 for ; Wed, 10 Apr 2013 02:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ct8JMwUw3jZ1S/4rWVAIa4q6Co71hJATfXU5zVvy6k0=; b=kOELkT/sZtMqvGs/i1aHgS0b8iMzG8vTz007vxEwWxXkPchDL45/Lxjfdvzr4kaOFO 7q0wF453w8D0IDR4IN9I2h3RE+HRwweTUO8/txBGc84i3UUSIkN2J5jDWE1pC3JakZQI tblqb5+5DTg1RM/2O+Z6zzgnA/89m+iDs9uG8udtZysGiwRYI+xrL/q3Qqg5RpzBO0Vk CE2pxmZ6NfNGjwOb0I0D9bk8VEoIdITuPQnP/Q2ny/BcEDyz6l6c5zg+62Vafbdgu9QX DmJeRmKyy/RhmJg8zzMq1xnnqdcgcr5XM15IMYwbbyyro2sNzVWv3B3QUeNwU174hqOd LOnw== MIME-Version: 1.0 X-Received: by 10.224.117.1 with SMTP id o1mr1646698qaq.13.1365587649263; Wed, 10 Apr 2013 02:54:09 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.12.9 with HTTP; Wed, 10 Apr 2013 02:54:09 -0700 (PDT) In-Reply-To: References: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675BA791@TK5EX14MBXC283.redmond.corp.microsoft.com> <02EB8AA5-5046-4633-B169-FAA2F534B505@ve7jtb.com> Date: Wed, 10 Apr 2013 10:54:09 +0100 X-Google-Sender-Auth: 6QA5QBBUKo-5ZTBOJOXk2XUDGrs Message-ID: From: Ben Laurie To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: Jim Schaad , "cfrg@irtf.org" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 09:54:16 -0000 On 8 April 2013 21:26, Richard Barnes wrote: > On Sat, Apr 6, 2013 at 6:56 AM, Ben Laurie wrote: >> >> On 5 April 2013 23:56, John Bradley wrote: >> > I took Russe's as being confirmation of why he believes CMS doesn't need >> > to >> > protect it's recipient-info. >> > >> > One thing to note is that the JWE version of recipient info is >> > extensible by >> > WG decision. >> > Some of those extensions are security related and benefit from integrity >> > protection. >> > >> > On point 3, while on the face of it integrity protecting the algorithm >> > information doesn't stop the key wrap alg from being changed before it >> > is >> > used, with proper care all such tampering with the JWE can be reported >> > as a >> > single failure. Continuing with decrypting the body and generating a >> > integrity error at the end has some benefit in discouraging timing >> > attacks. >> > >> > One of the reasons we decided to integrity protect the header was based >> > on >> > Ben's original advice. We may not know all of the possible future >> > attacks, >> > so better to be safe. >> >> Quite. A recurring pattern we see is that crypto mechanisms get pared >> down to the bare minimum. Which later turns out to be a little less >> then the minimum. Its time we resisted that temptation and started >> over-specifying crypto. > > > So it's better to do DES twice than just once, right [1]? Or double-ROT13? > :) It's not worse :-) And, in fact, DES-2 actually _is_ better than DES-1. > Seriously, if we're going to design cryptographic security mechanisms, we > should know what problem we're trying to solve. It is easy in this space to > do more work for no benefit. I don't disagree with that. So, the problem signing parameters is designed to solve is: algorithm becomes weak, algorithm specifier is not authenticated, manipulation of specifier is therefore trivial, authentication/content of the message is thus more easily faked. Now, you're going to say that if the specifier is authenticated by the broken algorithm, then it isn't authenticated anyway - and my response is that the more stuff the attacker has to get to come out right, the harder his job is. Without knowing what the specific break is, its hard to say whether this is going to matter in practice or not. But ... it seems unlikely to make matters worse. From prvs=7812ac4299=uri@ll.mit.edu Wed Apr 10 04:57:46 2013 Return-Path: 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 667B821F92F2 for ; Wed, 10 Apr 2013 04:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] 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 fGo-2c5m4ni6 for ; Wed, 10 Apr 2013 04:57:45 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3621F8BAE for ; Wed, 10 Apr 2013 04:57:45 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r3ABvJ5B029951; Wed, 10 Apr 2013 07:57:19 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'ben@links.org'" , "'rlb@ipv.sx'" Date: Wed, 10 Apr 2013 07:57:16 -0400 Thread-Topic: [Cfrg] What Algorithm information needs to be authenticated? Thread-Index: Ac410V+V4K6rHYywSbuJ0oLt2G6liAAESWND In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-10_05:2013-04-10, 2013-04-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1304100076 Message-Id: <20130410115745.7BA3621F8BAE@ietfa.amsl.com> Cc: "'ietf@augustcellars.com'" , "'cfrg@irtf.org'" Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:57:46 -0000 This question becomes: how much extra work do we have to do (including inco= nvenience and pitfalls we're creating for the implementers) to force the at= tacker walk an extra step, and how much (if at all) those extra steps matte= r (e.g., 2^56 vs 2*2^56?). -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Ben Laurie [mailto:ben@links.org] Sent: Wednesday, April 10, 2013 05:54 AM=0A= To: Richard Barnes Cc: Jim Schaad ; cfrg@irtf.org Subject: Re: [Cfrg] What Algorithm information needs to be authenticated? On 8 April 2013 21:26, Richard Barnes wrote: > On Sat, Apr 6, 2013 at 6:56 AM, Ben Laurie wrote: >> >> On 5 April 2013 23:56, John Bradley wrote: >> > I took Russe's as being confirmation of why he believes CMS doesn't ne= ed >> > to >> > protect it's recipient-info. >> > >> > One thing to note is that the JWE version of recipient info is >> > extensible by >> > WG decision. >> > Some of those extensions are security related and benefit from integri= ty >> > protection. >> > >> > On point 3, while on the face of it integrity protecting the algorith= m >> > information doesn't stop the key wrap alg from being changed before it >> > is >> > used, with proper care all such tampering with the JWE can be reported >> > as a >> > single failure. Continuing with decrypting the body and generating a >> > integrity error at the end has some benefit in discouraging timing >> > attacks. >> > >> > One of the reasons we decided to integrity protect the header was base= d >> > on >> > Ben's original advice. We may not know all of the possible future >> > attacks, >> > so better to be safe. >> >> Quite. A recurring pattern we see is that crypto mechanisms get pared >> down to the bare minimum. Which later turns out to be a little less >> then the minimum. Its time we resisted that temptation and started >> over-specifying crypto. > > > So it's better to do DES twice than just once, right [1]? Or double-ROT1= 3? > :) It's not worse :-) And, in fact, DES-2 actually _is_ better than DES-1. > Seriously, if we're going to design cryptographic security mechanisms, we > should know what problem we're trying to solve. It is easy in this space= to > do more work for no benefit. I don't disagree with that. So, the problem signing parameters is designed to solve is: algorithm becomes weak, algorithm specifier is not authenticated, manipulation of specifier is therefore trivial, authentication/content of the message is thus more easily faked. Now, you're going to say that if the specifier is authenticated by the broken algorithm, then it isn't authenticated anyway - and my response is that the more stuff the attacker has to get to come out right, the harder his job is. Without knowing what the specific break is, its hard to say whether this is going to matter in practice or not. But ... it seems unlikely to make matters worse. _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From kmigoe@nsa.gov Thu Apr 11 10:42:05 2013 Return-Path: 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 5FE6821F92CD for ; Thu, 11 Apr 2013 10:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 AGd3+doBcEYs for ; Thu, 11 Apr 2013 10:42:02 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 63D0721F92C3 for ; Thu, 11 Apr 2013 10:42:02 -0700 (PDT) X-TM-IMSS-Message-ID: <59a0c48000042f98@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 59a0c48000042f98 ; Thu, 11 Apr 2013 13:44:28 -0400 Received: from MSMR-GH1-UEA02.corp.nsa.gov (10.215.227.180) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 11 Apr 2013 13:41:11 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA02.corp.nsa.gov ([10.215.227.180]) with mapi id 14.01.0289.001; Thu, 11 Apr 2013 13:42:00 -0400 From: "Igoe, Kevin M." To: "'cfrg@irtf.org'" Thread-Topic: Hash substitution in PSS Thread-Index: Ac42293JdF4quuUXQ1KmUJ+FVnLXSw== Date: Thu, 11 Apr 2013 17:41:58 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 17:42:05 -0000 On 4 August Jim Schaad pointed out that the choice of hash algorithm in PSS= is not authenticated and asked if this was a security problem. The good news is that if all of the hash algorithms in use are "secure", th= e only risk is the "birthday problem", and the aVailability of more than on= e hash does not a priori result in a cheaper attack. The bad news is that if one of the hashes is broken, so broken that an adve= rsary has a non-trivial chance of finding an "evil" message that has the sa= me hash value as a benign message formed with a hash that is "secure", they= can substitute the evil message under the weak hash for the benign message= under the strong hash. Preventing this requires either that (1) the have a= policy to reject all messages with the weak hash or (2) the choice of hash= algorithm be authenticated. Personally I trust a cryptographic authenticat= ion over policy.= From prvs=08135012b4=dbrown@certicom.com Thu Apr 11 11:28:21 2013 Return-Path: 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 718CE21F8DC9 for ; Thu, 11 Apr 2013 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 n4QycQdT8Nc3 for ; Thu, 11 Apr 2013 11:28:20 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 911BC21F882A for ; Thu, 11 Apr 2013 11:28:20 -0700 (PDT) X-AuditID: 0a412830-b7f2f6d000007c2a-ff-516700b57b8a Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 1B.9B.31786.5B007615; Thu, 11 Apr 2013 13:28:05 -0500 (CDT) Received: from XCT113CNC.rim.net (10.65.161.213) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 11 Apr 2013 14:28:05 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT113CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Thu, 11 Apr 2013 14:28:05 -0400 From: Dan Brown To: "'Igoe, Kevin M.'" , "'cfrg@irtf.org'" Thread-Topic: Hash substitution in PSS Thread-Index: Ac42293JdF4quuUXQ1KmUJ+FVnLXSwAAineA Date: Thu, 11 Apr 2013 18:28:04 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513F1F2@XMB111CNC.rim.net> References: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXC5bjwnO5WhvRAg19XrS26fxxksphw6jWr A5PH5I2H2Tz6d71kDWCKamC0SUosKQvOTM/Tt7NJzMvLL0ksSVVISS1OtlXySU1PzFEIKMos S0yuVHDJLE7OSczMTS1SUshMsVUyUVIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5Cql5 yfkpmXnptkqewf66FhamlrqGSna6CZ08GVMmb2UuuCRece1DQAPjL6EuRk4OCQETiSOPz7FC 2GISF+6tZwOxhQTamSQWrhLoYuQCslcySjzbf4cdwpnDKPF76TsmkCo2AVWJ+0fPMYPYIgJe EvuvfgWbJAwUfzppEStEXE3i785+KNtIYvWMeewgNgtQzZcj74HmcHDwCrhJtF/kglgcJLH1 +0ewEk6BYIn+revBWhkFZCV2n70OtpZZQFzi1pP5TBBHC0gs2XOeGcIWlXj5+B/UM4oSz+4s ZYeo15FYsPsTG4StLbFs4Wuwel4BQYmTM5+wQOxVkLhyfR/LBEbxWUhWzELSPgtJ+ywk7QsY WVYxCuZmFBuYGSbnJesVZebq5aWWbGIEJw8Ngx2M799bHGIU4GBU4uH98iItUIg1say4MvcQ owQHs5IIb8xeoBBvSmJlVWpRfnxRaU5q8SFGV2AATWSW4k7OBya2vJJ4YwMD3Bwlcd7fwtGB QgLpwFSVnZpakFoEM4eJgxNkD5eUSDEw4aQWJZaWZMSD0mJ8MTAxSjUw6p8tKDX4Ip8jvlDw ym533q/M+2fkMd9gtHktsG9JuBWH04TY2lOXlaruXjZcK7XxY+amFu0TIqe7WD+anW8+KlqT Jyn45rroyxN7U2ayHO88wc+ja5adEyNz/pp2/vYbsWmbLBL4Yq+tm2Cu5bHqlcalxebt904d lA++yPVHsCDtz+a1LI0rlFiKMxINtZiLihMBwCJA0l8DAAA= Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 18:28:21 -0000 Doesn't the signer need to have a policy to avoid signing with a weak hash? Otherwise, if Alice the signer does not have such a policy, then she could s= ign with a weak hash. Then Eve the adversary, under your scenario (*), coul= d take the hash value from any message that Alice signed, and find an evil m= essage with the same hash, and fool Bob the verifier. What am I missing? It seems impossible to avoid having a good policy for the signer. I agree t= hat it would be fantastic to avoid such a policy on algorithms, via some alg= orithm. Surely, the verifier would be able to use the same policy as the signer. Ma= ybe this violates the principle of being "generous in what you receive", but= how appropriate is that particular principle when verifying a signature? Why not embed the signer's policy into the signer's certificate? That would= somewhat ease the burden on the verifier, and place responsibility for the= policy upon the signer, where the burden probably belongs. Best regards, Dan (*) Your scenario sounds like this to me: the hash is "weak" in the sense th= at evil pre-images of any hash can be found. That is what I am assume above= . (Or, you can take second preimages ...) A more elaborate scenario would be that the "weak" hash is still strong in t= he sense that it 1st and 2nd preimage resistant, but it is not 2nd preimage= resistant given a 1st preimage under the strong hash. In other words, it f= ails to be second cross-preimage resistant. This scenario is theoretically= possible, but seems unlikely for most conventional hash functions. The pol= icy-necessity argument I make above does not apply to this scenario. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Igoe, Kevin M. > Sent: Thursday, April 11, 2013 1:42 PM > To: 'cfrg@irtf.org' > Subject: [Cfrg] Hash substitution in PSS > > On 4 August Jim Schaad pointed out that the choice of hash algorithm in > PSS is not authenticated and asked if this was a security problem. > > The good news is that if all of the hash algorithms in use are > "secure", the only risk is the "birthday problem", and the aVailability > of more than one hash does not a priori result in a cheaper attack. > > The bad news is that if one of the hashes is broken, so broken that an > adversary has a non-trivial chance of finding an "evil" message that > has the same hash value as a benign message formed with a hash that is > "secure", they can substitute the evil message under the weak hash for > the benign message under the strong hash. Preventing this requires > either that (1) the have a policy to reject all messages with the weak > hash or (2) the choice of hash algorithm be authenticated. Personally I > trust a cryptographic authentication over policy. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From kmigoe@nsa.gov Thu Apr 11 17:38:53 2013 Return-Path: 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 EB91C21F8A0C for ; Thu, 11 Apr 2013 17:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 zZtPsJyLcIYA for ; Thu, 11 Apr 2013 17:38:53 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0532021F89B0 for ; Thu, 11 Apr 2013 17:38:52 -0700 (PDT) X-TM-IMSS-Message-ID: <7ee6a87c0004ac22@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 7ee6a87c0004ac22 ; Thu, 11 Apr 2013 20:37:37 -0400 Received: from MSMR-GH1-UEA07.corp.nsa.gov (10.215.224.5) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 11 Apr 2013 20:38:01 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA07.corp.nsa.gov ([10.215.224.5]) with mapi id 14.01.0289.001; Thu, 11 Apr 2013 20:38:49 -0400 From: "Igoe, Kevin M." To: "'dbrown@certicom.com'" , "'cfrg@irtf.org'" Thread-Topic: Hash substitution in PSS Thread-Index: Ac42293JdF4quuUXQ1KmUJ+FVnLXSwAAineAAA4EFHM= Date: Fri, 12 Apr 2013 00:38:47 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA91878EFE@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF513F1F2@XMB111CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 00:38:54 -0000 I believe we are in agreement. Any policy put in place by the signer to req= uire use of the strong hash when signing is useless unless the verifier als= o has a policy to not accept messages signed using the weak hash. Like CRLs= and patches, it takes a worrisomly long time for such changes to propogate= to every verifier. During the chage over period the signer is vulnerable = to having one of their benign messages "hijacked" and an evil version fed t= o an "unpatched" verifier. Having the policy be part of the cert sounds like a prudent precaution, but= doesn't that implicitly require the policy to be authenticated to stop Eve= from meddling with it? I suppose the bottom line is that if a commonly us= ed hash fails disasterously then even people who have not been using that h= ash are vulnerable.=20 This seems to say designing a protocol that allows for the use of several d= ifferent hashes actually increase everyones vulnerability. That certainly i= s counter intuitive. Of course the discussion above assumes a truly disaste= rous flaw. If the flaw more mundane, supporting more than one hash helps in= recovering from the discovery of this flaw. ----- Original Message ----- From: Dan Brown [mailto:dbrown@certicom.com] Sent: Thursday, April 11, 2013 02:28 PM Eastern Standard Time=0A= To: Igoe, Kevin M.; 'cfrg@irtf.org' Subject: RE: Hash substitution in PSS Doesn't the signer need to have a policy to avoid signing with a weak hash? Otherwise, if Alice the signer does not have such a policy, then she could = sign with a weak hash. Then Eve the adversary, under your scenario (*), co= uld take the hash value from any message that Alice signed, and find an evi= l message with the same hash, and fool Bob the verifier. What am I missing= ? It seems impossible to avoid having a good policy for the signer. I agree = that it would be fantastic to avoid such a policy on algorithms, via some a= lgorithm.=20 Surely, the verifier would be able to use the same policy as the signer. M= aybe this violates the principle of being "generous in what you receive", b= ut how appropriate is that particular principle when verifying a signature? Why not embed the signer's policy into the signer's certificate? That woul= d somewhat ease the burden on the verifier, and place responsibility for th= e policy upon the signer, where the burden probably belongs. Best regards, Dan (*) Your scenario sounds like this to me: the hash is "weak" in the sense t= hat evil pre-images of any hash can be found. That is what I am assume abo= ve. (Or, you can take second preimages ...) A more elaborate scenario would be that the "weak" hash is still strong in = the sense that it 1st and 2nd preimage resistant, but it is not 2nd preimag= e resistant given a 1st preimage under the strong hash. In other words, it= fails to be second cross-preimage resistant. This scenario is theoretical= ly possible, but seems unlikely for most conventional hash functions. The = policy-necessity argument I make above does not apply to this scenario.=20 > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Igoe, Kevin M. > Sent: Thursday, April 11, 2013 1:42 PM > To: 'cfrg@irtf.org' > Subject: [Cfrg] Hash substitution in PSS >=20 > On 4 August Jim Schaad pointed out that the choice of hash algorithm in > PSS is not authenticated and asked if this was a security problem. >=20 > The good news is that if all of the hash algorithms in use are > "secure", the only risk is the "birthday problem", and the aVailability > of more than one hash does not a priori result in a cheaper attack. >=20 > The bad news is that if one of the hashes is broken, so broken that an > adversary has a non-trivial chance of finding an "evil" message that > has the same hash value as a benign message formed with a hash that is > "secure", they can substitute the evil message under the weak hash for > the benign message under the strong hash. Preventing this requires > either that (1) the have a policy to reject all messages with the weak > hash or (2) the choice of hash algorithm be authenticated. Personally I > trust a cryptographic authentication over policy. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From prvs=48142666f4=dbrown@certicom.com Fri Apr 12 11:37:36 2013 Return-Path: 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 343E021F8555 for ; Fri, 12 Apr 2013 11:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 3piQ+eX5P3zM for ; Fri, 12 Apr 2013 11:37:35 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA9F21F854F for ; Fri, 12 Apr 2013 11:37:34 -0700 (PDT) X-AuditID: 0a41282f-b7fc06d00000359e-c8-5168545f3615 Received: from XCT102CNC.rim.net (xct102cnc.rim.net [10.65.161.202]) by mhs060cnc.rim.net (SBG) with SMTP id CF.D9.13726.F5458615; Fri, 12 Apr 2013 13:37:19 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.02.0328.009; Fri, 12 Apr 2013 14:37:18 -0400 From: Dan Brown To: "'Igoe, Kevin M.'" , "'cfrg@irtf.org'" Thread-Topic: Hash substitution in PSS Thread-Index: Ac42293JdF4quuUXQ1KmUJ+FVnLXSwAAineAAA4EFHMAImpEYA== Date: Fri, 12 Apr 2013 18:37:17 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513F5C5@XMB111CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF513F1F2@XMB111CNC.rim.net> <3C4AAD4B5304AB44A6BA85173B4675CA91878EFE@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA91878EFE@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsXC5bjwlG58SEagwYv3ghbdPw4yWUw49ZrV gclj8sbDbB79u16yBjBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejEnb9zAW7Neo6HywirGBcZlCFyMnh4SAicSVnlOs ELaYxIV769m6GLk4hARWMUq8733LDpIQEtjKKHHrtgGIzSagKnH/6DlmEFtEwEti/9WvYM3C QPGnkxaxQsTVJP7u7AeyOYBsJ4n9N9JBwixAJX9ubGADsXkF3CRm935mh9jVzygxtQ1kMQcH p0CwxKU31SA1jAKyErvPXmcCsZkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/0Hdryjx7M5Sdoh6 HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIUzM0oNjAzSM5L 1ivKzNXLSy3ZxAhOBhr6Oxjfvrc4xCjAwajEw7vXNCNQiDWxrLgy9xCjBAezkghvzN60QCHe lMTKqtSi/Pii0pzU4kOMrsBQmcgsxZ2cD0xUeSXxxgYGuDlK4rx8TEBzBdKBqSc7NbUgtQhm DhMHJ8geLimRYmACSS1KLC3JiAelufhiYKKTamDUMDzpV2VYM29nlcpr5YylhtNZ/Yqeq73m 4y6em3V0F6sqj1Exq+Zs+aoz+YLxqfyT1d4zvL+sXpR2z5lL+9rpyRPqbnK3N/TneaxL2jP/ 8rOV7Y2LlLT3hiwMX5PfVSmqITjDytP4dqak4qFQ1kUlUpfXl4dfL3A9H7bl0N7JJV8PNp1b p6LEUpyRaKjFXFScCABJxE7BRwMAAA== Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 18:37:36 -0000 > -----Original Message----- > From: Igoe, Kevin M. [mailto:kmigoe@nsa.gov] > I believe we are in agreement. [DB] I am sure that we agree on many points, but I think we disagree on some= specific points. I will try to be clearer. I am open to correction. I think a hash identifier in PSS does not help. Do you agree? I stand by my argument for that position: which, recall, is that if hash sub= stitution is a problem there will also be much bigger problem, except under= very unrealistic scenarios. > Any policy put in place by the signer to > require use of the strong hash when signing is useless unless the > verifier also has a policy to not accept messages signed using the weak > hash. Like CRLs and patches, it takes a worrisomly long time for such > changes to propogate to every verifier. [DB] Which is why I propose placing the policy in the certificate, so it is= available as soon as the verifier needs it. > During the chage over period > the signer is vulnerable to having one of their benign messages > "hijacked" and an evil version fed to an "unpatched" verifier. [DB] Your last sentence is why I think we still disagree. The "bigger problem" (that I alluded to above, and tried to express in a pre= vious email) is that the attacker will not need to "hijack" any benign messa= ges to feed evil messages to that "unpatched" verifier. Instead, if the has= h is weak, the attacker can feed evil messages to the verifier, without rely= ing any benign messages. > > Having the policy be part of the cert sounds like a prudent precaution, > but doesn't that implicitly require the policy to be authenticated to > stop Eve from meddling with it? [DB] Yes. E.g. if SHA-1 gets totally broken, then any relying party Bob who continues= to use SHA-1, will accept malicious certs from Eve, etc. So, it mainly helps if the issuer uses a stronger algorithm in the cert than= the subject uses to the sign message, or if the cert is authenticated out o= f band, i.e. pre-trusted. I realize that I failed to explain the benefit of using the signer's cert, i= nstead of the signer's signature, to convey the signer's policy on the alg.= If the signature security is compromised, then it cannot be presumed to sa= fely convey the signer's policy. The cert still has a chance to convey the= signer's policy (either by stronger algorithm, or by being pre-trusted, as= mentioned above). I also failed to clarify that my reason for conveying the signer's policy is= not to thwart "hijacking" attacks, but rather that weak hashes must be avoi= ded, and that the signer should be responsible for avoiding weak hashes. (M= y failure to clarify this point may have cause to you think that I agree wit= h the "hijacking" concern.) More technically, the signer needs to ensure the hash resists second-preimag= e attacks, while the verifier only must ensure that the hash resists first-p= reimage attacks. > I suppose the bottom line is that if a > commonly used hash fails disasterously then even people who have not > been using that hash are vulnerable. [DB] Yes. > > This seems to say designing a protocol that allows for the use of > several different hashes actually increase everyones vulnerability. > That certainly is counter intuitive. [DB] Why is it counter intuitive? If Bob accepts any of 5 hashes (or algs),= then his security is only as good as the weakest hash (or alg). If Bob ins= isted that a message was signed by all 5 algs, then his security could be as= a good as the strongest. > Of course the discussion above > assumes a truly disasterous flaw. If the flaw more mundane, supporting > more than one hash helps in recovering from the discovery of this flaw. [DB] To recover from a total disaster, only distributing a policy to stop al= l signing and verifying with the weak hash seems to work. I have yet to be persuaded that there is a realistic milder flaw in the hash= that hash ids in PSS would thwart. I agree that there is benefit to having signature schemes reduce their relia= nce on the hash for security. For example, randomized hashing reduces the r= eliance on collision resistance of the hash, which, I am persuaded, addresse= s a realistic concern. (It also reduces the reliance on other security prop= erties of the hash, such as second-preimage and first-preimage resistance, a= nd instead relies on milder versions thereof.) I agree that it is prudent to take steps to address unforeseen attacks, e.g.= the provable security analyses of PSS [but unfortunately the current resear= ch mostly ignores hash attacks because it mostly assumes a random oracle has= h]. I disagree that a good way to thwart unforeseen attacks is to speculate abou= t unrealistic possible attacks, e.g. second cross-preimage attacks (but no f= irst preimage attacks), and to speculate about countermeasures. I think it is important to have a clear statement of what protection a crypt= o scheme provides, to help ensure users do not rely on the crypto scheme in= the wrong way. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From James.H.Manger@team.telstra.com Sun Apr 14 18:55:39 2013 Return-Path: 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 5893121F92C1 for ; Sun, 14 Apr 2013 18:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 Hl1n4wINLLvS for ; Sun, 14 Apr 2013 18:55:38 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE6921F92B2 for ; Sun, 14 Apr 2013 18:55:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,472,1363093200"; d="scan'208";a="129790092" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 15 Apr 2013 11:55:36 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7045"; a="125367304" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 15 Apr 2013 11:55:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 15 Apr 2013 11:55:36 +1000 From: "Manger, James H" To: "cfrg@irtf.org" , "jose@ietf.org" Date: Mon, 15 Apr 2013 11:55:34 +1000 Thread-Topic: [jose] [Cfrg] GCM nonce reuse question Thread-Index: Ac4vy0pZp5NcBv21Sdau+wVKi4QJGQJp0EiA Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.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> <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> In-Reply-To: <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Cfrg] [jose] GCM nonce reuse question X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 01:55:39 -0000 SSB0aGluayB0aGVyZSBhcmUgbW9yZSBvcHRpb25zIGZvciBoYW5kbGluZyBtdWx0aXBsZSByZWNp cGllbnRzIG9mIEFFQUQtc2VjdXJlZCBjb250ZW50Og0KDQoNCk9wdGlvbiAzOiBQdXQgYWxsIHBl ci1yZWNpcGllbnQgaW5mbyBpbnRvIG9uZSBoZWFkZXI7IGtlZXAgdGhpcyBoZWFkZXIgdW5kZXIg dGhlIEFFQUQgaW50ZWdyaXR5IGNoZWNrOyBoYXZlIG9uZSBub25jZS4NCiAgQ09TVDogQWxsIHJl Y2lwaWVudHMgbmVlZCB0byBiZSBrbm93biAoYW5kIHRoZWlyIGtleSBleGNoYW5nZSBpbmZvIGNy ZWF0ZWQpIGJlZm9yZSB0aGUgQUVBRCBhbGdvcml0aG0gaXMgYXBwbGllZC4NCiAgQ09TVDogVGhl IEpXRSBKU09OIGhlYWRlciBzdHJ1Y3R1cmUgbmVlZHMgdG8gYmUgYWRqdXN0ZWQgKGVnIHRvIGhh dmUgYW4gYXJyYXkgb2YgcmVjaXBpZW50IGluZm8pIHNvIGl0IGlzIG5vdCBiYWNrd2FyZCBjb21w YXRpYmxlIHdpdGggY3VycmVudCBkcmFmdHMuDQogIENPU1Q6IERvZXNuJ3QgaGVscCB1c2UgY2Fz ZXMgd2hlcmUgb25lIHJlY2lwaWVudCBmb3J3YXJkcyBhbiBBRUFELXNlY3VyZWQgbWVzc2FnZSBv biB0byBhIG5ldyByZWNpcGllbnQgKGVnIGFuIFhNUFAgc3lzdGVtIHJlY2VpdmVzIGEgbWVzc2Fn ZSBzZWN1cmVkIGZvciBhIHVzZXIgYW5kIHJlLXNlY3VyZXMgaXQgZm9yIGEgc3BlY2lmaWMgZGV2 aWNlIG9mIHRoYXQgdXNlcikuIENoYW5naW5nIHJlY2lwaWVudHMgcmVxdWlyZXMgcmVhcHBseWlu ZyB0aGUgQUVBRCBvcGVyYXRpb25zLg0KICBDT1NUOiBFYWNoIHJlY2lwaWVudCBuZWVkcyB0byBz ZWUga2V5IGV4Y2hhbmdlIGluZm8gb2YgYWxsIHJlY2lwaWVudHMgKHByaXZhY3kgaW1wYWN0Pyku DQogIFBPU1NJQkxFLUJFTkVGSVQ6IFJlY2lwaWVudHMsIGtleSBleGNoYW5nZXMsIHBhcmFtZXRl cnMsIGFuZCBjb250ZW50IGlzIHNlY3VyZWQgYXMgYSBjb21wbGV0ZSB1bml0Lg0KIA0KDQpPcHRp b24gMmI6IFJlbW92ZSBwZXItcmVjaXBpZW50IGluZm8gZnJvbSBBRUFEIGludGVncml0eSBjaGVj azsgYnV0IGFkZCBBRUFEIGRldGFpbHMgdG8gZWFjaCBrZXkgZXhjaGFuZ2UuIEZvciBpbnN0YW5j ZSwgaW5mbyBhYm91dCBhbiBBRUFEIG9wZXJhdGlvbiAoYWxnIGlkLCBrZXkgaWQgZXRjKSBwb3Rl bnRpYWxseSBldmVuIGluY2x1ZGluZyB0aGUgd2hvbGUgY2lwaGVydGV4dCBpcyB1c2VkIGFzIHRo ZSAibGFiZWwiIGZvciB0aGUgUlNBRVMtT0FFUC1FTkNSWVBUIG9wZXJhdGlvbiB0aGF0IGVuY3J5 cHRzIHRoZSBBRUFEIHNlY3JldCBrZXkgZm9yIGEgcmVjaXBpZW50Lg0KICBCRU5FRklUOiBUaGUg a2V5IGV4Y2hhbmdlIGlzIHRpZWQgdG8gYSBzcGVjaWZpYyBBRUFEIG9wZXJhdGlvbi4NCiAgQ09T VDogQ3J5cHRvIGlzIG5vdCB0eXBpY2FsbHkgZG9uZSBsaWtlIHRoaXM7IHVuY2VydGFpbiBhcyB0 byB3aGF0IGV4YWN0IHNlY3VyaXR5IHByb3BlcnRpZXMgeW91IGFyZSBnZXR0aW5nLiBQZXJoYXBz IHRoZXJlIGFyZSBzb21lIHNpbWlsYXJpdGllcyB0byBOSVNUIENvbmNhdCBLREYgdGhhdCBhZGRz ICJjb250ZXh0IiB0byBrZXkgZGVyaXZhdGlvbjogdGhpcyBhZGRzICJjb250ZXh0IiBhYm91dCBh biBBRUFEIG9wZXJhdGlvbiB0byB0aGUga2V5IGV4Y2hhbmdlLg0KDQoNCkkgYWdyZWUgd2l0aCBS aWNoYXJkIEJhcm5lcyB0aGF0IHRoZSBwZXItcmVjaXBpZW50IGtleSBleGNoYW5nZSBkZXRhaWxz IHNob3VsZCBiZSBvdXRzaWRlIHRoZSBBRUFEIG9wZXJhdGlvbiAobm90IGNvdmVyZWQgYnkgdGhl IEFFQUQgaW50ZWdyaXR5IGNoZWNrKS4gR28gd2l0aCBvcHRpb24gMiBvciAyYi4NClRoZW4sIHNl cGFyYXRlbHksIHdlIGNhbiBkZWNpZGUgd2hpY2ggZGV0YWlscyBvZiB0aGUgQUVBRCBvcGVyYXRp b24gc2hvdWxkIGJlIGJvdW5kIHRvIGVhY2gga2V5IGV4Y2hhbmdlOiBub25lPyBBRUFEIGtleSBs ZW5ndGg/IEFFQUQgYWxnIGlkPyB3aG9sZSBBRUFEIGhlYWRlcj8gQUVBRCBjaXBoZXJ0ZXh0PyBv dGhlciBjb250ZXh0Pw0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KPiAtLS0tLS0tLS0tDQo+IEZy b206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IFJpY2hhcmQgQmFybmVzDQo+IFNlbnQ6IFdlZG5lc2RheSwgMyBBcHJp bCAyMDEzIDQ6NTUgQU0NCj4g4oCmIA0KPiBUaGUgcHJvYmxlbSBoZXJlIGlzIEpXRSwgc3BlY2lm aWNhbGx5IHRoZSBmYWN0IHRoYXQgdGhlIGhlYWRlciAod2l0aA0KPiBwZXItcmVjaXBpZW50IGRh dGEpIGlzIGNvdmVyZWQgYnkgdGhlIGludGVncml0eSBjaGVjay4gIElmIHlvdSByZW1vdmUNCj4g dGhlIHBlci1yZWNpcGllbnQgZGF0YSBmcm9tIHRoZSBpbnRlZ3JpdHkgY2hlY2ssIHRoZW4gdGhp cyBwcm9ibGVtIGdvZXMNCj4gYXdheS4gIEluIHRoYXQgY2FzZSwgdGhlcmUgaXMgb25seSBvbmUg aW52b2NhdGlvbiBvZiBHQ00gKG5vdCBvbmUgcGVyDQo+IHJlY2lwaWVudCksIHNvIHRoZXJlJ3Mg bm8gcHJvYmxlbS4NCj4gDQo+IFNvIHRoZSBjaG9pY2UgdGhhdCBKT1NFIGZhY2VzIGlzIGZyb20g dGhlIGZvbGxvd2luZyBvcHRpb25zOg0KPiANCj4gT3B0aW9uIDAuIE91dGxhdyBHQ00gZm9yIG11 bHRpcGxlIHJlY2lwaWVudHMuDQo+ICAgQ09TVDogR0NNDQo+IA0KPiBPcHRpb24gMS4gS2VlcCBw ZXItcmVjaXBpZW50IGluZm8gdW5kZXIgaW50ZWdyaXR5IGNoZWNrLCBhbmQgcmVxdWlyZSBhDQo+ IGZyZXNoIG5vbmNlIGZvciBlYWNoIHJlY2lwaWVudA0KPiAgIENPU1Q6IFJlbW92ZXMgYWxsIHNh dmluZ3MgaW4gdGhlIG11bHRpcGxlIHJlY2lwaWVudCBjYXNlDQo+ICAgQkVORUZJVDogRG9lc24n dCBicmVhayBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggY3VycmVudCwgc2luZ2xlLQ0KPiBy ZWNpcGllbnQgSldFDQo+IA0KPiBPcHRpb24gMi4gUmVtb3ZlIHBlci1yZWNpcGllbnQgaW5mbyBm cm9tIGludGVncml0eSBjaGVjaw0KPiAgIENPU1Q6IEJyZWFrcyBiYWNrd2FyZCBjb21wYXRpYmls aXR5IHdpdGggY3VycmVudCwgc2luZ2xlLXJlY2lwaWVudA0KPiBKV0UNCj4gICBCRU5FRklUOiBJ bmNyZWFzZXMgc2F2aW5ncyBpbiBtdWx0aXBsZS1yZWNpcGllbnQgY2FzZSAoc2luY2Ugbm8gcGVy LQ0KPiByZWNpcGllbnQgaW50ZWdyaXR5IGNoZWNrIHZhbHVlKQ0KPiANCj4gT3B0aW9uIDAgaXMg Y2xlYXJseSBub3QgYWNjZXB0YWJsZS4gIFNvIGJhc2ljYWxseSwgdGhpcyBpcyBhIGNob2ljZQ0K PiBhYm91dCBob3cgbXVjaCB3ZSB3YW50IHRvIGxldCBkZXBsb3llZCBjb2RlIGtlZXAgdXMgZnJv bSBzZW5zaWJsZQ0KPiBhcmNoaXRlY3R1cmUuDQo+IA0KPiBUbyBtZSwgdGhlIGNob2ljZSBpcyBj bGVhci4gIENoYW5naW5nIGNvZGUgaXMgbWlub3IsIHNob3J0LXRlcm0gcGFpbi4NCj4gR2V0dGlu ZyBhcmNoaXRlY3R1cmUgd3JvbmcgaXMgbWFqb3IsIGxvbmctdGVybSBwYWluLiAgTGV0J3MgZG8g b3B0aW9uDQo+ICgyKS4NCg== From rlb@ipv.sx Mon Apr 15 08:25:58 2013 Return-Path: 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 C4DDF21F93EC for ; Mon, 15 Apr 2013 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SWwKenM-8uqa for ; Mon, 15 Apr 2013 08:25:57 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5E621F93C8 for ; Mon, 15 Apr 2013 08:25:57 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id j1so4534527oag.21 for ; Mon, 15 Apr 2013 08:25:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wli3klY2CK5b1cQr/cy4xn7tq3cRaTccszlY4OcknZo=; b=NK2PAkxNmSiqH7n+SRw6JO5GXTXBfVZG8rWGiuV/L+Dc2HmuYtmEgpzjue96+cH31I ZnPsc77VS9qL8lHcUmz/l7NfFXbvGM/D7iPFFfKabuRuwqN/NOhk1f/t4C2x/5pU/Qzz mxGBT3Bk6dM9sn/J+sEJKTQ89DvJGQHulG3DTnUNkn2DKKAxTcucgHBNlBvecrk5FsNz +W5i+IwSMOZcJQz9SfsfrQ3EYJqkLUvR3cII6acmGyr3XmK57OzuHF9W+uX5tUeSofM5 va4uVL+WJarIIDy/Ky4zbToaIctRH2/5ZqhxzjUTb1ySGzEy4vb6GlAod22GPWF7/pKv F5UQ== MIME-Version: 1.0 X-Received: by 10.60.62.39 with SMTP id v7mr2429326oer.5.1366039556989; Mon, 15 Apr 2013 08:25:56 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 08:25:56 -0700 (PDT) X-Originating-IP: [66.207.95.33] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.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> <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 15 Apr 2013 11:25:56 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=089e013a005a8b409104da67dec7 X-Gm-Message-State: ALoCoQkdvqFjBZtUfLXxgQCs+kYWoRnjcQYDP+jI5kG1l+aILWv8FVMQGb5l1qc7HRINI6rYhC8T Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] GCM nonce reuse question X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:25:58 -0000 --089e013a005a8b409104da67dec7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > I think there are more options for handling multiple recipients of > AEAD-secured content: > > > Option 3: Put all per-recipient info into one header; keep this header > under the AEAD integrity check; have one nonce. > COST: All recipients need to be known (and their key exchange info > created) before the AEAD algorithm is applied. > COST: The JWE JSON header structure needs to be adjusted (eg to have an > array of recipient info) so it is not backward compatible with current > drafts. > COST: Doesn't help use cases where one recipient forwards an > AEAD-secured message on to a new recipient (eg an XMPP system receives a > message secured for a user and re-secures it for a specific device of tha= t > user). Changing recipients requires reapplying the AEAD operations. > COST: Each recipient needs to see key exchange info of all recipients > (privacy impact?). > POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is > secured as a complete unit. > > > Option 2b: Remove per-recipient info from AEAD integrity check; but add > AEAD details to each key exchange. For instance, info about an AEAD > operation (alg id, key id etc) potentially even including the whole > ciphertext is used as the "label" for the RSAES-OAEP-ENCRYPT operation th= at > encrypts the AEAD secret key for a recipient. > BENEFIT: The key exchange is tied to a specific AEAD operation. > COST: Crypto is not typically done like this; uncertain as to what exac= t > security properties you are getting. Perhaps there are some similarities = to > NIST Concat KDF that adds "context" to key derivation: this adds "context= " > about an AEAD operation to the key exchange. > > > I agree with Richard Barnes that the per-recipient key exchange details > should be outside the AEAD operation (not covered by the AEAD integrity > check). Go with option 2 or 2b. > Then, separately, we can decide which details of the AEAD operation shoul= d > be bound to each key exchange: none? AEAD key length? AEAD alg id? whole > AEAD header? AEAD ciphertext? other context? > > > -- > James Manger > > Hey James, Thanks for this. I agree that Option 3 is a valid possibility, but not a desirable one. Option 2b is an interesting possibility. Effectively, you would be including a hash of the JWE (sans key) under the key wrap integrity check, binding the key to the JWE. I would note that we're already talking about adding the ability to bind attributes to wrapped keys (for WebCrypto). In light of that, the "JWE digest" could just be included as one of those attributes. At the same time, this attribute should be optional, since I think there are use cases where the CMK is not entirely ephemeral. For example, I think the current XMPP e2e document uses it as a session key rather than an individual message key, so you wouldn't want to limit the key to a single JWE. So I think that lands us back at Option 2, with one more reason to make JWE key wrapping the same as general key wrapping [draft-barnes-jose-key-wrapping]. --Richard > > ---------- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Richard Barnes > > Sent: Wednesday, 3 April 2013 4:55 AM > > =85 > > The problem here is JWE, specifically the fact that the header (with > > per-recipient data) is covered by the integrity check. If you remove > > the per-recipient data from the integrity check, then this problem goes > > away. In that case, there is only one invocation of GCM (not one per > > recipient), so there's no problem. > > > > So the choice that JOSE faces is from the following options: > > > > Option 0. Outlaw GCM for multiple recipients. > > COST: GCM > > > > Option 1. Keep per-recipient info under integrity check, and require a > > fresh nonce for each recipient > > COST: Removes all savings in the multiple recipient case > > BENEFIT: Doesn't break backward compatibility with current, single- > > recipient JWE > > > > Option 2. Remove per-recipient info from integrity check > > COST: Breaks backward compatibility with current, single-recipient > > JWE > > BENEFIT: Increases savings in multiple-recipient case (since no per- > > recipient integrity check value) > > > > Option 0 is clearly not acceptable. So basically, this is a choice > > about how much we want to let deployed code keep us from sensible > > architecture. > > > > To me, the choice is clear. Changing code is minor, short-term pain. > > Getting architecture wrong is major, long-term pain. Let's do option > > (2). > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --089e013a005a8b409104da67dec7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H <James.H.Ma= nger@team.telstra.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I think there are more options for handling multiple recipients of AEAD-sec= ured content:


Option 3: Put all per-recipient info into one header; keep this header unde= r the AEAD integrity check; have one nonce.
=A0 COST: All recipients need to be known (and their key exchange info crea= ted) before the AEAD algorithm is applied.
=A0 COST: The JWE JSON header structure needs to be adjusted (eg to have an= array of recipient info) so it is not backward compatible with current dra= fts.
=A0 COST: Doesn't help use cases where one recipient forwards an AEAD-s= ecured message on to a new recipient (eg an XMPP system receives a message = secured for a user and re-secures it for a specific device of that user). C= hanging recipients requires reapplying the AEAD operations.
=A0 COST: Each recipient needs to see key exchange info of all recipients (= privacy impact?).
=A0 POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is= secured as a complete unit.


Option 2b: Remove per-recipient info from AEAD integrity check; but add AEA= D details to each key exchange. For instance, info about an AEAD operation = (alg id, key id etc) potentially even including the whole ciphertext is use= d as the "label" for the RSAES-OAEP-ENCRYPT operation that encryp= ts the AEAD secret key for a recipient.
=A0 BENEFIT: The key exchange is tied to a specific AEAD operation.
=A0 COST: Crypto is not typically done like this; uncertain as to what exac= t security properties you are getting. Perhaps there are some similarities = to NIST Concat KDF that adds "context" to key derivation: this ad= ds "context" about an AEAD operation to the key exchange.


I agree with Richard Barnes that the per-recipient key exchange details sho= uld be outside the AEAD operation (not covered by the AEAD integrity check)= . Go with option 2 or 2b.
Then, separately, we can decide which details of the AEAD operation should = be bound to each key exchange: none? AEAD key length? AEAD alg id? whole AE= AD header? AEAD ciphertext? other context?


--
James Manger



Hey James,
Thanks for this. =A0I agree that Option 3 is a valid possibili= ty, but not a desirable one.

Option 2b is an inter= esting possibility. =A0Effectively, you would be including a hash of the JW= E (sans key) under the key wrap integrity check, binding the key to the JWE= . =A0 I would note that we're already talking about adding the ability = to bind attributes to wrapped keys (for WebCrypto). =A0In light of that, th= e "JWE digest" could just be included as one of those attributes.= =A0

At the same time, this attribute should be optional, si= nce I think there are use cases where the CMK is not entirely ephemeral. = =A0For example, I think the current XMPP e2e document uses it as a session = key rather than an individual message key, so you wouldn't want to limi= t the key to a single JWE.

So I think that lands us back at Option 2, with one mor= e reason to make JWE key wrapping the same as general key wrapping [draft-b= arnes-jose-key-wrapping].

--Richard


=A0
> ----------
> From: jose-= bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of
> Richard Barnes
> Sent: Wednesday, 3 April 2013 4:55 AM
> =85
> The problem here is JWE, specifically the fact that the header (with > per-recipient data) is covered by the integrity check. =A0If you remov= e
> the per-recipient data from the integrity check, then this problem goe= s
> away. =A0In that case, there is only one invocation of GCM (not one pe= r
> recipient), so there's no problem.
>
> So the choice that JOSE faces is from the following options:
>
> Option 0. Outlaw GCM for multiple recipients.
> =A0 COST: GCM
>
> Option 1. Keep per-recipient info under integrity check, and require a=
> fresh nonce for each recipient
> =A0 COST: Removes all savings in the multiple recipient case
> =A0 BENEFIT: Doesn't break backward compatibility with current, si= ngle-
> recipient JWE
>
> Option 2. Remove per-recipient info from integrity check
> =A0 COST: Breaks backward compatibility with current, single-recipient=
> JWE
> =A0 BENEFIT: Increases savings in multiple-recipient case (since no pe= r-
> recipient integrity check value)
>
> Option 0 is clearly not acceptable. =A0So basically, this is a choice<= br> > about how much we want to let deployed code keep us from sensible
> architecture.
>
> To me, the choice is clear. =A0Changing code is minor, short-term pain= .
> Getting architecture wrong is major, long-term pain. =A0Let's do o= ption
> (2).
_____________________________= __________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--089e013a005a8b409104da67dec7-- From rlb@ipv.sx Mon Apr 15 10:39:05 2013 Return-Path: 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 90CE021F9635 for ; Mon, 15 Apr 2013 10:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 fJAqOC-eLUrv for ; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AC4B921F9640 for ; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wc20so1314664obb.2 for ; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6xMlGhKVdhpotrFRk3uRrjKNddHS/gpb8oVoPXpCTqk=; b=ZAAfqJOyjfDK1Fp/l5cnCRFnWi3Xjc2knlghb7oX5MMnwYdto+JSj3zSK9mgQmoYyc c3Tl2BRKe3tnI0SaGWR1vOLMaoees/zfNrWnbN8/21KkJGEVHyuWhO5Ze9AVJFAIKJTq nwKphkcA6ul6Tm0xiV3ZDuFqin6F4itlcHJ+EkWvkTGKGPxhbqyVJo66EHIkg6luA7oH w1OY8dBJwqq9hNEUMj1EENEbcoEW2BqQITCrML3W5OwHbHp8ekzp202JZgGJgKT4kMMs 8oZOWxMhTsU5C+iuP8gsrCJxNfO1PgqcMq0iTrpdIGDBD25l1+EyIE6oEp9cHUAwOKYh CbzQ== MIME-Version: 1.0 X-Received: by 10.60.62.39 with SMTP id v7mr2608509oer.5.1366047544040; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 10:39:03 -0700 (PDT) X-Originating-IP: [137.54.9.111] In-Reply-To: <57A12B7F-30D2-4406-A66F-1FA0B03B4313@cisco.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> <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.com> <57A12B7F-30D2-4406-A66F-1FA0B03B4313@cisco.com> Date: Mon, 15 Apr 2013 13:39:03 -0400 Message-ID: From: Richard Barnes To: Matt Miller Content-Type: multipart/alternative; boundary=089e013a005a9bf1df04da69ba4e X-Gm-Message-State: ALoCoQk6X97/7EtYlltFo3Xnlf7DVk+kS+s8qHCNbrS6ToSyBBuG5AlOhTWN1atYFmw7XqO+FDGK Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] GCM nonce reuse question X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:39:05 -0000 --089e013a005a9bf1df04da69ba4e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 15, 2013 at 11:50 AM, Matt Miller wrote: > > On Apr 15, 2013, at 9:25 AM, Richard Barnes > wrote: > > > On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H < > > James.H.Manger@team.telstra.com> wrote: > > > >> I think there are more options for handling multiple recipients of > >> AEAD-secured content: > >> > >> > >> Option 3: Put all per-recipient info into one header; keep this header > >> under the AEAD integrity check; have one nonce. > >> COST: All recipients need to be known (and their key exchange info > >> created) before the AEAD algorithm is applied. > >> COST: The JWE JSON header structure needs to be adjusted (eg to have an > >> array of recipient info) so it is not backward compatible with current > >> drafts. > >> COST: Doesn't help use cases where one recipient forwards an > >> AEAD-secured message on to a new recipient (eg an XMPP system receives a > >> message secured for a user and re-secures it for a specific device of > that > >> user). Changing recipients requires reapplying the AEAD operations. > >> COST: Each recipient needs to see key exchange info of all recipients > >> (privacy impact?). > >> POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is > >> secured as a complete unit. > >> > >> > >> Option 2b: Remove per-recipient info from AEAD integrity check; but add > >> AEAD details to each key exchange. For instance, info about an AEAD > >> operation (alg id, key id etc) potentially even including the whole > >> ciphertext is used as the "label" for the RSAES-OAEP-ENCRYPT operation > that > >> encrypts the AEAD secret key for a recipient. > >> BENEFIT: The key exchange is tied to a specific AEAD operation. > >> COST: Crypto is not typically done like this; uncertain as to what > exact > >> security properties you are getting. Perhaps there are some > similarities to > >> NIST Concat KDF that adds "context" to key derivation: this adds > "context" > >> about an AEAD operation to the key exchange. > >> > >> > >> I agree with Richard Barnes that the per-recipient key exchange details > >> should be outside the AEAD operation (not covered by the AEAD integrity > >> check). Go with option 2 or 2b. > >> Then, separately, we can decide which details of the AEAD operation > should > >> be bound to each key exchange: none? AEAD key length? AEAD alg id? whole > >> AEAD header? AEAD ciphertext? other context? > >> > >> > >> -- > >> James Manger > >> > >> > > > > At the same time, this attribute should be optional, since I think there > > are use cases where the CMK is not entirely ephemeral. For example, I > > think the current XMPP e2e document uses it as a session key rather than > an > > individual message key, so you wouldn't want to limit the key to a single > > JWE. > > > > XMPP e2e has both a session key and a per-message key. The per-message key > is protected by the session key. > > That said, I also think Option 2 or 2b makes the most sense. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > Thanks for the clarification. I think the point stands, however, that the "JWE-digest" attribute can be added as a protected attribute to the wrapped key -- if we do wrapped keys right! --Richard --089e013a005a9bf1df04da69ba4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 11:50 AM, Matt Miller <mamille2@cisco.com>= wrote:

On Apr 15, 2013, at 9:25 AM, Richard Barnes <rlb@ipv.sx>
=A0wrote:

> On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H <
> James.H.Manger@team= .telstra.com> wrote:
>
>> I think there are more options for handling multiple recipients of=
>> AEAD-secured content:
>>
>>
>> Option 3: Put all per-recipient info into one header; keep this he= ader
>> under the AEAD integrity check; have one nonce.
>> =A0COST: All recipients need to be known (and their key exchange i= nfo
>> created) before the AEAD algorithm is applied.
>> =A0COST: The JWE JSON header structure needs to be adjusted (eg to= have an
>> array of recipient info) so it is not backward compatible with cur= rent
>> drafts.
>> =A0COST: Doesn't help use cases where one recipient forwards a= n
>> AEAD-secured message on to a new recipient (eg an XMPP system rece= ives a
>> message secured for a user and re-secures it for a specific device= of that
>> user). Changing recipients requires reapplying the AEAD operations= .
>> =A0COST: Each recipient needs to see key exchange info of all reci= pients
>> (privacy impact?).
>> =A0POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and co= ntent is
>> secured as a complete unit.
>>
>>
>> Option 2b: Remove per-recipient info from AEAD integrity check; bu= t add
>> AEAD details to each key exchange. For instance, info about an AEA= D
>> operation (alg id, key id etc) potentially even including the whol= e
>> ciphertext is used as the "label" for the RSAES-OAEP-ENC= RYPT operation that
>> encrypts the AEAD secret key for a recipient.
>> =A0BENEFIT: The key exchange is tied to a specific AEAD operation.=
>> =A0COST: Crypto is not typically done like this; uncertain as to w= hat exact
>> security properties you are getting. Perhaps there are some simila= rities to
>> NIST Concat KDF that adds "context" to key derivation: t= his adds "context"
>> about an AEAD operation to the key exchange.
>>
>>
>> I agree with Richard Barnes that the per-recipient key exchange de= tails
>> should be outside the AEAD operation (not covered by the AEAD inte= grity
>> check). Go with option 2 or 2b.
>> Then, separately, we can decide which details of the AEAD operatio= n should
>> be bound to each key exchange: none? AEAD key length? AEAD alg id?= whole
>> AEAD header? AEAD ciphertext? other context?
>>
>>
>> --
>> James Manger
>>
>>
>
> At the same time, this attribute should = be optional, since I think there
> are use cases where the CMK is not entirely ephemeral. =A0For example,= I
> think the current XMPP e2e document uses it as a session key rather th= an an
> individual message key, so you wouldn't want to limit the key to a= single
> JWE.
>

XMPP e2e has both a session key and a per-message key. The per-messag= e key is protected by the session key.

That said, I also think Option 2 or 2b makes the most sense.


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.



--Richard
=A0
--089e013a005a9bf1df04da69ba4e-- From prvs=3817aad607=dbrown@certicom.com Mon Apr 15 13:33:56 2013 Return-Path: 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 BBBA121F93A9 for ; Mon, 15 Apr 2013 13:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 jRwOT5l2EhFv for ; Mon, 15 Apr 2013 13:33:56 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7D21F93A5 for ; Mon, 15 Apr 2013 13:33:55 -0700 (PDT) X-AuditID: 0a412830-b7fdc6d000006f8d-f8-516c6425f7ed Received: from XCT107CNC.rim.net (xct107cnc.rim.net [10.65.161.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 32.08.28557.5246C615; Mon, 15 Apr 2013 15:33:42 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 16:33:41 -0400 From: Dan Brown To: "'Igoe, Kevin M.'" , "'cfrg@irtf.org'" Thread-Topic: Hash substitution in PSS Thread-Index: Ac42293JdF4quuUXQ1KmUJ+FVnLXSwDOuAqA Date: Mon, 15 Apr 2013 20:33:40 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513FF48@XMB111CNC.rim.net> References: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsXC5bjwvK5aSk6gwdMnLBbdPw4yWUw49ZrV gclj8sbDbB79u16yBjBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejOkXGpgLFvNXHJ/7n6mBcQ1PFyMnh4SAicS5hW/Z IGwxiQv31gPZXBxCAu1MEp3bX0E5Wxkl3q5uYAepYhNQlbh/9BwziC0i4CWx/+pXVhBbGCj+ dNIiVoi4msTfnf1QtpHE/ZUfwWwWoJqj93eB2bwCbhLzT65lAbGFBIIktn7/CDafUyBYon/r erAaRgFZid1nrzOB2MwC4hK3nsxngrhUQGLJnvPMELaoxMvH/1ghbEWJF5PPsUDU60gs2P2J DcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjYG5GsYGZYXJesl5RZq5e XmrJJkZwQtAw2MH4/r3FIUYBDkYlHt4FyTmBQqyJZcWVuYcYJTiYlUR4j3MAhXhTEiurUovy 44tKc1KLDzG6AkNlIrMUd3I+MFnllcQbGxjg5iiJ8/IzZQQKCaQD0092ampBahHMHCYOTpA9 XFIixcAkklqUWFqSEQ9KdfHFwGQn1cAYzfv6IfeLGz/n3I+dv9y5I/6dV4rSszk929qrLkxs f7/07ZP2D46fv+ncPqkww3WekOVP3YsS9/YI3+RIyfqVdDQjWFqET2HK2uwPX+9bXco8ouTp sIDnYsCD5UxbuDvvu/117jnrayfh3JW/1nr16xPpod5Xf7j+nbR6oaTD1QULymu/MFueUmIp zkg01GIuKk4EAMojXElJAwAA Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:33:56 -0000 Hi Kevin, Somehow, I missed Kaliski's paper from CT-RSA 2002 [even though it is a refe= rence in PKCS #1 ver. 2.1!]: you may wish to consider Kaliski's argument why= RSA-PSS does not need a hash firewall, and his general recommendations abou= t algorithm authentication (via the infrastructure, not the message). I thi= nk the Kaliski paper shows that the issue was considered carefully, and not= just something that was forgotten and fell through the cracks. Best regards, Dan PS My view on the issue has not changed much. Overall, it is somewhat diff= erent from Kaliski's, although our conclusions for PSS are similar. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Igoe, Kevin M. > Sent: Thursday, April 11, 2013 1:42 PM > To: 'cfrg@irtf.org' > Subject: [Cfrg] Hash substitution in PSS > > On 4 August Jim Schaad pointed out that the choice of hash algorithm in > PSS is not authenticated and asked if this was a security problem. > > The good news is that if all of the hash algorithms in use are > "secure", the only risk is the "birthday problem", and the aVailability > of more than one hash does not a priori result in a cheaper attack. > > The bad news is that if one of the hashes is broken, so broken that an > adversary has a non-trivial chance of finding an "evil" message that > has the same hash value as a benign message formed with a hash that is > "secure", they can substitute the evil message under the weak hash for > the benign message under the strong hash. Preventing this requires > either that (1) the have a policy to reject all messages with the weak > hash or (2) the choice of hash algorithm be authenticated. Personally I > trust a cryptographic authentication over policy. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ietf@augustcellars.com Mon Apr 15 21:29:32 2013 Return-Path: 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 1884221F93E0 for ; Mon, 15 Apr 2013 21:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 1J5uqWFTfRGW for ; Mon, 15 Apr 2013 21:29:31 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2021F8FDD for ; Mon, 15 Apr 2013 21:29:31 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 180D938F06; Mon, 15 Apr 2013 21:29:29 -0700 (PDT) From: "Jim Schaad" To: "'Dan Brown'" , "'Igoe, Kevin M.'" , References: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> <810C31990B57ED40B2062BA10D43FBF513FF48@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF513FF48@XMB111CNC.rim.net> Date: Mon, 15 Apr 2013 21:28:45 -0700 Message-ID: <02fe01ce3a5a$e4be2fa0$ae3a8ee0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFRO5hdY8mJN2fmJDw36gG0Cb0zFQHVXziYmcORjvA= Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 04:29:32 -0000 Dan, I will note that almost none of the recommendations in this paper would appear to have made it into practice and in fact are actively suppressed There is no requirement in any standard that I have seen that says that the hash function for the mask generation and that hash function for the body compression match. There is no requirement that the set of hash algorithms for a PSS RSA key be included in a certificate (in fact it is currently actively precluded from happening). While interesting in theory, I find the argument made for the creation of a new weak hash function id to be one that would be difficult to get the real-world to accept. And note that without this extension of the attack there is a strong defense imposed by RSA v1.5 signatures by having the firewall present. Finally, I know of no research that says that the birthday attack cannot be improved by allowing multiple hash functions to be used in the RSA-PSS, DSA or ECDSA cases where there is no hash firewall even in the presence of accepting only strong hash functions. I am far less interested in the case of accepting known weak hash functions. (Although there is still the problem of accepting weak hash functions which are thought to be strong.) Jim > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan > Brown > Sent: Monday, April 15, 2013 1:34 PM > To: 'Igoe, Kevin M.'; 'cfrg@irtf.org' > Subject: Re: [Cfrg] Hash substitution in PSS > > Hi Kevin, > > Somehow, I missed Kaliski's paper from CT-RSA 2002 [even though it is a > reference in PKCS #1 ver. 2.1!]: you may wish to consider Kaliski's argument > why RSA-PSS does not need a hash firewall, and his general recommendations > about algorithm authentication (via the infrastructure, not the message). I > think the Kaliski paper shows that the issue was considered carefully, and not > just something that was forgotten and fell through the cracks. > > Best regards, > > Dan > > PS My view on the issue has not changed much. Overall, it is somewhat > different from Kaliski's, although our conclusions for PSS are similar. > > > -----Original Message----- > > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > > Of Igoe, Kevin M. > > Sent: Thursday, April 11, 2013 1:42 PM > > To: 'cfrg@irtf.org' > > Subject: [Cfrg] Hash substitution in PSS > > > > On 4 August Jim Schaad pointed out that the choice of hash algorithm > > in PSS is not authenticated and asked if this was a security problem. > > > > The good news is that if all of the hash algorithms in use are > > "secure", the only risk is the "birthday problem", and the > > aVailability of more than one hash does not a priori result in a cheaper > attack. > > > > The bad news is that if one of the hashes is broken, so broken that an > > adversary has a non-trivial chance of finding an "evil" message that > > has the same hash value as a benign message formed with a hash that is > > "secure", they can substitute the evil message under the weak hash for > > the benign message under the strong hash. Preventing this requires > > either that (1) the have a policy to reject all messages with the weak > > hash or (2) the choice of hash algorithm be authenticated. Personally > > I trust a cryptographic authentication over policy. > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the solicitor- > client or other applicable privileges), or constitute non-public information. > Any use of this information by anyone other than the intended recipient is > prohibited. If you have received this transmission in error, please immediately > reply to the sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From kmigoe@nsa.gov Mon Apr 29 10:59:25 2013 Return-Path: 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 8335921F9ACD for ; Mon, 29 Apr 2013 10:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3e3LwRo+gV2W for ; Mon, 29 Apr 2013 10:59:21 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id E0FB721F9ACB for ; Mon, 29 Apr 2013 10:59:20 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id b662252d0012c2ff ; Mon, 29 Apr 2013 14:01:43 -0400 Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 29 Apr 2013 13:58:55 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.01.0289.001; Mon, 29 Apr 2013 13:58:55 -0400 From: "Igoe, Kevin M." To: 'Jim Schaad' , 'Dan Brown' , "cfrg@irtf.org" Thread-Topic: [Cfrg] Hash substitution in PSS Thread-Index: Ac42293JdF4quuUXQ1KmUJ+FVnLXSwDOuAqAABlqu4ACoYaesA== Date: Mon, 29 Apr 2013 17:58:54 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA9C969027@MSMR-GH1-UEA03.corp.nsa.gov> References: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> <810C31990B57ED40B2062BA10D43FBF513FF48@XMB111CNC.rim.net> <02fe01ce3a5a$e4be2fa0$ae3a8ee0$@augustcellars.com> In-Reply-To: <02fe01ce3a5a$e4be2fa0$ae3a8ee0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.224.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 17:59:25 -0000 Under the assumption that the two hash functions behave as independent rand= om functions, the birthday problem isn't affected if more than one hash functi= ons is allowed. This falls apart if the two hash functions are related, say the s= ame=20 compression function used in each, but with different initial fills. > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Tuesday, April 16, 2013 12:29 AM > To: 'Dan Brown'; Igoe, Kevin M.; cfrg@irtf.org > Subject: RE: [Cfrg] Hash substitution in PSS >=20 > Dan, >=20 > I will note that almost none of the recommendations in this paper would > appear to have made it into practice and in fact are actively > suppressed >=20 > There is no requirement in any standard that I have seen that says that > the > hash function for the mask generation and that hash function for the > body > compression match. >=20 > There is no requirement that the set of hash algorithms for a PSS RSA > key be > included in a certificate (in fact it is currently actively precluded > from > happening). >=20 > While interesting in theory, I find the argument made for the creation > of a > new weak hash function id to be one that would be difficult to get the > real-world to accept. And note that without this extension of the > attack > there is a strong defense imposed by RSA v1.5 signatures by having the > firewall present. >=20 > Finally, I know of no research that says that the birthday attack > cannot be > improved by allowing multiple hash functions to be used in the RSA-PSS, > DSA > or ECDSA cases where there is no hash firewall even in the presence of > accepting only strong hash functions. I am far less interested in the > case > of accepting known weak hash functions. (Although there is still the > problem of accepting weak hash functions which are thought to be > strong.) >=20 > Jim >=20 >=20 > > -----Original Message----- > > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > Of > Dan > > Brown > > Sent: Monday, April 15, 2013 1:34 PM > > To: 'Igoe, Kevin M.'; 'cfrg@irtf.org' > > Subject: Re: [Cfrg] Hash substitution in PSS > > > > Hi Kevin, > > > > Somehow, I missed Kaliski's paper from CT-RSA 2002 [even though it is > a > > reference in PKCS #1 ver. 2.1!]: you may wish to consider Kaliski's > argument > > why RSA-PSS does not need a hash firewall, and his general > recommendations > > about algorithm authentication (via the infrastructure, not the > message). > I > > think the Kaliski paper shows that the issue was considered > carefully, and > not > > just something that was forgotten and fell through the cracks. > > > > Best regards, > > > > Dan > > > > PS My view on the issue has not changed much. Overall, it is > somewhat > > different from Kaliski's, although our conclusions for PSS are > similar. > > > > > -----Original Message----- > > > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On > Behalf > > > Of Igoe, Kevin M. > > > Sent: Thursday, April 11, 2013 1:42 PM > > > To: 'cfrg@irtf.org' > > > Subject: [Cfrg] Hash substitution in PSS > > > > > > On 4 August Jim Schaad pointed out that the choice of hash > algorithm > > > in PSS is not authenticated and asked if this was a security > problem. > > > > > > The good news is that if all of the hash algorithms in use are > > > "secure", the only risk is the "birthday problem", and the > > > aVailability of more than one hash does not a priori result in a > cheaper > > attack. > > > > > > The bad news is that if one of the hashes is broken, so broken that > an > > > adversary has a non-trivial chance of finding an "evil" message > that > > > has the same hash value as a benign message formed with a hash that > is > > > "secure", they can substitute the evil message under the weak hash > for > > > the benign message under the strong hash. Preventing this requires > > > either that (1) the have a policy to reject all messages with the > weak > > > hash or (2) the choice of hash algorithm be authenticated. > Personally > > > I trust a cryptographic authentication over policy. > > > _______________________________________________ > > > Cfrg mailing list > > > Cfrg@irtf.org > > > http://www.irtf.org/mailman/listinfo/cfrg > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain > confidential > > information, privileged material (including material protected by the > solicitor- > > client or other applicable privileges), or constitute non-public > information. > > Any use of this information by anyone other than the intended > recipient is > > prohibited. If you have received this transmission in error, please > immediately > > reply to the sender and delete this information from your system. > Use, > > dissemination, distribution, or reproduction of this transmission by > > unintended recipients is not authorized and may be unlawful. > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg From prvs=3831be4b0f=dbrown@certicom.com Mon Apr 29 12:28:02 2013 Return-Path: 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 0A88721F9B25 for ; Mon, 29 Apr 2013 12:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_ALI=1.666] 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 Fau8tQ8GmseN for ; Mon, 29 Apr 2013 12:27:57 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B9F4321F9B23 for ; Mon, 29 Apr 2013 12:27:56 -0700 (PDT) X-AuditID: 0a41282f-b7f326d000005ad9-e2-517ec9ae84c1 Received: from XCT107CNC.rim.net (xct107cnc.rim.net [10.65.161.207]) by mhs060cnc.rim.net (SBG) with SMTP id FC.E7.23257.EA9CE715; Mon, 29 Apr 2013 14:27:42 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 15:27:42 -0400 From: Dan Brown To: 'Jim Schaad' , "'Igoe, Kevin M.'" , "cfrg@irtf.org" Thread-Topic: [Cfrg] Hash substitution in PSS Thread-Index: Ac42293JdF4quuUXQ1KmUJ+FVnLXSwDOuAqAABlqu4ACouW9cA== Date: Mon, 29 Apr 2013 19:27:41 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5144ECA@XMB111CNC.rim.net> References: <3C4AAD4B5304AB44A6BA85173B4675CA9150F119@MSMR-GH1-UEA03.corp.nsa.gov> <810C31990B57ED40B2062BA10D43FBF513FF48@XMB111CNC.rim.net> <02fe01ce3a5a$e4be2fa0$ae3a8ee0$@augustcellars.com> In-Reply-To: <02fe01ce3a5a$e4be2fa0$ae3a8ee0$@augustcellars.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsXC5bjwvO66k3WBBkuma1p0/zjIZLF6+nc2 iwmnXrM6MHtsnDOdzWPyxsNsHv27XrIGMEc1MNokJZaUBWem5+nb2STm5eWXJJakKqSkFifb KvmkpifmKAQUZZYlJlcquGQWJ+ckZuamFikpZKbYKpkoKRTkJCan5qbmldgqJRYUpOalKNlx KWAAG6CyzDyF1Lzk/JTMvHRbJc9gf10LC1NLXUMlO92ETp6M1q6jjAWPeSqeXX3N3sB4irOL kZNDQsBE4vGD/4wQtpjEhXvr2boYuTiEBFYxSjRfbGcCSQgJbGWU2HAnB8RmE1CVuH/0HDOI LSJQKNFy7gIriC0soCPx/dMbdoi4rsTzBX1QtpNEV+c7MJsFqHd12zmwmbwCbhLN2zZALTvK KDG9+zQLSIJTwEFi5fmPYBcxCshK7D57HayBWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4St KPFi8jkWiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhTM zSg2MDNIzkvWK8rM1ctLLdnECE4SGvo7GN++tzjEKMDBqMTD67ijLlCINbGsuDL3EKMEB7OS CC/bFqAQb0piZVVqUX58UWlOavEhRldgsExkluJOzgcmsLySeGMDA9wcJXHeKrfKQCGBdGD6 yU5NLUgtgpnDxMEJsodLSqQYmERSixJLSzLiQakuvhiY7KQaGA83r7Yu1TbNj3gxN/jjpg/l X+fy3GfneL97YkWT5O+EdNtdi2JmRwT5mutv99h1xvolp+F2gYLgaUZ6Kblse2fd4/u76O6F a3+ybwg/uvD89xKtxvNXLeYGRZjbis1OVn52n5NJuli7rv3/g8wZasJ8h9bITQx+ekTyO5v6 m9nOHPOUn9zxvaXEUpyRaKjFXFScCABzoWogUwMAAA== Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:28:02 -0000 > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Tuesday, April 16, 2013 12:29 AM > > There is no requirement that the set of hash algorithms for a PSS RSA > key be > included in a certificate (in fact it is currently actively precluded > from > happening). > [DB] RFC 5756 says "When the id-RSASSA-PSS object identifier appears in the TBSCertificate subjectPublicKeyInfo algorithm field of EE certificates, then the parameters field MAY include the RSASSA- PSS-params structure." RFC 4055 says "RSASSA-PSS-params ::=3D SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 }" So, I agree with you that there is no requirement to identify RSA-PSS hash a= lgs, but I disagree that it is precluded: because the way I read 5756 says t= hat it is optional, not precluded. What am I missing? For ECDSA: I agree that 5480 precludes placing hash restriction for ECDSA in= a certificate. I, as a 5480 co-author, only reluctantly agreed to this pre= clusion (based on some survey comments and interoperability issues). Meanwh= ile, SEC1 offers an optional ASN.1 syntax that does allow hash-restriction,= for the signers and verifiers who, rather nervously, want to retain assuran= ce, for the long-term, against a hypothetical flaw in a hash, such as SHA1.= --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pgut001@cs.auckland.ac.nz Tue Apr 30 09:44:01 2013 Return-Path: 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 3409021F9C4A for ; Tue, 30 Apr 2013 09:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_OBFU_PART_ALI=1.666] 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 nsza4ripg1yx for ; Tue, 30 Apr 2013 09:43:56 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id D70F221F9BFD for ; Tue, 30 Apr 2013 09:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1367340236; x=1398876236; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GRZLH97tVVWr/6vaq4l9UIXlt69qCxWFDT1IuIWohR8=; b=trDOoJphrqC6Y9MSX3dKtj5Of6OsaYQOtDDl/xSimnp8FF7hQuPTCEIc 7ZqTWbmDS+56+Sy6AiJNcebulP2X+IN3+8vOra8uKSTeEEzgM+uxLzLQh Xdn3zCZgPSido/2X4AV6nhjwchaFbvJM/cDT9GBVJJmKpX6qrRTqBWjBn A=; X-IronPort-AV: E=Sophos;i="4.87,582,1363086000"; d="scan'208";a="183911555" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 01 May 2013 04:43:52 +1200 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.4]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Wed, 1 May 2013 04:43:51 +1200 From: Peter Gutmann To: 'Jim Schaad' , "'Igoe, Kevin M.'" , "cfrg@irtf.org" Thread-Topic: [Cfrg] Hash substitution in PSS Thread-Index: Ac5FweRPICwc2zGqQxWHo+99HFzt9g== Date: Tue, 30 Apr 2013 16:43:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D49137@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 16:44:01 -0000 Dan Brown writes:=0A= =0A= >[DB] RFC 5756 says "When the id-RSASSA-PSS object identifier=0A= > appears in the TBSCertificate subjectPublicKeyInfo algorithm field of= =0A= > EE certificates, then the parameters field MAY include the RSASSA-=0A= > PSS-params structure."=0A= >=0A= >RFC 4055 says "RSASSA-PSS-params ::=3D SEQUENCE {=0A= > hashAlgorithm [0] HashAlgorithm DEFAULT=0A= > sha1Identifier,=0A= > maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT=0A= > mgf1SHA1Identifier,=0A= > saltLength [2] INTEGER DEFAULT 20,=0A= > trailerField [3] INTEGER DEFAULT 1 }"=0A= =0A= I think the problem is with RFC 4055, it should have either made the entire= =0A= sequence optional if all-defaults are used or otherwise constrained it so t= hat=0A= at least one element must be present (making it non-optional). At the mome= nt=0A= the sequence (via its ASN.1 definition) is non-optional but every parameter= is=0A= optional. OTOH the text then makes it optional, except when it's not. It'= s a=0A= bit of a mess (uh, sorry Jim :-), I can see implementers arguing over whose= =0A= interpretation is correct...=0A= =0A= Peter.=0A= From housley@vigilsec.com Tue Apr 30 10:11:53 2013 Return-Path: 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 01A4D21F9BFD for ; Tue, 30 Apr 2013 10:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.933 X-Spam-Level: X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_OBFU_PART_ALI=1.666, 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 Q6P8kL90-3d4 for ; Tue, 30 Apr 2013 10:11:46 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id BDF9E21F9AD8 for ; Tue, 30 Apr 2013 10:11:46 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C4FB5F24078; Tue, 30 Apr 2013 13:11:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id vtYEdbSKd9yB; Tue, 30 Apr 2013 13:11:42 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5F388F2407D; Tue, 30 Apr 2013 13:11:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D49137@uxcn10-tdc02.UoA.auckland.ac.nz> Date: Tue, 30 Apr 2013 13:11:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C7343D49137@uxcn10-tdc02.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1085) Cc: IRTF CFRG Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 17:11:53 -0000 Peter: >> [DB] RFC 5756 says "When the id-RSASSA-PSS object identifier >> appears in the TBSCertificate subjectPublicKeyInfo algorithm field = of >> EE certificates, then the parameters field MAY include the RSASSA- >> PSS-params structure." >>=20 >> RFC 4055 says "RSASSA-PSS-params ::=3D SEQUENCE { >> hashAlgorithm [0] HashAlgorithm DEFAULT >> sha1Identifier, >> maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT >> mgf1SHA1Identifier, >> saltLength [2] INTEGER DEFAULT 20, >> trailerField [3] INTEGER DEFAULT 1 }" >=20 > I think the problem is with RFC 4055, it should have either made the = entire > sequence optional if all-defaults are used or otherwise constrained it = so that > at least one element must be present (making it non-optional). At the = moment > the sequence (via its ASN.1 definition) is non-optional but every = parameter is > optional. OTOH the text then makes it optional, except when it's not. = It's a > bit of a mess (uh, sorry Jim :-), I can see implementers arguing over = whose > interpretation is correct... This is aligned with PKCS#1. Yes, it would be ideal for the whole thing = to be NULL if all of the values are DEFAULT, but that is not the way = PKCS#1 did it. Russ From prvs=383211b764=dbrown@certicom.com Tue Apr 30 10:39:18 2013 Return-Path: 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 6359121F9AAA for ; Tue, 30 Apr 2013 10:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_ALI=1.666] 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 81-clo5W5312 for ; Tue, 30 Apr 2013 10:39:13 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0421F9A6A for ; Tue, 30 Apr 2013 10:39:12 -0700 (PDT) X-AuditID: 0a41282f-b7f326d000005ad9-57-518001b369df Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) by mhs060cnc.rim.net (SBG) with SMTP id 7B.73.23257.3B100815; Tue, 30 Apr 2013 12:39:00 -0500 (CDT) Received: from XCT114CNC.rim.net (10.65.161.214) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 30 Apr 2013 13:38:59 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT114CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Tue, 30 Apr 2013 13:38:59 -0400 From: Dan Brown To: 'Peter Gutmann' , 'Jim Schaad' , "'Igoe, Kevin M.'" , "cfrg@irtf.org" Thread-Topic: [Cfrg] Hash substitution in PSS Thread-Index: Ac5FweRPdF4quuUXQ1KmUJ+FVnLXSwAAs6XQ Date: Tue, 30 Apr 2013 17:38:58 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF514549D@XMB111CNC.rim.net> References: <9A043F3CF02CD34C8E74AC1594475C7343D49137@uxcn10-tdc02.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D49137@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIKsWRmVeSWpSXmKPExsXC5bjwgu4WxoZAg9udnBbdPw4yWaye/p3N YsKp16wWL989Z3Vg8dg4Zzqbx8XGA0wekzceZvPo3/WSNYAlqoHRJimxpCw4Mz1P384mMS8v vySxJFUhJbU42VbJJzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/E VimxoCA1L0XJjksBA9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpJnTyZKxpuMNUcEqp YvP++AbG9VJdjJwcEgImEq3P3zBD2GISF+6tZ+ti5OIQEljFKLHkyGHWLkYOIGclo8REVYj4 HEaJ+f93gTWwCahK3D96jhkkISKwgFFi6+d9bCAJYQEdie+f3rCD2CICuhLPF/RB2UYSM7e0 g9ksQM3Lz09kBLF5Bdwkvt1rBesVEgiT2Lx+ByuIzSkQLvFxzzcWEJtRQFZi99nrTCA2s4C4 xK0n85kgrhaQWLLnPNQHohIvH/9jhbAVJV5MPscCUa8jsWD3JzYIW1ti2cLXzBB7BSVOznzC ArFXQeLK9X0sExjFZyFZMQtJ+ywk7bOQtC9gZFnFKJibUWxgZpCcl6xXlJmrl5dasokRnGY0 9Hcwvn1vcYhRgINRiYfX4k19oBBrYllxZe4hRgkOZiURXp+HQCHelMTKqtSi/Pii0pzU4kOM rsAQmsgsxZ2cD0yBeSXxxgYGuDlK4rxVbpWBQgLpwGSVnZpakFoEM4eJgxNkD5eUSDEw5aQW JZaWZMSDEmN8MTA1SjUwLj286vS2P8psDRenX9/vLif/SH6F44xVZ8WSrI5/eG2/V+m33KfV e5/vOLE4V1r9+mOHJjFlBuFXVbK1WxmFIvaYLVudvTNwlYBf96S57s86T28vf9hReNDXxlrF PWj12m7J+eq7N+jEOyX4uc7NWB8wofH87L59KveeP3VI6VmkWGzO/LrRXImlOCPRUIu5qDgR AMd2DDF0AwAA Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 17:39:18 -0000 This part of the thread has diverged from crypto. It should probably go on= the PKIX mailing list instead. It mainly concerns interpreting ASN.1, not= whether particular actions have security benefits. For now, I respond belo= w, just trying to establish what PKIX says about PSS hash algorithm identifi= cation in certificates (and then CFRG can discuss its merits). > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Peter Gutmann > Dan Brown writes: > > >[DB] RFC 5756 says "When the id-RSASSA-PSS object identifier > > appears in the TBSCertificate subjectPublicKeyInfo algorithm field > of > > EE certificates, then the parameters field MAY include the RSASSA- > > PSS-params structure." > > > >RFC 4055 says "RSASSA-PSS-params ::=3D SEQUENCE { > > hashAlgorithm [0] HashAlgorithm DEFAULT > > sha1Identifier, > > maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT > > mgf1SHA1Identifier, > > saltLength [2] INTEGER DEFAULT 20, > > trailerField [3] INTEGER DEFAULT 1 }" > > I think the problem is with RFC 4055, it should have either made the entir= e > sequence optional if all-defaults are used or otherwise constrained it so= that > at least one element must be present (making it non-optional). At the mom= ent > the sequence (via its ASN.1 definition) is non-optional but every paramete= r is > optional. OTOH the text then makes it optional, except when it's not. > It's a bit of a mess (uh, sorry Jim :-), I can see implementers arguing ov= er > whose interpretation is correct... > [DB] RFC 3280 says " An algorithm identifier is defined by the following A= SN.1 structure: AlgorithmIdentifier ::=3D SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }" and " SubjectPublicKeyInfo ::=3D SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }" so, the optionality of the parameters for the algorithm associated with a ke= y inside a cert is also present in the ASN.1 definition, not just the text.= The text in 5756 simply says that parameters remain optional. DEFAULT does not mean OPTIONAL in meaning, only in encoding. So, when RSASS= A-PSS-params is included in AlgorithmIdentifier and BER or DER encoded as a= sequence of no elements, then the abstract value should be taken as the def= ault values. In fact, if I understand ASN.1 correctly, DER requires omissio= n of DEFAULT elements (when the abstract value has the default elements). Y= es, it does seem weird, changes in tag and length octets only could have a s= uch drastic change in value (this might be argument for avoiding DEFAULT ...= ). RFC 4055 says " 3. The key is identified by the id-RSASSA-PSS signature a= lgorithm identifier and the parameters are present. In this case all parameters in the signature structure algorithm identifier MUST match the parameters in the key structure algorithm identifier except the saltLength field. The saltLength field in the signature parameters MUST be greater or equal to that in the key parameters field." This requires checking consistency between the RSA-PSS cert and the RSA-PSS= signature (independently of whether DEFAULT elements are encoded or not.) I do not see much of a problem in this at all (let alone a preclusion of has= h-checking). Yes, it is still optional both in the text and the ASN.1. Perhaps things could be a little clearer: The relevant portions of other RF= Cs could have been quoted, so that the final RFC contained all necessary ASN= .1 to be able to parse things. The ASN.1 field optionality may not be a cle= ar enough mechanism for optionality of certain algorithm steps (like item 3= above from RFC 4055), maybe an additional flag ASN.1 field like requirePara= meterChecking could have inserted somewhere. I agree that implementers could argue over this, especially if they miss out= parts of the specifications (which is easy to do, and thus the clarificatio= ns I suggested), or they have already deployed this, or they don't see the n= eed, etc. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From housley@vigilsec.com Tue Apr 30 11:06:26 2013 Return-Path: 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 4DB7821F97D2 for ; Tue, 30 Apr 2013 11:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.183 X-Spam-Level: X-Spam-Status: No, score=-102.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, 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 RnkItgCL0VUe for ; Tue, 30 Apr 2013 11:06:20 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0B89C21F9763 for ; Tue, 30 Apr 2013 11:06:20 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1721BF2407D for ; Tue, 30 Apr 2013 14:06:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id n-0+QYBj6rlK for ; Tue, 30 Apr 2013 14:05:36 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 38A3BF24078 for ; Tue, 30 Apr 2013 14:06:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <810C31990B57ED40B2062BA10D43FBF51454CA@XMB111CNC.rim.net> Date: Tue, 30 Apr 2013 14:06:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8122A90E-E106-4A22-BB82-6D70450816F3@vigilsec.com> References: <9A043F3CF02CD34C8E74AC1594475C7343D49137@uxcn10-tdc02.UoA.auckland.ac.nz> <810C31990B57ED40B2062BA10D43FBF51454CA@XMB111CNC.rim.net> To: IRTF CFRG X-Mailer: Apple Mail (2.1085) Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 18:06:26 -0000 >> This is aligned with PKCS#1. Yes, it would be ideal for the whole >> thing to be NULL if all of the values are DEFAULT, but that is not = the >> way PKCS#1 did it. >>=20 > [DB] Why would that be ideal? NULL parameters usually mean the = equivalent of absent parameters, not DEFAULT parameters. >=20 > This does raise an orthogonal issue: what about historial = implementations that do not support OPTIONAL parameters (in = AlgorithmIdentifier). (((Chances are such an implementation would also = not support DEFAULT parameters?))). Some RFCs specify that NULL-valued = parameters have the same meaning as absent parameters. To address such = implementations, RFC 4055 could be modified to take the same approach, = with an erratum. (Also, NULL-value parameter do not count as present = for the purposes of the actions to be taken, etc.) >=20 > But maybe 4055 does not need to grandfather to such implementations, = since it is all about some kind of newfangled RSA-PSS that grandpa never = heard of and would never bother with anyway, being happy with good old = PKCS#1v1.5. I did not intend to pick the scab off the absent vs NULL discussion. My = point was that a shorthand for four default values would have been = desirable, but it is way too late. Russ From James.H.Manger@team.telstra.com Tue Apr 30 17:44:44 2013 Return-Path: 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 B8D7221F85DC for ; Tue, 30 Apr 2013 17:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994, SARE_OBFU_PART_ALI=1.666] 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 oPpl2c4XdpjE for ; Tue, 30 Apr 2013 17:44:38 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5456B21F87B7 for ; Tue, 30 Apr 2013 17:44:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,584,1363093200"; d="scan'208";a="126703753" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 01 May 2013 10:44:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7061"; a="133482697" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 01 May 2013 10:44:32 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 1 May 2013 10:44:32 +1000 From: "Manger, James H" To: Russ Housley , IRTF CFRG Date: Wed, 1 May 2013 10:44:31 +1000 Thread-Topic: [Cfrg] Hash substitution in PSS Thread-Index: Ac5FzXuCHLxQxOY/Sje7d2JdjsPbGAAMWU5A Message-ID: <255B9BB34FB7D647A506DC292726F6E1150CF65FC5@WSMSG3153V.srv.dir.telstra.com> References: <9A043F3CF02CD34C8E74AC1594475C7343D49137@uxcn10-tdc02.UoA.auckland.ac.nz> <810C31990B57ED40B2062BA10D43FBF51454CA@XMB111CNC.rim.net> <8122A90E-E106-4A22-BB82-6D70450816F3@vigilsec.com> In-Reply-To: <8122A90E-E106-4A22-BB82-6D70450816F3@vigilsec.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Cfrg] Hash substitution in PSS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 00:44:44 -0000 PiBJIGRpZCBub3QgaW50ZW5kIHRvIHBpY2sgdGhlIHNjYWIgb2ZmIHRoZSBhYnNlbnQgdnMgTlVM TCBkaXNjdXNzaW9uLg0KPiBNeSBwb2ludCB3YXMgdGhhdCBhIHNob3J0aGFuZCBmb3IgZm91ciBk ZWZhdWx0IHZhbHVlcyB3b3VsZCBoYXZlIGJlZW4NCj4gZGVzaXJhYmxlLCBidXQgaXQgaXMgd2F5 IHRvbyBsYXRlLg0KDQpTdXJlbHkgYSBzaG9ydGhhbmQgZm9yIFJTQVNTQS1QU1MtcGFyYW1zIHRo YXQgdXNlIHRoZSA0IGRlZmF1bHQgdmFsdWVzIGlzIHByZWNpc2VseSB3aGF0IHRoZSB1c2Ugb2Yg REVGQVVMVCBpbiBpdHMgQVNOLjEgZGVmaW5pdGlvbiBwcm92aWRlcy4NCg0KVGhlIERFUi1lbmNv ZGluZyBvZiBSU1NBU0EtUFNTLXBhcmFtcyB0aGF0IHVzZSBTSEEtMSwgTUdGMSB3aXRoIFNIQS0x LCBhIDIwLWJ5dGUgc2FsdCwgYW5kIHRoZSAweEJDIHRyYWlsZXIgYnl0ZSBpczoNCg0KICAzMCAw MA0KDQpUaG9zZSAyIGJ5dGVzIGFyZSBqdXN0IGFzIHNob3J0IGFzIHRoZSBERVItZW5jb2Rpbmcg b2YgTlVMTCAoMDUgMDApLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KPj4gUkZDIDQwNTUgc2F5 cyAiUlNBU1NBLVBTUy1wYXJhbXMgIDo6PSAgU0VRVUVOQ0UgIHsNCj4+ICAgICAgICBoYXNoQWxn b3JpdGhtICAgICAgWzBdIEhhc2hBbGdvcml0aG0gREVGQVVMVA0KPj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc2hhMUlkZW50aWZpZXIsDQo+PiAgICAgICAgbWFza0dlbkFsZ29y aXRobSAgIFsxXSBNYXNrR2VuQWxnb3JpdGhtIERFRkFVTFQNCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG1nZjFTSEExSWRlbnRpZmllciwNCj4+ICAgICAgICBzYWx0TGVuZ3Ro ICAgICAgICAgWzJdIElOVEVHRVIgREVGQVVMVCAyMCwNCj4+ICAgICAgICB0cmFpbGVyRmllbGQg ICAgICAgWzNdIElOVEVHRVIgREVGQVVMVCAxICB9Ig0K