From kmigoe@nsa.gov Wed May 2 13:07:55 2012 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 934D221E80F5 for ; Wed, 2 May 2012 13:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.85 X-Spam-Level: X-Spam-Status: No, score=-8.85 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, 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 Gv0lBt+xMxWO for ; Wed, 2 May 2012 13:07:54 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E521E80F2 for ; Wed, 2 May 2012 13:07:54 -0700 (PDT) X-TM-IMSS-Message-ID: <342e0f4f0009018c@nsa.gov> Received: from MSCS-GH1-UEA03.corp.nsa.gov ([10.215.228.134]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 342e0f4f0009018c ; Wed, 2 May 2012 16:08:58 -0400 Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA03.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 May 2012 16:07:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD289F.4097E5A5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 2 May 2012 16:07:51 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425BF6@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PAKE Thread-Index: Ac0on0GmoxGRBW5zQZqTViEfntPTMw== From: "Igoe, Kevin M." To: , "Dan Harkins" X-OriginalArrivalTime: 02 May 2012 20:07:51.0644 (UTC) FILETIME=[40D849C0:01CD289F] Subject: [Cfrg] PAKE 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, 02 May 2012 20:07:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD289F.4097E5A5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One quick piece of feedback. In the EC case, the construction of the PassWrod Element (PWE) on the curve involves trying to take the square root of f =3D x^3 + ax + b. This is MUCH easier to do in p =3D 3 mod 4 (in this case compute y =3D f^( (p+1)/4). If y^2 =3D f, your done, otherwise y^2 =3D -f and f doesn't have a square root mod p. =20 The p =3D 1 mod 4 case gets ugly, especially if p-1 is divisible by a high power of 2. Luckily most EC groups use p=3D3 mod 4. =20 I'd advise adding the constraint that for eliiptic cureves pmust be 3 mod 4.=20 =20 P.S. The fact that f has a preferred square root mod p might eliminate the code that decides whether to use (x,y) or (x,-y) as the PWE. =20 Kevin M. Igoe | "Everyone is entitled to their own kmigoe@nsa.gov | opinions, but not to their own facts." | - Daniel Patrick Moynihan - ------_=_NextPart_001_01CD289F.4097E5A5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One quick = piece of feedback.  In the EC case, the = construction

of the PassWrod Element = (PWE) on the curve involves

trying to = take the square root of f =3D x^3 + ax + b.  This

is MUCH easier to do in p =3D 3 mod 4 (in this case = compute

y =3D f^( (p+1)/4).  If = y^2 =3D f, your done, otherwise y^2 =3D -f

and f doesn’t have a square root mod = p.

 

The p =3D 1 mod 4 case gets ugly, especially if p-1 is = divisible

by a high power of 2. =   Luckily most EC groups use p=3D3 mod 4.

 

I’d = advise adding the constraint that for eliiptic cureves = pmust

be 3 mod 4.

 

P.S.  = The fact that f has a preferred square root mod p might

eliminate the code that decides whether to use (x,y) = or

(x,-y) as the = PWE.

 

Kevin M. = Igoe       |   "Everyone is = entitled to their own
kmigoe@nsa.gov  |    = opinions, but not to their own = facts."
         &nb= sp;           &nbs= p;     |       - = Daniel Patrick Moynihan -

------_=_NextPart_001_01CD289F.4097E5A5-- From paul.hoffman@vpnc.org Wed May 2 18:15:49 2012 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 3C2FB11E80B7 for ; Wed, 2 May 2012 18:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 SymVFYCZuVci for ; Wed, 2 May 2012 18:15:48 -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 71AD111E808D for ; Wed, 2 May 2012 18:15:48 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q431FhN3030354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 2 May 2012 18:15:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 May 2012 18:15:42 -0700 References: <20120503010052.9710.qmail@cr.yp.to> To: cfrg@irtf.org Message-Id: <80B68AF4-573B-423E-82D0-897AE8317F9F@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Cfrg] Fwd: DIAC: Directions in Authenticated Ciphers 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, 03 May 2012 01:15:49 -0000 Of interest to this list: > From: "D. J. Bernstein" > Subject: [cryptography] DIAC: Directions in Authenticated Ciphers > Date: May 2, 2012 6:00:52 PM PDT > To: cryptography@randombit.net >=20 > The DIAC submission page is now open, with a deadline at the end of > Monday 7 May (American Samoa time): >=20 > http://hyperelliptic.org/conferences/diac/iChair/submit.php >=20 > DIAC is an ECRYPT-sponsored workshop that will take place 5--6 July in > Stockholm, in particular evaluating the idea of a new competition for > authenticated ciphers. The call for papers asks for submissions on new > components, combinations, attacks, and implementations, but also asks > for submissions discussing requirements---what users actually want. > Submissions of panel proposals, white papers, lists of desiderata, = etc. > are encouraged, and there are no particular length requirements. >=20 > I should emphasize that an authenticated-cipher competition would be > much more than an "AE mode" competition. There are certainly people > working on new ways to use AES, but there are many more people working > on new authenticators, new block ciphers, new stream ciphers, new > ciphers with built-in authentication mechanisms, etc. >=20 > . . . (The rest of the message applies to an earlier thread on the = cryptography mailing list) . . . >=20 > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at = Chicago From thomas.r.henderson@boeing.com Fri May 11 07:29:53 2012 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 279BB21F8686 for ; Fri, 11 May 2012 07:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.932 X-Spam-Level: X-Spam-Status: No, score=-104.932 tagged_above=-999 required=5 tests=[AWL=-2.333, 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 tb8t5lGdOAJw for ; Fri, 11 May 2012 07:29:52 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1221F860B for ; Fri, 11 May 2012 07:29:48 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4BETlv3023996 for ; Fri, 11 May 2012 07:29:48 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4BETkXv023967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 May 2012 07:29:46 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4BETjMA026283; Fri, 11 May 2012 09:29:46 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4BETjAe026267 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 May 2012 09:29:45 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 11 May 2012 07:29:45 -0700 From: "Henderson, Thomas R" To: "'cfrg@irtf.org'" Date: Fri, 11 May 2012 07:29:44 -0700 Thread-Topic: advice about best current practices for HIP Thread-Index: Ac0idsJYLzFbb+aKQea5f90FHsHniQNC5QWw Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD24C87A1@XCH-NW-16V.nw.nos.boeing.com> References: <758141CC3D829043A8C3164DD3D593EA1BD24C86F7@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA1BD24C86F7@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: 'Robert Moskowitz' Subject: Re: [Cfrg] advice about best current practices for HIP 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, 11 May 2012 14:29:53 -0000 Hi, I was wondering if anyone was going to be able to respond to the below = questions, or if we should proceed otherwise. - Tom > -----Original Message----- > From: Henderson, Thomas R > Sent: Tuesday, April 24, 2012 5:03 PM > To: 'cfrg@irtf.org' > Cc: 'Tobias Heer'; 'Robert Moskowitz' > Subject: advice about best current practices for HIP >=20 > Hello, I'm one of the authors working on revising HIP [*], and I would > like advice on how to respond to an IESG comment on RFC5201. >=20 > The IESG comment in the experimental specification for HIP reads as > follows: >=20 > HIP defines the usage of RSA in signing and encrypting data. > Current > recommendations propose usage of, for example, RSA OAEP/PSS for > these > operations in new protocols. Changing the algorithms to more > current > best practice should be considered. >=20 > This comment was made over four years ago, and I'm not an expert on > cryptography, so I thought I'd check with the CFRG for advice on how to > respond now. >=20 > 1) signature padding >=20 > Presently, the HIP draft specifies these algorithms for keys (section > 5.2.9 of the draft): >=20 > DSA 3 [RFC2536] (RECOMMENDED) > RSA 5 [RFC3110] (REQUIRED) > ECDSA 7 [RFC4754] (RECOMMENDED) > ECDSA_LOW 9 [SECG] (RECOMMENDED) >=20 > However, the specification of how to compute the signature is somewhat > vague: >=20 > 3. Compute the signature using the private key corresponding to the > Host Identifier (public key). >=20 > I believe that, in practice, whatever default padding was provided by > OpenSSL RSA_sign() has been used (I believe it to be PKCS#1 v1.5). I'm > wondering whether the way to address this comment is to mandate that, > when signatures are computed, and RSA is the key type, the RSAASA-PSS > [RFC3447] method of padding is required, and to replace the reference > to RFC3110 above with RFC3447. >=20 > The above discussion is limited to RSA. Do we need signature > specifications for all of these key types, or is it well implied for > the other key types how to perform the signatures? >=20 > 2) encryption padding >=20 > HIP uses a block cipher to generate ENCRYPTED parameters, using > encryption keys generated by the Diffie Hellman exchange. In practice, > the Host Identity (a public key) may be encrypted for privacy in the I2 > message. >=20 > These ciphers are specified for HIP (section 5.2.8 of the draft): >=20 > AES-128-CBC 2 ([RFC3602]) > 3DES-CBC 3 ([RFC2451]) > AES-256-CBC 4 ([RFC3602]) >=20 > The draft specifies also to use whatever padding is specified by the > encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES-CBC > padding (in practice, our implementation also pads this according to > PKCS5). >=20 > I understand that RSAES-OAEP is a padding technique for key transport > in particular. However, HIP does not specify RSA for encryption, and > does not use 'key transport' mode but rather 'data encryption' mode. > Does RSAES-OAEP apply in this case? Should HIP be considering another > best practice algorithm for doing this? >=20 > In closing, an important consideration for our implementations is > availability in OpenSSL, so required algorithms should be supported > there. >=20 > Thanks, > Tom >=20 > [*] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08 From kmigoe@nsa.gov Mon May 14 06:35:18 2012 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 6DCE821F85A7 for ; Mon, 14 May 2012 06:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.163 X-Spam-Level: X-Spam-Status: No, score=-10.163 tagged_above=-999 required=5 tests=[AWL=0.435, 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 WuqEldht645q for ; Mon, 14 May 2012 06:35:17 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id CC57A21F849A for ; Mon, 14 May 2012 06:35:16 -0700 (PDT) X-TM-IMSS-Message-ID: <7092909c000f0c1a@nsa.gov> Received: from MSCS-GH1-UEA02.corp.nsa.gov ([10.215.225.42]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 7092909c000f0c1a ; Mon, 14 May 2012 09:36:56 -0400 Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 May 2012 09:35:15 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD31D6.65190AA4" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 May 2012 09:35:15 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C0A@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HIP Help (I hope!) Thread-Index: Ac0x1mO4SqW+ChrlSvGTnFlpVMgdPw== From: "Igoe, Kevin M." To: X-OriginalArrivalTime: 14 May 2012 13:35:15.0753 (UTC) FILETIME=[65659190:01CD31D6] Subject: [Cfrg] HIP Help (I hope!) 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, 14 May 2012 13:35:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD31D6.65190AA4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do have an obvious observation on the use of DSA. =20 In SP-800-131A, NIST states that for signing, a 1024 bit DSA modulus with a 160-bit subgroup is acceptable through 2010, deprecated from 2011 through 2013, and disallowed after 2013. While we are not bound by NIST's authority, I for one feel it would be prudent to follow their lead. (SP-800-131A=3D http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf ) =20 RFC 5114 [Additional Diffie-Hellman Groups for Use with IETF Standards] provides an alternative to 1024-bit/SHA1 DSA. Sections 2.2 and 2.3 lists 2048 bit groups suitable for use with DSA/SHA2-224 and DSA/SHA2-256 respectively. Is either of these this in the latest version of openSSL? In all the excitement, I've kinda lost track myself.=20 =20 Comments anyone? =20 =20 Anyone with comments on the padding? My gut instinct so to keep it as simple as possible, avoid defining new key types & use as much pre-existing code as possible. Dare to be consistent! =20 =20 =20 We could really use some input here from folks with concrete experience on the=20 padding issues! Speak now or forever hold your peace. =20 P.S. I'm impressed by the amount of detailed work that went into this draft. =20 Well done! =20 =20 > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Henderson, Thomas R > Sent: Friday, May 11, 2012 10:30 AM > To: 'cfrg@irtf.org' > Cc: 'Robert Moskowitz' > Subject: Re: [Cfrg] advice about best current practices for HIP >=20 > Hi, I was wondering if anyone was going to be able to respond to the > below questions, or if we should proceed otherwise. >=20 > - Tom >=20 > > -----Original Message----- > > From: Henderson, Thomas R > > Sent: Tuesday, April 24, 2012 5:03 PM > > To: 'cfrg@irtf.org' > > Cc: 'Tobias Heer'; 'Robert Moskowitz' > > Subject: advice about best current practices for HIP > > > > Hello, I'm one of the authors working on revising HIP [*], and I > would > > like advice on how to respond to an IESG comment on RFC5201. > > > > The IESG comment in the experimental specification for HIP reads as > > follows: > > > > HIP defines the usage of RSA in signing and encrypting data. > > Current > > recommendations propose usage of, for example, RSA OAEP/PSS for > > these > > operations in new protocols. Changing the algorithms to more > > current > > best practice should be considered. > > > > This comment was made over four years ago, and I'm not an expert on > > cryptography, so I thought I'd check with the CFRG for advice on how > to > > respond now. > > > > 1) signature padding > > > > Presently, the HIP draft specifies these algorithms for keys (section > > 5.2.9 of the draft): > > > > DSA 3 [RFC2536] (RECOMMENDED) > > RSA 5 [RFC3110] (REQUIRED) > > ECDSA 7 [RFC4754] (RECOMMENDED) > > ECDSA_LOW 9 [SECG] (RECOMMENDED) > > > > However, the specification of how to compute the signature is > somewhat > > vague: > > > > 3. Compute the signature using the private key corresponding to > the > > Host Identifier (public key). > > > > I believe that, in practice, whatever default padding was provided by > > OpenSSL RSA_sign() has been used (I believe it to be PKCS#1 v1.5). > I'm > > wondering whether the way to address this comment is to mandate that, > > when signatures are computed, and RSA is the key type, the RSAASA-PSS > > [RFC3447] method of padding is required, and to replace the reference > > to RFC3110 above with RFC3447. > > > > The above discussion is limited to RSA. Do we need signature > > specifications for all of these key types, or is it well implied for > > the other key types how to perform the signatures? > > > > 2) encryption padding > > > > HIP uses a block cipher to generate ENCRYPTED parameters, using > > encryption keys generated by the Diffie Hellman exchange. In > practice, > > the Host Identity (a public key) may be encrypted for privacy in the > I2 > > message. > > > > These ciphers are specified for HIP (section 5.2.8 of the draft): > > > > AES-128-CBC 2 ([RFC3602]) > > 3DES-CBC 3 ([RFC2451]) > > AES-256-CBC 4 ([RFC3602]) > > > > The draft specifies also to use whatever padding is specified by the > > encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES- > CBC > > padding (in practice, our implementation also pads this according to > > PKCS5). > > > > I understand that RSAES-OAEP is a padding technique for key transport > > in particular. However, HIP does not specify RSA for encryption, and > > does not use 'key transport' mode but rather 'data encryption' mode. > > Does RSAES-OAEP apply in this case? Should HIP be considering > another > > best practice algorithm for doing this? > > > > In closing, an important consideration for our implementations is > > availability in OpenSSL, so required algorithms should be supported > > there. > > > > Thanks, > > Tom > > > > [*] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg ------_=_NextPart_001_01CD31D6.65190AA4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do = have an obvious observation on the use of DSA.

 

In = SP-800-131A, NIST states that for signing, a 1024 bit DSA modulus with a = 160-bit subgroup is acceptable through 2010, deprecated from 2011 = through 2013, and disallowed after 2013. While we are not bound by = NIST's authority, I for one feel it would be prudent to follow their = lead.

(SP-800-131A=3D http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf= )

 

RFC 5114  [Additional Diffie-Hellman Groups = for Use with IETF Standards] provides an alternative to 1024-bit/SHA1 = DSA.  Sections 2.2 and 2.3 lists 2048 bit groups suitable for use = with DSA/SHA2-224 and DSA/SHA2-256 respectively. Is either of these this = in the latest version of openSSL?  In all the excitement, I've = kinda lost track myself.

 

Comments anyone?

 

 

Anyone = with comments on the padding?  My gut instinct so  to keep it = as simple as possible, avoid defining new key types & use as much = pre-existing code as possible. Dare to be consistent!  =

 

 

<impassioned_plea>

We could really use some input here from folks with = concrete experience on the

padding issues!  Speak now or forever hold = your peace.

</impassioned_plea>

 

P.S. = I'm impressed by the amount of detailed work that went into this = draft. 

Well = done!

 

 

> = -----Original Message-----

> = From: cfrg-bounces@irtf.org = [mailto:cfrg-bounces@irtf.= org] On Behalf Of

> = Henderson, Thomas R

> Sent: = Friday, May 11, 2012 10:30 AM

> = To: 'cfrg@irtf.org'

> Cc: = 'Robert Moskowitz'

> Subject: = Re: [Cfrg] advice about best current practices for HIP

>

> = Hi, I was wondering if anyone was going to be able to respond to = the

> below questions, or if we = should proceed otherwise.

> =

> - Tom

>

> = > -----Original Message-----

> > From: Henderson, Thomas = R

> > Sent: Tuesday, April = 24, 2012 5:03 PM

> > To: = 'cfrg@irtf.org'

> > Cc: = 'Tobias Heer'; 'Robert Moskowitz'

> > Subject: advice about best current = practices for HIP

> = >

> > Hello, I'm one of = the authors working on revising HIP [*], and I

> would

> > like advice on how to respond to an IESG = comment on RFC5201.

> = >

> > The IESG comment in = the experimental specification for HIP reads as

> > follows:

> >

> >    HIP defines the usage = of RSA in signing and encrypting data.

> > Current

> >    recommendations propose = usage of, for example, RSA OAEP/PSS for

> > these

> >    operations in new = protocols.  Changing the algorithms to more

> > current

> >    best practice should be = considered.

> = >

> > This comment was = made over four years ago, and I'm not an expert on

> > cryptography, so I thought I'd check with = the CFRG for advice on how

> = to

> > respond = now.

> >

> > 1) signature padding

> >

> > Presently, the HIP draft specifies these = algorithms for keys (section

> = > 5.2.9 of the draft):

> = >

> = >         = DSA           &nbs= p;  3 [RFC2536] (RECOMMENDED)

> = >         = RSA           &nbs= p;  5 [RFC3110] (REQUIRED)

> = >         = ECDSA            = 7 [RFC4754] (RECOMMENDED)

> = >         = ECDSA_LOW        9 = [SECG]    (RECOMMENDED)

> >

> > However, the specification of how to = compute the signature is

> = somewhat

> > = vague:

> >

> >    3.  Compute the = signature using the private key corresponding to

> the

> = >        Host Identifier (public = key).

> >

> > I believe that, in practice, whatever = default padding was provided by

> > OpenSSL RSA_sign() has been used (I = believe it to be PKCS#1 v1.5).

> I'm

> = > wondering whether the way to address this comment is to mandate = that,

> > when signatures = are computed, and RSA is the key type, the RSAASA-PSS

> > [RFC3447] method of padding is required, = and to replace the reference

> = > to RFC3110 above with RFC3447.

> >

> > The above discussion is limited to = RSA.  Do we need signature

> > specifications for all of these key = types, or is it well implied for

> > the other key types how to perform the = signatures?

> = >

> > 2) encryption = padding

> >

> > HIP uses a block cipher to generate = ENCRYPTED parameters, using

> = > encryption keys generated by the Diffie Hellman exchange.  = In

> practice,

> > the Host Identity (a public key) may be = encrypted for privacy in the

> = I2

> > = message.

> = >

> > These ciphers are = specified for HIP (section 5.2.8 of the draft):

> >

> = >         = AES-128-CBC        = 2     ([RFC3602])

> = >         = 3DES-CBC           = 3     ([RFC2451])

> = >         = AES-256-CBC        = 4     ([RFC3602])

> >

> > The draft specifies also to use whatever = padding is specified by the

> = > encryption algorithm, citing PKCS5 for AES, and not mentioning = 3DES-

> CBC

> > padding (in practice, our implementation = also pads this according to

> = > PKCS5).

> = >

> > I understand that = RSAES-OAEP is a padding technique for key transport

> > in particular.  However, HIP does = not specify RSA for encryption, and

> > does not use 'key transport' mode but = rather 'data encryption' mode.

> > Does RSAES-OAEP apply in this case?  = Should HIP be considering

> = another

> > best practice = algorithm for doing this?

> = >

> > In closing, an = important consideration for our implementations is

> > availability in OpenSSL, so required = algorithms should be supported

> > there.

> >

> > Thanks,

> > Tom

> >

> > [*] http://= tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08

> = _______________________________________________

> Cfrg mailing list

> Cfrg@irtf.org

> http://www.irtf.org/ma= ilman/listinfo/cfrg

------_=_NextPart_001_01CD31D6.65190AA4-- From kmigoe@nsa.gov Mon May 14 11:55:32 2012 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 2A62421F88D7 for ; Mon, 14 May 2012 11:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.373, 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 MdyOjNLnUEXf for ; Mon, 14 May 2012 11:55:29 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBC421F88D4 for ; Mon, 14 May 2012 11:55:28 -0700 (PDT) X-TM-IMSS-Message-ID: <4dffcb07000fbefb@nsa.gov> Received: from MSCS-GH1-UEA02.corp.nsa.gov ([10.215.225.42]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 4dffcb07000fbefb ; Mon, 14 May 2012 14:55:28 -0400 Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 May 2012 14:55:26 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3203.1FE72D39" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 May 2012 14:55:26 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C0D@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C0A@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] HIP Help (I hope!) Thread-Index: Ac0x1mO4SqW+ChrlSvGTnFlpVMgdPwAK/Yfw References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C0A@MSIS-GH1-UEA06.corp.nsa.gov> From: "Igoe, Kevin M." To: "Igoe, Kevin M." , X-OriginalArrivalTime: 14 May 2012 18:55:26.0737 (UTC) FILETIME=[20091810:01CD3203] Subject: Re: [Cfrg] HIP Help (I hope!) 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, 14 May 2012 18:55:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3203.1FE72D39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did some double checking with some certificate guru's & they agree that RSA-OAEP=20 is precisely what you should be using. =20 I've also had some discussions about HIP's use of 3DES. It will be difficult to uproot once it has been fielded, so it might be prudent to remove it now. The same applies to DSA SHA1/2048 and ECDSA_low.=20 =20 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Igoe, Kevin M. Sent: Monday, May 14, 2012 9:35 AM To: cfrg@irtf.org Subject: [Cfrg] HIP Help (I hope!) =20 I do have an obvious observation on the use of DSA. =20 In SP-800-131A, NIST states that for signing, a 1024 bit DSA modulus with a 160-bit subgroup is acceptable through 2010, deprecated from 2011 through 2013, and disallowed after 2013. While we are not bound by NIST's authority, I for one feel it would be prudent to follow their lead. (SP-800-131A=3D http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf ) =20 RFC 5114 [Additional Diffie-Hellman Groups for Use with IETF Standards] provides an alternative to 1024-bit/SHA1 DSA. Sections 2.2 and 2.3 lists 2048 bit groups suitable for use with DSA/SHA2-224 and DSA/SHA2-256 respectively. Is either of these this in the latest version of openSSL? In all the excitement, I've kinda lost track myself.=20 =20 Comments anyone? =20 =20 Anyone with comments on the padding? My gut instinct so to keep it as simple as possible, avoid defining new key types & use as much pre-existing code as possible. Dare to be consistent! =20 =20 =20 We could really use some input here from folks with concrete experience on the=20 padding issues! Speak now or forever hold your peace. =20 P.S. I'm impressed by the amount of detailed work that went into this draft. =20 Well done! =20 =20 > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Henderson, Thomas R > Sent: Friday, May 11, 2012 10:30 AM > To: 'cfrg@irtf.org' > Cc: 'Robert Moskowitz' > Subject: Re: [Cfrg] advice about best current practices for HIP >=20 > Hi, I was wondering if anyone was going to be able to respond to the > below questions, or if we should proceed otherwise. >=20 > - Tom >=20 > > -----Original Message----- > > From: Henderson, Thomas R > > Sent: Tuesday, April 24, 2012 5:03 PM > > To: 'cfrg@irtf.org' > > Cc: 'Tobias Heer'; 'Robert Moskowitz' > > Subject: advice about best current practices for HIP > > > > Hello, I'm one of the authors working on revising HIP [*], and I > would > > like advice on how to respond to an IESG comment on RFC5201. > > > > The IESG comment in the experimental specification for HIP reads as > > follows: > > > > HIP defines the usage of RSA in signing and encrypting data. > > Current > > recommendations propose usage of, for example, RSA OAEP/PSS for > > these > > operations in new protocols. Changing the algorithms to more > > current > > best practice should be considered. > > > > This comment was made over four years ago, and I'm not an expert on > > cryptography, so I thought I'd check with the CFRG for advice on how > to > > respond now. > > > > 1) signature padding > > > > Presently, the HIP draft specifies these algorithms for keys (section > > 5.2.9 of the draft): > > > > DSA 3 [RFC2536] (RECOMMENDED) > > RSA 5 [RFC3110] (REQUIRED) > > ECDSA 7 [RFC4754] (RECOMMENDED) > > ECDSA_LOW 9 [SECG] (RECOMMENDED) > > > > However, the specification of how to compute the signature is > somewhat > > vague: > > > > 3. Compute the signature using the private key corresponding to > the > > Host Identifier (public key). > > > > I believe that, in practice, whatever default padding was provided by > > OpenSSL RSA_sign() has been used (I believe it to be PKCS#1 v1.5). > I'm > > wondering whether the way to address this comment is to mandate that, > > when signatures are computed, and RSA is the key type, the RSAASA-PSS > > [RFC3447] method of padding is required, and to replace the reference > > to RFC3110 above with RFC3447. > > > > The above discussion is limited to RSA. Do we need signature > > specifications for all of these key types, or is it well implied for > > the other key types how to perform the signatures? > > > > 2) encryption padding > > > > HIP uses a block cipher to generate ENCRYPTED parameters, using > > encryption keys generated by the Diffie Hellman exchange. In > practice, > > the Host Identity (a public key) may be encrypted for privacy in the > I2 > > message. > > > > These ciphers are specified for HIP (section 5.2.8 of the draft): > > > > AES-128-CBC 2 ([RFC3602]) > > 3DES-CBC 3 ([RFC2451]) > > AES-256-CBC 4 ([RFC3602]) > > > > The draft specifies also to use whatever padding is specified by the > > encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES- > CBC > > padding (in practice, our implementation also pads this according to > > PKCS5). > > > > I understand that RSAES-OAEP is a padding technique for key transport > > in particular. However, HIP does not specify RSA for encryption, and > > does not use 'key transport' mode but rather 'data encryption' mode. > > Does RSAES-OAEP apply in this case? Should HIP be considering > another > > best practice algorithm for doing this? > > > > In closing, an important consideration for our implementations is > > availability in OpenSSL, so required algorithms should be supported > > there. > > > > Thanks, > > Tom > > > > [*] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg ------_=_NextPart_001_01CD3203.1FE72D39 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did some double checking with  some = certificate guru’s & they agree that RSA-OAEP =

is precisely what you should be = using.

 

I’ve also had some = discussions about HIP’s use of 3DES.  It will be difficult to = uproot once

it has been fielded, so it might be prudent to = remove it now.  The same applies

to DSA SHA1/2048 and = ECDSA_low.

 

From:= = cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of = Igoe, Kevin M.
Sent: Monday, May 14, 2012 9:35 = AM
To: cfrg@irtf.org
Subject: [Cfrg] HIP Help (I = hope!)

 

I do have = an obvious observation on the use of DSA.

 

In = SP-800-131A, NIST states that for signing, a 1024 bit DSA modulus with a = 160-bit subgroup is acceptable through 2010, deprecated from 2011 = through 2013, and disallowed after 2013. While we are not bound by = NIST's authority, I for one feel it would be prudent to follow their = lead.

(SP-800-131A=3D http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf= )

 

RFC 5114  [Additional Diffie-Hellman Groups = for Use with IETF Standards] provides an alternative to 1024-bit/SHA1 = DSA.  Sections 2.2 and 2.3 lists 2048 bit groups suitable for use = with DSA/SHA2-224 and DSA/SHA2-256 respectively. Is either of these this = in the latest version of openSSL?  In all the excitement, I've = kinda lost track myself.

 

Comments anyone?

 

 

Anyone = with comments on the padding?  My gut instinct so  to keep it = as simple as possible, avoid defining new key types & use as much = pre-existing code as possible. Dare to be consistent!  =

 

 

<impassioned_plea>

We could really use some input here from folks with = concrete experience on the

padding issues!  Speak now or forever hold = your peace.

</impassioned_plea>

 

P.S. = I'm impressed by the amount of detailed work that went into this = draft. 

Well = done!

 

 

> = -----Original Message-----

> = From: cfrg-bounces@irtf.org = [mailto:cfrg-bounces@irtf.= org] On Behalf Of

> = Henderson, Thomas R

> Sent: = Friday, May 11, 2012 10:30 AM

> = To: 'cfrg@irtf.org'

> Cc: = 'Robert Moskowitz'

> Subject: = Re: [Cfrg] advice about best current practices for HIP

>

> = Hi, I was wondering if anyone was going to be able to respond to = the

> below questions, or if we = should proceed otherwise.

> =

> - Tom

>

> = > -----Original Message-----

> > From: Henderson, Thomas = R

> > Sent: Tuesday, April = 24, 2012 5:03 PM

> > To: = 'cfrg@irtf.org'

> > Cc: = 'Tobias Heer'; 'Robert Moskowitz'

> > Subject: advice about best current = practices for HIP

> = >

> > Hello, I'm one of = the authors working on revising HIP [*], and I

> would

> > like advice on how to respond to an IESG = comment on RFC5201.

> = >

> > The IESG comment in = the experimental specification for HIP reads as

> > follows:

> >

> >    HIP defines the usage = of RSA in signing and encrypting data.

> > Current

> >    recommendations propose = usage of, for example, RSA OAEP/PSS for

> > these

> >    operations in new = protocols.  Changing the algorithms to more

> > current

> >    best practice should be = considered.

> = >

> > This comment was = made over four years ago, and I'm not an expert on

> > cryptography, so I thought I'd check with = the CFRG for advice on how

> = to

> > respond = now.

> >

> > 1) signature padding

> >

> > Presently, the HIP draft specifies these = algorithms for keys (section

> = > 5.2.9 of the draft):

> = >

> = >         = DSA           &nbs= p;  3 [RFC2536] (RECOMMENDED)

> = >         = RSA           &nbs= p;  5 [RFC3110] (REQUIRED)

> = >         = ECDSA            = 7 [RFC4754] (RECOMMENDED)

> = >         = ECDSA_LOW        9 = [SECG]    (RECOMMENDED)

> >

> > However, the specification of how to = compute the signature is

> = somewhat

> > = vague:

> >

> >    3.  Compute the = signature using the private key corresponding to

> the

> = >        Host Identifier (public = key).

> >

> > I believe that, in practice, whatever = default padding was provided by

> > OpenSSL RSA_sign() has been used (I = believe it to be PKCS#1 v1.5).

> I'm

> = > wondering whether the way to address this comment is to mandate = that,

> > when signatures = are computed, and RSA is the key type, the RSAASA-PSS

> > [RFC3447] method of padding is required, = and to replace the reference

> = > to RFC3110 above with RFC3447.

> >

> > The above discussion is limited to = RSA.  Do we need signature

> > specifications for all of these key = types, or is it well implied for

> > the other key types how to perform the = signatures?

> = >

> > 2) encryption = padding

> >

> > HIP uses a block cipher to generate = ENCRYPTED parameters, using

> = > encryption keys generated by the Diffie Hellman exchange.  = In

> practice,

> > the Host Identity (a public key) may be = encrypted for privacy in the

> = I2

> > = message.

> = >

> > These ciphers are = specified for HIP (section 5.2.8 of the draft):

> >

> = >         = AES-128-CBC        = 2     ([RFC3602])

> = >         = 3DES-CBC           = 3     ([RFC2451])

> = >         = AES-256-CBC        = 4     ([RFC3602])

> >

> > The draft specifies also to use whatever = padding is specified by the

> = > encryption algorithm, citing PKCS5 for AES, and not mentioning = 3DES-

> CBC

> > padding (in practice, our implementation = also pads this according to

> = > PKCS5).

> = >

> > I understand that = RSAES-OAEP is a padding technique for key transport

> > in particular.  However, HIP does = not specify RSA for encryption, and

> > does not use 'key transport' mode but = rather 'data encryption' mode.

> > Does RSAES-OAEP apply in this case?  = Should HIP be considering

> = another

> > best practice = algorithm for doing this?

> = >

> > In closing, an = important consideration for our implementations is

> > availability in OpenSSL, so required = algorithms should be supported

> > there.

> >

> > Thanks,

> > Tom

> >

> > [*] http://= tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08

> = _______________________________________________

> Cfrg mailing list

> Cfrg@irtf.org

> http://www.irtf.org/ma= ilman/listinfo/cfrg

------_=_NextPart_001_01CD3203.1FE72D39-- From kmigoe@nsa.gov Wed May 23 07:31:02 2012 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 2AF8021F8701 for ; Wed, 23 May 2012 07:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 nHAa9PP1wHXY for ; Wed, 23 May 2012 07:31:00 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5594A21F86F8 for ; Wed, 23 May 2012 07:31:00 -0700 (PDT) X-TM-IMSS-Message-ID: <9f1e88380014500c@nsa.gov> Received: from MSCS-GH1-UEA01.corp.nsa.gov ([10.215.224.47]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 9f1e88380014500c ; Wed, 23 May 2012 10:32:19 -0400 Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 May 2012 10:30:59 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD38F0.ABE78C4D" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 23 May 2012 10:30:59 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cryptographic meta-principles Thread-Index: Ac048KtI+eJiAhBwS0y3vfVxSHlzRA== From: "Igoe, Kevin M." To: X-OriginalArrivalTime: 23 May 2012 14:30:59.0185 (UTC) FILETIME=[ABF48E10:01CD38F0] Subject: [Cfrg] Cryptographic meta-principles 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, 23 May 2012 14:31:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD38F0.ABE78C4D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some cryptographic meta-principles. Feel free to disagree or make additions. I think 2, 5, 7 and 8=20 are the most relevant to the CFRG. I always found #1 useful in analyzing systems. Always ask "where have we moved the risk?". =20 1. You can't eliminate risk, you can just move it around.=20 2. Needless complexity is the enemy of security. 3. There is no such thing as a secure algorithm, only a secure system. Even the most "secure" algorithm, if used improperly, can be worthless. Without the proper architecture, implementation, and management we are effectively "putting bank vault doors on cardboard boxes".=20 4. In the end everything comes down to a cost analysis: how much does it cost an adversary to attempt to exploit a given system and what is the adversary's expected gain from succeeding? Our goal is to select cryptographic mechanisms and parameter sizes that make the adversary's expected return on investment negative.=20 5. Moore's Law continually decreases an adversary's cost to attack a system. so we must assume that eventually all parameter sizes will need to be readjusted. 6. In the limit as the parameter size/number of rounds goes to infinity, almost anything is secure. The art is in picking mechanisms and parameter sizes that meet our needs efficiently. 7. As far as possible, we should strive to provide a cryptographic environment that is both practical and stable. 8. We don't exist in a vacuum. We need to constantly monitor the impact of current cryptographic practices on vendors and IETF working groups, try to foresee emerging requirements, monitor the results being produced by the cryptologic research community, and co-ordinate our efforts with other standards bodies. =20 Strive to be simple, practical and consistent, but always be aware that in the long run change is inevitable. =20 =20 =20 Kevin M. Igoe | "Everyone is entitled to their own kmigoe@nsa.gov | opinions, but not to their own facts." co-chair CFRG | - Daniel Patrick Moynihan - ------_=_NextPart_001_01CD38F0.ABE78C4D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some cryptographic meta-principles.  = Feel free to disagree or make additions.    I think 2, 5, = 7 and 8

are the most relevant to the CFRG. =   I always found #1 useful in analyzing systems.  = Always

ask “where have we moved the = risk?”.

 

1.       You = can’t eliminate risk, you can just move it around. =

2.       = Needless complexity is the enemy of = security.

3.       = There is no such thing as a secure algorithm, = only a secure system.  Even the most “secure” = algorithm, if used improperly, can be  worthless.   Without = the proper architecture, implementation, and management we are = effectively “putting bank vault doors on cardboard boxes”. =

4.       In = the end everything  comes down to  a cost analysis: how much = does it cost an adversary to attempt to exploit a
given system and = what is the adversary's expected gain from succeeding? Our goal is to = select cryptographic mechanisms and parameter sizes that make the = adversary’s expected return on investment negative. =

5.       = Moore’s Law continually decreases an = adversary’s cost to attack a system. so we must assume that = eventually all parameter sizes will need to be = readjusted.

6.       In = the limit as the parameter size/number of rounds goes to infinity, = almost anything is secure.  The art is in picking mechanisms and = parameter sizes that meet our needs efficiently.

7.       As = far as possible, we should strive to provide a cryptographic environment = that is both practical and stable.

8.       We = don’t exist in a vacuum.  We need to constantly monitor the = impact of current cryptographic practices on vendors and IETF working = groups, try to foresee  emerging requirements, monitor the results = being produced by the cryptologic research community, and co-ordinate = our efforts with other standards bodies.

&n= bsp;

Strive = to be simple, practical and consistent, but always be aware that in the = long run change is inevitable.

 

 

 

Kevin M. = Igoe        |   "Everyone = is entitled to their own
kmigoe@nsa.gov  =  |    opinions, but not to their own = facts."
co-chair CFRG       = |       - Daniel Patrick Moynihan = -

------_=_NextPart_001_01CD38F0.ABE78C4D-- From smb@cs.columbia.edu Wed May 23 09:00:35 2012 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 ECDCF21F8734 for ; Wed, 23 May 2012 09:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 M2VKcx+cULyf for ; Wed, 23 May 2012 09:00:34 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5104F21F8694 for ; Wed, 23 May 2012 09:00:34 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4NG0Qr5017332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 May 2012 12:00:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Steven Bellovin In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> Date: Wed, 23 May 2012 12:00:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> To: "Igoe, Kevin M." X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: cfrg@irtf.org Subject: Re: [Cfrg] Cryptographic meta-principles 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, 23 May 2012 16:00:36 -0000 These are excellent. Are they published anywhere stable and citable? = I'd also incorporate some of Shamir's Ten Commandments (from = http://www.ieee-security.org/Cipher/ConfReports/conf-rep-Crypto95.html), = especially #4. On May 23, 2012, at 10:30 59AM, Igoe, Kevin M. wrote: > Some cryptographic meta-principles. Feel free to disagree or make = additions. I think 2, 5, 7 and 8 > are the most relevant to the CFRG. I always found #1 useful in = analyzing systems. Always > ask =93where have we moved the risk?=94. > =20 > 1. You can=92t eliminate risk, you can just move it around. > 2. Needless complexity is the enemy of security. > 3. There is no such thing as a secure algorithm, only a secure = system. Even the most =93secure=94 algorithm, if used improperly, can = be worthless. Without the proper architecture, implementation, and = management we are effectively =93putting bank vault doors on cardboard = boxes=94. > 4. In the end everything comes down to a cost analysis: how = much does it cost an adversary to attempt to exploit a > given system and what is the adversary's expected gain from = succeeding? Our goal is to select cryptographic mechanisms and parameter = sizes that make the adversary=92s expected return on investment = negative. > 5. Moore=92s Law continually decreases an adversary=92s cost to = attack a system. so we must assume that eventually all parameter sizes = will need to be readjusted. > 6. In the limit as the parameter size/number of rounds goes to = infinity, almost anything is secure. The art is in picking mechanisms = and parameter sizes that meet our needs efficiently. > 7. As far as possible, we should strive to provide a = cryptographic environment that is both practical and stable. > 8. We don=92t exist in a vacuum. We need to constantly monitor = the impact of current cryptographic practices on vendors and IETF = working groups, try to foresee emerging requirements, monitor the = results being produced by the cryptologic research community, and = co-ordinate our efforts with other standards bodies. > =20 > Strive to be simple, practical and consistent, but always be aware = that in the long run change is inevitable. > =20 > =20 > =20 > Kevin M. Igoe | "Everyone is entitled to their own > kmigoe@nsa.gov | opinions, but not to their own facts." > co-chair CFRG | - Daniel Patrick Moynihan - > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Steve Bellovin, https://www.cs.columbia.edu/~smb From paul.hoffman@vpnc.org Wed May 23 09:00:42 2012 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 9A50321F8733 for ; Wed, 23 May 2012 09:00:42 -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 uodNaqTAbyYQ for ; Wed, 23 May 2012 09:00:42 -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 C617321F8466 for ; Wed, 23 May 2012 09:00:41 -0700 (PDT) Received: from [172.19.131.144] ([12.130.118.43]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4NG0Z8V081742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 May 2012 09:00:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> Date: Wed, 23 May 2012 09:00:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D9637B5-A87E-4A4F-9FC5-483938AE0984@vpnc.org> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> To: "Igoe, Kevin M." X-Mailer: Apple Mail (2.1278) Cc: cfrg@irtf.org Subject: [Cfrg] Parameter sizes (was: Cryptographic meta-principles) 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, 23 May 2012 16:00:42 -0000 On May 23, 2012, at 7:30 AM, Igoe, Kevin M. wrote: > 5. Moore=92s Law continually decreases an adversary=92s cost to = attack a system. so we must assume that eventually all parameter sizes = will need to be readjusted. This statement assumes that there are always parameter sizes, which is = incorrect. SHA2-256 does not have a parameter to make its strength 300 = bits; AES-128 does not have a parameter to make its strength 150 bits; = and so on. This is not just a pedantic discussion. For many cryptographic = functions, you cannot make them stronger by changing parameters: you = have to change algorithms. The operational cost of this is much higher = than the cost of telling an administrator to change a configuration = setting and then verifying that the setting was changed. --Paul Hoffman From smb@cs.columbia.edu Wed May 23 09:37:30 2012 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 20E3621F86D3 for ; Wed, 23 May 2012 09:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZKl4iMPweZW2 for ; Wed, 23 May 2012 09:37:29 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2596721F86CB for ; Wed, 23 May 2012 09:37:28 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4NGbQns009986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 May 2012 12:37:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Steven Bellovin In-Reply-To: <4D9637B5-A87E-4A4F-9FC5-483938AE0984@vpnc.org> Date: Wed, 23 May 2012 12:37:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> <4D9637B5-A87E-4A4F-9FC5-483938AE0984@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: cfrg@irtf.org Subject: Re: [Cfrg] Parameter sizes (was: Cryptographic meta-principles) 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, 23 May 2012 16:37:30 -0000 On May 23, 2012, at 12:00 35PM, Paul Hoffman wrote: > On May 23, 2012, at 7:30 AM, Igoe, Kevin M. wrote: >=20 >> 5. Moore=92s Law continually decreases an adversary=92s cost to = attack a system. so we must assume that eventually all parameter sizes = will need to be readjusted. >=20 > This statement assumes that there are always parameter sizes, which is = incorrect. SHA2-256 does not have a parameter to make its strength 300 = bits; AES-128 does not have a parameter to make its strength 150 bits; = and so on. The 256 and 128 *are* parameters -- but of the system design, not the = algorithm. (Both also have a number of rounds which is in principle = tunable, if not in reality, though Schneier suggested changing the = number of rounds for AES: = http://www.schneier.com/blog/archives/2009/07/another_new_aes.html) >=20 > This is not just a pedantic discussion. For many cryptographic = functions, you cannot make them stronger by changing parameters: you = have to change algorithms. The operational cost of this is much higher = than the cost of telling an administrator to change a configuration = setting and then verifying that the setting was changed. Sure -- which is why the protocol has to allow for changes in such = things, too, and not just in a config file setting. For example, one = can envision an IKEvN initial exchange where one side or the other = listed a round count for SHA++ or a blocksize parameter for Rijndael = (note: not AES, Rijndael). But the implications of such fields are very = different than the "let's negotiate a new algorithm entirely" idea, per = the paper that ekr and I wrote some years back about hash functions. --Steve Bellovin, https://www.cs.columbia.edu/~smb From ggr@qualcomm.com Wed May 23 10:08:09 2012 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 38ECD21F8709 for ; Wed, 23 May 2012 10:08:09 -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 301jEXALM5no for ; Wed, 23 May 2012 10:08:08 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2D30A21F86A3 for ; Wed, 23 May 2012 10:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ggr@qualcomm.com; q=dns/txt; s=qcdkim; t=1337792887; x=1369328887; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-id: content-transfer-encoding:mime-version; bh=Ws95JKaDTzMt3gyG6vq9Pm/UhbqBiBpQV82qboJAL8I=; b=f/UiTSw/B34L4v0/t6Q5WbrPoC9vNzZH8UQd/SMkyl6EJUq1O91gu3zM EFJwwRQTn0v5d4ukfm/O2E/lp1e8FGDHUFsaNHQe7azVbDGwzHfBWwsJ+ mFs3ZwAtAoA8I9Mya9KQoXMsMiqCzcCXedewZX3WpBQJOoZvdAtYnI8jZ 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6720"; a="193952837" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 23 May 2012 10:08:06 -0700 X-IronPort-AV: E=Sophos;i="4.75,645,1330934400"; d="scan'208";a="159348069" Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 May 2012 10:08:05 -0700 Received: from NASANEXD01D.na.qualcomm.com ([169.254.4.196]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0283.003; Wed, 23 May 2012 10:08:05 -0700 From: "Rose, Greg" To: Paul Hoffman Thread-Topic: [Cfrg] Parameter sizes (was: Cryptographic meta-principles) Thread-Index: AQHNOP1JguRByrGxQ0SY0UHcFWeScZbYENAA Date: Wed, 23 May 2012 17:08:04 +0000 Message-ID: <3EE86141-EBA1-4E4D-AC70-3CD783483533@qualcomm.com> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> <4D9637B5-A87E-4A4F-9FC5-483938AE0984@vpnc.org> In-Reply-To: <4D9637B5-A87E-4A4F-9FC5-483938AE0984@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7E4235E72C4C5741BB0DF64D6EEA1062@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rose, Greg" , "" Subject: Re: [Cfrg] Parameter sizes (was: Cryptographic meta-principles) 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, 23 May 2012 17:08:09 -0000 On 2012 May 23, at 9:00 , Paul Hoffman wrote: > On May 23, 2012, at 7:30 AM, Igoe, Kevin M. wrote: >=20 >> 5. Moore=92s Law continually decreases an adversary=92s cost to at= tack a system. so we must assume that eventually all parameter sizes will n= eed to be readjusted. >=20 > This statement assumes that there are always parameter sizes, which is in= correct. SHA2-256 does not have a parameter to make its strength 300 bits; = AES-128 does not have a parameter to make its strength 150 bits; and so on. >=20 > This is not just a pedantic discussion. For many cryptographic functions,= you cannot make them stronger by changing parameters: you have to change a= lgorithms. The operational cost of this is much higher than the cost of tel= ling an administrator to change a configuration setting and then verifying = that the setting was changed. Also, while Moore's law is exponential, we know there are physical limits. = Suitable parameter sizes like AES-256 are manageable today, but won't be co= mpromised by Moore's law in the forseeable future. If it breaks, it will be= because of new attacks or a new computing model. So I would change point 5= to say that there has to be provision for changing algorithms to adapt to = a changing world. Greg.= From marshall.eubanks@gmail.com Wed May 23 11:20:17 2012 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 2636021F8769 for ; Wed, 23 May 2012 11:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 t2w6yOhfmJKu for ; Wed, 23 May 2012 11:20:15 -0700 (PDT) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id C601421F8643 for ; Wed, 23 May 2012 11:20:14 -0700 (PDT) Received: by laai10 with SMTP id i10so7692399laa.13 for ; Wed, 23 May 2012 11:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dTfogv38myNsKvdvpPHq69t54w7+6iTxumiiXI9fhJU=; b=WCpjndFmiKYln5wSOfxXWtYBhisbFocZ7DFi4xMwOwe8kXAo5lanB9bk8+ChlwKupC 6KOiyVtDkYMFcO1UjU3MoDJ1nLP9FjVgvXEatysfLcmbURoThlwhq5CEgDTpp5tb8lAe 6UmiDwMxuynafo0GvIXge92EtE+jifNSXmdDzyJ6KCyspxr4QMQBfbHxxVpPegmPtuNp r9hC3vsVjxg1BvOGTzMESzAhs37mllA9iGcVy3XHAOS/YLUggjLBz/I/2vv6kzS5KCuN zoqIywuiJD5Ru3ClHimoRPQCMuFuN65pHZUpDMvZPRMv9xTkGqNfbR2qd7mYnEhm5Bnv oMiw== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr17894398lab.40.1337797213476; Wed, 23 May 2012 11:20:13 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Wed, 23 May 2012 11:20:13 -0700 (PDT) In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> Date: Wed, 23 May 2012 14:20:13 -0400 Message-ID: From: Marshall Eubanks To: "Igoe, Kevin M." Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: cfrg@irtf.org Subject: Re: [Cfrg] Cryptographic meta-principles 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, 23 May 2012 18:20:17 -0000 On Wed, May 23, 2012 at 10:30 AM, Igoe, Kevin M. wrote: > Some cryptographic meta-principles.=A0 Feel free to disagree or make > additions. =A0=A0=A0I think 2, 5, 7 and 8 > > are the most relevant to the CFRG. =A0=A0I always found #1 useful in anal= yzing > systems.=A0 Always > > ask =93where have we moved the risk?=94. > > > > 1.=A0=A0=A0=A0=A0=A0 You can=92t eliminate risk, you can just move it aro= und. > > 2.=A0=A0=A0=A0=A0=A0 Needless complexity is the enemy of security. > > 3.=A0=A0=A0=A0=A0=A0 There is no such thing as a secure algorithm, only a= secure > system.=A0=A0Even the most =93secure=94 algorithm, if used improperly, ca= n be > =A0worthless. =A0 Without the proper architecture, implementation, and > management we are effectively =93putting bank vault doors on cardboard bo= xes=94. > > 4.=A0=A0=A0=A0=A0=A0 In the end everything =A0comes down to =A0a cost ana= lysis: how much > does it cost an adversary to attempt to exploit a > given system and what is the adversary's expected gain from succeeding? O= ur > goal is to select cryptographic mechanisms and parameter sizes that make = the > adversary=92s expected return on investment negative. This is a classic one, but I am not sure how relevant it is to us. In the military, you can say something like "information about the movement of a platoon is only really important for a day or so, while information about the movement of an entire army may be sensitive for months, so we will use a much larger key size for army movement messages than for platoon movement messages." However, in the Internet, I do not think that we can make such judgements, at least not at the protocol level. We don't have control on how things are used. What is the value of a packet, say one containing an email ? Consider the recent Facebook IPO. There, an adversary's gain from inside information might easily have been $ 1 billion or more. And, yet, it is not common to use a more complicated encryption modes to send an email or hold a videoconference about a $16 billion IPO than for a kid's birthday party. So, in practice, the adversary's expected gain should always be regarded as infinite on the Internet. Likewise, the time of sensitivity is effectively forever, at least for some packets, which makes it effectively forever for all of them. Regards Marshall > > 5.=A0=A0=A0=A0=A0=A0 Moore=92s Law continually decreases an adversary=92s= cost to attack a > system. so we must assume that eventually all parameter sizes will need t= o > be readjusted. > > 6.=A0=A0=A0=A0=A0=A0 In the limit as the parameter size/number of rounds = goes to > infinity, almost anything is secure.=A0 The art is in picking mechanisms = and > parameter sizes that meet our needs efficiently. > > 7.=A0=A0=A0=A0=A0=A0 As far as possible, we should strive to provide a cr= yptographic > environment that is both practical and stable. > > 8.=A0=A0=A0=A0=A0=A0 We don=92t exist in a vacuum.=A0 We need to constant= ly monitor the > impact of current cryptographic practices on vendors and IETF working > groups, try to foresee =A0emerging requirements, monitor the results bein= g > produced by the cryptologic research community, and co-ordinate our effor= ts > with other standards bodies. > > > > Strive to be simple, practical and consistent, but always be aware that i= n > the long run change is inevitable. > > > > > > > > Kevin M. Igoe=A0=A0=A0=A0=A0=A0 =A0| =A0 "Everyone is entitled to their o= wn > kmigoe@nsa.gov=A0 =A0|=A0=A0=A0 opinions, but not to their own facts." > co-chair CFRG=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 - Daniel Patrick Moyn= ihan - > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From ge@weijers.org Wed May 23 15:20:34 2012 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 BC22B11E80B4 for ; Wed, 23 May 2012 15:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 xnjoZrpL1Toz for ; Wed, 23 May 2012 15:20:34 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id A0B0321F84DD for ; Wed, 23 May 2012 15:20:33 -0700 (PDT) Received: by werg1 with SMTP id g1so6554320wer.13 for ; Wed, 23 May 2012 15:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=weijers.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r7bE5pKid6DOhIJ8HIPjOdr7VwuICb3wIZ5mjrX8200=; b=hfI0iNmLBjP76U91g2APyr8PFGRx+7/XrvfhGwZBlL2Uslbp6S035gMhwi7CN1u7lH mw8GARwkq5FrO0dh8bsERtfrnfDtlQ/etepdoHyZMXr8KAqs3OLj36zzTsdSRGVrITKe Mk71iwg9xifd9MODTw6K/yCJ/3R8j7zjasrtw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=r7bE5pKid6DOhIJ8HIPjOdr7VwuICb3wIZ5mjrX8200=; b=mNEgYeZzuasefy1GU7IpUdfyikeF7+wdO6ZkUJQSgKlLmNAhRvc/nXCr9AruPPGtlo Z+Fd9E6zoLoiDJ0NzfdmbnueLBpwOiPOreuIFNLqLYQFyyUBVv68GNPZZ3vCbDNAuBXt jFXji3OdoHeGAQ9RehQo/M5VE7JVK/geLsa4XcxbC7HUpV2xa9YEXEb/7futk8xCGYuW USwxhtTTcFT2lzWO9U5pqFxihnedeax7k38xSsGZVaT/gpyE2dHyKVzPf7WPrHdTBI2M r007Z4E1fxiHdVaZMGO/jQaPaj60WnwQUtRMn6JUhseinfG0jbWOgFI0QWSOBtJ1Snso e91A== MIME-Version: 1.0 Received: by 10.216.208.221 with SMTP id q71mr2147967weo.174.1337811632425; Wed, 23 May 2012 15:20:32 -0700 (PDT) Received: by 10.223.44.198 with HTTP; Wed, 23 May 2012 15:20:32 -0700 (PDT) In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> Date: Wed, 23 May 2012 15:20:32 -0700 Message-ID: From: =?UTF-8?Q?G=C3=A9_Weijers?= To: "Igoe, Kevin M." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQntcwxeodCC8CXHt7OZmGVG7juUnw1CbdcTNurJAoiJr+OPQtitC97iyggd7PqaeOJTYXim Cc: cfrg@irtf.org Subject: Re: [Cfrg] Cryptographic meta-principles 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, 23 May 2012 22:20:34 -0000 On Wed, May 23, 2012 at 7:30 AM, Igoe, Kevin M. wrote: > 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Needless complexity is the enemy o= f security. Even if the complexity is unavoidable: it's _still_ the enemy of security. --=20 G=C3=A9 From vf@unity.net Wed May 23 22:03:44 2012 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 B88CA21F860D for ; Wed, 23 May 2012 22:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.34 X-Spam-Level: * X-Spam-Status: No, score=1.34 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_CHARSET_FARAWAY=2.45] 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 trsdUlzldcey for ; Wed, 23 May 2012 22:03:43 -0700 (PDT) Received: from vc.unity.net (140-242.trifle.net [195.24.140.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA1621F8585 for ; Wed, 23 May 2012 22:03:42 -0700 (PDT) Received: from vf by vc.unity.net with local (Exim 4.72) (envelope-from ) id 1SXQD6-0005s2-2e for cfrg@irtf.org; Thu, 24 May 2012 08:03:40 +0300 Date: Thu, 24 May 2012 08:03:39 +0300 From: Vadym Fedyukovych To: cfrg@irtf.org Message-ID: <20120524050339.GL19329@unity.net> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Cfrg] Cryptographic meta-principles 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, 24 May 2012 05:03:44 -0000 On Wed, May 23, 2012 at 03:20:32PM -0700, G?? Weijers wrote: > > 2.šššššš Needless complexity is the enemy of security. > > Even if the complexity is unavoidable: it's _still_ the enemy of security. At the same time, complexity of computational Diffie-Hellman problem often is the basis of security. > > -- From sfluhrer@cisco.com Thu May 24 09:41:11 2012 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 CB4AF21F869F for ; Thu, 24 May 2012 09:41:11 -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 hXs3l0n15MUB for ; Thu, 24 May 2012 09:41:11 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9809721F863F for ; Thu, 24 May 2012 09:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=1454; q=dns/txt; s=iport; t=1337877663; x=1339087263; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=3pMpJ2xqSXP2M43VdqBrHQ2A539ZWNXRkynxAq7s7wg=; b=Rw4XOmfY+OLpXqbCjWt2lmkanzRziqnoWMHuPspJSWBoMFCawj6zfxwQ z5oEY3eBdFM78VJPGlCFokW272xWuMa3TrI54PG5Oe226h7K3N8hkOrtN OoENQQpckNH+L3iblzO+2vYBABR3GG1VxYAqassOv/VbB2BYK/GVejNnh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGtkvk+rRDoJ/2dsb2JhbABDtGSBB4IVAQEBBAEBAQ8BHT4XBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggBGYdqAQubUaACin+EQGADiAwzmmWBZIMK X-IronPort-AV: E=Sophos;i="4.75,652,1330905600"; d="scan'208";a="46249918" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 24 May 2012 16:40:53 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4OGeqkl010098; Thu, 24 May 2012 16:40:52 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 09:40:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2012 09:40:50 -0700 Message-ID: In-Reply-To: <20120524050339.GL19329@unity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] Cryptographic meta-principles thread-index: Ac05ap5/cMYwIwtrRFalVbqsSIoS1AAYFCEA References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> <20120524050339.GL19329@unity.net> From: "Scott Fluhrer (sfluhrer)" To: "Vadym Fedyukovych" , X-OriginalArrivalTime: 24 May 2012 16:40:52.0654 (UTC) FILETIME=[FBA34CE0:01CD39CB] Subject: Re: [Cfrg] Cryptographic meta-principles 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, 24 May 2012 16:41:12 -0000 -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of = Vadym Fedyukovych Sent: Thursday, May 24, 2012 1:04 AM To: cfrg@irtf.org Subject: Re: [Cfrg] Cryptographic meta-principles On Wed, May 23, 2012 at 03:20:32PM -0700, G?? Weijers wrote: > > 2.=A0=A0=A0=A0=A0=A0 Needless complexity is the enemy of security. >=20 > Even if the complexity is unavoidable: it's _still_ the enemy of = security. At the same time, complexity of computational Diffie-Hellman problem often is the basis of security. Actually, we're talking about two aspects of "complexity": - Kevin, Steve and Marshall are talking about complexity from the = implementation's (the "good guys") point of view. The idea here is that = if you have a cryptographical system with a lot of moving parts, well, = then there's a lot that can go wrong. In contrast, a simple system is = considerably easier to analyze to make sure that there wasn't anything = we missed. Remember, it is implementation mistakes, not cryptographical = issues, that are far more likely to cause actual security problems - You are talking about complexity from the attacker's (the "bad guys") = point of view. We don't mind at all making his job harder; in fact, = that's rather the goal. >=20 > --=20 _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From marshall.eubanks@gmail.com Thu May 24 09:51:58 2012 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 38B8321F84FF for ; Thu, 24 May 2012 09:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 iuYaK5cub5Te for ; Thu, 24 May 2012 09:51:57 -0700 (PDT) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1906021F84D5 for ; Thu, 24 May 2012 09:51:56 -0700 (PDT) Received: by laai10 with SMTP id i10so8753652laa.13 for ; Thu, 24 May 2012 09:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YDGqV+8+Kfhma0ztUppekasZGITYqUAmR3iOdrB+CmA=; b=g1/rsEVMkxFhzWeL92txOunoDE8o0pxZCWvFk4p5ZmhvZjdOLfRfnBh+NQQFUTuYrC U6vXv+Y4JSsndtoyhKy0Y20ri0Cb5nEx2P9HcLVRWjD9F8mcY9+Iq1eDxrhWHGnrawN6 6xAoxj0ZOaC+okj76AZdll5q9+MaOJi24BZB7oaDr0UM8lXLoUo5SaaGJslzAoTWKhnH T+TSNgr7ZqW6+QuNFSzOoI5T4zmPf4CUwKE2gh1XZG9d9qpm6N1hxmDudjkXLnYc6ZcD ZX4rtkPgewZhtb0EXaO06Cj4wKjIFng+VXy7xReUTGNnhWRPw/h7GdDm7F+yprihhW0V s7jw== MIME-Version: 1.0 Received: by 10.112.32.33 with SMTP id f1mr49030lbi.54.1337878315934; Thu, 24 May 2012 09:51:55 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Thu, 24 May 2012 09:51:55 -0700 (PDT) In-Reply-To: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> <20120524050339.GL19329@unity.net> Date: Thu, 24 May 2012 12:51:55 -0400 Message-ID: From: Marshall Eubanks To: "Scott Fluhrer (sfluhrer)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cfrg@irtf.org Subject: Re: [Cfrg] Cryptographic meta-principles 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, 24 May 2012 16:51:58 -0000 On Thu, May 24, 2012 at 12:40 PM, Scott Fluhrer (sfluhrer) wrote: > > > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of V= adym Fedyukovych > Sent: Thursday, May 24, 2012 1:04 AM > To: cfrg@irtf.org > Subject: Re: [Cfrg] Cryptographic meta-principles > > On Wed, May 23, 2012 at 03:20:32PM -0700, G?? Weijers wrote: >> > 2.=A0=A0=A0=A0=A0=A0 Needless complexity is the enemy of security. >> >> Even if the complexity is unavoidable: it's _still_ the enemy of securit= y. > > At the same time, complexity of computational Diffie-Hellman problem > often is the basis of security. > > Actually, we're talking about two aspects of "complexity": > > - Kevin, Steve and Marshall are talking about complexity from the impleme= ntation's (the "good guys") point of view. =A0The idea here is that if you = have a cryptographical system with a lot of moving parts, well, then there'= s a lot that can go wrong. =A0In contrast, a simple system is considerably = easier to analyze to make sure that there wasn't anything we missed. =A0Rem= ember, it is implementation mistakes, not cryptographical issues, that are = far more likely to cause actual security problems + (This is why I will be dubious about at least the first implementation of quantum cryptography.) Regards Marshall > > - You are talking about complexity from the attacker's (the "bad guys") p= oint of view. =A0We don't mind at all making his job harder; in fact, that'= s rather the goal. > >> >> -- > _______________________________________________ > 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 SChokhani@cygnacom.com Thu May 24 09:52:40 2012 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 1682A21F862B for ; Thu, 24 May 2012 09:52:40 -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 0T3I8DTmuKzx for ; Thu, 24 May 2012 09:52:39 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD4C21F84FF for ; Thu, 24 May 2012 09:52:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,652,1330923600"; d="scan'208";a="5099425" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 24 May 2012 12:52:15 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 24 May 2012 12:52:14 -0400 From: Santosh Chokhani To: "Scott Fluhrer (sfluhrer)" , Vadym Fedyukovych , "cfrg@irtf.org" Date: Thu, 24 May 2012 12:52:13 -0400 Thread-Topic: [Cfrg] Cryptographic meta-principles Thread-Index: Ac05ap5/cMYwIwtrRFalVbqsSIoS1AAYFCEAAACiWcA= Message-ID: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov> <20120524050339.GL19329@unity.net> 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 Subject: Re: [Cfrg] Cryptographic meta-principles 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, 24 May 2012 16:52:40 -0000 Simply stated one is "computational complexity" and the other is "software/= system complexity" -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Sco= tt Fluhrer (sfluhrer) Sent: Thursday, May 24, 2012 12:41 PM To: Vadym Fedyukovych; cfrg@irtf.org Subject: Re: [Cfrg] Cryptographic meta-principles -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Vad= ym Fedyukovych Sent: Thursday, May 24, 2012 1:04 AM To: cfrg@irtf.org Subject: Re: [Cfrg] Cryptographic meta-principles On Wed, May 23, 2012 at 03:20:32PM -0700, G?? Weijers wrote: > > 2.=A0=A0=A0=A0=A0=A0 Needless complexity is the enemy of security. >=20 > Even if the complexity is unavoidable: it's _still_ the enemy of security= . At the same time, complexity of computational Diffie-Hellman problem often = is the basis of security. Actually, we're talking about two aspects of "complexity": - Kevin, Steve and Marshall are talking about complexity from the implement= ation's (the "good guys") point of view. The idea here is that if you have= a cryptographical system with a lot of moving parts, well, then there's a = lot that can go wrong. In contrast, a simple system is considerably easier= to analyze to make sure that there wasn't anything we missed. Remember, i= t is implementation mistakes, not cryptographical issues, that are far more= likely to cause actual security problems - You are talking about complexity from the attacker's (the "bad guys") poi= nt of view. We don't mind at all making his job harder; in fact, that's ra= ther the goal. >=20 > -- _______________________________________________ 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 zhou.sujing@zte.com.cn Thu May 24 18:40:23 2012 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 7DD3711E8098 for ; Thu, 24 May 2012 18:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.64 X-Spam-Level: X-Spam-Status: No, score=-93.64 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, 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 pScS9gNvkWvM for ; Thu, 24 May 2012 18:40:22 -0700 (PDT) Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id DEA3711E8080 for ; Thu, 24 May 2012 18:40:21 -0700 (PDT) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 33453.1065689647; Fri, 25 May 2012 09:40:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q4P1e7mg093519; Fri, 25 May 2012 09:40:07 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: dharkins@lounge.org, cfrg@irtf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 25 May 2012 09:39:52 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-25 09:40:08, Serialize complete at 2012-05-25 09:40:08 Content-Type: multipart/alternative; boundary="=_alternative 0009343148257A09_=" X-MAIL: mse02.zte.com.cn q4P1e7mg093519 Subject: [Cfrg] =?gb2312?b?obBwYXNzd29yZC1iYXNlZCBrZXkgZXhjaGFuZ2WhsXJl?= =?gb2312?b?dmlzaXRlZA==?= 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, 25 May 2012 01:40:23 -0000 This is a multipart message in MIME format. --=_alternative 0009343148257A09_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QXMgaW4gdGhlIGNhbGN1bGF0aW9uIG9mICJLID0gUEVeKHBlZXJfcmFuZCpsb2NhbF9yYW5kKSBt b2QgcCINCksgY2FuIGJlIHJlZHVjZWQgdG8gUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcits b2NhbF9tYXNrKnBlZXJfbWFzaykgDQoqKHBlZXJfZWxlbWVudCleKGxvY2FsX3NjYWxhcikqKGxv Y2FsX2VsZW1lbnQpXihwZWVyX3NjYWxhcikgbW9kIHANCg0KSyA9IFBFXihwZWVyX3JhbmQqbG9j YWxfcmFuZCkgbW9kIHANCiAgID1QRV5bKCBwZWVyX3NjYWxhci1wZWVyX21hc2spKihsb2NhbF9z Y2FsYXItbG9jYWxfbWFzayldIG1vZCBwDQogDQo9UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxh ci1wZWVyX21hc2sqbG9jYWxfc2NhbGFyLWxvY2FsX21hc2sqcGVlcl9zY2FsYXIrbG9jYWxfbWFz aypwZWVyX21hc2spIA0KbW9kIHANCiAgID1QRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyK2xv Y2FsX21hc2sqcGVlcl9tYXNrKSANCioocGVlcl9lbGVtZW50KV4obG9jYWxfc2NhbGFyKSoobG9j YWxfZWxlbWVudCleKHBlZXJfc2NhbGFyKSBtb2QgcA0KDQpCZWNhdXNlICAocGVlcl9lbGVtZW50 KV4obG9jYWxfc2NhbGFyKSoobG9jYWxfZWxlbWVudCleKHBlZXJfc2NhbGFyKSBjYW4gDQpiZSBj YWxjdWxhdGVkIGRpcmVjdGx5IGZyb20gdGhlIGtleSBleGNoYW5nZSBtZXNzYWdlLA0KdGhlIGVm ZmVjdGl2ZSBwYXJ0IG9mIEsgaXMgDQpQRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyK2xvY2Fs X21hc2sqcGVlcl9tYXNrKSwgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCANCiBsb2NhbF9yYW5kIGFu ZCBwZWVyX3JhbmQsDQpzbyB0aGUgcGFzc3dvcmQgYmFzZWQga2V5IGV4Y2hhbmdlIGlzIGVzc2Vu dGlhbGx5IGVxdWFsIHdpdGggdGhlIGZvbGxvd2luZyANCiJleGNoYW5nZSKjug0KDQoNCg0KMicu IGdlbmVyYXRlIDIgcmFuZG9tIG51bWJlcnMgYmV0d2VlbiAwIGFuZCB0aGUgb3JkZXIgb2YgdGhl IGdyb3VwLCBxOg0KDQogICAwIDwgbG9jYWxfbWFzayxsb2NhbF9zY2FsYXIgPCBxDQoNCjMnLiBj b21wdXRlIGFuIGVsZW1lbnQ6DQogICBsb2NhbF9lbGVtZW50ID0gMS8oUEVebG9jYWxfbWFzaykg bW9kIHANCg0KICAgd2hlcmUgcCBpcyB0aGUgcHJpbWUgYW5kIHEgaXMgdGhlIG9yZGVyLiBTZW5k IGxvY2FsX3NjYWxhciBhbmQNCiAgIGxvY2FsX2VsZW1lbnQgdG8gb3RoZXIgc2lkZQ0KDQo0Jy4g cmVjZWl2ZSBwZWVyX3NjYWxhciBhbmQgcGVlcl9lbGVtZW50IGZyb20gb3RoZXIgc2lkZQ0KDQo1 Jy4gY29tcHV0ZSBzaGFyZWQga2V5LCBLDQoNCiAgIEsgPVBFXihwZWVyX3NjYWxhcipsb2NhbF9z Y2FsYXIpKiAocGVlcl9lbGVtZW50KV4oLWxvY2FsX21hc2spIG1vZCBwDQogICAgID1QRV4ocGVl cl9zY2FsYXIqbG9jYWxfc2NhbGFyK2xvY2FsX21hc2sqcGVlcl9tYXNrKSBtb2QgcA0KDQpJdCBp cyBzaW1wbGVyIGFuZCBsZXNzIGNvbXB1dGF0aW9uIGludmxvdmVkLCBhbmQgaG9wZWZ1bGx5IGVh c2llciB0byANCmFuYWx5c2lzIHRoZSBzZWN1cml0eS4NCg0KDQoNCkZyb206ICJEYW4gSGFya2lu cyIgPGRoYXJraW5zIGF0IGxvdW5nZS5vcmc+IA0KRGF0ZTogVHVlLCAyMCBEZWMgMjAxMSAxMzoz ODowOSAtMDgwMCAoUFNUKSANCiAgSGVsbG8sDQoNCiAgSSBwcm9wb3NlZCBhIG5ldyBUTFMgY2lw aGVyc3VpdGUgdXNpbmcgYSB6ZXJvIGtub3dsZWRnZSBwcm9vZiBhdA0KSUVURiA4MiBpbiBUYWlw ZWkuIFRoZSBkcmFmdCBpcyBoZXJlOg0KDQogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaGFya2lucy10bHMtcHdkLTAxDQoNCkF0IHRoZSBUTFMgV0cgbWVldGluZyBJIHdh cyByZXF1ZXN0ZWQgdG8gYXNrIHBlb3BsZSBvbiB0aGUgQ0ZSRyBsaXN0DQp3aXRoIGV4cGVydGlz ZSBpbiB0aGlzIGZpZWxkIHRvIHRha2UgYSBsb29rIGF0IGl0LiBTbyBoZXJlIEkgYW0sIGFza2lu Zy4NCklmIHNvbWVvbmUgaGFzIHNvbWUgc3BhcmUgY3ljbGVzIHRoaXMgaG9saWRheSBzZWFzb24s IGlmIHlvdSBqdXN0IGdvdHRhDQpnZXQgYXdheSBmcm9tIHRoZSByZWxhdGl2ZXMsIG9yIHlvdSBh cmUganVzdCBmZWVsaW5nIGluIHRoZSBnaXZpbmcgbW9vZCwNCnBsZWFzZSB0YWtlIGEgbG9vayBh bmQgY29tbWVudC4gQW55IGFuYWx5c2lzIG9uIHRoaXMgd291bGQgYmUgZ3JlYXRseQ0KYXBwcmVj aWF0ZWQuIChJIHRyaWVkIHRvIGRvIGEgZm9ybWFsIHByb29mIGJ1dCBJIGNhbm5vdCwgYW5kIHRo YXQncw0Kd2hhdCdzIHByb21wdGluZyB0aGlzKS4NCg0KICBJIGNhbiBkZXNjcmliZSB0aGUga2V5 IGV4Y2hhbmdlIGJyb2FkbHkgaGVyZS4gVGhlcmUgYXJlIHN1YnRsZQ0KZGlmZmVyZW5jZXMgaW4g dGhlIGRyYWZ0LS0gbGlrZSBvbmUgc2lkZSBrZWVwcyBhIHNhbHRlZCB2ZXJzaW9uIG9mIHRoZQ0K cGFzc3dvcmQgYW5kIGNvbW11bmljYXRlcyB0aGUgc2FsdCBkdXJpbmcgYSBIRUxMTyBtZXNzYWdl LS0gdGhhdCBkb24ndA0KYWZmZWN0IHRoZSBleGNoYW5nZS4gSXQgaXMgc3ltbWV0cmljIHNvIEkg Y2FuIGRlc2NyaWJlIGl0IGZyb20gb25lIHNpZGUncw0KcGVyc3BlY3RpdmUuIFRoZSBzaWRlIGJl aW5nIGRlc2NyaWJlZCBpcyAibG9jYWwiIGFuZCB0aGUgb3RoZXIgc2lkZSBpcw0KInBlZXIiLCBp dCBnb2VzIGxpa2UgdGhpczoNCg0KR2l2ZW46IGxvY2FsIElELCBwZWVyIElELCBwYXNzd29yZCwg YW4gYWdyZWVkLXVwb24gc2V0IG9mIGRvbWFpbg0KcGFyYW1ldGVycyBkZWZpbmluZyBhIGZpbml0 ZSBmaWVsZCBncm91cCAoaXQgd29ya3Mgd2lsbCBlbGxpcHRpYw0KY3VydmUgY3J5cHRvIHRvbykg YW5kIHVzaW5nIHR3byBmdW5jdGlvbjoNCg0KICAtIEUgPSBIYXNoVG9FbGVtZW50KGQpIHdoaWNo IHRha2VzIHNvbWUgZGF0YSwgZCwgYW5kIGhhc2hlcyBpbnRvDQogICAgdGhlIGZpbml0ZSBmaWVs ZCB0byByZXR1cm4gYW4gZWxlbWVudCwgRS4NCiAgLSB4ID0gSCh5KSByZXR1cm5zIGEgcmFuZG9t IHN0cmVhbSwgeCwgZ2l2ZW4gc29tZSBpbnB1dCwgeS4NCg0KVGhlIGtleSBleGNoYW5nZSB3b3Jr cyBsaWtlIHRoaXM6DQoNCjEuIFBFID0gSGFzaFRvRWxlbWVudChsb2NhbF9JRCB8IHBlZXJfSUQg fCBwYXNzd29yZCkNCiAgIGdldHMgYSAicGFzc3dvcmQgZWxlbWVudCINCg0KICAgVGhlcmUgaXMg YW4gb3JkZXJpbmcgZGVmaW5lZCBpbiB0aGUgZHJhZnQgdG8gZW5zdXJlIHRoYXQgdGhlIElEcw0K ICAgYXJlIHB1dCBpbiB0aGUgc2FtZSBvcmRlciBvbiBlYWNoIHNpZGUuDQoNCjIuIGdlbmVyYXRl IDIgcmFuZG9tIG51bWJlcnMgYmV0d2VlbiAwIGFuZCB0aGUgb3JkZXIgb2YgdGhlIGdyb3VwLCBx Og0KDQogICAwIDwgbG9jYWxfcmFuZCwgbG9jYWxfbWFzayA8IHENCg0KMy4gY29tcHV0ZSBhIHNj YWxhciBhbmQgYW4gZWxlbWVudDoNCiAgIGxvY2FsX3NjYWxhciA9IChsb2NhbF9yYW5kICsgbG9j YWxfbWFzaykgbW9kIHENCiAgIGxvY2FsX2VsZW1lbnQgPSAxLyhQRV5sb2NhbF9tYXNrKSBtb2Qg cA0KDQogICB3aGVyZSBwIGlzIHRoZSBwcmltZSBhbmQgcSBpcyB0aGUgb3JkZXIuIFNlbmQgbG9j YWxfc2NhbGFyIGFuZA0KICAgbG9jYWxfZWxlbWVudCB0byBvdGhlciBzaWRlDQoNCjQuIHJlY2Vp dmUgcGVlcl9zY2FsYXIgYW5kIHBlZXJfZWxlbWVudCBmcm9tIG90aGVyIHNpZGUNCg0KNS4gY29t cHV0ZSBzaGFyZWQga2V5LCBLDQoNCiAgIEsgPSAoUEVecGVlcl9zY2FsYXIgKiBwZWVyX2VsZW1l bnQpXmxvY2FsX3JhbmQgbW9kIHAgPQ0KICAgICAgIChQRV4ocGVlcl9yYW5kICsgcGVlcl9tYXNr KSAqIFBFXigtcGVlcl9tYXNrKSlebG9jYWxfcmFuZCBtb2QgcCA9DQogICAgICAgUEVeKHBlZXJf cmFuZCpsb2NhbF9yYW5kKSBtb2QgcA0KDQo2LiBjb21wdXRlIGEgY29uZmlybWF0aW9uDQoNCiAg IGxvY2FsX2NvbmZpcm0gPSBIKEssIGxvY2FsX3NjYWxhciB8IGxvY2FsX2VsZW1lbnQgfA0KICAg ICAgICAgICAgICAgICAgICAgcGVlcl9zY2FsYXIgfCBwZWVyX2VsZW1lbnQpDQoNCiAgIHNlbmQg Y29uZmlybWF0aW9uIHRvIHBlZXINCg0KNy4gcmVjZWl2ZSBwZWVyJ3MgY29uZmlybWF0aW9uLCBj YWxjdWxhdGUgdmVyaWZpZXINCg0KICAgdmVyaWZpZXIgPSBIKEssIHBlZXJfc2NhbGFyIHwgcGVl cl9lbGVtZW50IHwgbG9jYWxfc2NhbGFyIHwNCiAgICAgICAgICAgICAgICBsb2NhbF9lbGVtZW50 KQ0KDQogICBpZiB2ZXJpZmllciBlcXVhbHMgcGVlcidzIGNvbmZpcm1hdGlvbiB0aGUgcGVlciBp cyBhdXRoZW50aWNhdGVkLg0KDQpUaGUgcGVlciBkb2VzIHRoZSBzYW1lIHRoaW5nIGJ1dCBmcm9t IGl0cyBwZXJzcGVjdGl2ZSBpdCBpcyAibG9jYWwiDQphbmQgdGhlIHNpZGUgZGVzY3JpYmVkIGFi b3ZlIGlzICJwZWVyIi4NCg0KICBUaGFuayB5b3UgaW4gYWR2YW5jZSBmb3IgYW55IGFuYWx5c2lz IHRoYXQgY2FuIGJlIHByb3ZpZGVkIG9uIHRoaXMNCmV4Y2hhbmdlLg0KDQogIHJlZ2FyZHMsDQoN Cg0KDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHN+fn4NCg0KLVN1amluZyBaaG91DQo= --=_alternative 0009343148257A09_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIGluIHRoZSBjYWxjdWxhdGlv biBvZiAmcXVvdDtLID0gUEVeKHBlZXJfcmFuZCpsb2NhbF9yYW5kKQ0KbW9kIHAmcXVvdDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPksgY2FuIGJlIHJlZHVjZWQg dG8gUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFzaykNCioo cGVlcl9lbGVtZW50KV4obG9jYWxfc2NhbGFyKSoobG9jYWxfZWxlbWVudCleKHBlZXJfc2NhbGFy KSBtb2QgcDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ SyA9IFBFXihwZWVyX3JhbmQqbG9jYWxfcmFuZCkgbW9kIHA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDs9UEVeWyggcGVlcl9zY2FsYXItcGVl cl9tYXNrKSoobG9jYWxfc2NhbGFyLWxvY2FsX21hc2spXQ0KbW9kIHA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDs9UEVeKHBlZXJfc2NhbGFy KmxvY2FsX3NjYWxhci1wZWVyX21hc2sqbG9jYWxfc2NhbGFyLWxvY2FsX21hc2sqcGVlcl9zY2Fs YXIrbG9jYWxfbWFzaypwZWVyX21hc2spDQptb2QgcDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOz1QRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2Nh bGFyK2xvY2FsX21hc2sqcGVlcl9tYXNrKQ0KKihwZWVyX2VsZW1lbnQpXihsb2NhbF9zY2FsYXIp Kihsb2NhbF9lbGVtZW50KV4ocGVlcl9zY2FsYXIpIG1vZCBwPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZWNhdXNlICZuYnNwOyhwZWVyX2VsZW1lbnQp Xihsb2NhbF9zY2FsYXIpKihsb2NhbF9lbGVtZW50KV4ocGVlcl9zY2FsYXIpDQpjYW4gYmUgY2Fs Y3VsYXRlZCBkaXJlY3RseSBmcm9tIHRoZSBrZXkgZXhjaGFuZ2UgbWVzc2FnZSw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBlZmZlY3RpdmUgcGFydCBvZiBL IGlzICZuYnNwO1BFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIrbG9jYWxfbWFzaypwZWVyX21h c2spLA0KaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCAmbmJzcDtsb2NhbF9yYW5kIGFuZCBwZWVyX3Jh bmQsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zbyB0aGUgcGFz c3dvcmQgYmFzZWQga2V5IGV4Y2hhbmdlIGlzDQplc3NlbnRpYWxseSBlcXVhbCB3aXRoIHRoZSBm b2xsb3dpbmcgJnF1b3Q7ZXhjaGFuZ2UmcXVvdDujujwvZm9udD4NCjxicj4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MicuIGdlbmVyYXRlIDIgcmFuZG9t IG51bWJlcnMgYmV0d2Vlbg0KMCBhbmQgdGhlIG9yZGVyIG9mIHRoZSBncm91cCwgcTo8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsw ICZsdDsgbG9jYWxfPC9mb250Pjxmb250IHNpemU9Mj5tYXNrPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4sbG9jYWxfc2NhbGFyDQombHQ7IHE8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMnLiBjb21wdXRlIGFuIGVsZW1lbnQ6PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bG9j YWxfZWxlbWVudCA9IDEvKFBFXmxvY2FsX21hc2spDQptb2QgcDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3doZXJlIHAgaXMgdGhl IHByaW1lIGFuZA0KcSBpcyB0aGUgb3JkZXIuIFNlbmQgbG9jYWxfc2NhbGFyIGFuZDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2xvY2FsX2Vs ZW1lbnQgdG8gb3RoZXINCnNpZGU8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjQnLiByZWNlaXZlIHBlZXJfc2NhbGFyIGFuZCBwZWVyX2VsZW1lbnQNCmZy b20gb3RoZXIgc2lkZTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+NScuIGNvbXB1dGUgc2hhcmVkIGtleSwgSzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0sgPTwvZm9udD48Zm9udCBzaXpl PTI+UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikqDQoocGVlcl9lbGVtZW50KV4oLWxvY2Fs X21hc2spIG1vZCBwPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNw Oz1QRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyK2xvY2FsX21hc2sqcGVlcl9tYXNrKQ0KbW9k IHA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IGlz IHNpbXBsZXIgYW5kIGxlc3MgY29tcHV0YXRpb24gaW52bG92ZWQsDQphbmQgaG9wZWZ1bGx5IGVh c2llciB0byBhbmFseXNpcyB0aGUgc2VjdXJpdHkuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmcXVvdDtEYW4gSGFya2lu cyZxdW90OyAmbHQ7ZGhhcmtpbnMNCmF0IGxvdW5nZS5vcmcmZ3Q7IDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTogVHVlLCAyMCBEZWMgMjAxMSAxMzozODow OSAtMDgwMA0KKFBTVCkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgSGVsbG8sPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgSSBwcm9wb3NlZCBhIG5ldyBUTFMgY2lwaGVyc3VpdGUNCnVzaW5nIGEg emVybyBrbm93bGVkZ2UgcHJvb2YgYXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPklFVEYgODIgaW4gVGFpcGVpLiBUaGUgZHJhZnQgaXMgaGVyZTo8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmtpbnMtdGxzLXB3 ZC0wMTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXQg dGhlIFRMUyBXRyBtZWV0aW5nIEkgd2FzIHJlcXVlc3RlZA0KdG8gYXNrIHBlb3BsZSBvbiB0aGUg Q0ZSRyBsaXN0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj53aXRo IGV4cGVydGlzZSBpbiB0aGlzIGZpZWxkIHRvIHRha2UNCmEgbG9vayBhdCBpdC4gU28gaGVyZSBJ IGFtLCBhc2tpbmcuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5J ZiBzb21lb25lIGhhcyBzb21lIHNwYXJlIGN5Y2xlcyB0aGlzDQpob2xpZGF5IHNlYXNvbiwgaWYg eW91IGp1c3QgZ290dGE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PmdldCBhd2F5IGZyb20gdGhlIHJlbGF0aXZlcywgb3IgeW91DQphcmUganVzdCBmZWVsaW5nIGlu IHRoZSBnaXZpbmcgbW9vZCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnBsZWFzZSB0YWtlIGEgbG9vayBhbmQgY29tbWVudC4gQW55DQphbmFseXNpcyBvbiB0aGlz IHdvdWxkIGJlIGdyZWF0bHk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmFwcHJlY2lhdGVkLiAoSSB0cmllZCB0byBkbyBhIGZvcm1hbA0KcHJvb2YgYnV0IEkgY2Fu bm90LCBhbmQgdGhhdCdzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij53aGF0J3MgcHJvbXB0aW5nIHRoaXMpLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEkgY2FuIGRlc2NyaWJlIHRoZSBrZXkgZXhjaGFuZ2UN CmJyb2FkbHkgaGVyZS4gVGhlcmUgYXJlIHN1YnRsZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+ZGlmZmVyZW5jZXMgaW4gdGhlIGRyYWZ0LS0gbGlrZSBvbmUNCnNp ZGUga2VlcHMgYSBzYWx0ZWQgdmVyc2lvbiBvZiB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPnBhc3N3b3JkIGFuZCBjb21tdW5pY2F0ZXMgdGhlIHNhbHQgZHVy aW5nDQphIEhFTExPIG1lc3NhZ2UtLSB0aGF0IGRvbid0PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5hZmZlY3QgdGhlIGV4Y2hhbmdlLiBJdCBpcyBzeW1tZXRyaWMN CnNvIEkgY2FuIGRlc2NyaWJlIGl0IGZyb20gb25lIHNpZGUnczwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cGVyc3BlY3RpdmUuIFRoZSBzaWRlIGJlaW5nIGRlc2Ny aWJlZA0KaXMgJnF1b3Q7bG9jYWwmcXVvdDsgYW5kIHRoZSBvdGhlciBzaWRlIGlzPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtwZWVyJnF1b3Q7LCBpdCBn b2VzIGxpa2UgdGhpczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkdpdmVuOiBsb2NhbCBJRCwgcGVlciBJRCwgcGFzc3dvcmQsDQphbiBhZ3JlZWQtdXBv biBzZXQgb2YgZG9tYWluPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5wYXJhbWV0ZXJzIGRlZmluaW5nIGEgZmluaXRlIGZpZWxkIGdyb3VwDQooaXQgd29ya3Mgd2ls bCBlbGxpcHRpYzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Y3Vy dmUgY3J5cHRvIHRvbykgYW5kIHVzaW5nIHR3byBmdW5jdGlvbjo8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAtIEUgPSBIYXNoVG9FbGVtZW50 KGQpIHdoaWNoDQp0YWtlcyBzb21lIGRhdGEsIGQsIGFuZCBoYXNoZXMgaW50bzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyB0aGUgZmluaXRl IGZpZWxkIHRvIHJldHVybg0KYW4gZWxlbWVudCwgRS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAtIHggPSBIKHkpIHJldHVybnMgYSByYW5kb20gc3Ry ZWFtLA0KeCwgZ2l2ZW4gc29tZSBpbnB1dCwgeS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBrZXkgZXhjaGFuZ2Ugd29ya3MgbGlrZSB0aGlzOjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gUEUgPSBI YXNoVG9FbGVtZW50KGxvY2FsX0lEIHwgcGVlcl9JRA0KfCBwYXNzd29yZCk8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtnZXRzIGEgJnF1b3Q7 cGFzc3dvcmQgZWxlbWVudCZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1RoZXJlIGlzIGFuIG9yZGVyaW5nIGRlZmluZWQN CmluIHRoZSBkcmFmdCB0byBlbnN1cmUgdGhhdCB0aGUgSURzPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YXJlIHB1dCBpbiB0aGUgc2FtZSBv cmRlcg0Kb24gZWFjaCBzaWRlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Mi4gZ2VuZXJhdGUgMiByYW5kb20gbnVtYmVycyBiZXR3ZWVuDQowIGFuZCB0 aGUgb3JkZXIgb2YgdGhlIGdyb3VwLCBxOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzAgJmx0OyBsb2NhbF9yYW5kLCBsb2NhbF9t YXNrDQombHQ7IHE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjMuIGNvbXB1dGUgYSBzY2FsYXIgYW5kIGFuIGVsZW1lbnQ6PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bG9jYWxfc2NhbGFyID0gKGxv Y2FsX3JhbmQNCisgbG9jYWxfbWFzaykgbW9kIHE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtsb2NhbF9lbGVtZW50ID0gMS8oUEVebG9jYWxf bWFzaykNCm1vZCBwPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7d2hlcmUgcCBpcyB0aGUgcHJpbWUgYW5kDQpxIGlzIHRoZSBvcmRl ci4gU2VuZCBsb2NhbF9zY2FsYXIgYW5kPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bG9jYWxfZWxlbWVudCB0byBvdGhlcg0Kc2lkZTwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NC4gcmVjZWl2ZSBw ZWVyX3NjYWxhciBhbmQgcGVlcl9lbGVtZW50DQpmcm9tIG90aGVyIHNpZGU8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjUuIGNvbXB1dGUgc2hhcmVkIGtl eSwgSzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwO0sgPSAoUEVecGVlcl9zY2FsYXIgKiBwZWVyX2VsZW1lbnQpXmxvY2FsX3JhbmQN Cm1vZCBwID08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyhQRV4ocGVlcl9yYW5kDQorIHBlZXJfbWFzaykgKiBQRV4o LXBlZXJfbWFzaykpXmxvY2FsX3JhbmQgbW9kIHAgPTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UEVeKHBlZXJfcmFu ZCpsb2NhbF9yYW5kKQ0KbW9kIHA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjYuIGNvbXB1dGUgYSBjb25maXJtYXRpb248L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtsb2NhbF9jb25maXJt ID0gSChLLCBsb2NhbF9zY2FsYXINCnwgbG9jYWxfZWxlbWVudCB8PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BlZXJfc2NhbGFy IHwgcGVlcl9lbGVtZW50KTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3NlbmQgY29uZmlybWF0aW9uIHRvIHBlZXI8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjcuIHJlY2VpdmUgcGVlcidz IGNvbmZpcm1hdGlvbiwgY2FsY3VsYXRlDQp2ZXJpZmllcjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3ZlcmlmaWVyID0gSChLLCBw ZWVyX3NjYWxhcg0KfCBwZWVyX2VsZW1lbnQgfCBsb2NhbF9zY2FsYXIgfDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgbG9jYWxfZWxlbWVudCk8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtpZiB2ZXJp ZmllciBlcXVhbHMgcGVlcidzDQpjb25maXJtYXRpb24gdGhlIHBlZXIgaXMgYXV0aGVudGljYXRl ZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBw ZWVyIGRvZXMgdGhlIHNhbWUgdGhpbmcgYnV0IGZyb20NCml0cyBwZXJzcGVjdGl2ZSBpdCBpcyAm cXVvdDtsb2NhbCZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+YW5kIHRoZSBzaWRlIGRlc2NyaWJlZCBhYm92ZSBpcyAmcXVvdDtwZWVyJnF1b3Q7LjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFRoYW5r IHlvdSBpbiBhZHZhbmNlIGZvciBhbnkNCmFuYWx5c2lzIHRoYXQgY2FuIGJlIHByb3ZpZGVkIG9u IHRoaXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmV4Y2hhbmdl LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 IHJlZ2FyZHMsPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5S ZWdhcmRzfn5+PGJyPg0KPGJyPg0KLVN1amluZyBaaG91PC9mb250Pg0K --=_alternative 0009343148257A09_=-- From dharkins@lounge.org Sun May 27 21:35:42 2012 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 9D02B21F853D for ; Sun, 27 May 2012 21:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 uuiLwd9qRtsN for ; Sun, 27 May 2012 21:35:41 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E021F8494 for ; Sun, 27 May 2012 21:35:41 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 98F7D10224008; Sun, 27 May 2012 21:35:40 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 27 May 2012 21:35:40 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Sun, 27 May 2012 21:35:40 -0700 (PDT) From: "Dan Harkins" To: zhou.sujing@zte.com.cn User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org Subject: Re: [Cfrg] =?iso-8859-1?q?=A1=B0password-based_key_exchange=A1=B1revi?= =?iso-8859-1?q?sited?= 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, 28 May 2012 04:35:43 -0000 Hello, Thank you very much for your analysis of my protocol. On Thu, May 24, 2012 6:39 pm, zhou.sujing@zte.com.cn wrote: > As in the calculation of "K = PE^(peer_rand*local_rand) mod p" > K can be reduced to PE^(peer_scalar*local_scalar+local_mask*peer_mask) > *(peer_element)^(local_scalar)*(local_element)^(peer_scalar) mod p > > K = PE^(peer_rand*local_rand) mod p > =PE^[( peer_scalar-peer_mask)*(local_scalar-local_mask)] mod p > > =PE^(peer_scalar*local_scalar-peer_mask*local_scalar-local_mask*peer_scalar+local_mask*peer_mask) > mod p > =PE^(peer_scalar*local_scalar+local_mask*peer_mask) > *(peer_element)^(local_scalar)*(local_element)^(peer_scalar) mod p > > Because (peer_element)^(local_scalar)*(local_element)^(peer_scalar) can > be calculated directly from the key exchange message, > the effective part of K is > PE^(peer_scalar*local_scalar+local_mask*peer_mask), has nothing to do with > local_rand and peer_rand, > so the password based key exchange is essentially equal with the following > "exchange"£º The problem with this is that peer_mask is unknown so it is not possible to reduce computation of K in this manner. > 2'. generate 2 random numbers between 0 and the order of the group, q: > > 0 < local_mask,local_scalar < q > > 3'. compute an element: > local_element = 1/(PE^local_mask) mod p > > where p is the prime and q is the order. Send local_scalar and > local_element to other side > > 4'. receive peer_scalar and peer_element from other side > > 5'. compute shared key, K > > K =PE^(peer_scalar*local_scalar)* (peer_element)^(-local_mask) mod p > =PE^(peer_scalar*local_scalar+local_mask*peer_mask) mod p > > It is simpler and less computation invloved, and hopefully easier to > analysis the security. PE^(peer_scalar*local_scalar) is completely extraneous. This is just a standard diffie-hellman with peer_mask and local_mask as the private contributions using, presumably, a password-derived generator (you don't actually say). The exchange above has received quite a bit of analysis already: it's the SPEKE protocol. regards, Dan. > From: "Dan Harkins" > Date: Tue, 20 Dec 2011 13:38:09 -0800 (PST) > Hello, > > I proposed a new TLS ciphersuite using a zero knowledge proof at > IETF 82 in Taipei. The draft is here: > > http://tools.ietf.org/html/draft-harkins-tls-pwd-01 > > At the TLS WG meeting I was requested to ask people on the CFRG list > with expertise in this field to take a look at it. So here I am, asking. > If someone has some spare cycles this holiday season, if you just gotta > get away from the relatives, or you are just feeling in the giving mood, > please take a look and comment. Any analysis on this would be greatly > appreciated. (I tried to do a formal proof but I cannot, and that's > what's prompting this). > > I can describe the key exchange broadly here. There are subtle > differences in the draft-- like one side keeps a salted version of the > password and communicates the salt during a HELLO message-- that don't > affect the exchange. It is symmetric so I can describe it from one side's > perspective. The side being described is "local" and the other side is > "peer", it goes like this: > > Given: local ID, peer ID, password, an agreed-upon set of domain > parameters defining a finite field group (it works will elliptic > curve crypto too) and using two function: > > - E = HashToElement(d) which takes some data, d, and hashes into > the finite field to return an element, E. > - x = H(y) returns a random stream, x, given some input, y. > > The key exchange works like this: > > 1. PE = HashToElement(local_ID | peer_ID | password) > gets a "password element" > > There is an ordering defined in the draft to ensure that the IDs > are put in the same order on each side. > > 2. generate 2 random numbers between 0 and the order of the group, q: > > 0 < local_rand, local_mask < q > > 3. compute a scalar and an element: > local_scalar = (local_rand + local_mask) mod q > local_element = 1/(PE^local_mask) mod p > > where p is the prime and q is the order. Send local_scalar and > local_element to other side > > 4. receive peer_scalar and peer_element from other side > > 5. compute shared key, K > > K = (PE^peer_scalar * peer_element)^local_rand mod p = > (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p = > PE^(peer_rand*local_rand) mod p > > 6. compute a confirmation > > local_confirm = H(K, local_scalar | local_element | > peer_scalar | peer_element) > > send confirmation to peer > > 7. receive peer's confirmation, calculate verifier > > verifier = H(K, peer_scalar | peer_element | local_scalar | > local_element) > > if verifier equals peer's confirmation the peer is authenticated. > > The peer does the same thing but from its perspective it is "local" > and the side described above is "peer". > > Thank you in advance for any analysis that can be provided on this > exchange. > > regards, > > > > > > > > > > > Regards~~~ > > -Sujing Zhou > From zhou.sujing@zte.com.cn Sun May 27 22:34:51 2012 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 625AA21F845D for ; Sun, 27 May 2012 22:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.637 X-Spam-Level: X-Spam-Status: No, score=-100.637 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_81=0.6, OBSCURED_EMAIL=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 c47ZtgJMnxLj for ; Sun, 27 May 2012 22:34:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0721F845C for ; Sun, 27 May 2012 22:34:49 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 62129344249031; Mon, 28 May 2012 13:29:36 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 93892.1065689647; Mon, 28 May 2012 13:34:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q4S5Yf2W094954; Mon, 28 May 2012 13:34:41 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: "Dan Harkins" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 28 May 2012 13:34:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-28 13:34:42, Serialize complete at 2012-05-28 13:34:42 Content-Type: multipart/alternative; boundary="=_alternative 001EADBE48257A0C_=" X-MAIL: mse01.zte.com.cn q4S5Yf2W094954 Cc: cfrg@irtf.org Subject: Re: [Cfrg] password-based key exchange,revisited 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, 28 May 2012 05:34:51 -0000 This is a multipart message in MIME format. --=_alternative 001EADBE48257A0C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KIkRhbiBIYXJraW5zIiA8ZGhhcmtpbnNAbG91 bmdlLm9yZz4g5YaZ5LqOIDIwMTItMDUtMjggMTI6MzU6NDA6DQoNCj4gDQo+ICAgSGVsbG8sDQo+ IA0KPiAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgYW5hbHlzaXMgb2YgbXkgcHJvdG9j b2wuDQo+IA0KPiBPbiBUaHUsIE1heSAyNCwgMjAxMiA2OjM5IHBtLCB6aG91LnN1amluZ0B6dGUu Y29tLmNuIHdyb3RlOg0KPiA+IEFzIGluIHRoZSBjYWxjdWxhdGlvbiBvZiAiSyA9IFBFXihwZWVy X3JhbmQqbG9jYWxfcmFuZCkgbW9kIHAiDQo+ID4gSyBjYW4gYmUgcmVkdWNlZCB0byBQRV4ocGVl cl9zY2FsYXIqbG9jYWxfc2NhbGFyK2xvY2FsX21hc2sqcGVlcl9tYXNrKQ0KPiA+ICoocGVlcl9l bGVtZW50KV4obG9jYWxfc2NhbGFyKSoobG9jYWxfZWxlbWVudCleKHBlZXJfc2NhbGFyKSBtb2Qg cA0KPiA+DQo+ID4gSyA9IFBFXihwZWVyX3JhbmQqbG9jYWxfcmFuZCkgbW9kIHANCj4gPiAgICA9 UEVeWyggcGVlcl9zY2FsYXItcGVlcl9tYXNrKSoobG9jYWxfc2NhbGFyLWxvY2FsX21hc2spXSBt b2QgcA0KPiA+DQo+ID4gPVBFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXItcGVlcl9tYXNrKmxv Y2FsX3NjYWxhci0NCj4gbG9jYWxfbWFzaypwZWVyX3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFz aykNCj4gPiBtb2QgcA0KPiA+ICAgID1QRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyK2xvY2Fs X21hc2sqcGVlcl9tYXNrKQ0KPiA+ICoocGVlcl9lbGVtZW50KV4obG9jYWxfc2NhbGFyKSoobG9j YWxfZWxlbWVudCleKHBlZXJfc2NhbGFyKSBtb2QgcA0KPiA+DQo+ID4gQmVjYXVzZSAgKHBlZXJf ZWxlbWVudCleKGxvY2FsX3NjYWxhcikqKGxvY2FsX2VsZW1lbnQpXihwZWVyX3NjYWxhcikgDQpj YW4NCj4gPiBiZSBjYWxjdWxhdGVkIGRpcmVjdGx5IGZyb20gdGhlIGtleSBleGNoYW5nZSBtZXNz YWdlLA0KPiA+IHRoZSBlZmZlY3RpdmUgcGFydCBvZiBLIGlzDQo+ID4gUEVeKHBlZXJfc2NhbGFy KmxvY2FsX3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFzayksIGhhcyBub3RoaW5nIHRvIGRvIA0K d2l0aA0KPiA+ICBsb2NhbF9yYW5kIGFuZCBwZWVyX3JhbmQsDQo+ID4gc28gdGhlIHBhc3N3b3Jk IGJhc2VkIGtleSBleGNoYW5nZSBpcyBlc3NlbnRpYWxseSBlcXVhbCB3aXRoIHRoZSANCmZvbGxv d2luZw0KPiA+ICJleGNoYW5nZSLCo8K6DQo+IA0KPiAgIFRoZSBwcm9ibGVtIHdpdGggdGhpcyBp cyB0aGF0IHBlZXJfbWFzayBpcyB1bmtub3duIHNvIGl0IGlzIG5vdCANCnBvc3NpYmxlDQo+IHRv IHJlZHVjZSBjb21wdXRhdGlvbiBvZiBLIGluIHRoaXMgbWFubmVyLg0KDQpJIG1lYW4gdGhlIGtl eSBpbiB5b3VyIHByb3RvY29sIEsgY2FuIGJlIHRha2VuIGludG8gdHdvIHBhcnRzLA0Kb25lIHBh cnQgaXMgIFBFXihTYVNiK01hTWEpICAgbGV0IFNhPXBlZXJfc2NhbGFyLCBTYj1sb2NhbF9zY2Fs YXI7IA0KTWE9cGVlcl9tYXNrLE1iPWxvY2FsX21hc2sgDQp0aGUgb3RoZXIgcGFydCBpcyBFYl4o U2EpRWFeKFNiKSAgbGV0IEViPWxvY2FsX2VsZW1lbnQsRWE9cGVlcl9lbGVtZW50LA0KYW5kIHRo ZSBzZWNvbmQgcGFydCBjYW4gYmUgY2FsY3VsYXRlZCBkaXJlY3RseSBmcm9tIEViLFNhLFNiLEVh LCB3aGljaCBhcmUgDQpleGNoYW5nZWQgaW4gcGxhaW50ZXh0LA0Kc28gdGhlIHNlY29uZCBwYXJ0 IGhhcyBsaXR0bGUgY29udHJpYnV0aW9uIGluIHRoZSBzZWNyZWN5IG9mIEsuDQpzbywgeW91ciBw cm90b2NvbCBjYW4gYmUgcmVkdWNlZCB0byB0aGUgZm9sbG93aW5nIG9uZSBhcyBJIGhhdmUgZGVz Y3JpYmVkOg0KDQpqdXN0IG5lZWQgdG8gZXhjaGFuZ2UgbG9jYWxfZWxlbWVudCBpbnN0ZWFkIG9m IGJvdGggbG9jYWxfZWxlbWVudCBhbmQgDQpsb2NhbF9zY2FsYXI7DQppbiBjb21wdXRhdGlvbiBv ZiBLICAoPVBFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIrbG9jYWxfbWFzaypwZWVyX21hc2sp IA0KbW9kIHApLCBvbmx5IA0Kb25lIGZpZWxkIHBvd2VyIG11bHRpcGxlIGluc3RlYWQgb2YgIHR3 byBmaWVsZCBwb3dlciBtdWx0aXBsZSBpbiAoSyA9IA0KKFBFXnBlZXJfc2NhbGFyICogcGVlcl9l bGVtZW50KV5sb2NhbF9yYW5kIG1vZCBwICkNCihwb3dlciBtdWx0aXBsZSBpcyB0aGUgbW9zdCBj b3N0bHkgcGFydCkNCg0KSXQganVzdCBuZWVkcyBhIHNpbXBsZSBjb21wdXRhdGlvbiB0byBnZXQg dG8gdGhpcyByZXN1bHQuDQoNCg0KPiANCj4gPiAyJy4gZ2VuZXJhdGUgMiByYW5kb20gbnVtYmVy cyBiZXR3ZWVuIDAgYW5kIHRoZSBvcmRlciBvZiB0aGUgZ3JvdXAsIHE6DQo+ID4NCj4gPiAgICAw IDwgbG9jYWxfbWFzayxsb2NhbF9zY2FsYXIgPCBxDQo+ID4NCj4gPiAzJy4gY29tcHV0ZSBhbiBl bGVtZW50Og0KPiA+ICAgIGxvY2FsX2VsZW1lbnQgPSAxLyhQRV5sb2NhbF9tYXNrKSBtb2QgcA0K PiA+DQo+ID4gICAgd2hlcmUgcCBpcyB0aGUgcHJpbWUgYW5kIHEgaXMgdGhlIG9yZGVyLiBTZW5k IGxvY2FsX3NjYWxhciBhbmQNCj4gPiAgICBsb2NhbF9lbGVtZW50IHRvIG90aGVyIHNpZGUNCj4g Pg0KPiA+IDQnLiByZWNlaXZlIHBlZXJfc2NhbGFyIGFuZCBwZWVyX2VsZW1lbnQgZnJvbSBvdGhl ciBzaWRlDQo+ID4NCj4gPiA1Jy4gY29tcHV0ZSBzaGFyZWQga2V5LCBLDQo+ID4NCj4gPiAgICBL ID1QRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyKSogKHBlZXJfZWxlbWVudCleKC1sb2NhbF9t YXNrKSBtb2QgDQpwDQo+ID4gICAgICA9UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcitsb2Nh bF9tYXNrKnBlZXJfbWFzaykgbW9kIHANCj4gPg0KPiA+IEl0IGlzIHNpbXBsZXIgYW5kIGxlc3Mg Y29tcHV0YXRpb24gaW52bG92ZWQsIGFuZCBob3BlZnVsbHkgZWFzaWVyIHRvDQo+ID4gYW5hbHlz aXMgdGhlIHNlY3VyaXR5Lg0KPiANCj4gICBQRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyKSBp cyBjb21wbGV0ZWx5IGV4dHJhbmVvdXMuIFRoaXMgaXMganVzdA0KPiBhIHN0YW5kYXJkIGRpZmZp ZS1oZWxsbWFuIHdpdGggcGVlcl9tYXNrIGFuZCBsb2NhbF9tYXNrIGFzIHRoZSBwcml2YXRlDQo+ IGNvbnRyaWJ1dGlvbnMgdXNpbmcsIHByZXN1bWFibHksIGEgcGFzc3dvcmQtZGVyaXZlZCBnZW5l cmF0b3IgKHlvdQ0KPiBkb24ndCBhY3R1YWxseSBzYXkpLiBUaGUgZXhjaGFuZ2UgYWJvdmUgaGFz IHJlY2VpdmVkIHF1aXRlIGEgYml0IG9mDQo+IGFuYWx5c2lzIGFscmVhZHk6IGl0J3MgdGhlIFNQ RUtFIHByb3RvY29sLg0KDQpUaGUgcmVkdWNlZCBwcm90b2NvbCBpcyBub3QgZXhhY3RseSBTUEVL RSwgYW5kIG9mIGNvdXJzZSB0aGV5IGFyZSBzaW1pbGFyLg0KSXQgaXMgYSBnb29kIG5ld3MgdGhh dCB5b3VyIHByb3RvY29sIGNhbiBiZSByZWR1Y2VkIHRvIGFzIHNlY3VyZSBhcyBTUEVLRSANCnBy b3RvY29sLEkgdGhpbmsuDQpJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSB1c2FnZSBvZiAgUEVeKHBl ZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikgaW4gdGhlIEvvvIwNCmJlY2F1c2Ugb25seSBwZXJzb24g d2hvIGtub3dzIFBFIGNhbg0KY2FsY3VsYXRlIGl0Lg0KDQpJbiBteSBvcGluaW9uLCBmb3IgYSBr ZXkgYWdyZWVtZW50IHByb3RvY29sLCB0aGUgc2ltcGxlciB0aGUgYmV0dGVyLCBib3RoIA0KZm9y IGFuYWx5c2lzIGFuZCBmb3Igc2VjdXJpdHkuDQpUbyBnbyBhcm91bmQgcGF0ZW50ZWQgcHJvdG9j b2wgaXMgYW5vdGhlciB0b3BpYy4NCg0KDQoNCg== --=_alternative 001EADBE48257A0C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtE YW4gSGFya2lucyZxdW90OyAmbHQ7ZGhhcmtpbnNAbG91bmdlLm9yZyZndDsNCuWGmeS6jiAyMDEy LTA1LTI4IDEyOjM1OjQwOjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgSGVsbG8s PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3Vy IGFuYWx5c2lzIG9mIG15IHByb3RvY29sLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUaHUsIE1h eSAyNCwgMjAxMiA2OjM5IHBtLCB6aG91LnN1amluZ0B6dGUuY29tLmNuIHdyb3RlOjxicj4NCiZn dDsgJmd0OyBBcyBpbiB0aGUgY2FsY3VsYXRpb24gb2YgJnF1b3Q7SyA9IFBFXihwZWVyX3JhbmQq bG9jYWxfcmFuZCkNCm1vZCBwJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IEsgY2FuIGJlIHJlZHVjZWQg dG8gUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFzayk8YnI+ DQomZ3Q7ICZndDsgKihwZWVyX2VsZW1lbnQpXihsb2NhbF9zY2FsYXIpKihsb2NhbF9lbGVtZW50 KV4ocGVlcl9zY2FsYXIpDQptb2QgcDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBLID0g UEVeKHBlZXJfcmFuZCpsb2NhbF9yYW5kKSBtb2QgcDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7PVBFXlsoIHBlZXJfc2NhbGFyLXBlZXJfbWFzaykqKGxvY2FsX3NjYWxhci1sb2NhbF9tYXNr KV0NCm1vZCBwPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ID1QRV4ocGVlcl9zY2FsYXIq bG9jYWxfc2NhbGFyLXBlZXJfbWFzaypsb2NhbF9zY2FsYXItPGJyPg0KJmd0OyBsb2NhbF9tYXNr KnBlZXJfc2NhbGFyK2xvY2FsX21hc2sqcGVlcl9tYXNrKTxicj4NCiZndDsgJmd0OyBtb2QgcDxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7PVBFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIr bG9jYWxfbWFzaypwZWVyX21hc2spPGJyPg0KJmd0OyAmZ3Q7ICoocGVlcl9lbGVtZW50KV4obG9j YWxfc2NhbGFyKSoobG9jYWxfZWxlbWVudCleKHBlZXJfc2NhbGFyKQ0KbW9kIHA8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgQmVjYXVzZSAmbmJzcDsocGVlcl9lbGVtZW50KV4obG9jYWxf c2NhbGFyKSoobG9jYWxfZWxlbWVudCleKHBlZXJfc2NhbGFyKQ0KY2FuPGJyPg0KJmd0OyAmZ3Q7 IGJlIGNhbGN1bGF0ZWQgZGlyZWN0bHkgZnJvbSB0aGUga2V5IGV4Y2hhbmdlIG1lc3NhZ2UsPGJy Pg0KJmd0OyAmZ3Q7IHRoZSBlZmZlY3RpdmUgcGFydCBvZiBLIGlzPGJyPg0KJmd0OyAmZ3Q7IFBF XihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIrbG9jYWxfbWFzaypwZWVyX21hc2spLCBoYXMgbm90 aGluZw0KdG8gZG8gd2l0aDxicj4NCiZndDsgJmd0OyAmbmJzcDtsb2NhbF9yYW5kIGFuZCBwZWVy X3JhbmQsPGJyPg0KJmd0OyAmZ3Q7IHNvIHRoZSBwYXNzd29yZCBiYXNlZCBrZXkgZXhjaGFuZ2Ug aXMgZXNzZW50aWFsbHkgZXF1YWwgd2l0aA0KdGhlIGZvbGxvd2luZzxicj4NCiZndDsgJmd0OyAm cXVvdDtleGNoYW5nZSZxdW90O8Kjwro8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7IFRoZSBw cm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IHBlZXJfbWFzayBpcyB1bmtub3duIHNvIGl0IGlzDQpu b3QgcG9zc2libGU8YnI+DQomZ3Q7IHRvIHJlZHVjZSBjb21wdXRhdGlvbiBvZiBLIGluIHRoaXMg bWFubmVyLjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSBtZWFuIHRo ZSBrZXkgaW4geW91ciBwcm90b2NvbCBLIGNhbiBiZSB0YWtlbiBpbnRvDQp0d28gcGFydHMsPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5vbmUgcGFydCBpcyAmbmJzcDtQRV4oU2FT YitNYU1hKSAmbmJzcDsgbGV0IFNhPXBlZXJfc2NhbGFyLA0KU2I9bG9jYWxfc2NhbGFyOyBNYT1w ZWVyX21hc2ssTWI9bG9jYWxfbWFzayA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PnRoZSBvdGhlciBwYXJ0IGlzIEViXihTYSlFYV4oU2IpICZuYnNwO2xldCBFYj1sb2NhbF9lbGVt ZW50LEVhPXBlZXJfZWxlbWVudCw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmFu ZCB0aGUgc2Vjb25kIHBhcnQgY2FuIGJlIGNhbGN1bGF0ZWQgZGlyZWN0bHkgZnJvbQ0KRWIsU2Es U2IsRWEsIHdoaWNoIGFyZSBleGNoYW5nZWQgaW4gcGxhaW50ZXh0LDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+c28gdGhlIHNlY29uZCBwYXJ0IGhhcyBsaXR0bGUgY29udHJpYnV0 aW9uIGluIHRoZQ0Kc2VjcmVjeSBvZiBLLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+c28sIHlvdXIgcHJvdG9jb2wgY2FuIGJlIHJlZHVjZWQgdG8gdGhlIGZvbGxvd2luZw0Kb25l IGFzIEkgaGF2ZSBkZXNjcmliZWQ6PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5qdXN0IG5lZWQgdG8gZXhjaGFuZ2UgbG9jYWxfZWxlbWVudCBpbnN0ZWFkIG9mIGJvdGgN CmxvY2FsX2VsZW1lbnQgYW5kIGxvY2FsX3NjYWxhcjs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPmluIGNvbXB1dGF0aW9uIG9mIEsgJm5ic3A7KD1QRV4ocGVlcl9zY2FsYXIqbG9j YWxfc2NhbGFyK2xvY2FsX21hc2sqcGVlcl9tYXNrKQ0KbW9kIHApLCBvbmx5IDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+b25lIGZpZWxkIHBvd2VyIG11bHRpcGxlIGluc3RlYWQg b2YgJm5ic3A7dHdvIGZpZWxkDQpwb3dlciBtdWx0aXBsZSBpbiAoSyA9IChQRV5wZWVyX3NjYWxh ciAqIHBlZXJfZWxlbWVudClebG9jYWxfcmFuZCBtb2QgcA0KKTwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+KHBvd2VyIG11bHRpcGxlIGlzIHRoZSBtb3N0IGNvc3RseSBwYXJ0KTwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SXQganVzdCBuZWVkcyBhIHNp bXBsZSBjb21wdXRhdGlvbiB0byBnZXQgdG8gdGhpcw0KcmVzdWx0LjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZndDsgMicuIGdl bmVyYXRlIDIgcmFuZG9tIG51bWJlcnMgYmV0d2VlbiAwIGFuZCB0aGUgb3JkZXIgb2YgdGhlDQpn cm91cCwgcTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOzAgJmx0 OyBsb2NhbF9tYXNrLGxvY2FsX3NjYWxhciAmbHQ7IHE8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgMycuIGNvbXB1dGUgYW4gZWxlbWVudDo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw O2xvY2FsX2VsZW1lbnQgPSAxLyhQRV5sb2NhbF9tYXNrKSBtb2QgcDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7d2hlcmUgcCBpcyB0aGUgcHJpbWUgYW5kIHEgaXMg dGhlIG9yZGVyLiBTZW5kIGxvY2FsX3NjYWxhcg0KYW5kPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDtsb2NhbF9lbGVtZW50IHRvIG90aGVyIHNpZGU8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgNCcuIHJlY2VpdmUgcGVlcl9zY2FsYXIgYW5kIHBlZXJfZWxlbWVudCBmcm9tIG90aGVy IHNpZGU8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgNScuIGNvbXB1dGUgc2hhcmVkIGtl eSwgSzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7SyA9UEVeKHBl ZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikqIChwZWVyX2VsZW1lbnQpXigtbG9jYWxfbWFzaykNCm1v ZCBwPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PVBFXihwZWVyX3NjYWxhcips b2NhbF9zY2FsYXIrbG9jYWxfbWFzaypwZWVyX21hc2spDQptb2QgcDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBJdCBpcyBzaW1wbGVyIGFuZCBsZXNzIGNvbXB1dGF0aW9uIGludmxvdmVk LCBhbmQgaG9wZWZ1bGx5IGVhc2llcg0KdG88YnI+DQomZ3Q7ICZndDsgYW5hbHlzaXMgdGhlIHNl Y3VyaXR5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgUEVeKHBlZXJfc2NhbGFyKmxvY2Fs X3NjYWxhcikgaXMgY29tcGxldGVseSBleHRyYW5lb3VzLiBUaGlzDQppcyBqdXN0PGJyPg0KJmd0 OyBhIHN0YW5kYXJkIGRpZmZpZS1oZWxsbWFuIHdpdGggcGVlcl9tYXNrIGFuZCBsb2NhbF9tYXNr IGFzIHRoZSBwcml2YXRlPGJyPg0KJmd0OyBjb250cmlidXRpb25zIHVzaW5nLCBwcmVzdW1hYmx5 LCBhIHBhc3N3b3JkLWRlcml2ZWQgZ2VuZXJhdG9yICh5b3U8YnI+DQomZ3Q7IGRvbid0IGFjdHVh bGx5IHNheSkuIFRoZSBleGNoYW5nZSBhYm92ZSBoYXMgcmVjZWl2ZWQgcXVpdGUgYSBiaXQgb2Y8 YnI+DQomZ3Q7IGFuYWx5c2lzIGFscmVhZHk6IGl0J3MgdGhlIFNQRUtFIHByb3RvY29sLjxicj4N CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhlIHJlZHVjZWQgcHJvdG9jb2wg aXMgbm90IGV4YWN0bHkgU1BFS0UsIGFuZCBvZg0KY291cnNlIHRoZXkgYXJlIHNpbWlsYXIuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JdCBpcyBhIGdvb2QgbmV3cyB0aGF0IHlv dXIgcHJvdG9jb2wgY2FuIGJlIHJlZHVjZWQNCnRvIGFzIHNlY3VyZSBhcyBTUEVLRSBwcm90b2Nv bCxJIHRoaW5rLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSBhbSBub3Qgc3Vy ZSBhYm91dCB0aGUgdXNhZ2Ugb2YgJm5ic3A7UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikN CmluIHRoZSBL77yMYmVjYXVzZSBvbmx5IHBlcnNvbiB3aG8ga25vd3MgUEUgY2FuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5jYWxjdWxhdGUgaXQuPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JbiBteSBvcGluaW9uLCBmb3IgYSBrZXkgYWdyZWVtZW50 IHByb3RvY29sLCB0aGUgc2ltcGxlcg0KdGhlIGJldHRlciwgYm90aCBmb3IgYW5hbHlzaXMgYW5k IGZvciBzZWN1cml0eS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRvIGdvIGFy b3VuZCBwYXRlbnRlZCBwcm90b2NvbCBpcyBhbm90aGVyIHRvcGljLjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPg0KPGJyPg0K --=_alternative 001EADBE48257A0C_=-- From zhou.sujing@zte.com.cn Sun May 27 22:53:56 2012 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 4CA1321F85CD for ; Sun, 27 May 2012 22:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.062 X-Spam-Level: X-Spam-Status: No, score=-97.062 tagged_above=-999 required=5 tests=[AWL=3.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, MIME_BASE64_TEXT=1.753, OBSCURED_EMAIL=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, 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 t3qbGVT0SJZf for ; Sun, 27 May 2012 22:53:55 -0700 (PDT) Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id AD7AF21F85C6 for ; Sun, 27 May 2012 22:53:54 -0700 (PDT) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 52926.1065689647; Mon, 28 May 2012 13:53:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q4S5rhGc017453; Mon, 28 May 2012 13:53:43 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: "Dan Harkins" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 28 May 2012 13:53:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-28 13:53:44, Serialize complete at 2012-05-28 13:53:44 Content-Type: multipart/alternative; boundary="=_alternative 00206BFC48257A0C_=" X-MAIL: mse01.zte.com.cn q4S5rhGc017453 Cc: cfrg@irtf.org Subject: Re: [Cfrg] password-based key exchange,revisited 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, 28 May 2012 05:53:56 -0000 This is a multipart message in MIME format. --=_alternative 00206BFC48257A0C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IkRhbiBIYXJraW5zIiA8ZGhhcmtpbnNAbG91bmdlLm9yZz4gIDIwMTItMDUtMjggMTI6MzU6NDA6 DQoNCj4gDQo+ICAgSGVsbG8sDQo+IA0KPiAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIg YW5hbHlzaXMgb2YgbXkgcHJvdG9jb2wuDQo+IA0KPiBPbiBUaHUsIE1heSAyNCwgMjAxMiA2OjM5 IHBtLCB6aG91LnN1amluZ0B6dGUuY29tLmNuIHdyb3RlOg0KPiA+IEFzIGluIHRoZSBjYWxjdWxh dGlvbiBvZiAiSyA9IFBFXihwZWVyX3JhbmQqbG9jYWxfcmFuZCkgbW9kIHAiDQo+ID4gSyBjYW4g YmUgcmVkdWNlZCB0byBQRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyK2xvY2FsX21hc2sqcGVl cl9tYXNrKQ0KPiA+ICoocGVlcl9lbGVtZW50KV4obG9jYWxfc2NhbGFyKSoobG9jYWxfZWxlbWVu dCleKHBlZXJfc2NhbGFyKSBtb2QgcA0KPiA+DQo+ID4gSyA9IFBFXihwZWVyX3JhbmQqbG9jYWxf cmFuZCkgbW9kIHANCj4gPiAgICA9UEVeWyggcGVlcl9zY2FsYXItcGVlcl9tYXNrKSoobG9jYWxf c2NhbGFyLWxvY2FsX21hc2spXSBtb2QgcA0KPiA+DQo+ID4gPVBFXihwZWVyX3NjYWxhcipsb2Nh bF9zY2FsYXItcGVlcl9tYXNrKmxvY2FsX3NjYWxhci0NCj4gbG9jYWxfbWFzaypwZWVyX3NjYWxh citsb2NhbF9tYXNrKnBlZXJfbWFzaykNCj4gPiBtb2QgcA0KPiA+ICAgID1QRV4ocGVlcl9zY2Fs YXIqbG9jYWxfc2NhbGFyK2xvY2FsX21hc2sqcGVlcl9tYXNrKQ0KPiA+ICoocGVlcl9lbGVtZW50 KV4obG9jYWxfc2NhbGFyKSoobG9jYWxfZWxlbWVudCleKHBlZXJfc2NhbGFyKSBtb2QgcA0KPiA+ DQo+ID4gQmVjYXVzZSAgKHBlZXJfZWxlbWVudCleKGxvY2FsX3NjYWxhcikqKGxvY2FsX2VsZW1l bnQpXihwZWVyX3NjYWxhcikgDQpjYW4NCj4gPiBiZSBjYWxjdWxhdGVkIGRpcmVjdGx5IGZyb20g dGhlIGtleSBleGNoYW5nZSBtZXNzYWdlLA0KPiA+IHRoZSBlZmZlY3RpdmUgcGFydCBvZiBLIGlz DQo+ID4gUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFzayks IGhhcyBub3RoaW5nIHRvIGRvIA0Kd2l0aA0KPiA+ICBsb2NhbF9yYW5kIGFuZCBwZWVyX3JhbmQs DQo+ID4gc28gdGhlIHBhc3N3b3JkIGJhc2VkIGtleSBleGNoYW5nZSBpcyBlc3NlbnRpYWxseSBl cXVhbCB3aXRoIHRoZSANCmZvbGxvd2luZw0KPiA+ICJleGNoYW5nZSKh6m8NCj4gDQo+ICAgVGhl IHByb2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgcGVlcl9tYXNrIGlzIHVua25vd24gc28gaXQgaXMg bm90IA0KcG9zc2libGUNCj4gdG8gcmVkdWNlIGNvbXB1dGF0aW9uIG9mIEsgaW4gdGhpcyBtYW5u ZXIuDQoNCkkgbWVhbiB0aGUga2V5IGluIHlvdXIgcHJvdG9jb2wgSyBjYW4gYmUgdGFrZW4gaW50 byB0d28gcGFydHMsDQpvbmUgcGFydCBpcyAgUEVeKFNhU2IrTWFNYSkgICBsZXQgU2E9cGVlcl9z Y2FsYXIsIFNiPWxvY2FsX3NjYWxhcjsgDQpNYT1wZWVyX21hc2ssTWI9bG9jYWxfbWFzayANCnRo ZSBvdGhlciBwYXJ0IGlzIEViXihTYSlFYV4oU2IpICBsZXQgRWI9bG9jYWxfZWxlbWVudCAgRWE9 cGVlcl9lbGVtZW50DQphbmQgdGhlIHNlY29uZCBwYXJ0IGNhbiBiZSBjYWxjdWxhdGVkIGRpcmVj dGx5IGZyb20gRWIgU2EgU2IgRWEgd2hpY2ggYXJlIA0KZXhjaGFuZ2VkIGluIHBsYWludGV4dA0K c28gdGhlIHNlY29uZCBwYXJ0IGhhcyBsaXR0bGUgY29udHJpYnV0aW9uIGluIHRoZSBzZWNyZWN5 IG9mIEsuDQpzbywgeW91ciBwcm90b2NvbCBjYW4gYmUgcmVkdWNlZCB0byB0aGUgZm9sbG93aW5n IG9uZSBhcyBJIGhhdmUgZGVzY3JpYmVkOg0KDQppbiBjb21wdXRhdGlvbiBvZiBLLCB0aGVpciBj b21wbGV4aXR5IGFyZSB0aGUgc2FtZTsgYnV0IA0KanVzdCBuZWVkIHRvIGV4Y2hhbmdlIGxvY2Fs X2VsZW1lbnQgaW5zdGVhZCBvZiBib3RoIGxvY2FsX2VsZW1lbnQgYW5kIA0KbG9jYWxfc2NhbGFy DQphbmQgZG8gbm90IG5lZWQgY2FsY3VsYXRlIGxvY2FsX3NjYWxhci4NCj4gDQo+ID4gMicuIGdl bmVyYXRlIDIgcmFuZG9tIG51bWJlcnMgYmV0d2VlbiAwIGFuZCB0aGUgb3JkZXIgb2YgdGhlIGdy b3VwLCBxOg0KPiA+DQo+ID4gICAgMCA8IGxvY2FsX21hc2ssbG9jYWxfc2NhbGFyIDwgcQ0KPiA+ DQo+ID4gMycuIGNvbXB1dGUgYW4gZWxlbWVudDoNCj4gPiAgICBsb2NhbF9lbGVtZW50ID0gMS8o UEVebG9jYWxfbWFzaykgbW9kIHANCj4gPg0KPiA+ICAgIHdoZXJlIHAgaXMgdGhlIHByaW1lIGFu ZCBxIGlzIHRoZSBvcmRlci4gU2VuZCBsb2NhbF9zY2FsYXIgYW5kDQo+ID4gICAgbG9jYWxfZWxl bWVudCB0byBvdGhlciBzaWRlDQo+ID4NCj4gPiA0Jy4gcmVjZWl2ZSBwZWVyX3NjYWxhciBhbmQg cGVlcl9lbGVtZW50IGZyb20gb3RoZXIgc2lkZQ0KPiA+DQo+ID4gNScuIGNvbXB1dGUgc2hhcmVk IGtleSwgSw0KPiA+DQo+ID4gICAgSyA9UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikqIChw ZWVyX2VsZW1lbnQpXigtbG9jYWxfbWFzaykgbW9kIA0KcA0KPiA+ICAgICAgPVBFXihwZWVyX3Nj YWxhcipsb2NhbF9zY2FsYXIrbG9jYWxfbWFzaypwZWVyX21hc2spIG1vZCBwDQo+ID4NCj4gPiBJ dCBpcyBzaW1wbGVyIGFuZCBsZXNzIGNvbXB1dGF0aW9uIGludmxvdmVkLCBhbmQgaG9wZWZ1bGx5 IGVhc2llciB0bw0KPiA+IGFuYWx5c2lzIHRoZSBzZWN1cml0eS4NCj4gDQo+ICAgUEVeKHBlZXJf c2NhbGFyKmxvY2FsX3NjYWxhcikgaXMgY29tcGxldGVseSBleHRyYW5lb3VzLiBUaGlzIGlzIGp1 c3QNCj4gYSBzdGFuZGFyZCBkaWZmaWUtaGVsbG1hbiB3aXRoIHBlZXJfbWFzayBhbmQgbG9jYWxf bWFzayBhcyB0aGUgcHJpdmF0ZQ0KPiBjb250cmlidXRpb25zIHVzaW5nLCBwcmVzdW1hYmx5LCBh IHBhc3N3b3JkLWRlcml2ZWQgZ2VuZXJhdG9yICh5b3UNCj4gZG9uJ3QgYWN0dWFsbHkgc2F5KS4g VGhlIGV4Y2hhbmdlIGFib3ZlIGhhcyByZWNlaXZlZCBxdWl0ZSBhIGJpdCBvZg0KPiBhbmFseXNp cyBhbHJlYWR5OiBpdCdzIHRoZSBTUEVLRSBwcm90b2NvbC4NCg0KVGhlIHJlZHVjZWQgcHJvdG9j b2wgaXMgbm90IGV4YWN0bHkgU1BFS0UsIGFuZCBvZiBjb3Vyc2UgdGhleSBhcmUgc2ltaWxhci4N Ckl0IGlzIGEgZ29vZCBuZXdzIHRoYXQgeW91ciBwcm90b2NvbCBjYW4gYmUgcmVkdWNlZCB0byBh cyBzZWN1cmUgYXMgU1BFS0UgDQpwcm90b2NvbCxJIHRoaW5rLg0KSSBhbSBub3Qgc3VyZSBhYm91 dCB0aGUgdXNhZ2Ugb2YgIFBFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIpIGluIHRoZSBLo6wN CmJlY2F1c2Ugb25seSBwZXJzb24gd2hvIGtub3dzIFBFIGNhbg0KY2FsY3VsYXRlIGl0Lg0KDQpJ biBteSBvcGluaW9uLCBmb3IgYSBrZXkgYWdyZWVtZW50IHByb3RvY29sLCB0aGUgc2ltcGxlciB0 aGUgYmV0dGVyLCBib3RoIA0KZm9yIGFuYWx5c2lzIGFuZCBmb3Igc2VjdXJpdHkuDQpUbyBnbyBh cm91bmQgcGF0ZW50ZWQgcHJvdG9jb2wgaXMgYW5vdGhlciB0b3BpYy4NCg== --=_alternative 00206BFC48257A0C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0RhbiBIYXJraW5zJnF1 b3Q7ICZsdDtkaGFya2luc0Bsb3VuZ2Uub3JnJmd0Ow0KJm5ic3A7MjAxMi0wNS0yOCAxMjozNTo0 MDo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOyBI ZWxsbyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOyBUaGFu ayB5b3UgdmVyeSBtdWNoIGZvcg0KeW91ciBhbmFseXNpcyBvZiBteSBwcm90b2NvbC48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IE9uIFRodSwgTWF5IDI0LCAyMDEyIDY6 MzkgcG0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCndyb3RlOjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IEFzIGluIHRoZSBjYWxjdWxhdGlvbiBv ZiAmcXVvdDtLDQo9IFBFXihwZWVyX3JhbmQqbG9jYWxfcmFuZCkgbW9kIHAmcXVvdDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyBLIGNhbiBiZSBy ZWR1Y2VkIHRvIFBFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIrbG9jYWxfbWFzaypwZWVyX21h c2spPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDsg KihwZWVyX2VsZW1lbnQpXihsb2NhbF9zY2FsYXIpKihsb2NhbF9lbGVtZW50KV4ocGVlcl9zY2Fs YXIpDQptb2QgcDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0 OyAmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZn dDsgSyA9IFBFXihwZWVyX3JhbmQqbG9jYWxfcmFuZCkNCm1vZCBwPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOz1QRV5bKCBw ZWVyX3NjYWxhci1wZWVyX21hc2spKihsb2NhbF9zY2FsYXItbG9jYWxfbWFzayldDQptb2QgcDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgPVBFXihwZWVy X3NjYWxhcipsb2NhbF9zY2FsYXItcGVlcl9tYXNrKmxvY2FsX3NjYWxhci08L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgbG9jYWxfbWFzaypwZWVyX3NjYWxh citsb2NhbF9tYXNrKnBlZXJfbWFzayk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgJmd0OyBtb2QgcDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDs9UEVeKHBlZXJfc2NhbGFyKmxvY2Fs X3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFzayk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyAqKHBlZXJfZWxlbWVudCleKGxvY2FsX3NjYWxhcikq KGxvY2FsX2VsZW1lbnQpXihwZWVyX3NjYWxhcikNCm1vZCBwPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyBCZWNhdXNlICZuYnNwOyhwZWVyX2VsZW1lbnQp Xihsb2NhbF9zY2FsYXIpKihsb2NhbF9lbGVtZW50KV4ocGVlcl9zY2FsYXIpDQpjYW48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyBiZSBjYWxjdWxh dGVkIGRpcmVjdGx5IGZyb20NCnRoZSBrZXkgZXhjaGFuZ2UgbWVzc2FnZSw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyB0aGUgZWZmZWN0aXZlIHBh cnQgb2YgSyBpczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0 OyAmZ3Q7IFBFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIrbG9jYWxfbWFzaypwZWVyX21hc2sp LA0KaGFzIG5vdGhpbmcgdG8gZG8gd2l0aDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7ICZuYnNwO2xvY2FsX3JhbmQgYW5kIHBlZXJfcmFuZCw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyBzbyB0aGUg cGFzc3dvcmQgYmFzZWQga2V5DQpleGNoYW5nZSBpcyBlc3NlbnRpYWxseSBlcXVhbCB3aXRoIHRo ZSBmb2xsb3dpbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZn dDsgJmd0OyAmcXVvdDtleGNoYW5nZSZxdW90O6HqbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgJm5ic3A7IFRoZSBwcm9ibGVtIHdpdGggdGhpcyBpcw0KdGhhdCBwZWVy X21hc2sgaXMgdW5rbm93biBzbyBpdCBpcyBub3QgcG9zc2libGU8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgdG8gcmVkdWNlIGNvbXB1dGF0aW9uIG9mIEsg aW4gdGhpcw0KbWFubmVyLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+SSBtZWFuIHRoZSBrZXkgaW4geW91ciBwcm90b2NvbCBLIGNhbg0KYmUgdGFrZW4g aW50byB0d28gcGFydHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5vbmUgcGFydCBpcyAmbmJzcDtQRV4oU2FTYitNYU1hKSAmbmJzcDsNCmxldCBTYT1wZWVyX3Nj YWxhciwgU2I9bG9jYWxfc2NhbGFyOyBNYT1wZWVyX21hc2ssTWI9bG9jYWxfbWFzayA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBvdGhlciBwYXJ0IGlzIEVi XihTYSlFYV4oU2IpICZuYnNwO2xldA0KRWI9bG9jYWxfZWxlbWVudCAmbmJzcDtFYT1wZWVyX2Vs ZW1lbnQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZCB0aGUg c2Vjb25kIHBhcnQgY2FuIGJlIGNhbGN1bGF0ZWQNCmRpcmVjdGx5IGZyb20gRWIgU2EgU2IgRWEg d2hpY2ggYXJlIGV4Y2hhbmdlZCBpbiBwbGFpbnRleHQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPnNvIHRoZSBzZWNvbmQgcGFydCBoYXMgbGl0dGxlIGNvbnRyaWJ1 dGlvbg0KaW4gdGhlIHNlY3JlY3kgb2YgSy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPnNvLCB5b3VyIHByb3RvY29sIGNhbiBiZSByZWR1Y2VkIHRvDQp0aGUgZm9s bG93aW5nIG9uZSBhcyBJIGhhdmUgZGVzY3JpYmVkOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aW4gY29tcHV0YXRpb24gb2YgSywgdGhlaXIgY29tcGxl eGl0eQ0KYXJlIHRoZSBzYW1lOyBidXQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5qdXN0IG5lZWQgdG8gZXhjaGFuZ2UgbG9jYWxfZWxlbWVudA0KaW5zdGVhZCBv ZiBib3RoIGxvY2FsX2VsZW1lbnQgYW5kIGxvY2FsX3NjYWxhcjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW5kIGRvIG5vdCBuZWVkIGNhbGN1bGF0ZSBsb2NhbF9z Y2FsYXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IDInLiBn ZW5lcmF0ZSAyIHJhbmRvbSBudW1iZXJzDQpiZXR3ZWVuIDAgYW5kIHRoZSBvcmRlciBvZiB0aGUg Z3JvdXAsIHE6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7 ICZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7MCAmbHQ7IGxvY2FsX21hc2ssbG9jYWxfc2NhbGFyDQombHQ7IHE8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IDMnLiBjb21wdXRl IGFuIGVsZW1lbnQ6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO2xvY2FsX2VsZW1lbnQNCj0gMS8oUEVebG9jYWxfbWFzaykg bW9kIHA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0 OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDt3aGVyZSBwIGlzIHRoZQ0KcHJpbWUgYW5kIHEgaXMgdGhlIG9yZGVyLiBTZW5k IGxvY2FsX3NjYWxhciBhbmQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7bG9jYWxfZWxlbWVudA0KdG8gb3RoZXIgc2lkZTwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgNCcuIHJlY2Vp dmUgcGVlcl9zY2FsYXIgYW5kDQpwZWVyX2VsZW1lbnQgZnJvbSBvdGhlciBzaWRlPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyA1Jy4gY29tcHV0ZSBzaGFy ZWQga2V5LCBLPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7 ICZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7SyA9UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikqDQoocGVlcl9l bGVtZW50KV4oLWxvY2FsX21hc2spIG1vZCBwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9UEVeKHBlZXJfc2Nh bGFyKmxvY2FsX3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFzaykNCm1vZCBwPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZndDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyBJdCBpcyBzaW1wbGVyIGFuZCBs ZXNzIGNvbXB1dGF0aW9uDQppbnZsb3ZlZCwgYW5kIGhvcGVmdWxseSBlYXNpZXIgdG88L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJmd0OyBhbmFseXNpcyB0 aGUgc2VjdXJpdHkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m Z3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmbmJz cDsgUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikNCmlzIGNvbXBsZXRlbHkgZXh0cmFuZW91 cy4gVGhpcyBpcyBqdXN0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mZ3Q7IGEgc3RhbmRhcmQgZGlmZmllLWhlbGxtYW4gd2l0aA0KcGVlcl9tYXNrIGFuZCBsb2Nh bF9tYXNrIGFzIHRoZSBwcml2YXRlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7IGNvbnRyaWJ1dGlvbnMgdXNpbmcsIHByZXN1bWFibHksDQphIHBhc3N3b3Jk LWRlcml2ZWQgZ2VuZXJhdG9yICh5b3U8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgZG9uJ3QgYWN0dWFsbHkgc2F5KS4gVGhlIGV4Y2hhbmdlDQphYm92ZSBo YXMgcmVjZWl2ZWQgcXVpdGUgYSBiaXQgb2Y8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgYW5hbHlzaXMgYWxyZWFkeTogaXQncyB0aGUgU1BFS0UNCnByb3Rv Y29sLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhl IHJlZHVjZWQgcHJvdG9jb2wgaXMgbm90IGV4YWN0bHkNClNQRUtFLCBhbmQgb2YgY291cnNlIHRo ZXkgYXJlIHNpbWlsYXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5JdCBpcyBhIGdvb2QgbmV3cyB0aGF0IHlvdXIgcHJvdG9jb2wNCmNhbiBiZSByZWR1Y2VkIHRv IGFzIHNlY3VyZSBhcyBTUEVLRSBwcm90b2NvbCxJIHRoaW5rLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgdXNhZ2Ugb2Yg Jm5ic3A7UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikNCmluIHRoZSBLo6xiZWNhdXNlIG9u bHkgcGVyc29uIHdobyBrbm93cyBQRSBjYW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPmNhbGN1bGF0ZSBpdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkluIG15IG9waW5pb24sIGZvciBhIGtleSBhZ3JlZW1lbnQgcHJv dG9jb2wsDQp0aGUgc2ltcGxlciB0aGUgYmV0dGVyLCBib3RoIGZvciBhbmFseXNpcyBhbmQgZm9y IHNlY3VyaXR5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VG8g Z28gYXJvdW5kIHBhdGVudGVkIHByb3RvY29sIGlzIGFub3RoZXINCnRvcGljLjwvZm9udD4NCg== --=_alternative 00206BFC48257A0C_=-- From dharkins@lounge.org Mon May 28 01:10:00 2012 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 35C0721F844F for ; Mon, 28 May 2012 01:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.514 X-Spam-Level: X-Spam-Status: No, score=-4.514 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_81=0.6, OBSCURED_EMAIL=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 l-uX9dLgFTRh for ; Mon, 28 May 2012 01:09:59 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id AE80421F844C for ; Mon, 28 May 2012 01:09:53 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0F57F10224008; Mon, 28 May 2012 01:09:53 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 May 2012 01:09:53 -0700 (PDT) Message-ID: <23a6d3dd03b27579cbf223f1aa52232b.squirrel@www.trepanning.net> In-Reply-To: References: Date: Mon, 28 May 2012 01:09:53 -0700 (PDT) From: "Dan Harkins" To: zhou.sujing@zte.com.cn User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org Subject: Re: [Cfrg] password-based key exchange,revisited 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, 28 May 2012 08:10:00 -0000 Hello again, On Sun, May 27, 2012 10:53 pm, zhou.sujing@zte.com.cn wrote: > "Dan Harkins" 2012-05-28 12:35:40: > >> >> Hello, >> >> Thank you very much for your analysis of my protocol. >> >> On Thu, May 24, 2012 6:39 pm, zhou.sujing@zte.com.cn wrote: >> > As in the calculation of "K = PE^(peer_rand*local_rand) mod p" >> > K can be reduced to >> PE^(peer_scalar*local_scalar+local_mask*peer_mask) >> > *(peer_element)^(local_scalar)*(local_element)^(peer_scalar) mod p >> > >> > K = PE^(peer_rand*local_rand) mod p >> > =PE^[( peer_scalar-peer_mask)*(local_scalar-local_mask)] mod p >> > >> > =PE^(peer_scalar*local_scalar-peer_mask*local_scalar- >> local_mask*peer_scalar+local_mask*peer_mask) >> > mod p >> > =PE^(peer_scalar*local_scalar+local_mask*peer_mask) >> > *(peer_element)^(local_scalar)*(local_element)^(peer_scalar) mod p >> > >> > Because (peer_element)^(local_scalar)*(local_element)^(peer_scalar) > can >> > be calculated directly from the key exchange message, >> > the effective part of K is >> > PE^(peer_scalar*local_scalar+local_mask*peer_mask), has nothing to do > with >> > local_rand and peer_rand, >> > so the password based key exchange is essentially equal with the > following >> > "exchange"¡êo >> >> The problem with this is that peer_mask is unknown so it is not > possible >> to reduce computation of K in this manner. > > I mean the key in your protocol K can be taken into two parts, > one part is PE^(SaSb+MaMa) let Sa=peer_scalar, Sb=local_scalar; > Ma=peer_mask,Mb=local_mask > the other part is Eb^(Sa)Ea^(Sb) let Eb=local_element Ea=peer_element > and the second part can be calculated directly from Eb Sa Sb Ea which are > exchanged in plaintext > so the second part has little contribution in the secrecy of K. > so, your protocol can be reduced to the following one as I have > described: > > in computation of K, their complexity are the same; but > just need to exchange local_element instead of both local_element and > local_scalar > and do not need calculate local_scalar. Part of your reduction requires knowledge of information that you cannot have so it doesn't work. What you are describing below is a *different* protocol. >> >> > 2'. generate 2 random numbers between 0 and the order of the group, >> q: >> > >> > 0 < local_mask,local_scalar < q >> > >> > 3'. compute an element: >> > local_element = 1/(PE^local_mask) mod p >> > >> > where p is the prime and q is the order. Send local_scalar and >> > local_element to other side >> > >> > 4'. receive peer_scalar and peer_element from other side >> > >> > 5'. compute shared key, K >> > >> > K =PE^(peer_scalar*local_scalar)* (peer_element)^(-local_mask) mod > p >> > =PE^(peer_scalar*local_scalar+local_mask*peer_mask) mod p >> > >> > It is simpler and less computation invloved, and hopefully easier to >> > analysis the security. >> >> PE^(peer_scalar*local_scalar) is completely extraneous. This is just >> a standard diffie-hellman with peer_mask and local_mask as the private >> contributions using, presumably, a password-derived generator (you >> don't actually say). The exchange above has received quite a bit of >> analysis already: it's the SPEKE protocol. > > The reduced protocol is not exactly SPEKE, and of course they are > similar. > It is a good news that your protocol can be reduced to as secure as SPEKE > protocol,I think. > I am not sure about the usage of PE^(peer_scalar*local_scalar) in the > K£¬ > because only person who knows PE can > calculate it. Not exactly SPEKE? It's SPEKE with extraneous computation which do not add anything to the security of the exchange. Also, it is an open question whether "my protocol can be reduced to as secure as SPEKE." That is what is prompting my request for help in this forum. As Dr. Katz noted, it doesn't seem likely that the protocol can be proven secure in the Random Oracle model, and I believe SPEKE can be proven secure in the Random Oracle model. > In my opinion, for a key agreement protocol, the simpler the better, both > for analysis and for security. > To go around patented protocol is another topic. If you believe the simpler the better then do away with the extraneous elements in the exchange you describe above. The secret information is "local_mask" and "peer_mask". You are exchanging elements in the group using a secret generator exponentiated to each side's respective secret information and doing a diffie-hellman exchange. Having each side multiply the result of the diffie-hellman by additional information-- 1, 8738, PE^8738 or PE^(peer_scalar*local_scalar)-- doesn't really contribute anything to the security of the exchange. regards, Dan. From zhou.sujing@zte.com.cn Mon May 28 01:41:26 2012 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 C63D621F8531 for ; Mon, 28 May 2012 01:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.65 X-Spam-Level: X-Spam-Status: No, score=-99.65 tagged_above=-999 required=5 tests=[AWL=2.588, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, 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 o5vsDFAqAYCu for ; Mon, 28 May 2012 01:41:25 -0700 (PDT) Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id B36BA21F844A for ; Mon, 28 May 2012 01:41:23 -0700 (PDT) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 52926.1065689647; Mon, 28 May 2012 16:41:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q4S8YHYb084794; Mon, 28 May 2012 16:34:17 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <23a6d3dd03b27579cbf223f1aa52232b.squirrel@www.trepanning.net> To: "Dan Harkins" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 28 May 2012 16:34:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-28 16:34:19, Serialize complete at 2012-05-28 16:34:19 Content-Type: multipart/alternative; boundary="=_alternative 002F171E48257A0C_=" X-MAIL: mse01.zte.com.cn q4S8YHYb084794 Cc: cfrg@irtf.org Subject: Re: [Cfrg] password-based key exchange,revisited 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, 28 May 2012 08:41:26 -0000 This is a multipart message in MIME format. --=_alternative 002F171E48257A0C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IkRhbiBIYXJraW5zIiA8ZGhhcmtpbnNAbG91bmdlLm9yZz4g5YaZ5LqOIDIwMTItMDUtMjggMTY6 MDk6NTM6DQoNCj4gDQoNCj4gDQo+ICAgUGFydCBvZiB5b3VyIHJlZHVjdGlvbiByZXF1aXJlcyBr bm93bGVkZ2Ugb2YgaW5mb3JtYXRpb24gdGhhdCB5b3UgDQpjYW5ub3QNCj4gaGF2ZQ0KPiBzbyBp dCBkb2Vzbid0IHdvcmsuDQpJIGhhdmUgY29ycmVjdGVkIHRoZSBwYXJ0IG9mIGNvbXB1dGF0aW9u IGNvbXBhcmlzb24gaW4gYW5vdGhlciBlbWFpbC4NClllcywgeW91IGFyZSByaWdodCwgdGhlIGNv bXB1dGF0aW9uIHNhdmluZyBpcyBsaXR0bGUsIA0KYnV0IHlvdSBjYW4gc2F2ZSB0aGUgZXhjaGFu Z2UgbWVzc2FnZS4gDQoNCg0KPiAgIFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGJlbG93IGlzIGEg KmRpZmZlcmVudCogcHJvdG9jb2wuDQpJdCBsb29rcyBkaWZmZXJlbnQsIGJ1dCBhY3R1YWxseSB0 aGUgc2FtZSwgSSBqdXN0IHRha2UgYXdheSB0aGUgcGFydA0Kd2hpY2ggY2FuIGJlIGRpcmVjdGx5 IGNhbGN1bGF0ZWQgZnJvbSB0aGUgZXhjaGFuZ2VkIHBsYWluIG1lc3NhZ2UuDQoNCj4gDQo+ID4+ DQo+ID4+ID4gMicuIGdlbmVyYXRlIDIgcmFuZG9tIG51bWJlcnMgYmV0d2VlbiAwIGFuZCB0aGUg b3JkZXIgb2YgdGhlIGdyb3VwLA0KPiA+PiBxOg0KPiA+PiA+DQo+ID4+ID4gICAgMCA8IGxvY2Fs X21hc2ssbG9jYWxfc2NhbGFyIDwgcQ0KPiA+PiA+DQo+ID4+ID4gMycuIGNvbXB1dGUgYW4gZWxl bWVudDoNCj4gPj4gPiAgICBsb2NhbF9lbGVtZW50ID0gMS8oUEVebG9jYWxfbWFzaykgbW9kIHAN Cj4gPj4gPg0KPiA+PiA+ICAgIHdoZXJlIHAgaXMgdGhlIHByaW1lIGFuZCBxIGlzIHRoZSBvcmRl ci4gU2VuZCBsb2NhbF9zY2FsYXIgYW5kDQo+ID4+ID4gICAgbG9jYWxfZWxlbWVudCB0byBvdGhl ciBzaWRlDQo+ID4+ID4NCj4gPj4gPiA0Jy4gcmVjZWl2ZSBwZWVyX3NjYWxhciBhbmQgcGVlcl9l bGVtZW50IGZyb20gb3RoZXIgc2lkZQ0KPiA+PiA+DQo+ID4+ID4gNScuIGNvbXB1dGUgc2hhcmVk IGtleSwgSw0KPiA+PiA+DQo+ID4+ID4gICAgSyA9UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxh cikqIChwZWVyX2VsZW1lbnQpXigtbG9jYWxfbWFzaykgDQptb2QNCj4gPiBwDQo+ID4+ID4gICAg ICA9UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcitsb2NhbF9tYXNrKnBlZXJfbWFzaykgbW9k IHANCj4gPj4gPg0KPiA+PiA+IEl0IGlzIHNpbXBsZXIgYW5kIGxlc3MgY29tcHV0YXRpb24gaW52 bG92ZWQsIGFuZCBob3BlZnVsbHkgZWFzaWVyIA0KdG8NCj4gPj4gPiBhbmFseXNpcyB0aGUgc2Vj dXJpdHkuDQo+ID4+DQo+ID4+ICAgUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikgaXMgY29t cGxldGVseSBleHRyYW5lb3VzLiBUaGlzIGlzIA0KanVzdA0KPiA+PiBhIHN0YW5kYXJkIGRpZmZp ZS1oZWxsbWFuIHdpdGggcGVlcl9tYXNrIGFuZCBsb2NhbF9tYXNrIGFzIHRoZSANCnByaXZhdGUN Cj4gPj4gY29udHJpYnV0aW9ucyB1c2luZywgcHJlc3VtYWJseSwgYSBwYXNzd29yZC1kZXJpdmVk IGdlbmVyYXRvciAoeW91DQo+ID4+IGRvbid0IGFjdHVhbGx5IHNheSkuIFRoZSBleGNoYW5nZSBh Ym92ZSBoYXMgcmVjZWl2ZWQgcXVpdGUgYSBiaXQgb2YNCj4gPj4gYW5hbHlzaXMgYWxyZWFkeTog aXQncyB0aGUgU1BFS0UgcHJvdG9jb2wuDQo+ID4NCj4gPiBUaGUgcmVkdWNlZCBwcm90b2NvbCBp cyBub3QgZXhhY3RseSBTUEVLRSwgYW5kIG9mIGNvdXJzZSB0aGV5IGFyZQ0KPiA+IHNpbWlsYXIu DQo+ID4gSXQgaXMgYSBnb29kIG5ld3MgdGhhdCB5b3VyIHByb3RvY29sIGNhbiBiZSByZWR1Y2Vk IHRvIGFzIHNlY3VyZSBhcyANClNQRUtFDQo+ID4gcHJvdG9jb2wsSSB0aGluay4NCj4gPiBJIGFt IG5vdCBzdXJlIGFib3V0IHRoZSB1c2FnZSBvZiAgUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxh cikgaW4gdGhlDQo+ID4gS8KjwqwNCj4gPiBiZWNhdXNlIG9ubHkgcGVyc29uIHdobyBrbm93cyBQ RSBjYW4NCj4gPiBjYWxjdWxhdGUgaXQuDQo+IA0KPiAgIE5vdCBleGFjdGx5IFNQRUtFPyBJdCdz IFNQRUtFIHdpdGggZXh0cmFuZW91cyBjb21wdXRhdGlvbiB3aGljaCBkbw0KPiBub3QgYWRkIGFu eXRoaW5nIHRvIHRoZSBzZWN1cml0eSBvZiB0aGUgZXhjaGFuZ2UuDQoNCj4gICBBbHNvLCBpdCBp cyBhbiBvcGVuIHF1ZXN0aW9uIHdoZXRoZXIgIm15IHByb3RvY29sIGNhbiBiZSByZWR1Y2VkIHRv IGFzDQo+IHNlY3VyZSBhcyBTUEVLRS4iIFRoYXQgaXMgd2hhdCBpcyBwcm9tcHRpbmcgbXkgcmVx dWVzdCBmb3IgaGVscCBpbiB0aGlzDQo+IGZvcnVtLiBBcyBEci4gS2F0eiBub3RlZCwgaXQgZG9l c24ndCBzZWVtIGxpa2VseSB0aGF0IHRoZSBwcm90b2NvbCBjYW4gDQpiZQ0KPiBwcm92ZW4gc2Vj dXJlIGluIHRoZSBSYW5kb20gT3JhY2xlIG1vZGVsLCBhbmQgSSBiZWxpZXZlIFNQRUtFIGNhbiBi ZQ0KPiBwcm92ZW4gc2VjdXJlIGluIHRoZSBSYW5kb20gT3JhY2xlIG1vZGVsLg0KDQpldmVuIGEg bGl0dGxlIGRpZmZlcmVuY2UgY2FuIGxlYWQgdG8gcHJvdmFibGUgb3IgdW4tcHJvdmFibGUuIA0K dGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgU1BFS0UgIGFjdHVhbGx5IG5vdCBoYXZlIGEgcHJvb2Yg b2Ygc2VjdXJpdHksbGF0ZXIgDQoNCmEgcHJvb2Ygc2VjdXJpdHkgaXMgZ2l2ZW4gb24gYSBzbGln aHQgdmFyaWFudCBvZiBTUEVLRSAsIGFuZCBub3QgdXNpbmcgDQpST00sIGJ1dA0KdXNpbmcgU2hv dXAncyBzaW11bGF0aW9uIG1vZGVsLg0KDQpBbmQgaXQgaXMgbm90IGNsZWFyIGlmIHRoZSAiZXh0 cmFuZW91cyBjb21wdXRhdGlvbiIgY2FuIGhlbHAgdGhlIHByb29mIG9mIA0Kc2VjdXJpdHkuDQoN Cj4gDQo+ID4gSW4gbXkgb3BpbmlvbiwgZm9yIGEga2V5IGFncmVlbWVudCBwcm90b2NvbCwgdGhl IHNpbXBsZXIgdGhlIGJldHRlciwgDQpib3RoDQo+ID4gZm9yIGFuYWx5c2lzIGFuZCBmb3Igc2Vj dXJpdHkuDQo+ID4gVG8gZ28gYXJvdW5kIHBhdGVudGVkIHByb3RvY29sIGlzIGFub3RoZXIgdG9w aWMuDQo+IA0KPiAgIElmIHlvdSBiZWxpZXZlIHRoZSBzaW1wbGVyIHRoZSBiZXR0ZXIgdGhlbiBk byBhd2F5IHdpdGggdGhlIGV4dHJhbmVvdXMNCj4gZWxlbWVudHMNCj4gaW4gdGhlIGV4Y2hhbmdl IHlvdSBkZXNjcmliZSBhYm92ZS4gVGhlIHNlY3JldCBpbmZvcm1hdGlvbiBpcyANCiJsb2NhbF9t YXNrIg0KPiBhbmQgInBlZXJfbWFzayIuIFlvdSBhcmUgZXhjaGFuZ2luZyBlbGVtZW50cyBpbiB0 aGUgZ3JvdXAgdXNpbmcgYSBzZWNyZXQNCj4gZ2VuZXJhdG9yIGV4cG9uZW50aWF0ZWQgdG8gZWFj aCBzaWRlJ3MgcmVzcGVjdGl2ZSBzZWNyZXQgaW5mb3JtYXRpb24gYW5kDQo+IGRvaW5nDQo+IGEg ZGlmZmllLWhlbGxtYW4gZXhjaGFuZ2UuIEhhdmluZyBlYWNoIHNpZGUgbXVsdGlwbHkgdGhlIHJl c3VsdCBvZiB0aGUNCj4gZGlmZmllLWhlbGxtYW4NCj4gYnkgYWRkaXRpb25hbCBpbmZvcm1hdGlv bi0tIDEsIDg3MzgsIFBFXjg3Mzggb3INCj4gUEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcikt LQ0KPiBkb2Vzbid0IHJlYWxseSBjb250cmlidXRlIGFueXRoaW5nIHRvIHRoZSBzZWN1cml0eSBv ZiB0aGUgZXhjaGFuZ2UuDQoNCkl0IGlzIG5vdCBhIG5ldyBwcm90b2NvbCBJIHB1dCBmb3J3YXJk LCBqdXN0IGEgcmVkdWNlZCB2ZXJzaW9uIG9mIHlvdXIgDQpwcm90b2NvbCwNClBFXihTYSpTYikg YWxvbmUgaXMgbm90IHNhZmUsIGJ1dCBpbiBjb21iaW5hdGlvbiBvZiBQRV4oTWEqTWIpLG1heWJl IGl0IA0KY2FuIGhlbHAgdGhlIA0KcHJvb2YuDQoNCkkgaGF2ZSBub3QgZG9uZSBzZWN1cml0eSBw cm9vZiBmb3IgYSBsb25nIHRpbWUsIGp1c3QgaG9wZSB0aGlzIHJlZHVjZWQgDQp2ZXJzaW9uIGNh biANCmhlbHAgb3RoZXIgcGVvcGxlIGFuYWx5c2luZyB5b3VyIHByb3RvY29sLiANCg0KPiANCj4g ICByZWdhcmRzLA0KPiANCj4gICBEYW4uDQo+IA0KPiANCj4gDQo+IA0KPiANCg0K --=_alternative 002F171E48257A0C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtEYW4gSGFya2lucyZxdW90OyAmbHQ7ZGhhcmtp bnNAbG91bmdlLm9yZyZndDsNCuWGmeS6jiAyMDEyLTA1LTI4IDE2OjA5OjUzOjxicj4NCjxicj4N CiZndDsgPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyBQYXJ0IG9mIHlvdXIgcmVk dWN0aW9uIHJlcXVpcmVzIGtub3dsZWRnZSBvZiBpbmZvcm1hdGlvbiB0aGF0DQp5b3UgY2Fubm90 PGJyPg0KJmd0OyBoYXZlPGJyPg0KJmd0OyBzbyBpdCBkb2Vzbid0IHdvcmsuPGJyPg0KSSBoYXZl IGNvcnJlY3RlZCB0aGUgcGFydCBvZiBjb21wdXRhdGlvbiBjb21wYXJpc29uIGluIGFub3RoZXIg ZW1haWwuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5ZZXMsIHlvdSBhcmUgcmln aHQsIHRoZSBjb21wdXRhdGlvbiBzYXZpbmcgaXMgbGl0dGxlLA0KPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5idXQgeW91IGNhbiBzYXZlIHRoZSBleGNoYW5nZSBtZXNzYWdlLiA8 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 IFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGJlbG93IGlzIGEgKmRpZmZlcmVudCoNCnByb3RvY29s Ljxicj4NCkl0IGxvb2tzIGRpZmZlcmVudCwgYnV0IGFjdHVhbGx5IHRoZSBzYW1lLCBJIGp1c3Qg dGFrZSBhd2F5IHRoZSBwYXJ0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj53aGlj aCBjYW4gYmUgZGlyZWN0bHkgY2FsY3VsYXRlZCBmcm9tIHRoZSBleGNoYW5nZWQNCnBsYWluIG1l c3NhZ2UuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgMicuIGdlbmVyYXRlIDIgcmFu ZG9tIG51bWJlcnMgYmV0d2VlbiAwIGFuZCB0aGUgb3JkZXINCm9mIHRoZSBncm91cCw8YnI+DQom Z3Q7ICZndDsmZ3Q7IHE6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDswICZsdDsgbG9jYWxfbWFzayxsb2NhbF9zY2FsYXIgJmx0OyBx PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDMnLiBjb21w dXRlIGFuIGVsZW1lbnQ6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtsb2Nh bF9lbGVtZW50ID0gMS8oUEVebG9jYWxfbWFzaykgbW9kIHA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3doZXJlIHAgaXMgdGhlIHBy aW1lIGFuZCBxIGlzIHRoZSBvcmRlci4NClNlbmQgbG9jYWxfc2NhbGFyIGFuZDxicj4NCiZndDsg Jmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7bG9jYWxfZWxlbWVudCB0byBvdGhlciBzaWRlPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDQnLiByZWNlaXZl IHBlZXJfc2NhbGFyIGFuZCBwZWVyX2VsZW1lbnQgZnJvbSBvdGhlcg0Kc2lkZTxicj4NCiZndDsg Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyA1Jy4gY29tcHV0ZSBzaGFyZWQg a2V5LCBLPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDtLID1QRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyKSogKHBlZXJfZWxlbWVu dCleKC1sb2NhbF9tYXNrKQ0KbW9kPGJyPg0KJmd0OyAmZ3Q7IHA8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9UEVeKHBlZXJfc2NhbGFyKmxvY2FsX3NjYWxhcits b2NhbF9tYXNrKnBlZXJfbWFzaykNCm1vZCBwPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEl0IGlzIHNpbXBsZXIgYW5kIGxlc3MgY29tcHV0YXRpb24gaW52 bG92ZWQsIGFuZCBob3BlZnVsbHkNCmVhc2llciB0bzxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBh bmFseXNpcyB0aGUgc2VjdXJpdHkuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgJm5ic3A7IFBFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIpIGlzIGNvbXBsZXRlbHkgZXh0 cmFuZW91cy4NClRoaXMgaXMganVzdDxicj4NCiZndDsgJmd0OyZndDsgYSBzdGFuZGFyZCBkaWZm aWUtaGVsbG1hbiB3aXRoIHBlZXJfbWFzayBhbmQgbG9jYWxfbWFzayBhcw0KdGhlIHByaXZhdGU8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGNvbnRyaWJ1dGlvbnMgdXNpbmcsIHByZXN1bWFibHksIGEgcGFz c3dvcmQtZGVyaXZlZCBnZW5lcmF0b3INCih5b3U8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRvbid0IGFj dHVhbGx5IHNheSkuIFRoZSBleGNoYW5nZSBhYm92ZSBoYXMgcmVjZWl2ZWQgcXVpdGUNCmEgYml0 IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhbmFseXNpcyBhbHJlYWR5OiBpdCdzIHRoZSBTUEVLRSBw cm90b2NvbC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIHJlZHVjZWQgcHJvdG9j b2wgaXMgbm90IGV4YWN0bHkgU1BFS0UsIGFuZCBvZiBjb3Vyc2UgdGhleQ0KYXJlPGJyPg0KJmd0 OyAmZ3Q7IHNpbWlsYXIuPGJyPg0KJmd0OyAmZ3Q7IEl0IGlzIGEgZ29vZCBuZXdzIHRoYXQgeW91 ciBwcm90b2NvbCBjYW4gYmUgcmVkdWNlZCB0byBhcyBzZWN1cmUNCmFzIFNQRUtFPGJyPg0KJmd0 OyAmZ3Q7IHByb3RvY29sLEkgdGhpbmsuPGJyPg0KJmd0OyAmZ3Q7IEkgYW0gbm90IHN1cmUgYWJv dXQgdGhlIHVzYWdlIG9mICZuYnNwO1BFXihwZWVyX3NjYWxhcipsb2NhbF9zY2FsYXIpDQppbiB0 aGU8YnI+DQomZ3Q7ICZndDsgS8Kjwqw8YnI+DQomZ3Q7ICZndDsgYmVjYXVzZSBvbmx5IHBlcnNv biB3aG8ga25vd3MgUEUgY2FuPGJyPg0KJmd0OyAmZ3Q7IGNhbGN1bGF0ZSBpdC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgJm5ic3A7IE5vdCBleGFjdGx5IFNQRUtFPyBJdCdzIFNQRUtFIHdpdGggZXh0 cmFuZW91cyBjb21wdXRhdGlvbiB3aGljaA0KZG88YnI+DQomZ3Q7IG5vdCBhZGQgYW55dGhpbmcg dG8gdGhlIHNlY3VyaXR5IG9mIHRoZSBleGNoYW5nZS48YnI+DQo8YnI+DQomZ3Q7ICZuYnNwOyBB bHNvLCBpdCBpcyBhbiBvcGVuIHF1ZXN0aW9uIHdoZXRoZXIgJnF1b3Q7bXkgcHJvdG9jb2wgY2Fu DQpiZSByZWR1Y2VkIHRvIGFzPGJyPg0KJmd0OyBzZWN1cmUgYXMgU1BFS0UuJnF1b3Q7IFRoYXQg aXMgd2hhdCBpcyBwcm9tcHRpbmcgbXkgcmVxdWVzdCBmb3IgaGVscA0KaW4gdGhpczxicj4NCiZn dDsgZm9ydW0uIEFzIERyLiBLYXR6IG5vdGVkLCBpdCBkb2Vzbid0IHNlZW0gbGlrZWx5IHRoYXQg dGhlIHByb3RvY29sDQpjYW4gYmU8YnI+DQomZ3Q7IHByb3ZlbiBzZWN1cmUgaW4gdGhlIFJhbmRv bSBPcmFjbGUgbW9kZWwsIGFuZCBJIGJlbGlldmUgU1BFS0UgY2FuDQpiZTxicj4NCiZndDsgcHJv dmVuIHNlY3VyZSBpbiB0aGUgUmFuZG9tIE9yYWNsZSBtb2RlbC48YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPmV2ZW4gYSBsaXR0bGUgZGlmZmVyZW5jZSBjYW4gbGVhZCB0 byBwcm92YWJsZSBvciB1bi1wcm92YWJsZS4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+dGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgU1BFS0UgJm5ic3A7YWN0dWFsbHkgbm90IGhh dmUNCmEgcHJvb2Ygb2Ygc2VjdXJpdHksbGF0ZXIgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5hIHByb29mIHNlY3VyaXR5IGlzIGdpdmVuIG9uIGEgc2xpZ2h0IHZhcmlhbnQgb2Yg U1BFS0UNCiwgYW5kIG5vdCB1c2luZyBST00sIGJ1dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+dXNpbmcgU2hvdXAncyBzaW11bGF0aW9uIG1vZGVsLjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QW5kIGl0IGlzIG5vdCBjbGVhciBpZiB0aGUgJnF1b3Q7 ZXh0cmFuZW91cyBjb21wdXRhdGlvbiZxdW90Ow0KY2FuIGhlbHAgdGhlIHByb29mIG9mIHNlY3Vy aXR5LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7ICZndDsgSW4gbXkgb3BpbmlvbiwgZm9yIGEga2V5IGFncmVlbWVudCBwcm90b2NvbCwgdGhl IHNpbXBsZXIgdGhlDQpiZXR0ZXIsIGJvdGg8YnI+DQomZ3Q7ICZndDsgZm9yIGFuYWx5c2lzIGFu ZCBmb3Igc2VjdXJpdHkuPGJyPg0KJmd0OyAmZ3Q7IFRvIGdvIGFyb3VuZCBwYXRlbnRlZCBwcm90 b2NvbCBpcyBhbm90aGVyIHRvcGljLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgSWYgeW91 IGJlbGlldmUgdGhlIHNpbXBsZXIgdGhlIGJldHRlciB0aGVuIGRvIGF3YXkgd2l0aCB0aGUNCmV4 dHJhbmVvdXM8YnI+DQomZ3Q7IGVsZW1lbnRzPGJyPg0KJmd0OyBpbiB0aGUgZXhjaGFuZ2UgeW91 IGRlc2NyaWJlIGFib3ZlLiBUaGUgc2VjcmV0IGluZm9ybWF0aW9uIGlzICZxdW90O2xvY2FsX21h c2smcXVvdDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgYW5kICZxdW90 O3BlZXJfbWFzayZxdW90Oy4gWW91IGFyZSBleGNoYW5naW5nDQplbGVtZW50cyBpbiB0aGUgZ3Jv dXAgdXNpbmcgYSBzZWNyZXQ8YnI+DQomZ3Q7IGdlbmVyYXRvciBleHBvbmVudGlhdGVkIHRvIGVh Y2ggc2lkZSdzIHJlc3BlY3RpdmUgc2VjcmV0IGluZm9ybWF0aW9uDQphbmQ8YnI+DQomZ3Q7IGRv aW5nPGJyPg0KJmd0OyBhIGRpZmZpZS1oZWxsbWFuIGV4Y2hhbmdlLiBIYXZpbmcgZWFjaCBzaWRl IG11bHRpcGx5IHRoZSByZXN1bHQgb2YNCnRoZTxicj4NCiZndDsgZGlmZmllLWhlbGxtYW48YnI+ DQomZ3Q7IGJ5IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24tLSAxLCA4NzM4LCBQRV44NzM4IG9yPGJy Pg0KJmd0OyBQRV4ocGVlcl9zY2FsYXIqbG9jYWxfc2NhbGFyKS0tPGJyPg0KJmd0OyBkb2Vzbid0 IHJlYWxseSBjb250cmlidXRlIGFueXRoaW5nIHRvIHRoZSBzZWN1cml0eSBvZiB0aGUgZXhjaGFu Z2UuPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JdCBpcyBub3QgYSBu ZXcgcHJvdG9jb2wgSSBwdXQgZm9yd2FyZCwganVzdCBhIHJlZHVjZWQNCnZlcnNpb24gb2YgeW91 ciBwcm90b2NvbCw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlBFXihTYSpTYikg YWxvbmUgaXMgbm90IHNhZmUsIGJ1dCBpbiBjb21iaW5hdGlvbiBvZg0KUEVeKE1hKk1iKSxtYXli ZSBpdCBjYW4gaGVscCB0aGUgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5wcm9v Zi48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgaGF2ZSBub3QgZG9u ZSBzZWN1cml0eSBwcm9vZiBmb3IgYSBsb25nIHRpbWUsIGp1c3QNCmhvcGUgdGhpcyByZWR1Y2Vk IHZlcnNpb24gY2FuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+aGVscCBvdGhl ciBwZW9wbGUgYW5hbHlzaW5nIHlvdXIgcHJvdG9jb2wuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyByZWdhcmRzLDxicj4NCiZn dDsgPGJyPg0KJmd0OyAmbmJzcDsgRGFuLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 002F171E48257A0C_=-- From zhou.sujing@zte.com.cn Mon May 28 02:14:20 2012 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 735DF21F856D for ; Mon, 28 May 2012 02:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.813 X-Spam-Level: X-Spam-Status: No, score=-100.813 tagged_above=-999 required=5 tests=[AWL=2.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, 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 Gl-G-1Iqi0Ke for ; Mon, 28 May 2012 02:14:20 -0700 (PDT) Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id BF1B221F8568 for ; Mon, 28 May 2012 02:14:18 -0700 (PDT) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 52926.1065689647; Mon, 28 May 2012 17:08:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q4S98V2v053969; Mon, 28 May 2012 17:08:31 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <23a6d3dd03b27579cbf223f1aa52232b.squirrel@www.trepanning.net> To: "Dan Harkins" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 28 May 2012 17:08:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-28 17:08:33, Serialize complete at 2012-05-28 17:08:33 Content-Type: multipart/alternative; boundary="=_alternative 0032417048257A0C_=" X-MAIL: mse02.zte.com.cn q4S98V2v053969 Cc: cfrg@irtf.org Subject: Re: [Cfrg] password-based key exchange,revisited 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, 28 May 2012 09:14:20 -0000 This is a multipart message in MIME format. --=_alternative 0032417048257A0C_= Content-Type: text/plain; charset="US-ASCII" > > What you are describing below is a *different* protocol. You can call it a different new protocol, but it has the same security as your protocol and simpler. > > >> > >> > 2'. generate 2 random numbers between 0 and the order of the group, > >> q: > >> > > >> > 0 < local_mask,local_scalar < q > >> > > >> > 3'. compute an element: > >> > local_element = 1/(PE^local_mask) mod p > >> > > >> > where p is the prime and q is the order. Send local_scalar and > >> > local_element to other side > >> > > >> > 4'. receive peer_scalar and peer_element from other side > >> > > >> > 5'. compute shared key, K > >> > > >> > K =PE^(peer_scalar*local_scalar)* (peer_element)^(-local_mask) mod > > p > >> > =PE^(peer_scalar*local_scalar+local_mask*peer_mask) mod p > >> > --=_alternative 0032417048257A0C_= Content-Type: text/html; charset="US-ASCII"

>
>   What you are describing below is a *different* protocol.
You can call it a different new protocol, but it has the same security as
your protocol and simpler.

>
> >>
> >> > 2'. generate 2 random numbers between 0 and the order of the group,
> >> q:
> >> >
> >> >    0 < local_mask,local_scalar < q
> >> >
> >> > 3'. compute an element:
> >> >    local_element = 1/(PE^local_mask) mod p
> >> >
> >> >    where p is the prime and q is the order. Send local_scalar and
> >> >    local_element to other side
> >> >
> >> > 4'. receive peer_scalar and peer_element from other side
> >> >
> >> > 5'. compute shared key, K
> >> >
> >> >    K =PE^(peer_scalar*local_scalar)* (peer_element)^(-local_mask) mod
> > p
> >> >      =PE^(peer_scalar*local_scalar+local_mask*peer_mask) mod p
> >> >
 --=_alternative 0032417048257A0C_=-- From dharkins@lounge.org Mon May 28 02:19:40 2012 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 C6F4421F8552 for ; Mon, 28 May 2012 02:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.39 X-Spam-Level: X-Spam-Status: No, score=-5.39 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ZsdsjnRpx9XG for ; Mon, 28 May 2012 02:19:40 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 56C8821F853D for ; Mon, 28 May 2012 02:19:40 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B1707A88810E; Mon, 28 May 2012 02:19:39 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 May 2012 02:19:39 -0700 (PDT) Message-ID: <475dd2f480aaa60ed1e2287ba5365c38.squirrel@www.trepanning.net> In-Reply-To: References: Date: Mon, 28 May 2012 02:19:39 -0700 (PDT) From: "Dan Harkins" To: zhou.sujing@zte.com.cn User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org Subject: Re: [Cfrg] password-based key exchange,revisited 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, 28 May 2012 09:19:40 -0000 On Mon, May 28, 2012 1:34 am, zhou.sujing@zte.com.cn wrote: [snip[ > It is not a new protocol I put forward, just a reduced version of your > protocol, > PE^(Sa*Sb) alone is not safe, but in combination of PE^(Ma*Mb),maybe it > can help the > proof. Let me repeat: you CANNOT do this "reduction" because it requires knowledge of unknown variables, namely "Ma" and "Mb". You CANNOT compute PE^(Ma*Mb) so this doesn't work! You have not "reduced" my protocol, you have just "rediscovered" a different protocol and added some extraneous and frivolous computation to it that serve no purpose whatsoever. > I have not done security proof for a long time, just hope this reduced > version can > help other people analysing your protocol. I would ask anyone who is thinking of analyzing my protocol to please just look at my protocol. Dan. From zhou.sujing@zte.com.cn Mon May 28 02:29:34 2012 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 35EB921F859E for ; Mon, 28 May 2012 02:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.795 X-Spam-Level: X-Spam-Status: No, score=-96.795 tagged_above=-999 required=5 tests=[AWL=-3.005, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, 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 C27CjU0V1zNR for ; Mon, 28 May 2012 02:29:33 -0700 (PDT) Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3B98221F8597 for ; Mon, 28 May 2012 02:29:33 -0700 (PDT) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 52926.1065689647; Mon, 28 May 2012 17:25:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q4S9PZhT089058; Mon, 28 May 2012 17:25:35 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <475dd2f480aaa60ed1e2287ba5365c38.squirrel@www.trepanning.net> To: "Dan Harkins" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 28 May 2012 17:25:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-28 17:25:38, Serialize complete at 2012-05-28 17:25:38 Content-Type: multipart/alternative; boundary="=_alternative 0033D27548257A0C_=" X-MAIL: mse02.zte.com.cn q4S9PZhT089058 Cc: cfrg@irtf.org Subject: [Cfrg] =?gb2312?b?tPC4tDogUkU6IFJFOnBhc3N3b3JkLWJhc2VkIGtleSBl?= =?gb2312?b?eGNoYW5nZSxyZXZpc2l0ZWQ=?= 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, 28 May 2012 09:29:34 -0000 This is a multipart message in MIME format. --=_alternative 0033D27548257A0C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IkRhbiBIYXJraW5zIiA8ZGhhcmtpbnNAbG91bmdlLm9yZz4g0LTT2iAyMDEyLTA1LTI4IDE3OjE5 OjM5Og0KDQo+IA0KPiANCj4gT24gTW9uLCBNYXkgMjgsIDIwMTIgMTozNCBhbSwgemhvdS5zdWpp bmdAenRlLmNvbS5jbiB3cm90ZToNCj4gW3NuaXBbDQo+ID4gSXQgaXMgbm90IGEgbmV3IHByb3Rv Y29sIEkgcHV0IGZvcndhcmQsIGp1c3QgYSByZWR1Y2VkIHZlcnNpb24gb2YgeW91cg0KPiA+IHBy b3RvY29sLA0KPiA+IFBFXihTYSpTYikgYWxvbmUgaXMgbm90IHNhZmUsIGJ1dCBpbiBjb21iaW5h dGlvbiBvZiBQRV4oTWEqTWIpLG1heWJlIA0KaXQNCj4gPiBjYW4gaGVscCB0aGUNCj4gPiBwcm9v Zi4NCj4gDQo+ICAgTGV0IG1lIHJlcGVhdDogeW91IENBTk5PVCBkbyB0aGlzICJyZWR1Y3Rpb24i IGJlY2F1c2UgaXQgcmVxdWlyZXMNCj4ga25vd2xlZGdlIG9mIHVua25vd24gdmFyaWFibGVzLCBu YW1lbHkgIk1hIiBhbmQgIk1iIi4gWW91IENBTk5PVA0KPiBjb21wdXRlIFBFXihNYSpNYikgc28g dGhpcyBkb2Vzbid0IHdvcmshDQoNCkkgZG9uJ3QgaGF2ZSB0byBrbm93IE1hIE1iIHRvIGNvbXB1 dGUgUEVeKE1hKk1iKQ0KUEVeKE1hKk1iKT0ocGVlcl9lbGVtZW50KV4oLWxvY2FsX21hc2spDQoN Cj4gDQo+ICAgWW91IGhhdmUgbm90ICJyZWR1Y2VkIiBteSBwcm90b2NvbCwgeW91IGhhdmUganVz dCAicmVkaXNjb3ZlcmVkIiBhDQo+IGRpZmZlcmVudCBwcm90b2NvbCBhbmQgYWRkZWQgc29tZSBl eHRyYW5lb3VzIGFuZCBmcml2b2xvdXMgY29tcHV0YXRpb24NCj4gdG8gaXQgdGhhdCBzZXJ2ZSBu byBwdXJwb3NlICB3aGF0c29ldmVyLg0KPiANCj4gPiBJIGhhdmUgbm90IGRvbmUgc2VjdXJpdHkg cHJvb2YgZm9yIGEgbG9uZyB0aW1lLCBqdXN0IGhvcGUgdGhpcyByZWR1Y2VkDQo+ID4gdmVyc2lv biBjYW4NCj4gPiBoZWxwIG90aGVyIHBlb3BsZSBhbmFseXNpbmcgeW91ciBwcm90b2NvbC4NCj4g DQo+ICAgSSB3b3VsZCBhc2sgYW55b25lIHdobyBpcyB0aGlua2luZyBvZiBhbmFseXppbmcgbXkg cHJvdG9jb2wgdG8gcGxlYXNlDQo+IGp1c3QgbG9vayBhdCBteSBwcm90b2NvbC4NCk9LLCB0aGVu IGFueW9uZSB0cnlpbmcgdG8gZG8gdGhpcyBqb2IgbWF5IGZpbmQgdGhlbXNlbHZzIHRoaXMgc2lt cGxlciANCnZlcnNpb24uDQoNCj4gDQo+ICAgRGFuLg0KPiANCj4gDQo+IA0KDQo= --=_alternative 0033D27548257A0C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtEYW4gSGFya2lucyZxdW90OyAmbHQ7 ZGhhcmtpbnNAbG91bmdlLm9yZyZndDsNCtC009ogMjAxMi0wNS0yOCAxNzoxOTozOTo8YnI+DQo8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIE1heSAyOCwgMjAxMiAxOjM0 IGFtLCB6aG91LnN1amluZ0B6dGUuY29tLmNuIHdyb3RlOjxicj4NCiZndDsgW3NuaXBbPGJyPg0K Jmd0OyAmZ3Q7IEl0IGlzIG5vdCBhIG5ldyBwcm90b2NvbCBJIHB1dCBmb3J3YXJkLCBqdXN0IGEg cmVkdWNlZCB2ZXJzaW9uDQpvZiB5b3VyPGJyPg0KJmd0OyAmZ3Q7IHByb3RvY29sLDxicj4NCiZn dDsgJmd0OyBQRV4oU2EqU2IpIGFsb25lIGlzIG5vdCBzYWZlLCBidXQgaW4gY29tYmluYXRpb24g b2YgUEVeKE1hKk1iKSxtYXliZQ0KaXQ8YnI+DQomZ3Q7ICZndDsgY2FuIGhlbHAgdGhlPGJyPg0K Jmd0OyAmZ3Q7IHByb29mLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgTGV0IG1lIHJlcGVh dDogeW91IENBTk5PVCBkbyB0aGlzICZxdW90O3JlZHVjdGlvbiZxdW90OyBiZWNhdXNlDQppdCBy ZXF1aXJlczxicj4NCiZndDsga25vd2xlZGdlIG9mIHVua25vd24gdmFyaWFibGVzLCBuYW1lbHkg JnF1b3Q7TWEmcXVvdDsgYW5kICZxdW90O01iJnF1b3Q7Lg0KWW91IENBTk5PVDxicj4NCiZndDsg Y29tcHV0ZSBQRV4oTWEqTWIpIHNvIHRoaXMgZG9lc24ndCB3b3JrITxicj4NCjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSBkb24ndCBoYXZlIHRvIGtub3cgTWEgTWIgdG8gY29t cHV0ZSBQRV4oTWEqTWIpPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5QRV4oTWEq TWIpPShwZWVyX2VsZW1lbnQpXigtbG9jYWxfbWFzayk8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgWW91IGhhdmUgbm90ICZxdW90 O3JlZHVjZWQmcXVvdDsgbXkgcHJvdG9jb2wsIHlvdSBoYXZlIGp1c3QNCiZxdW90O3JlZGlzY292 ZXJlZCZxdW90OyBhPGJyPg0KJmd0OyBkaWZmZXJlbnQgcHJvdG9jb2wgYW5kIGFkZGVkIHNvbWUg ZXh0cmFuZW91cyBhbmQgZnJpdm9sb3VzIGNvbXB1dGF0aW9uPGJyPg0KJmd0OyB0byBpdCB0aGF0 IHNlcnZlIG5vIHB1cnBvc2UgJm5ic3A7d2hhdHNvZXZlci48YnI+DQomZ3Q7IDxicj4NCiZndDsg Jmd0OyBJIGhhdmUgbm90IGRvbmUgc2VjdXJpdHkgcHJvb2YgZm9yIGEgbG9uZyB0aW1lLCBqdXN0 IGhvcGUgdGhpcw0KcmVkdWNlZDxicj4NCiZndDsgJmd0OyB2ZXJzaW9uIGNhbjxicj4NCiZndDsg Jmd0OyBoZWxwIG90aGVyIHBlb3BsZSBhbmFseXNpbmcgeW91ciBwcm90b2NvbC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgJm5ic3A7IEkgd291bGQgYXNrIGFueW9uZSB3aG8gaXMgdGhpbmtpbmcgb2Yg YW5hbHl6aW5nIG15IHByb3RvY29sDQp0byBwbGVhc2U8YnI+DQomZ3Q7IGp1c3QgbG9vayBhdCBt eSBwcm90b2NvbC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPk9LLCB0aGVuIGFu eW9uZSB0cnlpbmcgdG8gZG8gdGhpcyBqb2IgbWF5IGZpbmQgdGhlbXNlbHZzDQp0aGlzIHNpbXBs ZXIgdmVyc2lvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsg PGJyPg0KJmd0OyAmbmJzcDsgRGFuLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0033D27548257A0C_=-- From mcgrew@cisco.com Thu May 31 11:24:10 2012 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 8975B21F870B for ; Thu, 31 May 2012 11:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Yq7kYZAX258R for ; Thu, 31 May 2012 11:24:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CE6C321F86FD for ; Thu, 31 May 2012 11:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=265; q=dns/txt; s=iport; t=1338488649; x=1339698249; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=tEtA6nFDzTIZ+XIbFvYSfr6hZwRCuGU5Cwcq9zuWaB0=; b=Hie7P4Pp5SMDMfa6gspzrzx+so6+EsHaQk2OhdsdAz2LbeDOaaNjuFUP pOv4lQiUvLzSRknNYHKxEgXYNHfLfm++/MveAL4JIHnEt+7lxsfG4EK0l qB99RleTy1kmAiLedPt2bSMyFHibKB1bm82UALg1N6/NO0l1t21C2exhR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4HAC+2x0+tJV2Y/2dsb2JhbABEjRimfIEHgjEBJ4Iyh2mYBYEon0uNQYI2YAOVGI4NgWaCfA X-IronPort-AV: E=Sophos;i="4.75,693,1330905600"; d="scan'208";a="88397299" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 31 May 2012 18:24:01 +0000 Received: from rtp-mcgrew-8911.cisco.com (rtp-mcgrew-8911.cisco.com [10.117.10.226]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4VIO0LH020256 for ; Thu, 31 May 2012 18:24:00 GMT From: David McGrew Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 May 2012 14:23:59 -0400 Message-Id: <9F4ED04E-A6A3-4E7B-AB3C-574820A132DF@cisco.com> To: cfrg@irtf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Cfrg] review of OCBv3 draft 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, 31 May 2012 18:24:10 -0000 Hi, In Paris, several people volunteered to review draft-krovetz-ocb-03. = This is a gentle reminder - you know who you are :-) Comments are = solicited on security analysis, implementation experience, or other = relevant aspects. thanks, David=