From nobody Tue Aug 1 14:22:18 2017 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 B8BF4126C2F for ; Tue, 1 Aug 2017 14:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-JnpGol4wg5 for ; Tue, 1 Aug 2017 14:22:14 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B268126B6E for ; Tue, 1 Aug 2017 14:22:13 -0700 (PDT) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2017 17:22:11 -0400 Received: from XCT197YKF.rim.net (10.2.25.5) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 1 Aug 2017 17:22:11 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT197YKF.rim.net ([fe80::459a:3e96:7706:5ba1%12]) with mapi id 14.03.0319.002; Tue, 1 Aug 2017 17:22:10 -0400 From: Dan Brown To: Dan Brown , "cfrg@irtf.org" Thread-Topic: ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCQ9d+upA Date: Tue, 1 Aug 2017 21:22:10 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 21:22:16 -0000 Hi CFRG, A minor addition to this topic. In my first email on this topic, and in my recent IETF 99 presentation, I m= entioned that the proposed special curve 2y^2=3Dx^3+x was similar to curves= proposed in Miller's 1985 paper introducing of ECC.=20 I went back and worked out some more details about this similarity (just so= me basic elliptic curve math). To prepare, note that there exists a field element i in GF(8^91+5) with i^2= =3D-1. Putting x=3Diu and y=3D(-i/2)^(1/2)v defines a map to curve with equation v= ^2=3Du^3-u. I believe (99% sure) that this map is an isomorphism (of GF(8^= 91+5)-rational points). This equation has the same form as Miller's propos= ed equation y^2 =3D x^3 - ax, with a=3D1. However, Miller does suggest that value a should not be a perfect square, w= hich rules out a=3D1 above. =20 I believe (50% sure) that Miller made this non-square a recommendation mere= ly to help keep the group cofactor down (by ensuring a unique point of orde= r 2, namely (0,0)). =20 By contrast 2y^2=3Dx^3+x, has a subgroup of order 8. (With points O, (0,0)= , (i,0), (-i,0), (1,1), (1,-1), (-1,i), (-1,-i).) A subgroup of order 4 (o= r 8) is nowadays considered (arguably) an advantage, because of various Edw= ards curves (but I am only 10% sure, since I haven't looked at this in a wh= ile, please correct me this is wrong). So, the special curve 2y^2=3Dx^3+x is isomorphic to a curve with an even mo= re compact representation: y^2=3Dx^3-x. =20 Despite the more compact equation, the original form 2y^2=3Dx^3+x is slight= ly preferable because it is already in the convenient Montgomery form, so I= plan to use the original in the ID. (But if somebody knows how to do the= Montgomery ladder math equally as efficient on a Miller curve y^2=3Dx^3-x,= then I'm all ears :) Best regards, Dan -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan Brown Sent: Tuesday, May 16, 2017 1:36 PM To: cfrg@irtf.org Subject: [Cfrg] ECC mod 8^91+5 Hi all, I'm considering writing an I-D on doing ECC over the field of size 8^91+5 (=3D2^273+5), because it: - is written in just 6 symbols (=3Dlow Kolmogorov complexity, heuristically= minimizing threat of NOBUS-trapdoor), - has easy and fast inversion, Legendre symbols, and square roots, - has efficient arithmetic using at most five 64-bit words (use base 2^55), - is at least 2^(256-epsilon), - is (probably) prime, so not an extension field (has no subfields for desc= ent-type attacks on ECDLP). Other fields can improve on some of these properties, but might worsen the = others. For ECC with this field, I am also considering the special curve 2y^2=3Dx^3+x, because it: - is written in just 10 symbols (similar gains to 6-symbol field), - has Montgomery form (and easily converts to Weierstrass), - has efficient endomorphism (so it is a GLV curve), - is similar to curves already suggested by Miller in 1985 (well-aged), - is similar to sect256k1 already used in bitcoin (incentivized), - has an small enough cofactor 72 (over field size 8^91+5), - avoids the main ECDLP attacks: Pohlig-Hellman, Menezes-Okamoto-Vanstone, = etc., - is similar to the special curves of Koblitz-Menezes [ia.cr/2008/390, Sec = 11.1, Example 5] resisting a speculative attack. The motivation for this special curve largely matches the motivation for th= e special field. The curve's risks are at least: - CM (endomorphism) makes it potentially weak (after 32 years of being safe= ) (note exactly opposing Koblitz-Menezes rationale), - its small coefficients are weak for some unpublished reason (continuing t= rend of weak small-coefficients, y^2=3Dx^3 (singular), supersingular, etc. = being weak), - weak twist order (so, it requires a static ECDH Montgomery ladder to use = public key validation), - weak Cheon resistance (but this is an attack with many queries, much comp= utation, and faulty or no KDF). - den Boer or Maurer-Wolf reductions are not tight as possible, so perhaps = it has a big gap between DHP and DLP Other curves (over this field) can red= uce these risks, but may also lose some of the benefits. Overall, E(GF(8^91+5)):2y^2=3Dx^3+x might offer competitive efficiency with= fairly reasonable security (for 128-bit symmetric keys). It is only an inc= remental change over other standard ECC curves, not anything too radical. = =20 I'd be happy to hear what CFRG thinks, or if the CFRG would welcome such an= I-D as a CFRG work item. I hope to have this topic presented briefly at a= n upcoming CFRG meeting. Best regards, Dan Brown _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Aug 2 00:52:12 2017 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 5D37D126BF3 for ; Wed, 2 Aug 2017 00:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwJiu1fOOlmC for ; Wed, 2 Aug 2017 00:52:08 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079F01288B8 for ; Wed, 2 Aug 2017 00:52:07 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id d17so16520973lfe.0 for ; Wed, 02 Aug 2017 00:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OryFn5vO1Rx1MluFGkCe16QEzjlXwAs8jn+ez8esigs=; b=NBKuCAFVK56SSONZNp13LWZqkFEmitMyi5W0kEfFqp6LS872Eqcf3BIr4DzWkn9Tpm Tc/fNrHPTC9oA1l80c1aH8GiCAwZlbaarqoxvcaQHg/5dbV16wFomjAKKcsp9bn9Xn7T ttzXFiulFFpqDi6ZzKoOkMVk0IQB5Vx5Fa3S2h3Npc3pHgq5InBh4Bf+mDznIySANWJ0 jIUbCWviaNns1dcRQw/cDU+jaMAyQd6SWRU+4aVac5sF84xZdfoJRbZJhz7a4kprHaJw FBF7V7F6qzx8W487Iy4wLhk8mCAsdkDTxf5ghmD5HvfylFvoN/t1S3pI1DUgKfMPycOq kmBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OryFn5vO1Rx1MluFGkCe16QEzjlXwAs8jn+ez8esigs=; b=rRQ9+jAPtruMZ81noqTFqgVpgFHy+hkavovz1avSuJxG8XTJbz6ORalb//MvL87iTM Sa8/2xGd4I1sHjyf+SamHrzXIuM/sNoq86LJsv3NqZr1YY3CkF8DYD0/dZPLPvHZf/F3 CtE4XhWmuaVYWd4TRTdPDwk2amiLlLM5bikgj6dtiAPFSCL9e60mEl71DVEOaMc7286H ZSHvXIANqcX9pgoEVLexLCzLZdMvOF8WPa4rKuqizytZYowBS4h4ZwsADxuNbjL4qsqf KBdJkp0jzP7rn9vgK6gRrf7qexgUxYBPA/bRr8pu5sQ3lIlN8rsy8HPnRdVaBi+l2GrP 3yNQ== X-Gm-Message-State: AIVw112iJhSftNWix9zzYHAS/T1VypSTGyLWfWqOzQhbXIrt+YOc3Eji lHr6KDWoL2PIKLPsgnCKRxYQM4o2tg== X-Received: by 10.25.228.206 with SMTP id x75mr6450255lfi.94.1501660326035; Wed, 02 Aug 2017 00:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.40 with HTTP; Wed, 2 Aug 2017 00:52:05 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> From: Thomas Garcia Date: Wed, 2 Aug 2017 08:52:05 +0100 Message-ID: To: Dan Brown Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="94eb2c0c91664e85020555c08a42" Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:52:11 -0000 --94eb2c0c91664e85020555c08a42 Content-Type: text/plain; charset="UTF-8" Hi Dan, The transformation you proposed (x->iu, y->(-i/2)^(1/2)v) does indeed define an isomorphism between the curve (2y^2=x^3+x) and the curve (v^2=u^3-u), modulo p=8^91+5. As this transformation is defined over GF(p), it preserves the group of points modulo p. Thomas G. On Tue, Aug 1, 2017 at 10:22 PM, Dan Brown wrote: > Hi CFRG, > > A minor addition to this topic. > > In my first email on this topic, and in my recent IETF 99 presentation, I > mentioned that the proposed special curve 2y^2=x^3+x was similar to curves > proposed in Miller's 1985 paper introducing of ECC. > > I went back and worked out some more details about this similarity (just > some basic elliptic curve math). > > To prepare, note that there exists a field element i in GF(8^91+5) with > i^2=-1. > > Putting x=iu and y=(-i/2)^(1/2)v defines a map to curve with equation > v^2=u^3-u. I believe (99% sure) that this map is an isomorphism (of > GF(8^91+5)-rational points). This equation has the same form as Miller's > proposed equation y^2 = x^3 - ax, with a=1. > > However, Miller does suggest that value a should not be a perfect square, > which rules out a=1 above. > > I believe (50% sure) that Miller made this non-square a recommendation > merely to help keep the group cofactor down (by ensuring a unique point of > order 2, namely (0,0)). > > By contrast 2y^2=x^3+x, has a subgroup of order 8. (With points O, (0,0), > (i,0), (-i,0), (1,1), (1,-1), (-1,i), (-1,-i).) A subgroup of order 4 (or > 8) is nowadays considered (arguably) an advantage, because of various > Edwards curves (but I am only 10% sure, since I haven't looked at this in a > while, please correct me this is wrong). > > So, the special curve 2y^2=x^3+x is isomorphic to a curve with an even > more compact representation: y^2=x^3-x. > > Despite the more compact equation, the original form 2y^2=x^3+x is > slightly preferable because it is already in the convenient Montgomery > form, so I plan to use the original in the ID. (But if somebody knows how > to do the Montgomery ladder math equally as efficient on a Miller curve > y^2=x^3-x, then I'm all ears :) > > Best regards, > > Dan > > -----Original Message----- > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan Brown > Sent: Tuesday, May 16, 2017 1:36 PM > To: cfrg@irtf.org > Subject: [Cfrg] ECC mod 8^91+5 > > Hi all, > > I'm considering writing an I-D on doing ECC over the field of size > 8^91+5 (=2^273+5), > because it: > - is written in just 6 symbols (=low Kolmogorov complexity, heuristically > minimizing threat of NOBUS-trapdoor), > - has easy and fast inversion, Legendre symbols, and square roots, > - has efficient arithmetic using at most five 64-bit words (use base 2^55), > - is at least 2^(256-epsilon), > - is (probably) prime, so not an extension field (has no subfields for > descent-type attacks on ECDLP). > Other fields can improve on some of these properties, but might worsen the > others. > > For ECC with this field, I am also considering the special curve > 2y^2=x^3+x, > because it: > - is written in just 10 symbols (similar gains to 6-symbol field), > - has Montgomery form (and easily converts to Weierstrass), > - has efficient endomorphism (so it is a GLV curve), > - is similar to curves already suggested by Miller in 1985 (well-aged), > - is similar to sect256k1 already used in bitcoin (incentivized), > - has an small enough cofactor 72 (over field size 8^91+5), > - avoids the main ECDLP attacks: Pohlig-Hellman, Menezes-Okamoto-Vanstone, > etc., > - is similar to the special curves of Koblitz-Menezes [ia.cr/2008/390, > Sec 11.1, Example 5] resisting a speculative attack. > The motivation for this special curve largely matches the motivation for > the special field. > > The curve's risks are at least: > - CM (endomorphism) makes it potentially weak (after 32 years of being > safe) (note exactly opposing Koblitz-Menezes rationale), > - its small coefficients are weak for some unpublished reason (continuing > trend of weak small-coefficients, y^2=x^3 (singular), supersingular, etc. > being weak), > - weak twist order (so, it requires a static ECDH Montgomery ladder to use > public key validation), > - weak Cheon resistance (but this is an attack with many queries, much > computation, and faulty or no KDF). > - den Boer or Maurer-Wolf reductions are not tight as possible, so perhaps > it has a big gap between DHP and DLP Other curves (over this field) can > reduce these risks, but may also lose some of the benefits. > > Overall, E(GF(8^91+5)):2y^2=x^3+x might offer competitive efficiency with > fairly reasonable security (for 128-bit symmetric keys). It is only an > incremental change over other standard ECC curves, not anything too radical. > > I'd be happy to hear what CFRG thinks, or if the CFRG would welcome such > an I-D as a CFRG work item. I hope to have this topic presented briefly at > an upcoming CFRG meeting. > > Best regards, > > Dan Brown > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --94eb2c0c91664e85020555c08a42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dan,
The transformation you proposed (x->iu, y-&= gt;(-i/2)^(1/2)v) does indeed define an isomorphism between the curve (2y^2= =3Dx^3+x) and the curve (v^2=3Du^3-u), modulo p=3D8^91+5. As this transform= ation is defined over GF(p), it preserves the group of points modulo p.

Thomas G.

<= div class=3D"gmail_quote">On Tue, Aug 1, 2017 at 10:22 PM, Dan Brown <danibrown@blackberry.com> wrote:
Hi CFRG,

A minor addition to this topic.

In my first email on this topic, and in my recent IETF 99 presentation, I m= entioned that the proposed special curve 2y^2=3Dx^3+x was similar to curves= proposed in Miller's 1985 paper introducing of ECC.

I went back and worked out some more details about this similarity (just so= me basic elliptic curve math).

To prepare, note that there exists a field element i in GF(8^91+5) with i^2= =3D-1.

Putting x=3Diu and y=3D(-i/2)^(1/2)v defines a map to curve with equation v= ^2=3Du^3-u.=C2=A0 I believe (99% sure) that this map is an isomorphism (of = GF(8^91+5)-rational points).=C2=A0 This equation has the same form as Mille= r's proposed equation y^2 =3D x^3 - ax, with a=3D1.

However, Miller does suggest that value a should not be a perfect square, w= hich rules out a=3D1 above.

I believe (50% sure) that Miller made this non-square a recommendation mere= ly to help keep the group cofactor down (by ensuring a unique point of orde= r 2, namely (0,0)).

By contrast 2y^2=3Dx^3+x, has a subgroup of order 8.=C2=A0 (With points O, = (0,0), (i,0), (-i,0), (1,1), (1,-1), (-1,i), (-1,-i).)=C2=A0 A subgroup of = order 4 (or 8) is nowadays considered (arguably) an advantage, because of v= arious Edwards curves (but I am only 10% sure, since I haven't looked a= t this in a while, please correct me this is wrong).

So, the special curve 2y^2=3Dx^3+x is isomorphic to a curve with an even mo= re compact representation: y^2=3Dx^3-x.

Despite the more compact equation, the original form 2y^2=3Dx^3+x is slight= ly preferable because it is already in the convenient Montgomery form, so I= plan to use the original in the ID.=C2=A0 =C2=A0(But if somebody knows how= to do the Montgomery ladder math equally as efficient on a Miller curve y^= 2=3Dx^3-x, then I'm all ears :)

Best regards,

Dan

-----Original Message-----
From: Cfrg [mailto:cfrg-bounces@ir= tf.org] On Behalf Of Dan Brown
Sent: Tuesday, May 16, 2017 1:36 PM
To: cfrg@irtf.org
Subject: [Cfrg] ECC mod 8^91+5

Hi all,

I'm considering writing an I-D on doing ECC over the field of size
=C2=A0 =C2=A08^91+5=C2=A0 =C2=A0 (=3D2^273+5),
because it:
- is written in just 6 symbols (=3Dlow Kolmogorov complexity, heuristically= minimizing threat of NOBUS-trapdoor),
- has easy and fast inversion, Legendre symbols, and square roots,
- has efficient arithmetic using at most five 64-bit words (use base 2^55),=
- is at least 2^(256-epsilon),
- is (probably) prime, so not an extension field (has no subfields for desc= ent-type attacks on ECDLP).
Other fields can improve on some of these properties, but might worsen the = others.

For ECC with this field, I am also considering the special curve
=C2=A0 =C2=A02y^2=3Dx^3+x,
because it:
- is written in just 10 symbols (similar gains to 6-symbol field),
- has Montgomery form (and easily converts to Weierstrass),
- has efficient endomorphism (so it is a GLV curve),
- is similar to curves already suggested by Miller in 1985 (well-aged),
- is similar to sect256k1 already used in bitcoin (incentivized),
- has an small enough cofactor 72 (over field size 8^91+5),
- avoids the main ECDLP attacks: Pohlig-Hellman, Menezes-Okamoto-Vanstone, = etc.,
- is similar to the special curves of Koblitz-Menezes [ia.cr/2008/390, Sec = 11.1, Example 5] resisting a speculative attack.
The motivation for this special curve largely matches the motivation for th= e special field.

The curve's risks are at least:
- CM (endomorphism) makes it potentially weak (after 32 years of being safe= ) (note exactly opposing Koblitz-Menezes rationale),
- its small coefficients are weak for some unpublished reason (continuing t= rend of weak small-coefficients, y^2=3Dx^3 (singular), supersingular, etc. = being weak),
- weak twist order (so, it requires a static ECDH Montgomery ladder to use = public key validation),
- weak Cheon resistance (but this is an attack with many queries, much comp= utation, and faulty or no KDF).
- den Boer or Maurer-Wolf reductions are not tight as possible, so perhaps = it has a big gap between DHP and DLP Other curves (over this field) can red= uce these risks, but may also lose some of the benefits.

Overall, E(GF(8^91+5)):2y^2=3Dx^3+x might offer competitive efficiency with= fairly reasonable security (for 128-bit symmetric keys). It is only an inc= remental change over other standard ECC curves, not anything too radical.
I'd be happy to hear what CFRG thinks, or if the CFRG would welcome suc= h an I-D as a CFRG work item.=C2=A0 I hope to have this topic presented bri= efly at an upcoming CFRG meeting.

Best regards,

Dan Brown




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

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

--94eb2c0c91664e85020555c08a42-- From nobody Wed Aug 2 01:12:45 2017 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 E62FC12711E for ; Wed, 2 Aug 2017 01:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFjFt7BlHTIg for ; Wed, 2 Aug 2017 01:12:42 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3C126BF3 for ; Wed, 2 Aug 2017 01:12:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id E94332942A; Wed, 2 Aug 2017 11:12:39 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id aF1Y2zjQOIeR; Wed, 2 Aug 2017 11:12:39 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 924D62313; Wed, 2 Aug 2017 11:12:37 +0300 (EEST) Date: Wed, 2 Aug 2017 11:12:37 +0300 From: Ilari Liusvaara To: Dan Brown Cc: "cfrg@irtf.org" Message-ID: <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:12:44 -0000 On Tue, Aug 01, 2017 at 09:22:10PM +0000, Dan Brown wrote: > Hi CFRG, > > A minor addition to this topic. > > In my first email on this topic, and in my recent IETF 99 > presentation, I mentioned that the proposed special curve > 2y^2=x^3+x was similar to curves proposed in Miller's 1985 paper > introducing of ECC. > > I believe (50% sure) that Miller made this non-square a > recommendation merely to help keep the group cofactor down (by > ensuring a unique point of order 2, namely (0,0)). Unfortunately there is another related problem: The theorem that says that folded Montgomery ladder always works assumes that there is unique point of order 2. So if using curve with multiple points of order 2, there may be exceptional cases. And getting those cases wrong might be exploitable. And handling those cases without timing sidechannels might be very nasty to implement. And sets of complete Montgomery and complete Edwards curves are very closely related, so this is probably not complete either as Edwards curve. > By contrast 2y^2=x^3+x, has a subgroup of order 8. (With points > O, (0,0), (i,0), (-i,0), (1,1), (1,-1), (-1,i), (-1,-i).) A subgroup > of order 4 (or 8) is nowadays considered (arguably) an advantage, > because of various Edwards curves (but I am only 10% sure, since I > haven't looked at this in a while, please correct me this is wrong). It also seemingly has subgroup of order 9, which is considerably more problematic than subgroup of order 8. There are some more exotic ECC algorithms that just can't deal with cofactor bigger than 1, but I think the worst problems that are attributed to cofactor >1 are actually caused by having a notation for low-order points. And any complete curve has at least one such point. And then, not having notations for low-order points is annoying in implementing algorithms... -Ilari From nobody Wed Aug 2 07:11:43 2017 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 759B512008A for ; Wed, 2 Aug 2017 07:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQaQLv-CKoip for ; Wed, 2 Aug 2017 07:11:40 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A1E126C83 for ; Wed, 2 Aug 2017 07:11:39 -0700 (PDT) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2017 10:11:37 -0400 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 2 Aug 2017 10:11:37 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Wed, 2 Aug 2017 10:11:36 -0400 From: Dan Brown To: Ilari Liusvaara CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCQ9d+upAACBlnYAAA5l8wA== Date: Wed, 2 Aug 2017 14:11:35 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B79953@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> In-Reply-To: <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 14:11:41 -0000 Hi Ilari, Thank you very much for taking a look at these important details: I've been= focusing on other aspects. I did not know about the condition on uniqueness of a point of order 2. So= , I will try to better learn this important implementation issue. If you h= appen to know off-hand a reference to the theorem you cited, then please le= t me know - but don't sweat it, I'll eventually find it (99% sure). I did not understand what you meant by the "worst problem" being a "notatio= n" for low-order points. (My only guess (1% sure) is that "notation" coul= d be some kind of "exception"?) Also, I'm assuming that "worst" is in some= relative sense, since Curve25519 has low-order points. Also, is your impl= ied assertion that "a complete curve has low-order point" a theorem? (I ha= d mistakenly thought complete formulas for NIST had been found, albeit slow= er - maybe they were only unified, so my understanding of what "complete" m= eans is off.) In my slides, I mentioned that the propose curve's cofactor (72) not being = a power of 2 is problematic for easily generating signature ephemerals with= out bias. This has some known workarounds, but it is a serious issue. Did = you have something else in mind in saying that a subgroup of order 9 was pr= oblematic? -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Ilari Liusvaara Sent: Wednesday, August 2, 2017 4:13 AM To: Dan Brown Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC mod 8^91+5 On Tue, Aug 01, 2017 at 09:22:10PM +0000, Dan Brown wrote: > Hi CFRG, >=20 > A minor addition to this topic. >=20 > In my first email on this topic, and in my recent IETF 99=20 > presentation, I mentioned that the proposed special curve 2y^2=3Dx^3+x=20 > was similar to curves proposed in Miller's 1985 paper introducing of=20 > ECC. >=20 > I believe (50% sure) that Miller made this non-square a recommendation=20 > merely to help keep the group cofactor down (by ensuring a unique=20 > point of order 2, namely (0,0)). Unfortunately there is another related problem: The theorem that says that = folded Montgomery ladder always works assumes that there is unique point of= order 2. So if using curve with multiple points of order 2, there may be exceptional= cases. And getting those cases wrong might be exploitable. And handling those cases without timing sidechannels might be very nasty to= implement. =20 And sets of complete Montgomery and complete Edwards curves are very closel= y related, so this is probably not complete either as Edwards curve. > By contrast 2y^2=3Dx^3+x, has a subgroup of order 8. (With points O,=20 > (0,0), (i,0), (-i,0), (1,1), (1,-1), (-1,i), (-1,-i).) A subgroup of=20 > order 4 (or 8) is nowadays considered (arguably) an advantage, because=20 > of various Edwards curves (but I am only 10% sure, since I haven't=20 > looked at this in a while, please correct me this is wrong). It also seemingly has subgroup of order 9, which is considerably more probl= ematic than subgroup of order 8. There are some more exotic ECC algorithms that just can't deal with cofacto= r bigger than 1, but I think the worst problems that are attributed to cofa= ctor >1 are actually caused by having a notation for low-order points. And = any complete curve has at least one such point. And then, not having notations for low-order points is annoying in implemen= ting algorithms... -Ilari _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Aug 2 07:54:55 2017 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 BAE59132118 for ; Wed, 2 Aug 2017 07:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB9aKR4BDNUs for ; Wed, 2 Aug 2017 07:54:51 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2FA1319B4 for ; Wed, 2 Aug 2017 07:54:50 -0700 (PDT) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2017 10:54:48 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0319.002; Wed, 2 Aug 2017 10:54:48 -0400 From: Dan Brown To: Dan Brown , Ilari Liusvaara CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCQ9d+upAACBlnYAAA5l8wAABnPiQ Date: Wed, 2 Aug 2017 14:54:47 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B799D5@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> <810C31990B57ED40B2062BA10D43FBF501B79953@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B79953@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 14:54:54 -0000 Based on Ilari's advice, I sought and found some exceptions (on the curve i= n question, or perhaps even any prime-field curve with 3 points of order 2)= to the preferred differential addition formula: https://hyperelliptic.org/EFD/g1p/auto-montgom-xz.html#diffadd-mdadd-1987-m Put {(X2:Z2),(X3:Z3)}=3D{(1:1),(-1:1)}, which yields (X5:Z5)=3D(0:0) an EXC= EPTION. This seems to be only exception (25% sure), but is in line with Il= ari's claim about exceptions. (Also, I couldn't find any exceptions in the= preferred doubling formula (25% sure).) I'm not sure how exploitable this exception would be, however, so maybe I'm= still missing something. The two points have order 4, but differ by a poi= nt of order 2, so (X1:Z1) would have (10% sure) to be (0:1) or (i:1) or (-i= :1). This could be stopped by checking (X1:Z1) -- or perhaps (0.1% sure) j= ust using it anyway, and safely leaking just a few bits of information abou= t the private key. =20 -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan Brown Sent: Wednesday, August 2, 2017 10:12 AM To: Ilari Liusvaara Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC mod 8^91+5 Hi Ilari, Thank you very much for taking a look at these important details: I've been= focusing on other aspects. I did not know about the condition on uniqueness of a point of order 2. So= , I will try to better learn this important implementation issue. If you h= appen to know off-hand a reference to the theorem you cited, then please le= t me know - but don't sweat it, I'll eventually find it (99% sure). I did not understand what you meant by the "worst problem" being a "notatio= n" for low-order points. (My only guess (1% sure) is that "notation" coul= d be some kind of "exception"?) Also, I'm assuming that "worst" is in some= relative sense, since Curve25519 has low-order points. Also, is your impl= ied assertion that "a complete curve has low-order point" a theorem? (I ha= d mistakenly thought complete formulas for NIST had been found, albeit slow= er - maybe they were only unified, so my understanding of what "complete" m= eans is off.) In my slides, I mentioned that the propose curve's cofactor (72) not being = a power of 2 is problematic for easily generating signature ephemerals with= out bias. This has some known workarounds, but it is a serious issue. Did = you have something else in mind in saying that a subgroup of order 9 was pr= oblematic? -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Ilari Liusvaara Sent: Wednesday, August 2, 2017 4:13 AM To: Dan Brown Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC mod 8^91+5 On Tue, Aug 01, 2017 at 09:22:10PM +0000, Dan Brown wrote: > Hi CFRG, >=20 > A minor addition to this topic. >=20 > In my first email on this topic, and in my recent IETF 99=20 > presentation, I mentioned that the proposed special curve 2y^2=3Dx^3+x=20 > was similar to curves proposed in Miller's 1985 paper introducing of=20 > ECC. >=20 > I believe (50% sure) that Miller made this non-square a recommendation=20 > merely to help keep the group cofactor down (by ensuring a unique=20 > point of order 2, namely (0,0)). Unfortunately there is another related problem: The theorem that says that = folded Montgomery ladder always works assumes that there is unique point of= order 2. So if using curve with multiple points of order 2, there may be exceptional= cases. And getting those cases wrong might be exploitable. And handling those cases without timing sidechannels might be very nasty to= implement. =20 And sets of complete Montgomery and complete Edwards curves are very closel= y related, so this is probably not complete either as Edwards curve. > By contrast 2y^2=3Dx^3+x, has a subgroup of order 8. (With points O,=20 > (0,0), (i,0), (-i,0), (1,1), (1,-1), (-1,i), (-1,-i).) A subgroup of=20 > order 4 (or 8) is nowadays considered (arguably) an advantage, because=20 > of various Edwards curves (but I am only 10% sure, since I haven't=20 > looked at this in a while, please correct me this is wrong). It also seemingly has subgroup of order 9, which is considerably more probl= ematic than subgroup of order 8. There are some more exotic ECC algorithms that just can't deal with cofacto= r bigger than 1, but I think the worst problems that are attributed to cofa= ctor >1 are actually caused by having a notation for low-order points. And = any complete curve has at least one such point. And then, not having notations for low-order points is annoying in implemen= ting algorithms... -Ilari _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Aug 2 08:17:26 2017 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 01F9E12711B for ; Wed, 2 Aug 2017 08:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDqM7u0FlCmB for ; Wed, 2 Aug 2017 08:17:24 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6D124207 for ; Wed, 2 Aug 2017 08:17:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 431B73EB1E; Wed, 2 Aug 2017 18:17:22 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id n79eGiFG0qQT; Wed, 2 Aug 2017 18:17:22 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EB4822313; Wed, 2 Aug 2017 18:17:19 +0300 (EEST) Date: Wed, 2 Aug 2017 18:17:19 +0300 From: Ilari Liusvaara To: Dan Brown Cc: "cfrg@irtf.org" Message-ID: <20170802151719.ebdnjxpqj443f4th@LK-Perkele-VII> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> <810C31990B57ED40B2062BA10D43FBF501B79953@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B79953@XMB116CNC.rim.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:17:26 -0000 On Wed, Aug 02, 2017 at 02:11:35PM +0000, Dan Brown wrote: > Hi Ilari, > > I did not know about the condition on uniqueness of a point of order > 2. So, I will try to better learn this important implementation > issue. If you happen to know off-hand a reference to the theorem > you cited, then please let me know - but don't sweat it, I'll eventually > find it (99% sure). Safecurves says: "2006 Bernstein had shown a more limited form of completeness for the Montgomery ladder on Montgomery curves y^2=x^3+Ax^2+x with a unique point of order 2, i.e., with A^2-4 not a square. Specifically, given X0(P) as input, the Montgomery ladder always produces X0(nP) as output; here X0(P) means 0 if P=0, and otherwise the x-coordinate of P. It is possible that ladders provide completeness for other curves, but the analysis is not easy; the only literature is a second 2006 Bernstein paper on this topic." > I did not understand what you meant by the "worst problem" being a > "notation" for low-order points. (My only guess (1% sure) is that > "notation" could be some kind of "exception"?) Also, I'm assuming > that "worst" is in some relative sense, since Curve25519 has low-order > points. Also, is your implied assertion that "a complete curve has > low-order point" a theorem? (I had mistakenly thought complete > formulas for NIST had been found, albeit slower - maybe they were only > unified, so my understanding of what "complete" means is off.) If you can represent all points on the curve, you can also represent the additive identity, which has order 1. And being able to feed any low-order points (including point of order 1) into some ECC algorithms causes trouble. E.g., if fed as key to Schnorr signature algorithm, the resulting signatures have undesirable properties (which may be exploitable in some applications that assume nonstandard properties from signatures). > In my slides, I mentioned that the propose curve's cofactor (72) > not being a power of 2 is problematic for easily generating signature > ephemerals without bias. This has some known workarounds, but it is a > serious issue. Did you have something else in mind in saying that a > subgroup of order 9 was problematic? Well, the easiest way to generate signature ephremals on such groups without bias is to include the factor of 9 into initial space. This causes just some very minor slowdown. Also, there is a fast check for low-order points on Edwards curves. However, that check only works if cofactor is 4 or 8. -Ilari From nobody Wed Aug 2 08:25:09 2017 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 0550113214A for ; Wed, 2 Aug 2017 08:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUT0F2NDWkv8 for ; Wed, 2 Aug 2017 08:25:06 -0700 (PDT) Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id D29D9132145 for ; Wed, 2 Aug 2017 08:24:35 -0700 (PDT) Received: (qmail 10367 invoked by uid 1010); 2 Aug 2017 15:24:33 -0000 Received: from unknown (unknown) by unknown with QMTP; 2 Aug 2017 15:24:33 -0000 Received: (qmail 8451 invoked by uid 1000); 2 Aug 2017 15:24:30 -0000 Date: 2 Aug 2017 15:24:30 -0000 Message-ID: <20170802152430.8449.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:25:08 -0000 Ilari Liusvaara writes: > Unfortunately there is another related problem: The theorem that says > that folded Montgomery ladder always works assumes that there is > unique point of order 2. The theorem in the Curve25519 paper assumed a unique point of order 2, but this turned out to be unnecessary. See Theorem 4.5 in https://cr.yp.to/papers.html#montladder and in particular the proofs of the underlying DBL and DADD theorems via the Edwards addition law. The paper also gives proofs from the historical Weierstrass perspective. The completeness issue is more problematic outside the ladder context: * The fast complete Edwards formulas don't apply to this curve: the curve doesn't have a unique point of order 2. * The fast complete Hessian formulas also don't apply to this curve: the curve doesn't have a unique point of order 3. * The formulas from https://cr.yp.to/talks/2009.07.17/slides.pdf and https://eprint.iacr.org/2015/1060 do apply but don't meet the SafeCurves requirements of speed and simplicity ("implementations of scalar multiplication for the same curve cannot be much faster" and "reasonably fast implementations of scalar multiplication for the same curve cannot be much more concise"), so implementors are pressured to use incomplete formulas instead. ---Dan From nobody Wed Aug 2 08:31:13 2017 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 97EF1132131 for ; Wed, 2 Aug 2017 08:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DYTXa9Xm5ZG for ; Wed, 2 Aug 2017 08:31:07 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF36C132145 for ; Wed, 2 Aug 2017 08:31:06 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t138so41654442wmt.1 for ; Wed, 02 Aug 2017 08:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MyTrSmp/XnNFCrQs2h531iKvsJLw6JpnElQCShGYd4U=; b=lae8ZYbWrV11M82TTSirp4URQ7RaQfKU5mMwI4Fz673+h2CZXLEhQVHuj33oUbvSFz 6bmHMgYlSBf69NNOHJHhB5F27SZuHnsuQilDLqWrfNx+ZyNrCfQf+fzCbkW+uuN7xn1A P8MngqZ/FuPh36z+ijzYU9vnOAKzheVHB03/EYEEgfUEcyI/HgnIdjugITkEHpjKg4QJ wkCLW4wPLolXWYiI6RUc01vXenqhYc10zhmYDt3BKdnDfpLJQrtnsLpfJCr9LPkAZONn ONPDdDXKbEkRHzMIwKTD4tcWCKtHohOsBGvziFzArmRRYxAf/aSTyAs5nX667VJRxUJi DMyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MyTrSmp/XnNFCrQs2h531iKvsJLw6JpnElQCShGYd4U=; b=lA7CdyiRP3tgnXsDMf1AvXPNcGjcuyjBdoyS506/6jIjHzXSR7XLJF5YEjmaJPic2H Vr4fxSzFj6qDih7CqqPLXieeuDnUEx8U5ezZBX9id7OCgEUHwSKGj23THDCtBKT9Dlok yTjT5VCduciULY3J1kzCVDP93zlHtR6vYAHuzCBS9waAJMbdS6kx1z6XxL6fk+A/ukg2 fF35A3Bpis168LtdPfwtzbYRMbRBatKcTQkd4EjomLLMI38LbDfzMv2KzvgZGR+D7Y3D O3tIW6sppxsU5wu4NxsfHU+1U0xS2bcdnXYSJdSBsIHguEHWB2oZsVEyyj4XoQNB8qG7 8tTQ== X-Gm-Message-State: AIVw112l/ilEQ2lZau1k+nXYbwzoouIJXJ/TLM1kvsMbmzVunQkjt37O KzBnFmHWFOryhZv/2Hu4bLjXPuDfZw== X-Received: by 10.80.149.2 with SMTP id u2mr21557332eda.126.1501687865447; Wed, 02 Aug 2017 08:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.179.79 with HTTP; Wed, 2 Aug 2017 08:30:25 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B79953@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501B7969D@XMB116CNC.rim.net> <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> <810C31990B57ED40B2062BA10D43FBF501B79953@XMB116CNC.rim.net> From: Samuel Neves Date: Wed, 2 Aug 2017 16:30:25 +0100 Message-ID: To: Dan Brown Cc: "cfrg@irtf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:31:08 -0000 On Wed, Aug 2, 2017 at 3:11 PM, Dan Brown wrote: > (I had mistakenly thought complete formulas for NIST had been found, albeit slower - maybe they were only unified, so my understanding of what "complete" means is off.) These formulas do exist, cf. [1] or [2], but they require curves of _odd_ order, which is not the case here. [1] https://doi.org/10.1006/jnth.1995.1088 [2] https://eprint.iacr.org/2015/1060 Best regards, Samuel Neves From nobody Wed Aug 2 09:00:28 2017 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 04D86132143 for ; Wed, 2 Aug 2017 09:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJrma28aGPTO for ; Wed, 2 Aug 2017 09:00:25 -0700 (PDT) Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 7A790132153 for ; Wed, 2 Aug 2017 09:00:25 -0700 (PDT) Received: (qmail 11821 invoked by uid 1010); 2 Aug 2017 16:00:24 -0000 Received: from unknown (unknown) by unknown with QMTP; 2 Aug 2017 16:00:24 -0000 Received: (qmail 10530 invoked by uid 1000); 2 Aug 2017 16:00:15 -0000 Date: 2 Aug 2017 16:00:15 -0000 Message-ID: <20170802160015.10529.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 16:00:27 -0000 Samuel Neves writes: > These formulas do exist, cf. [1] or [2], but they require curves of > _odd_ order, which is not the case here. The complete formulas from https://cr.yp.to/talks/2009.07.17/slides.pdf don't require odd order. Fundamentally, incomplete implementations---and complete implementations with timing leaks from branches between different incomplete formulas--- are not the result of complete formulas failing to exist. They are the result of complete formulas failing to compete with the simplicity and speed of incomplete formulas. This tension is what's nicely resolved by Montgomery curves for DH, and by complete Edwards curves for more general applications. ---Dan From nobody Wed Aug 2 09:04:52 2017 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 17898132143 for ; Wed, 2 Aug 2017 09:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHXKQQliUdLY for ; Wed, 2 Aug 2017 09:04:50 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCDB129B03 for ; Wed, 2 Aug 2017 09:04:49 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2017 12:04:43 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0319.002; Wed, 2 Aug 2017 12:04:43 -0400 From: Dan Brown To: "D. J. Bernstein" , "cfrg@irtf.org" Thread-Topic: [Cfrg] ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCQ9d+upAACBlnYAADxVWAAAHoxmA Date: Wed, 2 Aug 2017 16:04:42 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B79B1B@XMB116CNC.rim.net> References: <20170802081237.k6pcmldfso4dkgeq@LK-Perkele-VII> <20170802152430.8449.qmail@cr.yp.to> In-Reply-To: <20170802152430.8449.qmail@cr.yp.to> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 16:04:52 -0000 Hi Dan, Thanks so much for clarifying this! =20 Sorry to all in CFRG that I am not up to speed on ECC implementation securi= ty and efficiency. Just to be clear: this proposed special curve 2y^2=3Dx^3+x (over GF(8^91+5)= ) is not intended to meet all SafeCurves requirements (as I remember them).= In particular and especially, (a) it is not twist-secure, and (b) it has = a special feature of an efficient (complex) endomorphism. Best regards, Dan Dumb question (on efficiency): For plain old Diffie--Hellman, is it right t= hat Edwards form (8M per op) is only better than Montgomery (9M per bit) if= a large window is used (to reduce ops/bit to something close to 1)? If so= , is this deemed simpler? I guess where I'm going with this, is that Edwar= ds form is very exciting from a research perspective, but maybe (0.000001% = sure) it is not ready and ideal for engineering. Again, I'm probably just = totally missing something. -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of D. J. Bernstein Sent: Wednesday, August 2, 2017 11:25 AM To: cfrg@irtf.org Subject: Re: [Cfrg] ECC mod 8^91+5 Ilari Liusvaara writes: > Unfortunately there is another related problem: The theorem that says=20 > that folded Montgomery ladder always works assumes that there is=20 > unique point of order 2. The theorem in the Curve25519 paper assumed a unique point of order 2, but = this turned out to be unnecessary. See Theorem 4.5 in https://cr.yp.to/papers.html#montladder and in particular the proofs of the underlying DBL and DADD theorems via th= e Edwards addition law. The paper also gives proofs from the historical Wei= erstrass perspective. The completeness issue is more problematic outside the ladder context: * The fast complete Edwards formulas don't apply to this curve: the curve doesn't have a unique point of order 2. * The fast complete Hessian formulas also don't apply to this curve: the curve doesn't have a unique point of order 3. * The formulas from https://cr.yp.to/talks/2009.07.17/slides.pdf and https://eprint.iacr.org/2015/1060 do apply but don't meet the SafeCurves requirements of speed and simplicity ("implementations of scalar multiplication for the same curve cannot be much faster" and "reasonably fast implementations of scalar multiplication for the same curve cannot be much more concise"), so implementors are pressured to use incomplete formulas instead. ---Dan _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Aug 3 23:17:12 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA94131761; Thu, 3 Aug 2017 23:17:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150182742257.7027.7167154249957778554@ietfa.amsl.com> Date: Thu, 03 Aug 2017 23:17:02 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-03.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 06:17:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : The memory-hard Argon2 password hash and proof-of-work function Authors : Alex Biryukov Daniel Dinu Dmitry Khovratovich Simon Josefsson Filename : draft-irtf-cfrg-argon2-03.txt Pages : 44 Date : 2017-08-03 Abstract: This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer- oriented description together with sample code and test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-argon2-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 4 01:55:11 2017 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 D1416124234 for ; Fri, 4 Aug 2017 01:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dx6Ky7VgBY9 for ; Fri, 4 Aug 2017 01:55:08 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E3A131CB5 for ; Fri, 4 Aug 2017 01:55:08 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id d136so5610790qkg.3 for ; Fri, 04 Aug 2017 01:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=cc5V9teKvVTPod7dw1s9WVhmh5Rha2U2OyWfQymmnb8=; b=QRHsH5EWugvmx4Xhd/Ypckz1qm+Gx2uvkju5MozvgdgyYVp5bcFE4OqB3Nks1ex27H uKl/LWXpgx0lUsKV4l2GUCowyP34lL45nmvCmnACko2erVQksepHHQxhX9t1vJyDEj97 gQUyvHteE9hb+mj0xre2TLOGAwf5PuI/z84+sNk+zcOeXURK5XulP3VAu0f9Nkl66Mt6 eyOJXP5wbVw8IHTGC9yZlbTZOL7XeMwQ/+8cvdjqROJ/aWARZElTeTYeFRzaonFnYpty t77YTp7IMzhI2vq94sRnyLC/Ayw3MVkPPxS13Wc82CnN6ucmuPepHbacqSZzPqeiRUnJ BAuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=cc5V9teKvVTPod7dw1s9WVhmh5Rha2U2OyWfQymmnb8=; b=PU/0O6Vamp5B8BKnFTyPzSrMbWaPDw/IRrujGA6sjrRCbRsvIV1hqrNVrEyNdTg7X1 Z2xV/N/hlTlVHij5VCy88MdqlD0PWKKMKbBVc1KGvKGIE60ednmseTqRjzOTUEBZMAs1 nEVJmAlBr00bbEXwl98NhyKGY0n0GnDg+I32ZYm7vL3A+L4Bdtd7VA26ZwLKCvnA6i3Y iqWGGDYDJchUY/5bZFR5XgZ1GqeoHukbrK1eHboYh1SUe6YuNiMex3HCm/gQ9eO4oHNi Rx8HxhSmb56eZpZ25E1hGQKuWSERusoy54Xf+YtgSCFZAkaxUKkeYmUyFCZ8oWpxujgQ K+rA== X-Gm-Message-State: AHYfb5jioiUX9T3vSssB26sLSUpaKLCsCdNMw24QJspTfaJxxHJI1EkT U/DCAUfhEH6o3znZOkVH+M+l3w0j0W9FCsQ= X-Received: by 10.55.155.23 with SMTP id d23mr1854075qke.271.1501836907097; Fri, 04 Aug 2017 01:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.195.200 with HTTP; Fri, 4 Aug 2017 01:54:51 -0700 (PDT) In-Reply-To: <150182742257.7027.7167154249957778554@ietfa.amsl.com> References: <150182742257.7027.7167154249957778554@ietfa.amsl.com> From: Dmitry Khovratovich Date: Fri, 4 Aug 2017 11:54:51 +0300 Message-ID: Cc: cfrg@ietf.org Content-Type: multipart/alternative; boundary="94eb2c06c7105bb8fa0555e9a769" Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-03.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:55:10 -0000 --94eb2c06c7105bb8fa0555e9a769 Content-Type: text/plain; charset="UTF-8" Dear CFRG, we have prepared a new version of the Argon2 draft. Great thanks to our reviewers, as the comments helped us to improve the text a lot. We also provided a self-containing reference implementation in C in the appendix. We have made our comments to the reviews at [1], but 95% of them are Fixed or Added, and no comment has been left unresolved. We would also like to thank Jeremiah Blocki for his helpful comments. In particular, he suggested a new formula for the edge distribution to make Argon2i more resistant to tradeoff attacks. We are very interested in such research, and are looking forward to the third-party analysis (by us or others) of the proposed constructions. If the new edge distribution withstands public scrutiny, it would make sense to apply it in future releases of Argon2i and Argon2id. We are ready to answer any other questions and integrate more comments if needed. Best regards, Alex, Daniel, Dmitry. [1] https://drive.google.com/open?id=0ByMtMw2hul0Ed2x2enlpR2dZdlE On Fri, Aug 4, 2017 at 9:17 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Crypto Forum RG of the IRTF. > > Title : The memory-hard Argon2 password hash and > proof-of-work function > Authors : Alex Biryukov > Daniel Dinu > Dmitry Khovratovich > Simon Josefsson > Filename : draft-irtf-cfrg-argon2-03.txt > Pages : 44 > Date : 2017-08-03 > > Abstract: > This document describes the Argon2 memory-hard function for password > hashing and proof-of-work applications. We provide an implementer- > oriented description together with sample code and test vectors. The > purpose is to simplify adoption of Argon2 for Internet protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03 > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-argon2-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > -- Best regards, Dmitry Khovratovich --94eb2c06c7105bb8fa0555e9a769 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CFRG,

we have prepared a new versi= on of the Argon2 draft. Great thanks to our reviewers, as the comments help= ed us to improve the text a lot. We also provided a self-containing referen= ce implementation in C in the appendix.

We have ma= de our comments to the reviews at [1], but 95% of them are Fixed or Added, = and no comment has been left unresolved.

We would = also like to thank Jeremiah Blocki for his helpful comments. In particular,= he suggested a new formula for the edge distribution to make Argon2i more = resistant to tradeoff attacks. We are very interested in such research, and= are looking forward to the third-party analysis (by us or others) of the p= roposed constructions. If the new edge distribution withstands public scrut= iny, it would make sense to apply it in future releases of Argon2i and Argo= n2id.

We are ready to answer any other questions a= nd integrate more comments if needed.

Best regards= ,
Alex, Daniel, Dmitry.


On Fri, Aug 4, 2017 at 9= :17 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Crypto Forum RG of the IRTF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The memory-hard Argon2 password hash and proof-of-work function
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alex= Biryukov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Daniel Dinu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dmitry Khovratovich
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Simon Josefsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-irt= f-cfrg-argon2-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 44
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-08-03

Abstract:
=C2=A0 =C2=A0This document describes the Argon2 memory-hard function for pa= ssword
=C2=A0 =C2=A0hashing and proof-of-work applications.=C2=A0 We provide an im= plementer-
=C2=A0 =C2=A0oriented description together with sample code and test vector= s.=C2=A0 The
=C2=A0 =C2=A0purpose is to simplify adoption of Argon2 for Internet protoco= ls.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= irtf-cfrg-argon2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-cfr= g-argon2-03
https://datatracker.ietf.org/doc= /html/draft-irtf-cfrg-argon2-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-irtf-cfrg-argon2-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



--
Best regards,<= /div>
Dmitry Khovratovich
--94eb2c06c7105bb8fa0555e9a769-- From nobody Tue Aug 8 06:42:20 2017 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 CFEA2132457; Tue, 8 Aug 2017 06:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yycR2jzTviAH; Tue, 8 Aug 2017 06:42:16 -0700 (PDT) Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C036132390; Tue, 8 Aug 2017 06:42:15 -0700 (PDT) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1df4lu-0007VU-5J; Tue, 08 Aug 2017 15:42:10 +0200 Received: from [131.155.70.110] by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1df4lt-0005Ot-L1; Tue, 08 Aug 2017 15:42:09 +0200 To: Allison Mankin Cc: Stephen Farrell , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" , "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> From: "A. Huelsing" Message-ID: <367c689b-1463-f39d-6541-24a68aa2227a@huelsing.net> Date: Tue, 8 Aug 2017 15:42:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8FC302CF60327746429A8B5D" Content-Language: en-GB X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.99.2/23645/Tue Aug 8 14:27:48 2017) Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 13:42:19 -0000 This is a multi-part message in MIME format. --------------8FC302CF60327746429A8B5D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear Allision, we were wondering what happens next. Is there any interaction from our side necessary (or helpful to speed things up)? Thanks, Andreas Am 24-07-17 um 16:39 schrieb Allison Mankin: > Thanks for making the changes. Stephen, let me know if you are ready to give > this a thumbs-up, and I'll start an IRSG poll. > > Allison > > On 24 July 2017 at 16:30, A. Huelsing > wrote: > > Dear Stephen, > > we tried to make the required changes. Please have a look if you are fine > with the changes (especially regarding section 5 and the reference > implementation). > > You find our answers to your review below and the new draft version attached. > > Thanks again for your time, > > Andreas, Aziz, Denis, Joost & Stefan > > > ################# Answers #################### > possible errors: > ---------------- > > - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be > missing parenthesis around the "(w-1)" to me. Without those > brackets I could interpret that test to always result in false. > > #Done > > - 4.1.9: should the call to setIdx in alg 12 be after treeSig? > as-is you seem to have incremented the index too soon so > that when alg 11 does getIdx it'd presumably get the > incremented index and cause verification failure. I think > the same is true of alg 16 as well, in section 4.2.4. > > #Done > > significant comments, but likely fixable: > ----------------------------------------- > > - section 5: there are waaaay too many options defined here. > As-is, this will damage potential deployment of xmss. I > would strongly suggest deleting all of the options except the > minimum, that being one (and only one) set of parameters for > XMSS and one for XMSS^MT. If others are needed later, those > can be defined later. (Note that the damage done here includes > the hours of developer time that would be wasted debating > which of these choices to implement/use. Consider the case of > pre-hash variants of eddsa for an ongoing example.) > > #### > # We significantly changed section 5, please check if this > # satisfies your remarks > #### > > - section 5 (or an appendix) should contain some test vectors > (including intermediate values). Without those, implementers > have a much harder time of getting their code right. > > # Added section on reference implementation > > > nits, near-nits and other ignorable things: > ------------------------------------------- > > - abstract: I'd suggest s/can withstand attacks/ can withstand > so-far known attacks/ > > # Done > > - 1.1: You say if used >1 time "no cryptographic security > guarantees remain." It might be clearer to give some > examples of consequences, e.g. that the attacker can forge new > signatures or whatever. > > # Done > > - 1.1: I think you might mention that XMSS and other OTS ideas > require some new crypto APIs. I'm not aware if anyone has > developed proposals for such, but would be interested if > someone has. > > # Done > > - 2.3, 2nd last para: you might want to say what happens with > e.g. B<<2 where B=0xf0. I assume the result is 0xc0 but > someone might think it's 0x3c0 or even 0xc3. > > # Done: Removed the left shift as it is never used for single bytes > > - 2.5: having the "type word" as octet 15 of a 32 byte address > seems odd. Is there a reason why? (Just wondering.) > > # Yes: We got the space and think that it simlifies implementation if > one always has to manipulate whole words (and can treat the address as > uint32_t[8]) > > - 2.6: It seems odd to given an example where the input and > output of base_w() are the same. A different example may be > more useful. (More examples generally would be great.) > > # Done > > - 3.1.3: maybe note that "/" means nothing? Which I assume it > does? Better might be to just say that. > > # Done > > - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing > units > > # Done: value -> Integer value > > - 3.1.5: "the variable" - which one? > > # Done: Added explanation > > - 3.1.5: "For the parameter sets given in Section 5 a 32-bit > unsigned integer is sufficient." Sufficient for what? > > # Done: Added " to hold the checksum" > > - 3.1.5: The ascii art at the end of p16 doesn't help much. > > # while the art does not contain new information, we think it's > a handy reminder. Would prefer to keep it like this. > > - 3.1.7: The "MUST match" statement doesn't seem enforceable > nor testable so I'm not sure it's a good idea to include. > OTOH, I do get the idea of using 2119 terms for emphasis. > > # Ok, so what should we do? I agree that key handling cannot be > verified. Still, it seems necessary to emphasize this. > If it is just about the use of the 2119 term, > how about: > "but it is crucial for security that the cryptographic strength > matches that of the used WOTS+ parameters."? > > - 3.1.7: I think it might be useful to point out any specific > problems associated with using a low entropy human memorable > secret (password) for the value S. No matter what you say, > people will do that, so better if you can say you told them > specifically about downsides of doing that. > > # We adressed this in a new sentence at the end of the > # paragraph. > > - 4.1.12: I'm not sure if the MAY there is correct or not. If > it means "you MAY use a different algorithm to get the same > output as alg 12" then that'd be fine. If something else is > meant I'm not sure what you're saying, and it'd probably be > better to not even mention it. > # That is exactly what it means. There are far more efficient > # algorithms to compute that output (but also far more complex) > > - section 5 should also spell out the signature and > public key sizes in bytes and ideally, if you keep multiple > options, (but please don't:-) describe relative or measured > timings. > > # Done > > --------------8FC302CF60327746429A8B5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Allision,

we were wondering what happens next. Is there any interaction from our side necessary (or helpful to speed things up)?

Thanks,

Andreas

Am 24-07-17 um 16:39 schrieb Allison Mankin:
Thanks for making the changes.  Stephen, let me know if you are ready to give this a thumbs-up, and I'll start an IRSG poll.

Allison

On 24 July 2017 at 16:30, A. Huelsing <ietf@huelsing.net> wrote:
Dear Stephen,

we tried to make the required changes. Please have a look if you are fine
with the changes (especially regarding section 5 and the reference
implementation).

You find our answers to your review below and the new draft version attached.

Thanks again for your time,

Andreas, Aziz, Denis, Joost & Stefan


################# Answers ####################
possible errors:
----------------

- 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be
missing parenthesis around the "(w-1)" to me.  Without those
brackets I could interpret that test to always result in false.

#Done

- 4.1.9: should the call to setIdx in alg 12 be after treeSig?
  as-is you seem to have incremented the index too soon so
that when alg 11 does getIdx it'd presumably get the
incremented index and cause verification failure. I think
the same is true of alg 16 as well, in section 4.2.4.

#Done

significant comments, but likely fixable:
-----------------------------------------

- section 5: there are waaaay too many options defined here.
  As-is, this will damage potential deployment of xmss. I
would strongly suggest deleting all of the options except the
minimum, that being one (and only one) set of parameters for
XMSS and one for XMSS^MT. If others are needed later, those
can be defined later. (Note that the damage done here includes
the hours of developer time that would be wasted debating
which of these choices to implement/use. Consider the case of
pre-hash variants of eddsa for an ongoing example.)

####
#   We significantly changed section 5, please check if this
#   satisfies your remarks
####

- section 5 (or an appendix) should contain some test vectors
  (including intermediate values). Without those, implementers
have a much harder time of getting their code right.

# Added section on reference implementation


nits, near-nits and other ignorable things:
-------------------------------------------

- abstract: I'd suggest s/can withstand attacks/ can withstand
  so-far known attacks/

# Done

- 1.1: You say if used >1 time "no cryptographic security
  guarantees remain." It might be clearer to give some
examples of consequences, e.g. that the attacker can forge new
signatures or whatever.

# Done

- 1.1: I think you might mention that XMSS and other OTS ideas
  require some new crypto APIs. I'm not aware if anyone has
developed proposals for such, but would be interested if
someone has.

# Done

- 2.3, 2nd last para: you might want to say what happens with
  e.g.  B<<2 where B=0xf0. I assume the result is 0xc0 but
someone might think it's 0x3c0 or even 0xc3.

# Done: Removed the left shift as it is never used for single bytes

- 2.5: having the "type word" as octet 15 of a 32 byte address
  seems odd. Is there a reason why? (Just wondering.)

# Yes: We got the space and think that it simlifies implementation if
one always has to manipulate whole words (and can treat the address as
uint32_t[8])

- 2.6: It seems odd to given an example where the input and
  output of base_w() are the same. A different example may be
more useful. (More examples generally would be great.)

# Done

- 3.1.3: maybe note that "/" means nothing? Which I assume it
  does? Better might be to just say that.

# Done

- 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing
  units

# Done: value -> Integer value

- 3.1.5: "the variable" - which one?

# Done: Added explanation

- 3.1.5: "For the parameter sets given in Section 5 a 32-bit
  unsigned integer is sufficient." Sufficient for what?

# Done: Added " to hold the checksum"

- 3.1.5: The ascii art at the end of p16 doesn't help much.

# while the art does not contain new information, we think it's
a handy reminder. Would prefer to keep it like this.

- 3.1.7: The "MUST match" statement doesn't seem enforceable
  nor testable so I'm not sure it's a good idea to include.
OTOH, I do get the idea of using 2119 terms for emphasis.

# Ok, so what should we do? I agree that key handling cannot be
verified. Still, it seems necessary to emphasize this.
If it is just about the use of the 2119 term,
how about:
"but it is crucial for security that the cryptographic strength
matches that of the used WOTS+ parameters."?

- 3.1.7: I think it might be useful to point out any specific
  problems associated with using a low entropy human memorable
secret (password) for the value S. No matter what you say,
people will do that, so better if you can say you told them
specifically about downsides of doing that.

# We adressed this in a new sentence at the end of the
# paragraph.

- 4.1.12: I'm not sure if the MAY there is correct or not.  If
  it means "you MAY use a different algorithm to get the same
output as alg 12" then that'd be fine. If something else is
meant I'm not sure what you're saying, and it'd probably be
better to not even mention it.
# That is exactly what it means. There are far more efficient
# algorithms to compute that output (but also far more complex)

- section 5 should also spell out the signature and
public key sizes in bytes and ideally, if you keep multiple
options, (but please don't:-) describe relative or measured
timings.

# Done



--------------8FC302CF60327746429A8B5D-- From nobody Tue Aug 8 20:52:50 2017 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 7F07D12702E for ; Tue, 8 Aug 2017 20:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac6b10p3ntnb for ; Tue, 8 Aug 2017 20:52:46 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B991124BAC for ; Tue, 8 Aug 2017 20:52:46 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id l82so33013700ywc.2 for ; Tue, 08 Aug 2017 20:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/IuePjjOdaCXgChUfSH/I1hizaEx67jkM00uw4FsdaY=; b=en6zdL7xDKl4IGBR0Flh5ZBWHHggm+ifAWFDIdoQFXPRJ7C2Rx9TJzsqvvKCXtF8GC zWbEuXtQDxXO6WN0OZ9Fo4Xv9iPpFUap8O1617EIj9ej+hIrZ5XwjFfx72DxQiOgJ8X9 +E+hPDJucN4oim+J4nsbQ1aqiLXvYArGwWKBX+3f57SbCLqCjS0EB1tEBTB/GXY2v1kG yf039i+/1Lredcu64ghCB+LYlT1AiQ16F+2CI+VmiH/TXvyL2DuNG96BT3hwG8TDnR5z aTkEF56iylydp3GyASLySBuULLZaZDTvwI1LuxUbdlSwjEpienXEKdkVtHu70Pw6u5dq k05w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/IuePjjOdaCXgChUfSH/I1hizaEx67jkM00uw4FsdaY=; b=XhcJrVc7rPf7g990r5YqchQFZzoe20V7yHhlEWHkc6U6HW5BttXa/PF5gL+fGNeCXk BpjHVgm255W5R/5yDQgmzlbpphMDHogcoqPwd45d6uJjEwobSko9B/0GSu+HLSfZOv0D 5uZQrkOvTmdeQeo71pv4POlHarwG1NTW1hegh6dGNEQoZLv3QndtmKda/+OxcZNvTb/u 6mGfLNWdYh1N1j3iaUMkj4fVvGzD4o9t6YUPebvaR50LP4oA3Nv/mIk1InYmzqGqFPy+ R/pKGROFs1N8hrjvnx+KPE4vCADMR9F2fhQqlAmdwlpo0a6bljLQrRmV3pXOvk+S3r9P UxBw== X-Gm-Message-State: AHYfb5hGGReSXUDQfZ8yOaHe4sPXkS/6mfXGFqYQdO2mTrXQ8kFLJNT0 tSQ0XH73Uqvl5vP9+lA252/l3tai1Vascz0= X-Received: by 10.129.197.73 with SMTP id o9mr5242460ywj.183.1502250765586; Tue, 08 Aug 2017 20:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.132 with HTTP; Tue, 8 Aug 2017 20:52:25 -0700 (PDT) From: Tony Arcieri Date: Tue, 8 Aug 2017 20:52:25 -0700 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="94eb2c1a4f383f1d6b05564a037a" Archived-At: Subject: [Cfrg] Ed25519 to be approved for FIPS use? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 03:52:48 -0000 --94eb2c1a4f383f1d6b05564a037a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I saw this message from Phillip Hallam-Baker on CA/Browser forum and thought it might be of interest to people here too: https://cabforum.org/pipermail/public/2017-July/011663.html ---------- Forwarded message ---------- From: Phillip Hallam-Baker via Public Date: Thu, Jul 20, 2017 at 2:56 AM Subject: [cabfpub] Curves Ed25519 may appear as NIST recommendations To: CA/Browser Forum Public Discussion List FYI: From the IETF meeting In DCRUP today a NIST employee withdrew a proposal to add the P256 curve to DKIM on the grounds that it is =E2=80=98likely=E2=80=99 that the Ed25519 (a= nd possibly Ed448) signatures will be approved for at least some purposes in a FIPS. There are many ways that this could not happen. Not least the lack of a director of NIST. But if it does, it would be a positive outcome. I really don=E2=80=99t much care which ECC curves we use so long as we all decide to= use the same curves everywhere. --94eb2c1a4f383f1d6b05564a037a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I saw this message from Phillip Hallam-Baker on CA/Browser= forum and thought it might be of interest to people here too:

ht= tps://cabforum.org/pipermail/public/2017-July/011663.html

---------- Forwarded message ----------
From:=C2= =A0Phillip Hallam-Baker via Public=C2=A0<= span dir=3D"ltr"><public@cabforum= .org>
Date: Thu, Jul 20, 2017 at 2:56 AM
Subject: [cabf= pub] Curves Ed25519 may appear as NIST recommendations
To: CA/Browser Fo= rum Public Discussion List <publi= c@cabforum.org>

FYI: From the IETF meeting

In DCRUP to= day a NIST employee withdrew a proposal to add the P256 curve to DKIM on th= e grounds that it is =E2=80=98likely=E2=80=99 that the Ed25519 (and possibl= y Ed448) signatures will be approved for at least some purposes in a FIPS.<= br>
There are many ways that this could not happen. Not least the lack o= f a director of NIST. But if it does, it would be a positive outcome. I rea= lly don=E2=80=99t much care which ECC curves we use so long as we all decid= e to use the same curves everywhere.
--94eb2c1a4f383f1d6b05564a037a-- From nobody Mon Aug 14 09:42:28 2017 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 AFA90120713 for ; Mon, 14 Aug 2017 09:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nExsFCh-CIx for ; Mon, 14 Aug 2017 09:42:25 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBB4124207 for ; Mon, 14 Aug 2017 09:42:25 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 14 Aug 2017 09:42:23 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 14 Aug 2017 09:42:22 -0700 From: Paul Hoffman To: "cfrg@irtf.org" Thread-Topic: New version of "The Transition from Classical to Post-Quantum Cryptography", draft-hoffman-c2pq Thread-Index: AQHTFRxNdh+MMkuOZUihazdbNF5DWg== Date: Mon, 14 Aug 2017 16:42:22 +0000 Message-ID: <7DF7B8B9-D7EF-4F8C-BC0E-B96CE15C2E37@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <562D37337E4D534F84E5FA2E26F9CCF1@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cfrg] New version of "The Transition from Classical to Post-Quantum Cryptography", draft-hoffman-c2pq X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 16:42:27 -0000 Greetings. Following Kenny's presentation for me at the last CFRG meeting, = I have posted a widely-updated version of draft-hoffman-c2pq; you can find = it at . A bunch of people gave me substantial updates to the last draft, and I thin= k the draft is solidifying. The draft still needs a lot of input from the c= rypto community (particularly the algorithm folks) about which recent paper= s say what about circuits that implement Shor's and Grover's algorithms aga= inst current algorithms. Even if you're not one of those folks, but you kno= w someone who is, please pass a copy of the draft to them and ask them to c= ontribute either here in CFRG or directly to me. --Paul Hoffman= From nobody Mon Aug 14 11:31:59 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C29811323B5; Mon, 14 Aug 2017 11:31:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: alexey.melnikov@isode.com, cfrg@ietf.org, irtf-chair@irtf.org, cfrg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150273551775.470.269414132744486782.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 11:31:57 -0700 Archived-At: Subject: [Cfrg] cfrg - New Meeting Session Request for IETF 100 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:31:58 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the cfrg working group. --------------------------------------------------------- Working Group Name: Crypto Forum Area Name: IRTF Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: kitten tcpinc uta dispatch dprive tls saag dmarc dcrup jmap Second Priority: mile People who must be present: Alexey Melnikov Kenny Paterson Resources Requested: Special Requests: Please generally avoid conflicts with SEC Area WGs/BOFs --------------------------------------------------------- From nobody Wed Aug 16 10:55:57 2017 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 E32CD132357 for ; Wed, 16 Aug 2017 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dsx6gGfVx3VI for ; Wed, 16 Aug 2017 10:55:53 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941E61200F3 for ; Wed, 16 Aug 2017 10:55:53 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 16 Aug 2017 10:55:51 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 16 Aug 2017 10:55:50 -0700 From: Paul Hoffman To: "cfrg@irtf.org" Thread-Topic: A terminology issue with "post-quantum cryptography" Thread-Index: AQHTFrjlYTwQzQbzSEaiw4aerLAloA== Date: Wed, 16 Aug 2017 17:55:50 +0000 Message-ID: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <90043660BC54C84398A2DF07D431FDCB@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 17:55:56 -0000 Greetings. I was talking with a colleague this morning about draft-hoffman-= c2pq and trying to describe quantum computing for cryptanalysis, and why qu= antum cryptography is not part of it. Their response should give us pause a= bout our terminology: "So post-quantum cryptography is what we get after qu= antum cryptography is fully developed?". I'm not offering a solution here, but that question is quite understandable= and terrible at the same time. --Paul Hoffman= From nobody Wed Aug 16 11:00:34 2017 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 98DA313235A for ; Wed, 16 Aug 2017 11:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIIarYDjlTXs for ; Wed, 16 Aug 2017 11:00:30 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811CA1200F3 for ; Wed, 16 Aug 2017 11:00:30 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id a77so24499946qkb.0 for ; Wed, 16 Aug 2017 11:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+3TMjfiMTCoZPYmYQAsoAqvvxexxI0+papr/LPYM6Ig=; b=ATnonsdcqDRAbOQz+cOVKOUZXLblVcaUUWFMg0byHrjFgVfkpgQ/YRSh56CBB+KFtM Ximw18Ipg4L9qslkmpP8/nYaZiQf7VRPF79lOSXqfoHCgaMs6cf6lc3KwVQypCKaCY0Q qqktjq+gl5ho3tE+zxp9EwftDkX4EOybefONw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+3TMjfiMTCoZPYmYQAsoAqvvxexxI0+papr/LPYM6Ig=; b=Yim9+YsrdfYGN2e5kDZoO30f9TusOdzUQhcSWPKfBaL+v3p8NOHSPlgKh5KXgm2VI2 VwdwJrpAYjWVcnn+OmtWjjZY0ICEpoiDj74GyQRnnJcMop5p+Z+IRGbcCTm2Q2rbc1Ur jtb5VPhIiQZ90r0a4mvhuI6SY5dpbNr9jFVqTikYtFdT39cnBofj0+oELD+XaLD/UiED v0x/dQleRsxOtZ4WwkdvP6K9Aexho9o1KjllNIuxK0nPyWUx05I1ULbTfDrxxCctSsBG degEWP2LhCHAm7mPpd9uobb0rLXqZkyXAHY+ym4tQL6JkLHx18hJCLh66bkha5P2AF1e c+sw== X-Gm-Message-State: AHYfb5gY5YrNdueT9pBRFdTlunzVdEwQLgrDmYmN75wrSTgiaFV0H0wP nyl5Ipp75VHnKFs+Ufi1e6rSvpM2oos3 X-Received: by 10.233.237.2 with SMTP id c2mr3488983qkg.107.1502906428677; Wed, 16 Aug 2017 11:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.225 with HTTP; Wed, 16 Aug 2017 11:00:28 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> References: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> From: Kyle Rose Date: Wed, 16 Aug 2017 14:00:28 -0400 Message-ID: To: Paul Hoffman Cc: "cfrg@irtf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:00:34 -0000 On Wed, Aug 16, 2017 at 1:55 PM, Paul Hoffman wrot= e: > Greetings. I was talking with a colleague this morning about draft-hoffma= n-c2pq and trying to describe quantum computing for cryptanalysis, and why = quantum cryptography is not part of it. Their response should give us pause= about our terminology: "So post-quantum cryptography is what we get after = quantum cryptography is fully developed?". > > I'm not offering a solution here, but that question is quite understandab= le and terrible at the same time. I wonder if "quantum resistant cryptography" is a better phrasing. (The fact that there are some strong lower-bound results makes it more than just "resistant", but it at least eliminates the other class of interpretations.) "PQC" may be here to stay, however: it's probably too widespread to easily change. Kyle From nobody Wed Aug 16 14:37:42 2017 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 8E55913271E for ; Wed, 16 Aug 2017 14:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAPl0y0Z_xsL for ; Wed, 16 Aug 2017 14:37:38 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8D013271A for ; Wed, 16 Aug 2017 14:37:38 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id v29so28322197qtv.3 for ; Wed, 16 Aug 2017 14:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DGk19f06M5vZqNzTI1mLYwzK+qqI3CqLvzuvft+vc4w=; b=SB3YQQ1NTGIyZ+KcdGs5IbgWv1KsEhE2+obtfNYD7cXm6CV8wIUcSvbOD5DegRuMBt Z2XvgFgUaGZxBn5u49+BErhzRxLmHTq/NxzCngCudipX5VzmQn8C4YZFQFckDj1ymJ+S a+S6u04SJMm+sT4XF9QP2PPiHlwgvXJPUXmxcg8bsGjJyokks48iA6Ji2DAt3U2Ak5K8 yhZkMd6tCeH5ST22H4+OInlW8iVjaVeTl+bg1H+EHWFCj8zx4T68eTOMDP3DsAd+ENzv bizoEPQK7XpVmgJ50SPHHB0X4cPDDCbk1xiFUXXF6yuuo+NEeNjrKvcv8zjgdhVlFhxg 2Tlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DGk19f06M5vZqNzTI1mLYwzK+qqI3CqLvzuvft+vc4w=; b=ARM4vNjL5WOFWPKPfwxTkJdDY46rKRQXpOYekQ4CDc0YZZhKadiioHXjNSzGGaSKhL DMe1jokfDSjEqzoQ8HQenMUlXpYLRA4Gb2v8QUvkyBihTLJSGjHWPQermhoKubZfXc50 tVZf2B/4QUOgqMzrlwffkqFWwDaQJXZ59oeVU2DirmOlVIRqx1wg2FIh4tpgH1gQPOKB lLtLsILq4z/unJWUA25OAL2zO5/eRFAt7Wa3ji8SCYmEly05z8Pg9nlCZvmcmwCtgbJq 3lIKPlkKBH8xvJGsRcl2b+tbVlpGWDAadCnKSzpFk0q5nI2cLOawTlPkn3V5mrge3Cju hF2w== X-Gm-Message-State: AHYfb5iDKIsdwgOPbcCwjUhkBIWfSw+/1+EhJTA+P1zxt/CxG5w7kY0m bVetkehpNVTXzSAYXsonHz7JKBoUWA== X-Received: by 10.237.53.169 with SMTP id c38mr4220647qte.191.1502919457199; Wed, 16 Aug 2017 14:37:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.23.135 with HTTP; Wed, 16 Aug 2017 14:37:16 -0700 (PDT) In-Reply-To: References: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> From: Ira McDonald Date: Wed, 16 Aug 2017 17:37:16 -0400 Message-ID: To: Kyle Rose , Ira McDonald Cc: Paul Hoffman , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a11c0d4ee5f5b730556e5b40c" Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:37:41 -0000 --001a11c0d4ee5f5b730556e5b40c Content-Type: text/plain; charset="UTF-8" Hi, The "quantum resistant crypto" is a lot more accurate term. The term "quantum safe crypto" is heavily used in some SDOs (and of course the "safe" part is inaccurate and should be "resistant"). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Aug 16, 2017 at 2:00 PM, Kyle Rose wrote: > On Wed, Aug 16, 2017 at 1:55 PM, Paul Hoffman > wrote: > > Greetings. I was talking with a colleague this morning about > draft-hoffman-c2pq and trying to describe quantum computing for > cryptanalysis, and why quantum cryptography is not part of it. Their > response should give us pause about our terminology: "So post-quantum > cryptography is what we get after quantum cryptography is fully developed?". > > > > I'm not offering a solution here, but that question is quite > understandable and terrible at the same time. > > I wonder if "quantum resistant cryptography" is a better phrasing. > (The fact that there are some strong lower-bound results makes it more > than just "resistant", but it at least eliminates the other class of > interpretations.) > > "PQC" may be here to stay, however: it's probably too widespread to > easily change. > > Kyle > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a11c0d4ee5f5b730556e5b40c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The "quantu= m resistant crypto" is a lot more accurate term.

The term= "quantum safe crypto" is heavily used in some SDOs (and
of course the "safe" part is inaccurate and should be "resi= stant").

Cheers,
- Ira


Ira M= cDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility = Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IE= EE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing= Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof= Music / High North Inc
http://sites.google= .com/site/blueroofmusic
http://sites.goo= gle.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Pa= rk Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
May-Dec: PO Box= 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434

<= /div>

On Wed, Aug 16, 2017 at 2:00 PM, Kyle Rose <= span dir=3D"ltr"><k= rose@krose.org> wrote:
On Wed, Aug 16, 2017 at 1:55 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
> Greetings. I was talking with a colleague this morning about draft-hof= fman-c2pq and trying to describe quantum computing for cryptanalysis, and w= hy quantum cryptography is not part of it. Their response should give us pa= use about our terminology: "So post-quantum cryptography is what we ge= t after quantum cryptography is fully developed?".
>
> I'm not offering a solution here, but that question is quite under= standable and terrible at the same time.

I wonder if "quantum resistant cryptography" is a better p= hrasing.
(The fact that there are some strong lower-bound results makes it more
than just "resistant", but it at least eliminates the other class= of
interpretations.)

"PQC" may be here to stay, however: it's probably too widespr= ead to
easily change.

Kyle

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

--001a11c0d4ee5f5b730556e5b40c-- From nobody Wed Aug 16 16:24:52 2017 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 EA09713235E for ; Wed, 16 Aug 2017 16:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZi_yKVEARu0 for ; Wed, 16 Aug 2017 16:24:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F33D132335 for ; Wed, 16 Aug 2017 16:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1248; q=dns/txt; s=iport; t=1502925888; x=1504135488; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Rbara2ksXooNsgqT45zsZu8A4vi95Sl6hXPi2VXbEjo=; b=ThBM931IYw1zy7+RgL3ZKJIM2UZEXuchMe/Q46AcFXOfbk5XHu5rZnEI 5vhBVqWhaj/JBYZl5x9f/sXlLJoY/G1RtHQpF3seg0rR2SQdJ1Zpiic2/ sdoPXN7cuaqFIBfOn8WvFZXSDZsKiGHrbnxzklkQGztNq1tt+quytFWRf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAgAG05RZ/5BdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1pkgRUHnh2aGSELhRschCxCFQECAQEBAQEBAWsohRkGAQEhETodAQgaAiY?= =?us-ascii?q?CBCULFRIEARIbihUQqlSCJoteAQEBAQEBAQECAQEBAQEBAQEBAQEYBYELgh2CA?= =?us-ascii?q?oNagnyDAIFzgxMwgjEFoEUClECSXJYaATUigQp3FUkSAYcHdohJgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,385,1498521600"; d="scan'208";a="281476453" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2017 23:24:47 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v7GNOlgb031280 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Aug 2017 23:24:47 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Aug 2017 18:24:46 -0500 Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1210.000; Wed, 16 Aug 2017 18:24:46 -0500 From: "David McGrew (mcgrew)" To: Paul Hoffman , "cfrg@irtf.org" Thread-Topic: [Cfrg] A terminology issue with "post-quantum cryptography" Thread-Index: AQHTFubZYTwQzQbzSEaiw4aerLAloA== Date: Wed, 16 Aug 2017 23:24:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.0.33] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 23:24:51 -0000 SGkgUGF1bCwNCg0KDQpPbiA4LzE2LzE3LCAxOjU1IFBNLCAiQ2ZyZyBvbiBiZWhhbGYgb2YgUGF1 bCBIb2ZmbWFuIiA8Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBwYXVsLmhvZmZt YW5AaWNhbm4ub3JnPiB3cm90ZToNCg0KPkdyZWV0aW5ncy4gSSB3YXMgdGFsa2luZyB3aXRoIGEg Y29sbGVhZ3VlIHRoaXMgbW9ybmluZyBhYm91dCBkcmFmdC1ob2ZmbWFuLWMycHEgYW5kIHRyeWlu ZyB0byBkZXNjcmliZSBxdWFudHVtIGNvbXB1dGluZyBmb3IgY3J5cHRhbmFseXNpcywgYW5kIHdo eSBxdWFudHVtIGNyeXB0b2dyYXBoeSBpcyBub3QgcGFydCBvZiBpdC4gVGhlaXIgcmVzcG9uc2Ug c2hvdWxkIGdpdmUgdXMgcGF1c2UgYWJvdXQgb3VyIHRlcm1pbm9sb2d5OiAiU28gcG9zdC1xdWFu dHVtIGNyeXB0b2dyYXBoeSBpcyB3aGF0IHdlIGdldCBhZnRlciBxdWFudHVtIGNyeXB0b2dyYXBo eSBpcyBmdWxseSBkZXZlbG9wZWQ/Ii4NCg0KVGhlIGN1cnJlbnQgdGVybWlub2xvZ3kgaXMgZmlu ZS4gICBXZSBzaG91bGQganVzdCBiZSBkb2luZyBhIGJldHRlciBqb2Igb2YgZGVzY3JpYmluZyB3 aHkgcXVhbnR1bSBjcnlwdG9ncmFwaHkgaXMgbm90IGEgdmlhYmxlIGN5YmVyc2VjdXJpdHkgc29s dXRpb24uICANCg0KRGF2aWQNCg0KPg0KPkknbSBub3Qgb2ZmZXJpbmcgYSBzb2x1dGlvbiBoZXJl LCBidXQgdGhhdCBxdWVzdGlvbiBpcyBxdWl0ZSB1bmRlcnN0YW5kYWJsZSBhbmQgdGVycmlibGUg YXQgdGhlIHNhbWUgdGltZS4NCj4NCj4tLVBhdWwgSG9mZm1hbg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Q2ZyZyBtYWlsaW5nIGxpc3QNCj5DZnJn QGlydGYub3JnDQo+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo= From nobody Wed Aug 16 21:34:51 2017 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 8369613235C for ; Wed, 16 Aug 2017 21:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew26QXO40wyX for ; Wed, 16 Aug 2017 21:34:48 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436AE1241F5 for ; Wed, 16 Aug 2017 21:34:47 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id i12so34644422pgr.3 for ; Wed, 16 Aug 2017 21:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GpT2FAxeq7Eb8Hkac0lJUwyi8ZHAEe8/9sAioqh9qdw=; b=RiAaR1ohgX9WgODjYnPLuWrbW65dL9+3fsAyV01dtq/F9Nmz5kfHj2ItaupWj4C1/x tcJMk4MabvtL+cmQpq5q0E5CuFfTBCtx167GknoVAVUwA/fdq/1/K0+Vho9o4rnloeAI Zc6XezVUSvMZCUd/W/aTghE5Q8mymP5CIT2wnkmXn6yH0biSDHkD0wCltTwsga4pAlPP fAqQbskkBlphjdjvZ6UJmPUiYFjGehGSWxsvx4yFFbq9jpKAzXXaVnRi7JoAoj5DsMc2 1J1aAvfKsEJMMMHSdp0sMG9bHCdwish8lnY3Xv+84a9SYCY1ajnmFp59KMRCwh7hVA6+ plIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GpT2FAxeq7Eb8Hkac0lJUwyi8ZHAEe8/9sAioqh9qdw=; b=jV905Ui8wKRDtectbillbiBLtQjEAi2cXBP+B2NyvgzzezU9H8T75PwMaJEYi2ZCK0 W7bzgrfIQc0ClTu1HzwEb+498pmqAlDR7fpXNCLNN/hIHonaG0V3zbpSBp6fEoewvFAL EY6ibwnMz4o5QhcXmKIJkDKGw0DkQC35B/PQRGSORnZ2/x0Se1KzrTIW4z4Ef33yIXsr 9sujLKn/i9UxX06fre0Cr8HHCeBMbBT6qD6GmdQ0TJLfl/tBPW2/dQsZa+Yhr9vH9cqc zywPShiPFyQJSMwbLLQLXQdfv2qH16FCp5qGTQv72hJXsQYQs3CErIwtUPvoHVDDa0HE qNxw== X-Gm-Message-State: AHYfb5h0ctQPLrrl4xYfxX73yTBiOx56VK3eOOmstA/c98CLSFTZv2Eh 4GLcStqL6iG3uQ== X-Received: by 10.99.117.90 with SMTP id f26mr363604pgn.441.1502944487448; Wed, 16 Aug 2017 21:34:47 -0700 (PDT) Received: from [10.0.1.25] (c-98-234-217-127.hsd1.ca.comcast.net. [98.234.217.127]) by smtp.gmail.com with ESMTPSA id s14sm4538564pgo.14.2017.08.16.21.34.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 21:34:46 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0E1BB1E1-0253-4D69-B072-B5CA05F627D0 Mime-Version: 1.0 (1.0) From: Jon Hudson X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 16 Aug 2017 21:34:46 -0700 Cc: Kyle Rose , Paul Hoffman , "cfrg@irtf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> To: Ira McDonald Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 04:34:50 -0000 --Apple-Mail-0E1BB1E1-0253-4D69-B072-B5CA05F627D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Aug 16, 2017, at 2:37 PM, Ira McDonald wrote:= >=20 > Hi, >=20 > The "quantum resistant crypto" is a lot more accurate term. Completely agree. "Quantum resistant crypto" is more accurate & descriptive.= =20 >=20 > The term "quantum safe crypto" is heavily used in some SDOs (and > of course the "safe" part is inaccurate and should be "resistant"). Anyone using quantum safe, quantum proof or any other definite and/or finite= terms will regret doing so. This is just the beginning.=20 >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=20 >> On Wed, Aug 16, 2017 at 2:00 PM, Kyle Rose wrote: >> On Wed, Aug 16, 2017 at 1:55 PM, Paul Hoffman wr= ote: >> > Greetings. I was talking with a colleague this morning about draft-hoff= man-c2pq and trying to describe quantum computing for cryptanalysis, and why= quantum cryptography is not part of it. Their response should give us pause= about our terminology: "So post-quantum cryptography is what we get after q= uantum cryptography is fully developed?". >> > >> > I'm not offering a solution here, but that question is quite understand= able and terrible at the same time. >>=20 >> I wonder if "quantum resistant cryptography" is a better phrasing. >> (The fact that there are some strong lower-bound results makes it more >> than just "resistant", but it at least eliminates the other class of >> interpretations.) >>=20 >> "PQC" may be here to stay, however: it's probably too widespread to >> easily change. >>=20 >> Kyle >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-0E1BB1E1-0253-4D69-B072-B5CA05F627D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 16, 2017, at 2:3= 7 PM, Ira McDonald <blueroofmu= sic@gmail.com> wrote:

Hi,

The "quantum resista= nt crypto" is a lot more accurate term.

Completely agree. "Quantum resistant cry= pto" is more accurate & descriptive.
 

The term "q= uantum safe crypto" is heavily used in some SDOs (and
of course the= "safe" part is inaccurate and should be "resistant").
=

Anyone using quantum safe, quantum pr= oof or any other definite and/or finite terms will regret doing so.

This is just the beginning. 


Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co= -Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open P= rinting WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE= -ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP &= ; Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com<= br>Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094=
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434
<= br>
<= div style=3D"display:inline">

On Wed, Aug 16, 2017 at 2:00 PM, Kyle Rose <kro= se@krose.org> wrote:
On Wed, Aug 16, 2017 at 1:55 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
> Greetings. I was talking with a colleague this morning about draft-hoff= man-c2pq and trying to describe quantum computing for cryptanalysis, and why= quantum cryptography is not part of it. Their response should give us pause= about our terminology: "So post-quantum cryptography is what we get after q= uantum cryptography is fully developed?".
>
> I'm not offering a solution here, but that question is quite understand= able and terrible at the same time.

I wonder if "quantum resistant cryptography" is a better phrasing. (The fact that there are some strong lower-bound results makes it more
than just "resistant", but it at least eliminates the other class of
interpretations.)

"PQC" may be here to stay, however: it's probably too widespread to
easily change.

Kyle

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

____________________= ___________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman= /listinfo/cfrg
= --Apple-Mail-0E1BB1E1-0253-4D69-B072-B5CA05F627D0-- From nobody Thu Aug 17 05:43:28 2017 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 ED96B1323CE for ; Thu, 17 Aug 2017 05:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkKbtpwVEHhj for ; Thu, 17 Aug 2017 05:43:23 -0700 (PDT) Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id D9E25132391 for ; Thu, 17 Aug 2017 05:43:22 -0700 (PDT) Received: (qmail 27462 invoked by uid 1010); 17 Aug 2017 12:43:20 -0000 Received: from unknown (unknown) by unknown with QMTP; 17 Aug 2017 12:43:20 -0000 Received: (qmail 2039 invoked by uid 1000); 17 Aug 2017 12:43:13 -0000 Date: 17 Aug 2017 12:43:13 -0000 Message-ID: <20170817124313.2037.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 12:43:25 -0000 FIPS 186-4 has the sensible title "Digital signature standard", not "Safe digital signature standard" or "Attack-resistant digital signature standard". AES isn't the "Safe Advanced Encryption Standard". SHA-1 is an outlier in terminology, and so now we get to say ridiculous-sounding things like "Secure Hash Algorithm 1 is not secure". One of the top hits for "quantum-safe cryptography" is referring to ID Quantique's QKD products as "provably secure quantum-safe" cryptography. But research by Makarov et al. has convincingly shown that these products are breakable at low cost. Do we say "Makarov has broken quantum-safe cryptography"? Jon Hudson writes: > Anyone using quantum safe, quantum proof or any other definite and/or > finite terms will regret doing so. "Quantum-resistant" is similarly unusable for serious discussions: it's slightly more vague than "quantum-safe" but shares the basic mistake of stating a highly questionable _conclusion_. "Post-quantum" is different. It's focusing on the right _metric_, namely what security levels we'll have after the apocalyptic moment when the attackers acquire large quantum computers. Post-quantum attacks are more powerful than pre-quantum attacks. Algorithms often have post-quantum security levels far below their apparent pre-quantum security levels. [Bias alert: I introduced the phrase "post-quantum" in 2003.] David McGrew (mcgrew) writes: > The current terminology is fine. We should just be doing a better > job of describing why quantum cryptography is not a viable > cybersecurity solution. Here's my latest effort: https://blog.cr.yp.to/20160516-quantum.html Paul Hoffman writes: > I was talking with a colleague this morning about > draft-hoffman-c2pq and trying to describe quantum computing for > cryptanalysis, and why quantum cryptography is not part of it. > Their response should give us pause about our terminology: "So > post-quantum cryptography is what we get after quantum cryptography is > fully developed?". What's the dispute here supposed to be? Quantum cryptography was discussed in the early 1970s; published and named in the early 1980s; implemented in the late 1980s; brought to market in the early 2000s. The concept of post-quantum cryptography would have been awfully difficult to articulate before Shor's algorithm and Grover's algorithm were published in the mid-1990s. Of course there was already security analysis of, e.g., McEliece's cryptosystem, but nobody was separating post-quantum security levels from pre-quantum security levels. ---Dan From nobody Thu Aug 17 05:59:39 2017 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 84AFD1323C6 for ; Thu, 17 Aug 2017 05:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46iy-LTREiUG for ; Thu, 17 Aug 2017 05:59:34 -0700 (PDT) Received: from ecserv7.uwaterloo.ca (ecserv7.uwaterloo.ca [129.97.50.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7531323AC for ; Thu, 17 Aug 2017 05:59:34 -0700 (PDT) Received: from ecserv7.uwaterloo.ca (localhost [127.0.0.1]) by ecserv7.uwaterloo.ca (8.14.3/8.14.3) with ESMTP id v7HCxAXB008832; Thu, 17 Aug 2017 08:59:10 -0400 (EDT) (envelope-from vsoukhar@uwaterloo.ca) Received: (from www@localhost) by ecserv7.uwaterloo.ca (8.14.3/8.14.3/Submit) id v7HCx55f008831; Thu, 17 Aug 2017 08:59:05 -0400 (EDT) (envelope-from vsoukhar@uwaterloo.ca) Received: from 38.110.119.144 ([38.110.119.144]) by www.nexusmail.uwaterloo.ca (Horde Framework) with HTTP; Thu, 17 Aug 2017 08:59:04 -0400 Message-ID: <20170817085904.11747ft66soa9sm0@www.nexusmail.uwaterloo.ca> Date: Thu, 17 Aug 2017 08:59:04 -0400 From: vsoukhar@uwaterloo.ca To: "David McGrew (mcgrew)" Cc: Paul Hoffman , "cfrg@irtf.org" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.5) / FreeBSD-7.2 X-Originated-By: vsoukhar@mailservices.uwaterloo.ca X-Originating-IP: 38.110.119.144 X-Remote-Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 12:59:37 -0000 Hi everyone, "Post Quantum Cryptography" is a well established term in the cryptographic community now, so I think it is best to keep as is. I think a good rational to explain the term to others would be to say that it is the crypto that will still be safe after (full scale) quantum computers become available. Vladimir Quoting "David McGrew (mcgrew)" : > Hi Paul, > > > On 8/16/17, 1:55 PM, "Cfrg on behalf of Paul Hoffman" > wrote: > >> Greetings. I was talking with a colleague this morning about >> draft-hoffman-c2pq and trying to describe quantum computing for >> cryptanalysis, and why quantum cryptography is not part of it. >> Their response should give us pause about our terminology: "So >> post-quantum cryptography is what we get after quantum cryptography >> is fully developed?". > > The current terminology is fine. We should just be doing a better > job of describing why quantum cryptography is not a viable > cybersecurity solution. > > David > >> >> I'm not offering a solution here, but that question is quite >> understandable and terrible at the same time. >> >> --Paul Hoffman >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Fri Aug 18 04:36:08 2017 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 D466313202D for ; Fri, 18 Aug 2017 04:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIj8qICv-ntv for ; Fri, 18 Aug 2017 04:36:06 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1325E126B71 for ; Fri, 18 Aug 2017 04:36:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.41,392,1498518000"; d="scan'208";a="19401297" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Aug 2017 12:36:04 +0100 X-IronPort-AV: E=Sophos;i="5.41,392,1498518000"; d="scan'208";a="17223608" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 18 Aug 2017 12:36:04 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.199]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0361.001; Fri, 18 Aug 2017 12:36:04 +0100 From: "Dearlove, Christopher (UK)" To: Kyle Rose , Paul Hoffman CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] A terminology issue with "post-quantum cryptography" Thread-Index: AQHTFrjlYTwQzQbzSEaiw4aerLAloKKHNOAAgALJX3A= Date: Fri, 18 Aug 2017 11:36:02 +0000 Message-ID: References: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 11:36:08 -0000 Kyle Rose > I wonder if "quantum resistant cryptography" is a better phrasing. Technically, I think it definitely is. Unfortunately when I last (a few mon= th ago) tried the crude "how many hits in Google" test, Post-Quantum Crypto= graphy won hands down. (There's also a significant usage of the phrase Quantum Safe cryptography o= ut there.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Fri Aug 18 04:41:57 2017 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 D96111321F5 for ; Fri, 18 Aug 2017 04:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwhfRrDV1Jve for ; Fri, 18 Aug 2017 04:41:54 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5101321F1 for ; Fri, 18 Aug 2017 04:41:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.41,392,1498518000"; d="scan'208";a="19402638" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Aug 2017 12:41:52 +0100 X-IronPort-AV: E=Sophos;i="5.41,392,1498518000"; d="scan'208";a="17224477" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 18 Aug 2017 12:41:52 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.199]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0361.001; Fri, 18 Aug 2017 12:41:52 +0100 From: "Dearlove, Christopher (UK)" To: Kyle Rose , Paul Hoffman CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] A terminology issue with "post-quantum cryptography" Thread-Index: AQHTFrjlYTwQzQbzSEaiw4aerLAloKKHNOAAgALJX3CAAAFEIA== Date: Fri, 18 Aug 2017 11:41:51 +0000 Message-ID: References: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 11:41:56 -0000 Responding to myself, I see Dan Bernstein's argument in favour of post-quan= tum as also technically better. It's a good point. It does however run into= the problem already noted that post-quantum isn't after quantum, and that = you can do PQC now, before there are any (realistic sized) quantum computer= s, and that can be confusing too, so nothing is perfect. --=20 Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: =A0+44 3300 467500 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dearlove, Christophe= r (UK) Sent: 18 August 2017 12:36 To: Kyle Rose; Paul Hoffman Cc: cfrg@irtf.org Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. Kyle Rose > I wonder if "quantum resistant cryptography" is a better phrasing. Technically, I think it definitely is. Unfortunately when I last (a few mon= th ago) tried the crude "how many hits in Google" test, Post-Quantum Crypto= graphy won hands down. (There's also a significant usage of the phrase Quantum Safe cryptography o= ut there.) ******************************************************************** This email and any attachments are confidential to the intended recipient a= nd may also be privileged. If you are not the intended recipient please del= ete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute= its contents to any other person. ******************************************************************** _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Aug 18 09:02:44 2017 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 E75AA1329D9 for ; Fri, 18 Aug 2017 09:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPRSxKVt_DF2 for ; Fri, 18 Aug 2017 09:02:40 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202A41321DC for ; Fri, 18 Aug 2017 09:02:40 -0700 (PDT) X-Spoof: Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2017 12:01:58 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 18 Aug 2017 12:02:38 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Fri, 18 Aug 2017 12:02:37 -0400 From: Dan Brown To: "D. J. Bernstein" , "cfrg@irtf.org" Thread-Topic: [Cfrg] A terminology issue with "post-quantum cryptography" Thread-Index: AQHTF1ZjYTwQzQbzSEaiw4aerLAloKKIvayQ Date: Fri, 18 Aug 2017 16:02:37 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B925F4@XMB116CNC.rim.net> References: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> <20170817124313.2037.qmail@cr.yp.to> In-Reply-To: <20170817124313.2037.qmail@cr.yp.to> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:02:42 -0000 How about quantum-prudent or quantum-cautious cryptography? /* I'm not a PQC researcher, so please feel free to ignore my $0.02. Finding (brief) terminology for this topic seems difficult, mainly because = of the extra conjectures and timing (see below). But it is only terminolog= y, so it is probably okay just to stick to a tradition, or okay to churn it= up, or be imperfect. There is a need (see below) for distinct terminology for task and the tool.= For example, McEliece (the tool) is (reasonably) conjectured to provide q= uantum-resistance (the task). Postquantum crypto could a help as a noun fo= r a generic tool (conjectured to be quantum-resistant). There seems some value in specificity. For example, ECC is rarely called p= ost-factoring or sieving-resistant ,etc. (to address the non-zero risk of a= faster classical-computer factoring or sieving algorithm), partly because = that's not specific to ECC. There is a need for quantum-resistance because of a non-negligible risk of = quantum computer. But it is bad if pushes towards this need seem to imply d= ropping ECC, because that would trade one risk for another. Terms like pos= tquantum and quantum-resistant do little to remind us that a quantum comput= er is only conjectural, so these terms must often be accompanied by further= clarifications and explanations (e.g., don't drop ECC). Supplementing ECC or RSA with some kind of conjecturally quantum-resistant = proposal pre-emptively is often justified (the cost is worth addressing the= risk), but calling this "postquantum" does not go far enough to encourage = this practice (because post suggests waiting) or clarify the timing (recall= how NIST called forward secrecy backtracking resistance.) Shor's algorithm makes it a certainty that a large-enough quantum computer = would break RSA and ECC. Confusing that certainty with various PQC proposal= s being quantum-resistant is inaccurate. In this regard, the leading terms= postquantum and quantum-resistant overstate the case (as do quantum-pruden= t and quantum-cautious). To this end, I tried to think up a short name mor= e specific to Shor's algorithm, but only came up with silly jokes, such as = shor-ward-secure, or vague techno terms like no-hidden-group. (This strate= gy also completely ignores the symmetric key case and Grover's algorithm, b= ut that situation is simpler.) */ From nobody Fri Aug 18 09:43:53 2017 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 B274A132A08 for ; Fri, 18 Aug 2017 09:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4w8lDRT5hBd for ; Fri, 18 Aug 2017 09:43:48 -0700 (PDT) Received: from exchange.robsoninc.com (ex-g3-cashub01.yourhostingbrand.com [204.244.181.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91355132A01 for ; Fri, 18 Aug 2017 09:43:48 -0700 (PDT) Received: from EX-G3-MBX02.hosting.local ([fe80::e170:8488:6617:f969]) by ex-g3-cashub01.hosting.local ([172.16.0.71]) with mapi id 14.03.0361.001; Fri, 18 Aug 2017 09:45:20 -0700 From: Andre Brisson To: Dan Brown , "D. J. Bernstein" , "cfrg@irtf.org" Thread-Topic: [Cfrg] A terminology issue with "post-quantum cryptography" Thread-Index: AQHTFrjlYTwQzQbzSEaiw4aerLAloKKIvayQgAGSfGA= Date: Fri, 18 Aug 2017 16:42:59 +0000 Message-ID: References: <5397C02D-A4C5-47CD-9383-E47D3262D8C4@icann.org> <20170817124313.2037.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF501B925F4@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B925F4@XMB116CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.180.128.17] Content-Type: multipart/alternative; boundary="_000_D038A273DEC97649BB60309DE259B8800176C337A1exg3mbx02host_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:43:51 -0000 --_000_D038A273DEC97649BB60309DE259B8800176C337A1exg3mbx02host_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The assertion highlighted in yellow is interesting. The IEEE is publishing = papers concerning the factoring topic and the utility was demonstrated at = a ATC IEEE Trusted Computing workshop in Silicon Valley August 4. It has be= en around a while. It is being demonstrated at the Hague during another con= ference particularly to NATO and Europol in October. Before knee jerk comments it is recommended that you build and test it. Sci= entific method and informed comments are always good. It is simple enough t= o build. It is also simple to request a copy of the utility if you can be p= ermitted under regulatory regime. AB http://www.wnlabs.com/news/ECC-is-easier-to-break.php http://www.wnlabs.com/pdf/IEEE-ATC-R-CyberTrust-27.pdf This informs enginee= rs or beginner computer scientists how to build utility. http://www.wnlabs.com/news/IEEE_copyright_WN_papers.php -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan Brown Sent: Friday, August 18, 2017 9:03 AM To: D. J. Bernstein; cfrg@irtf.org Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptography" How about quantum-prudent or quantum-cautious cryptography? /* I'm not a PQC researcher, so please feel free to ignore my $0.02. Finding (brief) terminology for this topic seems difficult, mainly because = of the extra conjectures and timing (see below). But it is only terminolog= y, so it is probably okay just to stick to a tradition, or okay to churn it= up, or be imperfect. There is a need (see below) for distinct terminology for task and the tool.= For example, McEliece (the tool) is (reasonably) conjectured to provide q= uantum-resistance (the task). Postquantum crypto could a help as a noun fo= r a generic tool (conjectured to be quantum-resistant). There seems some value in specificity. For example, ECC is rarely called p= ost-factoring or sieving-resistant ,etc. (to address the non-zero risk of a= faster classical-computer factoring or sieving algorithm), partly because = that's not specific to ECC. There is a need for quantum-resistance because of a non-negligible risk of = quantum computer. But it is bad if pushes towards this need seem to imply d= ropping ECC, because that would trade one risk for another. Terms like pos= tquantum and quantum-resistant do little to remind us that a quantum comput= er is only conjectural (questionable), so these terms must often be accompa= nied by further clarifications and explanations (e.g., don't drop ECC). Supplementing ECC or RSA with some kind of conjecturally quantum-resistant = proposal pre-emptively is often justified (the cost is worth addressing the= risk), but calling this "postquantum" does not go far enough to encourage = this practice (because post suggests waiting) or clarify the timing (recall= how NIST called forward secrecy backtracking resistance.) Shor's algorithm makes it a certainty that a large-enough quantum computer = would break RSA and ECC. Confusing that certainty with various PQC proposal= s being quantum-resistant is inaccurate. In this regard, the leading terms= postquantum and quantum-resistant overstate the case (as do quantum-pruden= t and quantum-cautious). To this end, I tried to think up a short name mor= e specific to Shor's algorithm, but only came up with silly jokes, such as = shor-ward-secure, or vague techno terms like no-hidden-group. (This strate= gy also completely ignores the symmetric key case and Grover's algorithm, b= ut that situation is simpler.) */ _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --_000_D038A273DEC97649BB60309DE259B8800176C337A1exg3mbx02host_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The assertion highlighted in yellow is interestin= g. The IEEE is publishing papers concerning the factoring topic and the uti= lity  was demonstrated at a ATC IEEE Trusted Computing workshop in Sil= icon Valley August 4. It has been around a while. It is being demonstrated at the Hague during another conference p= articularly to NATO and Europol in October.

 

Before knee jerk comments it is recommended that = you build and test it. Scientific method and informed comments are always g= ood. It is simple enough to build. It is also simple to request a copy of t= he utility if you can be permitted under regulatory regime.

 

AB

 

http://www.wnlabs.com/news/ECC-is-easier-to-break.php<= o:p>

http://www.wnlabs.com/pdf/IEEE-ATC-R-CyberTrust-27.pdf This informs engineers or beginner computer scientists how to build utili= ty.

 

http://www.wnlabs.com/news/IEEE_copyright_WN_papers.php<= /a>

 

-----Original Message-----
From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan Brown
Sent: Friday, August 18, 2017 9:03 AM
To: D. J. Bernstein; cfrg@irtf.org
Subject: Re: [Cfrg] A terminology issue with "post-quantum cryptograph= y"

 

How about quantum-prudent or quantum-cautious cry= ptography?

/*

I'm not a PQC researcher, so please feel free to = ignore my $0.02.

 

Finding (brief) terminology for this topic seems = difficult, mainly because of the extra conjectures and timing (see below).&= nbsp; But it is only terminology, so it is probably okay just to stick to a= tradition, or okay to churn it up, or be imperfect.

 

There is a need (see below) for distinct terminol= ogy for task and the tool.  For example, McEliece (the tool) is (reaso= nably) conjectured to provide quantum-resistance (the task).  Postquan= tum crypto could a help as a noun for a generic tool (conjectured to be quantum-resistant).

 

There seems some value in specificity.&nbs= p; For example, ECC is rarely called= post-factoring or sieving-resistant ,etc. (to address the non-zero risk of= a faster classical-computer factoring or sieving algorithm), partly becaus= e that's not specific to ECC.

 

There is a need for quantum-resistance because of= a non-negligible risk of quantum computer. But it is bad if pushes towards= this need seem to imply dropping ECC, because that would trade one risk fo= r another.  Terms like postquantum and quantum-resistant do little to remind us that a quantum computer is only conjectural (questionable), so these terms must often be accompanied by furt= her clarifications and explanations (e.g., don't drop ECC).

 

Supplementing ECC or RSA with some kind of conjec= turally quantum-resistant proposal pre-emptively is often justified (the co= st is worth addressing the risk), but calling this "postquantum" = does not go far enough to encourage this practice (because post suggests waiting) or clarify the timing (recall how NIST cal= led forward secrecy backtracking resistance.)

 

Shor's algorithm makes it a certainty that a larg= e-enough quantum computer would break RSA and ECC. Confusing that certainty= with various PQC proposals being quantum-resistant is inaccurate.  In= this regard, the leading terms postquantum and quantum-resistant overstate the case (as do quantum-prudent and quantu= m-cautious).  To this end, I tried to think up a short name more speci= fic to Shor's algorithm, but only came up with silly jokes, such as shor-wa= rd-secure, or vague techno terms like no-hidden-group.  (This strategy also completely ignores the symmetri= c key case and Grover's algorithm, but that situation is simpler.) */<= /o:p>

 

_______________________________________________

Cfrg mailing list

Cfrg@irtf.org

https://www.irt= f.org/mailman/listinfo/cfrg

--_000_D038A273DEC97649BB60309DE259B8800176C337A1exg3mbx02host_-- From nobody Fri Aug 18 14:20:09 2017 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 8B6071323A2 for ; Fri, 18 Aug 2017 14:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I08S9pk_2JKP for ; Fri, 18 Aug 2017 14:20:04 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41002132380 for ; Fri, 18 Aug 2017 14:20:03 -0700 (PDT) X-Spoof: Received: from xct104cnc.rim.net ([10.65.161.204]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2017 17:19:22 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Fri, 18 Aug 2017 17:20:02 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: Twist insecurity of 2y^2=x^3+x/GF(8^91+5) Thread-Index: AdMYYsJG2Is69L22T1eqnhv8dyO27Q== Date: Fri, 18 Aug 2017 21:20:01 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B9284D@XMB116CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Cfrg] Twist insecurity of 2y^2=x^3+x/GF(8^91+5) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 21:20:08 -0000 --_004_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi CFRG, As noted in earlier discussions, the curve 2y^2=3Dx^3+x over GF(8^91+5) was= chosen without considering the criterion of twist security, instead electi= ng for some other security goals. In this thread, I wish to discuss and quantify the consequences of forgoing= twist security for this specific curve, to ensure that an Internet-Draft o= n it (eventually) specifies any necessary security precautions, but also to= be clear the tradeoffs in security features of this curve compared to othe= rs. I'm a bit shaky on the theory and motivation of twist security, but I'll st= ate what I currently think and hope for corrections from the CFRG list. First of all, this curve has complex multiplication by i, which I vaguely u= nderstand to imply that the curve has four twists, under some of theoretica= l definition of a twist (1% sure). Nevertheless, for the Montgomery ladder= context of twist security, only two of these twists are relevant (10% sure= ): the original curve and the twist y^2=3Dx^3+x. The original curve has size 72n for n prime, while the relevant twist (20% = sure) has size with prime factorization 2^2 * 5 * 1526119141 * 788069478421 * 182758084524062861993 * 3452464930451= 677330036005252040328546941 With the prime factors having base-2 logs of approximately: 1 1 2.3 30.5 39.5 67.3 131.3 This makes the ECDLP on the twist quite insecure (2^65), due to Pohlig-Hell= man, which rules out using this curve in the few specialized protocols that= make equal use of the curve and its twist. For a conventional DH protocol using a Montgomery ladder, the critical ques= tion seems to be what is lost by skipping point validation? Three interact= ions against the same static DH private key can used to find the private ke= y at a cost of about 2^65 (off-line) operations. (1% sure of no known fast= er attack). By contrast, the gain of skipping point validation is about 5-= 10% in DH runtime (is this right?). So, the remedy is either MUST not re-u= se DH private keys or MUST do point validation on public keys, but wait ... If the static DH key in the Montgomery ladder implementation above is used = in a higher-level protocol that requires key confirmation from the other si= de before using the shared key in encryption, then it seems the previous at= tacker's chances either are drastically reduced, or the attacker requires b= illions of (failed) interactions (instead of 5). Is this right? If so, in= such a protocol, would a good remedy be to place a limit (e.g. 1000/month)= on the number of failed key confirmation attempts? Is this kind of key confirmation in a protocol the norm, or the exception? = For example, do current versions TLS and IKE and SSH check a MAC with the = shared secret from the other side before using the shared secret in AES, et= c.? Non-interactive protocols cannot give key confirmation to the sender, = but usually the sender/CA would also validate the receiver's certificate (r= educing the relative incentive to skip point validation). Best regards, Dan [BlackBerry] --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi CFRG,

 

As noted in earlier discussions, the curve 2y^2=3Dx^= 3+x over GF(8^91+5) was chosen without considering the criterion of= twist security, instead electing for some other security goals.  

 

In this thread, I wish to discuss and quantify the c= onsequences of forgoing twist security for this specific curve, to ensure t= hat an Internet-Draft on it (eventually) specifies any necessary security p= recautions, but also to be clear the tradeoffs in security features of this curve compared to others.

 

I’m a bit shaky on the theory and motivation o= f twist security, but I’ll state what I currently think and hope for = corrections from the CFRG list.

 

First of all, this curve has complex multiplication = by i, which I vaguely understand to imply that the curve has four twists, u= nder some of theoretical definition of a twist (1% sure).  Nevertheles= s, for the Montgomery ladder context of twist security, only two of these twists are relevant (10% sure): the orig= inal curve and the twist y^2=3Dx^3+x.

 

The original curve has size 72n for n prime, while t= he relevant twist (20% sure) has size with prime factorization

2^2 * 5 * 1526119141 * 788069478421 * 18275808452406= 2861993 * 3452464930451677330036005252040328546941

With the prime factors having base-2 logs of approxi= mately:

1 1 2.3 30.5 39.5 67.3 131.3

 

This makes the ECDLP on the twist quite insecure (2^= 65), due to Pohlig-Hellman, which rules out using this curve in the few spe= cialized protocols that make equal use of the curve and its twist.

 

For a conventional DH protocol using a Montgomery la= dder, the critical question seems to be what is lost by skipping point vali= dation?  Three interactions against the same static DH private key can= used to find the private key at a cost of about 2^65 (off-line) operations.  (1% sure of no known faster att= ack).  By contrast, the gain of skipping point validation is about 5-1= 0% in DH runtime (is this right?).  So, the remedy is either MUST not = re-use DH private keys or MUST do point validation on public keys, but wait …

 

If the static DH key in the Montgomery ladder implem= entation above is used in a higher-level protocol that requires key confirm= ation from the other side before using the shared key in encryption, then i= t seems the previous attacker’s chances either are drastically reduced, or the attacker requires billions of (fail= ed) interactions (instead of 5).  Is this right?  If so, in such = a protocol, would a good remedy be to place a limit (e.g. 1000/month) on th= e number of failed key confirmation attempts?

 

Is this kind of key confirmation in a protocol the n= orm, or the exception?  For example, do current versions TLS and IKE a= nd SSH check a MAC with the shared secret from the other side before using = the shared secret in AES, etc.?  Non-interactive protocols cannot give key confirmation to the sender, but usually the send= er/CA would also validate the receiver’s certificate (reducing the re= lative incentive to skip point validation).

 

Best regards,

 

Dan

3D"BlackBerry"

 

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=174; creation-date="Fri, 18 Aug 2017 21:20:01 GMT"; modification-date="Fri, 18 Aug 2017 21:20:01 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAMAAABEpIrGAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAAEklEQVQ4y2NgGAWjYBSMAuwAAAQgAAFWu83mAAAAAElFTkSu QmCC --_004_810C31990B57ED40B2062BA10D43FBF501B9284DXMB116CNCrimnet_-- From nobody Sat Aug 19 08:33:12 2017 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 38059132933 for ; Sat, 19 Aug 2017 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88OT59t8BHaj for ; Sat, 19 Aug 2017 08:33:08 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D2873132494 for ; Sat, 19 Aug 2017 08:33:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C41FD8358F; Sat, 19 Aug 2017 18:33:04 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id slLTij5DStWu; Sat, 19 Aug 2017 18:33:04 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 77DE0288; Sat, 19 Aug 2017 18:33:02 +0300 (EEST) Date: Sat, 19 Aug 2017 18:33:02 +0300 From: Ilari Liusvaara To: Dan Brown Cc: "cfrg@irtf.org" Message-ID: <20170819153302.pymmplx2wvfl3h7p@LK-Perkele-VII> References: <810C31990B57ED40B2062BA10D43FBF501B9284D@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B9284D@XMB116CNC.rim.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] Twist insecurity of 2y^2=x^3+x/GF(8^91+5) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 15:33:10 -0000 On Fri, Aug 18, 2017 at 09:20:01PM +0000, Dan Brown wrote: > > If the static DH key in the Montgomery ladder implementation above > is used in a higher-level protocol that requires key confirmation > from the other side before using the shared key in encryption, > then it seems the previous attacker's chances either are > drastically reduced, or the attacker requires billions of (failed) > interactions (instead of 5). Is this right? If so, in such a > protocol, would a good remedy be to place a limit (e.g. 1000/month) > on the number of failed key confirmation attempts? It depends on protocol. As example of how things can go wrong, take TLS 1.3. If the server keeps fixed DH key, one can send a few handshakes, and from the resposes (the server does key confirmation first!) do offline ~2^65 operation attack to find the fixed DH key. And TLS 1.3 breaks _really_ badly if the server static DH key is compromised. -Ilari From nobody Mon Aug 21 09:05:20 2017 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 1BBE713234C for ; Mon, 21 Aug 2017 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6-w9w818YxN for ; Mon, 21 Aug 2017 09:05:16 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAD6132026 for ; Mon, 21 Aug 2017 09:05:15 -0700 (PDT) X-Spoof: Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Aug 2017 12:04:20 -0400 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 21 Aug 2017 12:05:14 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 21 Aug 2017 12:05:13 -0400 From: Dan Brown To: "ilariliusvaara@welho.com" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Twist insecurity of 2y^2=x^3+x/GF(8^91+5) Thread-Index: AdMYYsJG2Is69L22T1eqnhv8dyO27QAvzZcAAFzk0KA= Date: Mon, 21 Aug 2017 16:05:13 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B92EC7@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B9284D@XMB116CNC.rim.net> <20170819153302.pymmplx2wvfl3h7p@LK-Perkele-VII> In-Reply-To: <20170819153302.pymmplx2wvfl3h7p@LK-Perkele-VII> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Twist insecurity of 2y^2=x^3+x/GF(8^91+5) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 16:05:18 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNv bSANCk9uIEZyaSwgQXVnIDE4LCAyMDE3IGF0IDA5OjIwOjAxUE0gKzAwMDAsIERhbiBCcm93biB3 cm90ZToNCj4gDQo+IElmIHRoZSBzdGF0aWMgREgga2V5IGluIHRoZSBNb250Z29tZXJ5IGxhZGRl ciBpbXBsZW1lbnRhdGlvbiBhYm92ZSBpcyANCj4gdXNlZCBpbiBhIGhpZ2hlci1sZXZlbCBwcm90 b2NvbCB0aGF0IHJlcXVpcmVzIGtleSBjb25maXJtYXRpb24gZnJvbSANCj4gdGhlIG90aGVyIHNp ZGUgYmVmb3JlIHVzaW5nIHRoZSBzaGFyZWQga2V5IGluIGVuY3J5cHRpb24sIHRoZW4gaXQgDQo+ IHNlZW1zIHRoZSBwcmV2aW91cyBhdHRhY2tlcidzIGNoYW5jZXMgZWl0aGVyIGFyZSBkcmFzdGlj YWxseSByZWR1Y2VkLCANCj4gb3IgdGhlIGF0dGFja2VyIHJlcXVpcmVzIGJpbGxpb25zIG9mIChm YWlsZWQpIGludGVyYWN0aW9ucyAoaW5zdGVhZCBvZiANCj4gNSkuICBJcyB0aGlzIHJpZ2h0PyAg SWYgc28sIGluIHN1Y2ggYSBwcm90b2NvbCwgd291bGQgYSBnb29kIHJlbWVkeSBiZSANCj4gdG8g cGxhY2UgYSBsaW1pdCAoZS5nLiAxMDAwL21vbnRoKSBvbiB0aGUgbnVtYmVyIG9mIGZhaWxlZCBr ZXkgDQo+IGNvbmZpcm1hdGlvbiBhdHRlbXB0cz8NCg0KSXQgZGVwZW5kcyBvbiBwcm90b2NvbC4N Cg0KQXMgZXhhbXBsZSBvZiBob3cgdGhpbmdzIGNhbiBnbyB3cm9uZywgdGFrZSBUTFMgMS4zLiBJ ZiB0aGUgc2VydmVyIGtlZXBzIGZpeGVkIERIIGtleSwgb25lIGNhbiBzZW5kIGEgZmV3IGhhbmRz aGFrZXMsIGFuZCBmcm9tIHRoZSByZXNwb3NlcyAodGhlIHNlcnZlciBkb2VzIGtleSBjb25maXJt YXRpb24gZmlyc3QhKSBkbyBvZmZsaW5lIH4yXjY1IG9wZXJhdGlvbiBhdHRhY2sgdG8gZmluZCB0 aGUgZml4ZWQgREgga2V5Lg0KDQpBbmQgVExTIDEuMyBicmVha3MgX3JlYWxseV8gYmFkbHkgaWYg dGhlIHNlcnZlciBzdGF0aWMgREgga2V5IGlzIGNvbXByb21pc2VkLg0KDQo8REI+DQpUaGFua3Mu ICANCg0KSSByZXZpZXdlZCBUTFMgMS4zIGJhc2VkIG9uIHlvdXIgY29tbWVudHMsIGFuZCBJIGFn cmVlIHdpdGggeW91ciBjb25jbHVzaW9uLg0KDQpJIG5vdGljZWQgdGhhdCB0aGUgY2xpZW50IGlu IFRMUyAxLjMgc2hvdWxkIG5vcm1hbGx5IHJlY2VpdmUgYSBwcm90ZWN0ZWQge0ZpbmlzaH0gZnJv bSB0aGUgc2VydmVyIGJlZm9yZSByZWxlYXNpbmcgaW5mb3JtYXRpb24gZGVyaXZlZCB0aGUgc2hh cmVkIHNlY3JldC4gIFNvLCB0aGUgY2xpZW50IHJlY2VpdmVzIGtleSBjb25maXJtYXRpb24uICBJ ZiB0aGUgY2xpZW50IGlzIHJlLXVzaW5nIHRoZSBzYW1lIHN0YXRpYyBESCBrZXksIHVzaW5nIGEg TW9udGdvbWVyeSB3aXRob3V0IHBvaW50IHZhbGlkYXRpb24sIHRoZW4gYnkgdmVyaWZ5aW5nIGtl eSBjb25maXJtYXRpb24sIHRoZSBjbGllbnQgaXMgcGFydGlhbGx5IHByb3RlY3RlZCBmcm9tIHNt YWxsLXN1Ymdyb3VwIGF0dGFja3MuICAoSSBkb24ndCBrbm93IGlmIHRoaXMgaXMgYSBrbm93biBj b3VudGVybWVhc3VyZS4pICBPciwgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KU28sIGFueXdh eSwgYW55IGluaXRpYWwgSS1EIEkgd3JpdGUgd2lsbCBsaWtlbHkgcHV0IGEgTVVTVCBvbiBwb2lu dCB2YWxpZGF0aW9uIG9mIHN0YXRpYyBESCBrZXlzLi4uDQoNCjwvREI+DQoNCg== From nobody Thu Aug 24 10:32:14 2017 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 35D371329B3 for ; Thu, 24 Aug 2017 10:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVsVl6V1jeNp for ; Thu, 24 Aug 2017 10:32:11 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FBA132969 for ; Thu, 24 Aug 2017 10:32:10 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id b189so942693wmd.0 for ; Thu, 24 Aug 2017 10:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=from:subject:date:message-id:cc:to:mime-version; bh=OtP3PrZ8lEzfZ6uLeY8/GvGYBVfJ7OzcVnxR/YgphE8=; b=GZrS5qqwdhyK+NntI2T0GtykWd08Kg1w7DAeFT4vJygOFeAFnJtbL0pN5HV/+ksJw+ kYBrLrlcaYLUwCyr9JAPTzdH8/vk9RxKMq+71h/23zHtcgCwhdbIcZwEc0f/3kb6FDyf X7hkvUwcYGz/2yoz30Mb4tBfQuRc72NKxpsdw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=OtP3PrZ8lEzfZ6uLeY8/GvGYBVfJ7OzcVnxR/YgphE8=; b=lWsoh1qjBpIgWwxB99BM8qzlFvWfFuf8iZLiH+dZc+eBrlFRwyAAySkPzgn/O3A5Hb YgUh/bAy/RCnK5w7flBZq3WQoUjRlGZzwuRyGj+lRsp9FSxZJ6qOgpGH0bY77vWk05mk v4OysM+PuJRpgkUESSqvDRMRIrISKPXLjL52iVE/bFxQ0h1Pqr33gRD9MI9aD2oOLdf6 j1R9V8EC6fiuHjOO4EFMocttDzvkpMqebUAO3qH+h08E3NneelQHJBwMkBzBmjby0afD GqXjwbHcKUWMSFEUB/oQQeqcCde5gwxaearABQe/GNJMryKi3NzhjQ687BFJrLihbDxU avgQ== X-Gm-Message-State: AHYfb5j7fC6EfLcPcppsID6ZlVL2XlA1XP/GNozrlJRMZPEarbWp3gGO KjRXDm1SVJlzd3H5MrC3bA== X-Received: by 10.28.97.11 with SMTP id v11mr3728120wmb.170.1503595928963; Thu, 24 Aug 2017 10:32:08 -0700 (PDT) Received: from aarons-macbook.home.azet.org (80-108-49-181.cable.dynamic.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id q141sm3811056wmb.11.2017.08.24.10.32.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Aug 2017 10:32:08 -0700 (PDT) From: Aaron Zauner X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_8D032E6D-921F-405B-A330-7222537CCD81"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 24 Aug 2017 19:32:10 +0200 Message-Id: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> Cc: Daniel Kahn Gillmor , Werner Koch , prz@acm.org, Moxie Marlinspike To: IRTF CFRG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 17:32:13 -0000 --Apple-Mail=_8D032E6D-921F-405B-A330-7222537CCD81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, A recent Twitter discussion [0] prompted me to look up any IETF = documents specifying "PGP word lists" [1] as in use for for short = authentication strings (SAS) in ZRTP and e.g. Signal. Apparently there's = no such document, nor any other document that concerns word-lists that = humans can easily read, say and hear/comprehend. GPG implements the ICAO = phonetic alphabet as a command line option (`--with-icao-spelling`). = This is nice, but I'd rather have a key-signing party that sounds like = drunk anthropologists than forward air controllers having fun. I've = considered a patch. As the OpenPGP WG has been "closed", I'm unsure = where to take this topic to, but CFRG seems to be a good place to ask. The original publication - as used in PGPfone - is here: = http://www.mathcs.duq.edu/~juola/papers.d/icslp96.pdf ..obviously there may be different views on how such a word-list should = look like and I'm seeking input from the crypto and UX community. I = think a standard or BCP would be nice to have. Obviously word-lists are = in use for DH without WebPKI already - even different ones, as far as I = know - but it would make sense to have a discussion on the topic. What's your opinion on the matter? Aaron [0] https://twitter.com/AaronToponce/status/900767850142380033 [1] https://en.wikipedia.org/wiki/PGP_word_list --Apple-Mail=_8D032E6D-921F-405B-A330-7222537CCD81 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZnw2cAAoJEOTbZJL9ubXVdNcP/11UUsF/6LjvbroEH3ZwoVJ6 eJ79dctz/VDIKuZ4+a6MUPwEqeVJ9orn3sEwaJfFhfnchThxHNwzl60R+7Enoe9i cv3zx/1Uaqqg+BZkw4Uiq+2gM8LIIeGlzp2I43KinFR6ARBY4cLlXy7gIkqvEFp4 FIRrJCWv7BRVKy7zOPBONJIhUcsWEHy/h7JpRapRguzRh5kXTAC0QULluQdFqNhZ LM5wkSyyghuhGcohzmUvs6mUa6N6+iJrzUffszri6Sgqpxo/dfe8etpuRMbwDuNG TXH0A/NUQGOi3XEmorShsL+u6MnKSJztPIj7DF3n1SAL4ms8t6BrNN+D7fmf4S7W VzR7v7bs9lsruA9GJ8dYfpsawAFb0xKYhuuY9CfokAFD2qiXuFs7fO+uyeTH5P/q ZKfrB9+SPcjj4ZRC0ddgDALh6eKEEXlq9mNJlt1QpJNfAtv5aAkuZqSo+I7AuguF 3uT+V1k+20yjGmBiLcpiIZiDgNhF78ZJX31DDhmbSITz3cMKbeCGuO5J0Q8nLK6J LemSEPREqLbdSthMIyLInJgqB0TiKyXpPJ9X/vQWkNfl4hkbub3OlzWKS9PzLrBF UCb5ho+D7sxsAhY0BwtOFWQKhxXU1aEzndH9UFaicVHX931eg4B/bOqKz+bC1+Dq jseQfOw0qPQTl2b5yPFA =T84L -----END PGP SIGNATURE----- --Apple-Mail=_8D032E6D-921F-405B-A330-7222537CCD81-- From nobody Thu Aug 24 13:33:38 2017 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 9C5C213235A for ; Thu, 24 Aug 2017 13:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_VtVK_foXnA for ; Thu, 24 Aug 2017 13:33:34 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6481204DA for ; Thu, 24 Aug 2017 13:33:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1dkyom-0007mr-Gv for ; Thu, 24 Aug 2017 22:33:32 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1dkyhW-0002Yr-1C; Thu, 24 Aug 2017 22:26:02 +0200 From: Werner Koch To: Aaron Zauner Cc: IRTF CFRG , Daniel Kahn Gillmor , prz@acm.org, Moxie Marlinspike References: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Date: Thu, 24 Aug 2017 22:25:55 +0200 In-Reply-To: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> (Aaron Zauner's message of "Thu, 24 Aug 2017 19:32:10 +0200") Message-ID: <87d17kpvak.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Operation_Iraqi_Freedom_Bush_Wired_event_security_PET_Bin_Laden=Alba"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:33:36 -0000 --=Operation_Iraqi_Freedom_Bush_Wired_event_security_PET_Bin_Laden=Alba Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 24 Aug 2017 19:32, azet@azet.org said: > What's your opinion on the matter? Word list are probably good for native speakers of a language but they are problematic for non-native speakers and are useless for non-speakers. We had several discussions on that topic over the last decades and the only solution we cam up with was to use the ICAO spelling. It has the advantage that not only aviation people know it but also a million or so Hams. For all other gpg has the --with-icao-spelling option ;-). Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Operation_Iraqi_Freedom_Bush_Wired_event_security_PET_Bin_Laden=Alba Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWZ82VAAKCRD/gK6dHew1 jfRKAQDeFVtEUnihvvNcURV4HlQCvO+7/BMytenuFYvKt2+YTQD9HBucGR6lHI9J ByKE73gjOuo1gQXBEuk0COVbEzktUgY= =8iSH -----END PGP SIGNATURE----- --=Operation_Iraqi_Freedom_Bush_Wired_event_security_PET_Bin_Laden=Alba-- From nobody Fri Aug 25 07:16:00 2017 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 7C344132937 for ; Fri, 25 Aug 2017 07:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-Ot_dkVMjKC for ; Fri, 25 Aug 2017 07:15:56 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4E3132932 for ; Fri, 25 Aug 2017 07:15:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id F0C60E2055; Fri, 25 Aug 2017 10:15:54 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 08491-02; Fri, 25 Aug 2017 10:15:43 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::530:248d:f760:bb62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 3CDAFE2042; Fri, 25 Aug 2017 10:15:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1503670543; bh=oifdeXSOxlbSTH2/0WokUG3vVi78bDEoD4QZndqYebg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=DQo9aXE3G12F7nHJoOT+VD2rCPHBa4I/EJlBqCLnjVSRGaUpO0NtT6yWISXM7VuA3 oU/ZozlYLaSomVt0fV0NPlU+/6Cut+nfH5N8QW881o7XWV3pHA/yLl+XzxCHAA//yz kEOiEwlhWrQMBde7gkrjEsitP4OOmzlqZajgb4Cc= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id v7PEFfNU019407; Fri, 25 Aug 2017 10:15:41 -0400 From: Derek Atkins To: Aaron Zauner Cc: IRTF CFRG , Werner Koch , prz@acm.org, Moxie Marlinspike References: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> Date: Fri, 25 Aug 2017 10:15:41 -0400 In-Reply-To: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> (Aaron Zauner's message of "Thu, 24 Aug 2017 19:32:10 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 14:15:58 -0000 Hi, Aaron Zauner writes: > Hi, > > A recent Twitter discussion [0] prompted me to look up any IETF > documents specifying "PGP word lists" [1] as in use for for short > authentication strings (SAS) in ZRTP and e.g. Signal. Apparently > there's no such document, nor any other document that concerns > word-lists that humans can easily read, say and hear/comprehend. GPG > implements the ICAO phonetic alphabet as a command line option > (`--with-icao-spelling`). This is nice, but I'd rather have a > key-signing party that sounds like drunk anthropologists than forward > air controllers having fun. I've considered a patch. As the OpenPGP > WG has been "closed", I'm unsure where to take this topic to, but CFRG > seems to be a good place to ask. Have you looked at S/Key? (RFC1760)? It's not specific to PGP, but it does give a possible mapping. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Aug 25 11:13:43 2017 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 EC8C9132977 for ; Fri, 25 Aug 2017 11:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS2vdqhJaZsw for ; Fri, 25 Aug 2017 11:13:40 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D894132962 for ; Fri, 25 Aug 2017 11:13:40 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id r203so1451726oih.0 for ; Fri, 25 Aug 2017 11:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jgdX806IicTcyiKG4Cklf0yYv/ZxIAruvMr514LW31E=; b=RhIES2yg9jx/+HEtntmwHribblRf3ZhB81ftafSSNfsYjCSS7CsaBvT/usgnEGn0bK tB53tqYGYJwydoXIUU5FYebSwvjP7LTwCpLcLJRcPq9yoUx1vx0sr5cExtiE9+mWyUvt gjiNc5W3DIqRlO+mlCIxJMLYds9nf/SkjfQC9Z97qBfAIRVEgErqX8BPBjwn9fBqlZ3l F9cllx5oVTXrcufPTRl7FnEOu9WTcXWxFDe5MhN9VBZqeecbQUQKkm56H14lJVnH0J+J LY31z0tBXXGiY9WLWBuWtRyg+Su8j2aFDm2KTc1LvExgXqRWBhNqlnt3vcL9mCWFsdwq PyAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jgdX806IicTcyiKG4Cklf0yYv/ZxIAruvMr514LW31E=; b=lWayF28CW9QJQ/iA4GxC5CE6VwupY0ki6NpsCD3eLpXrcqCtbHsdS0BF+GwQLvlAV2 WmcihkMB1s5KdzQemoCmeXQa806rRTNwEGF+FyxtiV0/YdZc0p6zc5zm6j3fFgVTlNIc ooc98eBim2Ra8hh7fOFGubJWyXol4+oJwIcVDonm7z88OipUlijgBZZK2kX3F/GF6MLt DU2gw+uKyEmsGkYCVeHf+FjTM365AtdPd317Coqw029hrpbfOADggCtVuXYuIpPJN+/U eARB/RYMdQM5GBh1RCzMZdfLlXQK1mc/8ISkhFkKrxk5R2coWKyvXP8mSax0+2g6VQhr EQ1g== X-Gm-Message-State: AHYfb5hOJP1hRvhYsncIpPb9+JRCYSOZfqr7ayYQUxf7SJD19UG8MHRX JVOl131gEhT4AySh2FjZ2KRFpx1J3A== X-Received: by 10.202.82.87 with SMTP id g84mr15259752oib.252.1503684819235; Fri, 25 Aug 2017 11:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.56.162 with HTTP; Fri, 25 Aug 2017 11:13:38 -0700 (PDT) In-Reply-To: References: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> From: Bill Cox Date: Fri, 25 Aug 2017 11:13:38 -0700 Message-ID: To: Derek Atkins Cc: Aaron Zauner , Werner Koch , prz@acm.org, IRTF CFRG , Moxie Marlinspike Content-Type: multipart/mixed; boundary="001a113d83e081ce94055797e753" Archived-At: Subject: Re: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 18:13:42 -0000 --001a113d83e081ce94055797e753 Content-Type: multipart/alternative; boundary="001a113d83e081ce90055797e751" --001a113d83e081ce90055797e751 Content-Type: text/plain; charset="UTF-8" Here's a 1024-long word list for English that I cooked up with a few hours of work. In short, the process for any language is: - Find multiple lists of the most common words in the target language - Throw away words that you feel are commonly misspelled. like forty (not fourty). - Throw away words with homophones, such as: to two too, dear deer, I eye, hear here - Throw away words with almost-homophones, such as: fifty fifteen It has uses in password reset flows where a support person is trying to help an employee who is at a loud airport using a cell phone. The list could certainly be improved, but it is a good starting point for English. Bill --001a113d83e081ce90055797e751 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's a 1024-long word list for English that I cooked= up with a few hours of work.=C2=A0 In short, the process for any language = is:

- Find multiple lists of the most common words = in the target language
- Throw away words that you feel are commo= nly misspelled. like forty (not fourty).
- Throw away words with = homophones, such as: to two too, dear deer, I eye, hear here
- Th= row away words with almost-homophones, such as: fifty fifteen

It has uses in password reset flows where a support perso= n is trying to help an employee who is at a loud airport using a cell phone= .

The list could certainly be improved, but it is = a good starting point for English.

Bill
--001a113d83e081ce90055797e751-- --001a113d83e081ce94055797e753 Content-Type: application/octet-stream; name=words Content-Disposition: attachment; filename=words Content-Transfer-Encoding: base64 X-Attachment-Id: f_j6s70tm60 YQphYmxlCmFib3V0CmFib3ZlCmFjZQphY3Jvc3MKYWN0CmFjdGlvbgphY3RpdmUKYWRkCmFmcmFp ZAphZnJpY2EKYWZ0ZXIKYWdhaW4KYWdlCmFnbwphZ3JlZQphaGVhZAphaWQKYWltCmFpcgphbGwK YWxsb3cKYWxtb3N0ZQphbG9uZQphbG9uZwphbHJlYWR5CmFsc28KYWx3YXlzCmFtCmFtb25nCmFt b3VudAphbgphbmQKYW5nbGUKYW5ncnkKYW5pbWFsCmFub3RoZXIKYW5zd2VyCmFueQphbnlvbmUK YW55dGhpbmcKYW55dGltZQphcGUKYXBwZWFyCmFwcGxlCmFyZQphcmVhCmFybQphcm15CmFyb3Vu ZAphcnJpdmUKYXJ0CmFzCmFzaAphc2sKYXQKYXR0YWNrCmF3YXkKYXhlCmJhYnkKYmFjawpiYWQK YmFnCmJhbGwKYmFuawpiYXIKYmFzZQpiYXNrZXQKYmF0CmJhdGgKYmF5CmJlYW4KYmVhcgpiZWF0 CmJlYXV0eQpiZWNhbWUKYmVjb21lCmJlZApiZWRyb29tCmJlZXIKYmVmb3JlCmJlZ2luCmJlaGF2 ZQpiZWhpbmQKYmVsbApiZWxvbmcKYmVzaWRlCmJlc3QKYmV0CmJldHRlcgpiZXR3ZWVuCmJpZApi aWcKYmlsbApiaW4KYmlyZApiaXJ0aApiaXJ0aGRheQpiaXQKYml0ZQpibGFjawpibGVlZApibG9j awpibG9vZApibG93CmJsdWUKYm9hcmQKYm9hdApib2R5CmJvaWwKYm9uZQpib29rCmJvcmRlcgpi b3JuCmJvcnJvdwpib3RoCmJvdHRsZQpib3R0b20KYm93CmJvd2wKYm94CmJveQpicmFuY2gKYnJh dmUKYnJlYWQKYnJlYWsKYnJlYWtmYXN0CmJyZWF0aApicmlkZ2UKYnJpZ2h0CmJyaW5nCmJyb2tl bgpicm90aGVyCmJyb3duCmJydXNoCmJ1ZApidWlsZApidWlsdApidW4KYnVybgpidXMKYnVzaW5l c3MKYnVzeQpidXQKY2FiCmNha2UKY2FsbApjYW1lCmNhbgpjYW5kbGUKY2FwCmNhcgpjYXJkCmNh cmUKY2FyZWZ1bApjYXJlbGVzcwpjYXJyeQpjYXNlCmNhdApjYXRjaApjYXR0bGUKY2F1c2UKY2Vs bApjZW50ZXIKY2VudHJhbApjZW50dXJ5CmNlcnRhaW4KY2hhaXIKY2hhbmNlCmNoYW5nZQpjaGFy dApjaGFzZQpjaGVhcApjaGVjawpjaGVlc2UKY2hpY2tlbgpjaGlsZApjaGlsZHJlbgpjaG9jb2xh dGUKY2hvaWNlCmNob29zZQpjaXJjbGUKY2l0eQpjbGFzcwpjbGVhbgpjbGVhcgpjbGV2ZXIKY2xp bWIKY2xvY2sKY2xvdGgKY2xvdWQKY2xvdWR5CmNvYXN0CmNvYXQKY29mZmVlCmNvaW4KY29sZApj b2xsZWN0CmNvbWUKY29tbW9uCmNvbXBhcmUKY29tcGxldGUKY29tcHV0ZXIKY29uZGl0aW9uCmNv bnRhaW4KY29udGludWUKY29udHJvbApjb29rCmNvb2wKY29wcGVyCmNvcHkKY29ybgpjb3JuZXIK Y29ycmVjdApjb3N0CmNvdHRvbgpjb3VsZApjb3VudApjb3VudHJ5CmNvdXJzZQpjb3Zlcgpjb3cK Y3Jhc2gKY3JlYXRlCmNyb3NzCmNyb3dkCmNyeQpjdXAKY3V0CmRhZApkYW5jZQpkYW5nZXIKZGFy awpkYXVnaHRlcgpkYXkKZGVhZApkZWNpZGUKZGVjcmVhc2UKZGVlcApkZXBlbmQKZGVzawpkZXN0 cm95CmRpZQpkaWZmaWN1bHQKZGlubmVyCmRpcmVjdApkaXJlY3Rpb24KZGlydHkKZGlzY292ZXIK ZGlzaApkbwpkb2N0b3IKZG9lcwpkb2cKZG9uZQpkb29yCmRvdApkb3VibGUKZG93bgpkcmF3CmRy ZWFtCmRyZXNzCmRyaW5rCmRyaXZlCmRyb3AKZHJ5CmR1Y2sKZHVyaW5nCmR1c3QKZHV0eQplYWNo CmVhcgplYXJseQplYXJuCmVhcnRoCmVhc3QKZWFzeQplYXQKZWRnZQplZHVjYXRlCmVnZwplaWdo dAplaXRoZXIKZWxlY3RyaWMKZWxlcGhhbnQKZWxmCmVsc2UKZW1wdHkKZW5kCmVuZW15CmVuZXJn eQplbmpveQplbm91Z2gKZW50ZXIKZW50cmFuY2UKZXF1YWwKZXNjYXBlCmV2ZW4KZXZlbmluZwpl dmVudApldmVyCmV2ZXJ5CmV2ZXJ5Ym9keQpldmVyeW9uZQpleGFjdApleGFtaW5lCmV4YW1wbGUK ZXhjaXRlZApleGVyY2lzZQpleHBlY3QKZXhwZW5zaXZlCmV4cGxhaW4KZXh0cmVtZQpmYWNlCmZh Y3QKZmFpbApmYWlyCmZhbGwKZmFsc2UKZmFtaWx5CmZhbW91cwpmYW4KZmFyCmZhcm0KZmFzdApm YXQKZmF0aGVyCmZhdWx0CmZlYXIKZmVlZApmZWVsCmZlZXQKZmVsbApmZWx0CmZlbWFsZQpmZXZl cgpmZXcKZmllbGQKZmlnaHQKZmlndXJlCmZpbGwKZmlsbQpmaW5kCmZpbmUKZmluZ2VyCmZpbmlz aApmaXJlCmZpcnN0CmZpc2gKZml0CmZpdmUKZml4CmZsYWcKZmxhdApmbG9hdApmbG9vcgpmbG93 CmZseQpmb2cKZm9sZApmb2xsb3cKZm9vZApmb29sCmZvb3QKZm9vdGJhbGwKZm9yY2UKZm9yZWln bgpmb3Jlc3QKZm9yZ2V0CmZvcmdpdmUKZm9yawpmb3JtCmZvdW5kCmZveApmcmVlCmZyZWVkb20K ZnJlZXplCmZyZXNoCmZyaWVuZApmcmllbmRseQpmcm9tCmZyb250CmZydWl0CmZyeQpmdWxsCmZ1 bgpmdW5ueQpmdXJuaXR1cmUKZnVydGhlcgpmdXR1cmUKZ2FtZQpnYXJkZW4KZ2FzCmdhdGUKZ2F2 ZQpnZW5lcmFsCmdldApnaWZ0CmdpcmwKZ2l2ZQpnbGFkCmdsYXNzCmdvCmdvYXQKZ29kCmdvbGQK Z29vZApnb29kYnllCmdvdApncmFzcwpncmF2ZQpncmVhdApncmVlbgpncmV3Cmdyb3VuZApncm91 cApncm93Cmd1ZXNzCmd1bgpndXQKZ3V5CmhhZApoYWlyCmhhbGYKaGFsbApoYWx0CmhhbQpoYW1t ZXIKaGFuZApoYXBwZW4KaGFwcHkKaGFyZApoYXMKaGF0CmhhdGUKaGF2ZQpoZQpoZWFkCmhlYWx0 aHkKaGVhcgpoZWFydApoZWF0CmhlYXZlbgpoZWF2eQpoZWlnaHQKaGVsZApoZWxsbwpoZWxwCmhl bgpoZXIKaGVycwpoaWRlCmhpbGwKaGltCmhpcwpoaXQKaG9iYnkKaG9sZApob2xlCmhvbGlkYXkK aG9tZQpob3AKaG9wZQpob3JzZQpob3NwaXRhbApob3QKaG90ZWwKaG91cgpob3VzZQpob3cKaHVn ZQpodW0KaHVtYW4KaHVuZHJlZApodW5ncnkKaHVycnkKaHVydApodXNiYW5kCmljZQppZGVhCmlm CmltcG9ydGFudAppbgppbmNoCmluY3JlYXNlCmluawppbnNpZGUKaW50bwppbnRybwppbnZlbnQK aW52aXRlCmlyb24KaXMKaXNsYW5kCml0Cml0c2VsZgppdnkKamFyCmphdwpqZWxseQpqb2IKam9p bgpqdWljZQpqdW1wCmp1c3QKa2VlcAprZXkKa2lkCmtpbGwKa2luZApraW5nCmtpdGNoZW4Ka25l ZQprbmlmZQprbm9jawpsYWRkZXIKbGFkeQpsYWtlCmxhbXAKbGFuZApsYXAKbGFyZ2UKbGFzdAps YXRlCmxhdGVyCmxhdWdoCmxhdwpsYXp5CmxlYWYKbGVhcm4KbGVhc3QKbGVhdmUKbGVmdApsZWcK bGVuZApsZW5ndGgKbGVzcwpsZXNzb24KbGV0CmxldHRlcgpsaWJyYXJ5CmxpZQpsaWZlCmxpZ2h0 Cmxpa2UKbGluZQpsaW9uCmxpcApsaXN0Cmxpc3RlbgpsaXR0bGUKbGl2ZQpsb2NrCmxvZwpsb25n Cmxvb2sKbG9zZQpsb3N0CmxvdApsb3ZlCmxvdwpsb3dlcgpsdWNrCm1hY2hpbmUKbWFkCm1hZGUK bWFpbgptYWpvcgptYWtlCm1hbGUKbWFuCm1hbnkKbWFwCm1hcmNoCm1hcmsKbWFya2V0Cm1hdApt YXRjaAptYXR0ZXIKbWF5Cm1heWJlCm1lCm1lYWwKbWVhbgptZWFzdXJlCm1lZGljaW5lCm1lbWJl cgptZW50aW9uCm1ldGFsCm1ldGhvZAptaWRkbGUKbWlsawptaWxsaW9uCm1pbmQKbWluZQptaW51 dGUKbWlzcwptaXN0YWtlCm1peAptb2RlbAptb2Rlcm4KbW9tZW50Cm1vbmV5Cm1vbmtleQptb250 aAptb29kCm1vb24KbW9wCm1vcmUKbW9ybmluZwptb3N0Cm1vdGhlcgptb3VudGFpbgptb3V0aApt b3ZlCm11Y2gKbXVzaWMKbXVzdApteQpuYW1lCm5hcApuYXJyb3cKbmF0aW9uCm5hdHVyZQpuZWFy Cm5lY2sKbmVlZApuZWVkbGUKbmVpdGhlcgpuZXQKbmV2ZXIKbmV3Cm5ld3MKbmV4dApuaWNlCm5p Z2h0Cm5pbmUKbm9ibGUKbm9pc2UKbm9uZQpub3J0aApub3NlCm5vdGhpbmcKbm90aWNlCm5vdW4K bm93Cm51bWJlcgpvYWsKb2JqZWN0Cm9jZWFuCm9kZApvZgpvZmYKb2ZmZXIKb2ZmaWNlCm9mdGVu Cm9pbApvbGQKb24Kb25jZQpvbmx5Cm9wZW4Kb3JhbmdlCm9yZGVyCm90aGVyCm91dApvdXRzaWRl Cm92ZXIKb3duCnBhZ2UKcGFpbgpwYWludApwYWlyCnBhbgpwYXBlcgpwYXJlbnQKcGFyawpwYXJ0 CnBhcnRuZXIKcGFydHkKcGFzcwpwYXN0CnBhdGgKcGF5CnBlbgpwZW5jaWwKcGVvcGxlCnBlcHBl cgpwZXJmZWN0CnBlcmlvZApwZXJzb24KcGhvdG8KcGlhbm8KcGljawpwaWN0dXJlCnBpZwpwaW4K cGluawpwbGFjZQpwbGFudApwbGFzdGljCnBsYXRlCnBsYXkKcGxlYXNlCnBsZW50eQpwb2NrZXQK cG9pbnQKcG9saWNlCnBvbGl0ZQpwb29sCnBvb3IKcG9wdWxhcgpwb3NpdGlvbgpwb3NzaWJsZQpw b3dlcgpwcmVzZW50CnByZXNzCnByZXR0eQpwcmV2ZW50CnByaWNlCnByaW5jZQpwcmlzb24KcHJp dmF0ZQpwcml6ZQpwcm9ibGVtCnByb2R1Y2UKcHJvbWlzZQpwcm9wZXIKcHJvdGVjdApwcm92aWRl CnB1YmxpYwpwdWxsCnB1bmlzaApwdXNoCnB1dApxdWVlbgpxdWVzdGlvbgpxdWljawpyYWRpbwpy YWluCnJhaW55CnJlYWNoCnJlYWR5CnJlYWwKcmVhbGx5CnJlY29yZApyZW1lbWJlcgpyZW1pbmQK cmVtb3ZlCnJlbnQKcmVwYWlyCnJlcGVhdApyZXBseQpyZXBvcnQKcmVzdWx0CnJldHVybgpyaWNl CnJpY2gKcmlkZQpyaW5nCnJpc2UKcm9hZApyb2IKcm9jawpyb29tCnJvdW5kCnJ1YmJlcgpydWRl CnJ1bGUKcnVuCnJ1c2gKc2FkCnNhZmUKc2FpbApzYWx0CnNhbWUKc2FuZApzYXZlCnNheQpzY2hv b2wKc2NpZW5jZQpzZWFyY2gKc2VhdApzZWNvbmQKc2VlbQpzZWxsCnNlbmQKc2VydmUKc2V2ZW4K c2V2ZXJhbApzaGFkZQpzaGFkb3cKc2hha2UKc2hhcGUKc2hhcmUKc2hhcnAKc2hlCnNoZWVwCnNo ZWV0CnNoZWxmCnNoaW5lCnNoaXAKc2hpcnQKc2hvZQpzaG9vdApzaG9wCnNob3J0CnNob3VsZApz aG91dApzaG93CnNpZGUKc2lnbmFsCnNpbGVuY2UKc2lsbHkKc2lsdmVyCnNpbWlsYXIKc2ltcGxl CnNpbmNlCnNpbmcKc2luZ2xlCnNpbmsKc2lzdGVyCnNpdApzaXgKc2l6ZQpza2lsbApza2luCnNr aXJ0CnNreQpzbGVlcApzbGlwCnNsb3cKc21hbGwKc21lbGwKc21pbGUKc21va2UKc25vdwpzbwpz b2FwCnNvY2sKc29mdApzb21lCnNvbWVvbmUKc29tZXRoaW5nCnNvbWV0aW1lcwpzb29uCnNvcnJ5 CnNvdW5kCnNvdXAKc291dGgKc3BhY2UKc3BlYWsKc3BlY2lhbApzcGVlZApzcGVsbApzcGVuZApz cG9vbgpzcG9ydApzcHJlYWQKc3ByaW5nCnNxdWFyZQpzdGFtcApzdGFuZApzdGFyCnN0YXJ0CnN0 YXRpb24Kc3RheQpzdGVhbQpzdGVwCnN0aWxsCnN0b25lCnN0b3AKc3RvcmUKc3Rvcm0Kc3RvcnkK c3RvdmUKc3RyYW5nZQpzdHJlYW0Kc3RyZWV0CnN0cmluZwpzdHJvbmcKc3R1ZGVudApzdHVkeQpz dWJqZWN0CnN1YnN0YW5jZQpzdWNjZXNzCnN1Y2gKc3VkZGVuCnN1Z2FyCnN1aXRhYmxlCnN1bW1l cgpzdW5ueQpzdXBwb3J0CnN1cmUKc3VycHJpc2UKc3dlZXQKc3dpbQpzd29yZAp0YWJsZQp0YWtl CnRhbGsKdGFsbAp0YXN0ZQp0YXhpCnRlYWNoCnRlYW0KdGVhcgp0ZWxlcGhvbmUKdGVsbAp0ZW4K dGVubmlzCnRlcm0KdGVycmlibGUKdGVzdAp0aGFuCnRoYXQKdGhlCnRoZW4KdGhlcmVmb3JlCnRo ZXNlCnRoaWNrCnRoaW4KdGhpbmcKdGhpbmsKdGhpcmQKdGhpcwp0aG91Z2gKdGhyZWF0CnRocmVl CnRpZHkKdGllCnRpdGxlCnRvZGF5CnRvZ2V0aGVyCnRvbGQKdG9uaWdodAp0b29rCnRvb2wKdG9v dGgKdG9wCnRvdGFsCnRvdWNoCnRvd24KdHJhaW4KdHJhdmVsCnRyZWUKdHJvdWJsZQp0cnVlCnRy dXN0CnRyeQp0dXJuCnR3aWNlCnR5cGUKdWdseQp1bmNsZQp1bmRlcgp1bml0CnVudGlsCnVwCnVz ZQp1c2VmdWwKdXN1YWwKdXN1YWxseQp2ZWdldGFibGUKdmVyeQp2aWxsYWdlCnZpc2l0CnZvaWNl Cndha2UKd2Fsawp3YW50Cndhcm0Kd2FzCndhc2gKd2FzdGUKd2F0Y2gKd2F0ZXIKd2UKd2Vhcgp3 ZWF0aGVyCndlZGRpbmcKd2VsY29tZQp3ZWxsCndlc3QKd2V0CndoYXQKd2hlZWwKd2hlbgp3aGVy ZQp3aGljaAp3aGlsZQp3aGl0ZQp3aG8Kd2h5CndpZGUKd2lmZQp3aWxkCndpbGwKd2luCndpbmQK d2luZG93CndpbmUKd2luZwp3aW50ZXIKd2lyZQp3aXNlCndpc2gKd2l0aAp3b21hbgp3b25kZXIK d29vZAp3b3JkCndvcmsKd29ybGQKd29ycnkKeWFyZAp5ZWFyCnllbGwKeWV0CnlvdQp5b3VuZwp6 ZXJvCnpvbwo= --001a113d83e081ce94055797e753-- From nobody Fri Aug 25 15:14:57 2017 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 62805132BC6 for ; Fri, 25 Aug 2017 15:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57BaWsWn63JN for ; Fri, 25 Aug 2017 15:14:53 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153C0132C6F for ; Fri, 25 Aug 2017 15:14:49 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id j189so3451115vka.0 for ; Fri, 25 Aug 2017 15:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q5J2QWa636HsNzOk0byZt1r7bHY3J4n2D63zT70CNfM=; b=MwmmYjiEmmhaagkVTgxIe7N4bUbuzKhPbhZ2LyCmrWSlV+GoN+jhdeVrc9Wml6Hw1V Sh8U7I68yjn/SeIElLPOTM0AJ0ssuyGZSTVSeASAXQuK85YtizE0K0Mvc2Vw9Q9KV/vw DRuTBnVoyPEdPbmwGXpxNhFgBpOl6Rm9EuktvBBJWuz7IiP2/APEDLWV8qIJJHm/5hGa OsnBxf7Ft3um/ERCdMqg63hO/eJDBTagZ89RNnRKTk5yfmUI9Sw4CFxJtV/bauzeYPm6 oq+7s5B+j25tfoPcC0VXw9LqRipmC6Gv9F6birpeGFP63LkhzVT+3c8WonnRloqBiFtr r1Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q5J2QWa636HsNzOk0byZt1r7bHY3J4n2D63zT70CNfM=; b=JT3GB9WCA1E6RIDrXRwhvv6QOrMWkHN5qoox7e37Ka9NN8Hrjo7PrDTxqTQYtdoUql u95tMqKfZC3B8gZgcD1t9f23i0jMpi+zOxV1Rt2KT58GBiE45dgZ1c/IJfwQTZ+vHCn9 JOGh0/lWe2Z4XJuQC2vV73Ud4ahCwtFjNklsRnVBs85qDPpAizTMJcBZ1osmZ3tj9S/y OFjhTMdPfS036Gi2MC7fjjvdnCqXx20XS4v983yQWAREls+VVbYYp9EgqzNA5ECLhzsI 1/MWy0pIugv16V7I7Wy8eDEKWCaGTA7Wsl1+0XS4aNqfq54oV6JVD7T1NWuNKlfQ1TvU IfoA== X-Gm-Message-State: AHYfb5iFph40Xz0Z9i+dKONnxlMeFUBY43txAzYPI4yVzro5qImWcT5I H24Pzp6MGXYHkn0hApJu0VNcJby7ng== X-Received: by 10.31.98.67 with SMTP id w64mr7011939vkb.108.1503699288027; Fri, 25 Aug 2017 15:14:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.18.67 with HTTP; Fri, 25 Aug 2017 15:14:27 -0700 (PDT) In-Reply-To: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> References: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> From: Tony Arcieri Date: Fri, 25 Aug 2017 15:14:27 -0700 Message-ID: To: Aaron Zauner Cc: IRTF CFRG , Werner Koch , prz@acm.org, Moxie Marlinspike Content-Type: multipart/alternative; boundary="94eb2c096050e97b7c05579b4514" Archived-At: Subject: Re: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 22:14:55 -0000 --94eb2c096050e97b7c05579b4514 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 24, 2017 at 10:32 AM, Aaron Zauner wrote: > A recent Twitter discussion [0] prompted me to look up any IETF documents > specifying "PGP word lists" [1] as in use for for short authentication > strings (SAS) in ZRTP and e.g. Signal. Apparently there's no such document, > nor any other document that concerns word-lists that humans can easily > read, say and hear/comprehend. > I've found this to be an excellent resource for comparing various wordlists and the quality of passwords or other authentication phrases generated from them: https://ae7.st/g/ > What's your opinion on the matter? I am a big fan of this approach. See this video for some of my work (warning: turn your wound down): https://www.youtube.com/watch?v=BAeJsskGHsQ That said I'm not sure it's a CFRG-relevant topic... On Thu, Aug 24, 2017 at 1:25 PM, Werner Koch wrote: > Word list are probably good for native speakers of a language but they > are problematic for non-native speakers and are useless for > non-speakers. The obvious (to me, at least) solution to this is language-localized wordlists. It compounds the problem, and requires native speakers of each language to curate good word lists, but I don't think the problem is intractable. -- Tony Arcieri --94eb2c096050e97b7c05579b4514 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 24, 2017 at 10:32 AM, Aaron Zauner <azet@azet.org> wrote= :
A recent Twitter dis= cussion [0] prompted me to look up any IETF documents specifying "PGP = word lists" [1] as in use for for short authentication strings (SAS) i= n ZRTP and e.g. Signal. Apparently there's no such document, nor any ot= her document that concerns word-lists that humans can easily read, say and = hear/comprehend.

I've found this to= be an excellent resource for comparing various wordlists and the quality o= f passwords or other authentication phrases generated from them:
=
=C2=A0
What's your opinion on the matter?

I am= a big fan of this approach. See this video for some of my work (warning: t= urn your wound down):=C2=A0https://www.youtube.com/watch?v=3DBAeJsskGHsQ

<= /div>
That said I'm not sure it's a CFRG-relevant topic...

On Thu, Aug 24, 2017 at 1:25 PM, Werner Koch=C2=A0<wk@gnup= g.org>=C2=A0wrote:
Word list are probably good for native speakers of a language bu= t they
are problematic for non-native speakers and are useless for
no= n-speakers.

The obvious (to me, at least) s= olution to this is language-localized wordlists. It compounds the problem, = and requires native speakers of each language to curate good word lists, bu= t I don't think the problem is intractable.

<= /div>--
Tony Arcieri
--94eb2c096050e97b7c05579b4514-- From nobody Mon Aug 28 15:49:04 2017 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 77EEC13213D for ; Mon, 28 Aug 2017 15:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fb7AizVjugS for ; Mon, 28 Aug 2017 15:48:59 -0700 (PDT) Received: from mail.iiec.unam.mx (mail.iiec.unam.mx [132.248.241.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAF21321C9 for ; Mon, 28 Aug 2017 15:48:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iiec.unam.mx (Postfix) with ESMTP id 22422177651; Mon, 28 Aug 2017 17:48:57 -0500 (CDT) Received: from mail.iiec.unam.mx ([127.0.0.1]) by localhost (mail.local.iiec [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtP_NXMHzYUh; Mon, 28 Aug 2017 17:48:56 -0500 (CDT) Received: from v.gwolf.org (unknown [132.248.72.123]) by mail.iiec.unam.mx (Postfix) with ESMTP id C5ED5177404; Mon, 28 Aug 2017 17:48:55 -0500 (CDT) Received: by v.gwolf.org (Postfix, from userid 1000) id 641B028A9A; Mon, 28 Aug 2017 17:48:55 -0500 (CDT) Date: Mon, 28 Aug 2017 17:48:55 -0500 From: Gunnar Wolf To: Bill Cox Cc: Derek Atkins , prz@acm.org, Moxie Marlinspike , IRTF CFRG , Werner Koch Message-ID: <20170828224854.7jf6rywiwzyf5vqp@gwolf.org> References: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 22:49:01 -0000 Bill Cox dijo [Fri, Aug 25, 2017 at 11:13:38AM -0700]: > Here's a 1024-long word list for English that I cooked up with a few hours > of work. In short, the process for any language is: > (...) > It has uses in password reset flows where a support person is trying to > help an employee who is at a loud airport using a cell phone. > > The list could certainly be improved, but it is a good starting point for > English. ...Of course, a sensible workflow whenever possible is just to stay away from English for any uses that need to be the least bit phonetic. From nobody Tue Aug 29 07:23:38 2017 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 46B6E132CF8 for ; Tue, 29 Aug 2017 07:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiOUoLHDBHov for ; Tue, 29 Aug 2017 07:23:34 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECCE132C4C for ; Tue, 29 Aug 2017 07:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7TENUjE004049 for ; Tue, 29 Aug 2017 16:23:30 +0200 (CEST) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xhW8L41gWzDLpy for ; Tue, 29 Aug 2017 16:23:30 +0200 (CEST) Received: by mail-io0-f177.google.com with SMTP id s101so20367662ioe.0 for ; Tue, 29 Aug 2017 07:23:30 -0700 (PDT) X-Gm-Message-State: AHYfb5iEE+Zq3O9LgVN8JfVhl48fUmdo6VIyUs/SGCjVSV7DQQq0EbfV dF4UEewL2h6uCWaJ0U+qZiwzQnY6Yw== X-Received: by 10.36.204.6 with SMTP id x6mr2268592itf.108.1504016609257; Tue, 29 Aug 2017 07:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.15.211 with HTTP; Tue, 29 Aug 2017 07:22:48 -0700 (PDT) From: Klaus Hartke Date: Tue, 29 Aug 2017 16:22:48 +0200 X-Gmail-Original-Message-ID: Message-ID: To: cfrg@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cfrg] draft-irtf-cfrg-argon2: PBKDF2-params? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 14:23:36 -0000 Hi all, does Argon2 have an equivalent to Section 7 of RFC 7914 [1]? Would it make sense to add it to draft-irtf-cfrg-argon2 [2]? Klaus [1] https://tools.ietf.org/html/rfc7914#section-7 [2] https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03 From nobody Tue Aug 29 22:01:44 2017 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 CBE901321A7 for ; Tue, 29 Aug 2017 22:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm3NSXY0ruOI for ; Tue, 29 Aug 2017 22:01:41 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D310E132144 for ; Tue, 29 Aug 2017 22:01:40 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id m85so65078wma.0 for ; Tue, 29 Aug 2017 22:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ockPMHSexs8DOBVQtBXYgDGqlqBbSCKRLieFWM0EfUc=; b=Hsp9ETAK0PjoBSfH3ceY6Rw3wTBa2/mXvzLUGUsQOC1Jr/sbmP2BvbOL/zZx1yKyzE tUbOVmo+SlQYjIPOuvFdhWfjS2FHV3QGVQ0eVXbbEQFTRy1ApmrxRaccHutM3qqdwD8l e0rw664IgZZnOoj9F0MlXZbong/4y2QVDMfuIiy/Gw1jGv61Izs5VIhoGSFJkQ/yQDsH tkEF3V+F6DW++7PA2QlOJuDlj6tf9Sg/gQrCdNN1ZjgmYKBKIgeDRADtcL2y5GsFh4Xb UpIzssJGkCH/xXtXl5GNzc8fwuSHHrbWGPtf+G+90vRYrt5iTILtz7XklTqHcePHappu aLiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ockPMHSexs8DOBVQtBXYgDGqlqBbSCKRLieFWM0EfUc=; b=dpQd50mjnFmwhCWRB4KEcmKM1NSTaLcsQqsDoLju+Dld3hXaTsgMy8YaGmawpvDXKe 55isASo19+4My4vwr9UAFsNAn/3l8It9JeGcx0QiTYZDYx2YTtKHc097UOGMxcpTIwM2 VrOqhrsS1x02XWHglN8BKaflJX2B301pvkOm7yeysA9fYOmZoHtpyRewangGpac6qJVb X1Q0tp7HDSGXEHL60NiglFm7sVdX+mB34U0eeb9e6Pg4beUZe0HfH+V1l9oCo3bPvLWe 3ELRP1L+MJNkEh1Bh6BUAJoIVqunXR1ooTgrJFfpxApN25J4DYvHGJFVTKRNe7CO9zkc lG+w== X-Gm-Message-State: AHYfb5hihgIaEYTqmEXvvqCkNhn3J8puRmtrzKE96KTaXrKFnlXkaxbu fL4u7nH9BBcLoQ== X-Received: by 10.80.220.200 with SMTP id v8mr621601edk.182.1504069299281; Tue, 29 Aug 2017 22:01:39 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m14sm2140626edl.97.2017.08.29.22.01.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 22:01:38 -0700 (PDT) From: Yoav Nir Message-Id: <08A18D2C-794D-4272-9DF3-5F1FB449D5F5@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_51BC1707-9162-4685-B58D-17E727FBC2B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 08:01:35 +0300 In-Reply-To: Cc: Derek Atkins , prz@acm.org, Moxie Marlinspike , IRTF CFRG , Werner Koch To: Bill Cox References: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 05:01:43 -0000 --Apple-Mail=_51BC1707-9162-4685-B58D-17E727FBC2B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why not re-use the list of words from appendix A of RFC 1751? > On 25 Aug 2017, at 21:13, Bill Cox wrote: >=20 > Here's a 1024-long word list for English that I cooked up with a few = hours of work. In short, the process for any language is: >=20 > - Find multiple lists of the most common words in the target language > - Throw away words that you feel are commonly misspelled. like forty = (not fourty). > - Throw away words with homophones, such as: to two too, dear deer, I = eye, hear here > - Throw away words with almost-homophones, such as: fifty fifteen >=20 > It has uses in password reset flows where a support person is trying = to help an employee who is at a loud airport using a cell phone. >=20 > The list could certainly be improved, but it is a good starting point = for English. >=20 > Bill > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_51BC1707-9162-4685-B58D-17E727FBC2B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZpkawAAoJELhJCxUKWMyZ+u0H/AmYQ6JBQnd7YZB9w/VRgP8L o13udS9uUEIprsX4MNeThtpnjB+kcG5zb5SvObSJHUkiEnG1R5eH8bDxXi59azCp hG7ngFYUuH5HVvVw64YsHYWDoJ/Y6c+9jGMe0YZz78yun+G5NLv1fDqtMBs9OJtG Qn6V58vt8uaHcDKLkSHNtaM0e/QYdzOKBAtOOaIeHNGudCX0SdjaCuadJKwbovpE rSCliF2V3urD6etXxliA3KrTK1PkmJiRw0xN6WQCwnLFzFuhsipx1Cwc5l25fm4A HPUAZJlQGNrM8jaUQd4ezDa7f280O4+hqu7nkx4CGVk6kvBp6tsIQmmNUOB2BiA= =7hBl -----END PGP SIGNATURE----- --Apple-Mail=_51BC1707-9162-4685-B58D-17E727FBC2B0-- From nobody Tue Aug 29 22:24:23 2017 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 55AEA132144 for ; Tue, 29 Aug 2017 22:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukGbBCC96URs for ; Tue, 29 Aug 2017 22:24:21 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B5213201E for ; Tue, 29 Aug 2017 22:24:21 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id g11so16011580uah.2 for ; Tue, 29 Aug 2017 22:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B+8rXl8x8RU4+Rb2FCZZDYJUp/5p0Y8JXARJfSU34k0=; b=UCv0vRCOCRyMWc5GvosDCJ60PnR4UPRtQoYv7b7CPILDpBsqdwO/qgCXyawQopZ/2r t82yQyAcK7EzohdxiMnaxilXAR89i7t4XkuXCldxoYups3Xr5IllsYzPvC1yIO3/XaEt QZ4wxrzivDf5UcUeAcgDFOQmTLGGwZrXb5nBkhZkAQk8YEYxCdTDa8pR4LhiSKQ4ALOA aYw3oZZkClzbIO8P9XupiZz9O5erpBv3h/89LFqofMJ84+hy4BfG1YvvgGHYMPEY189i D3OTZXpVlF3PUKSYk4r/34+3xhbmWZS3yu3bgiDfBhpA6vtcs3ASNQHtX3fsr/P/yOqX 0dWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B+8rXl8x8RU4+Rb2FCZZDYJUp/5p0Y8JXARJfSU34k0=; b=UxNAQNg9n4HxOtW9ep3P9sZEOzARWndrbmx53osZ0oYzYRJ/Os+AgeJgaBvc+iKY7F pV6SMCbt554KvheUtm0Ffjoz0sEcSY1xKi94NHXQxVLLvLoT3+8aPAcopEk4PYlUIDhs AzPuu6fD8R2aBXDvjSMk5Ejm0NwA9hJ3C3ZNQGK4UdQd6kai2cn8EfdY49CjHGjHQG6F fL70J9x7WEiNsaENz33kRq3PNQYmEE01rb4Y9uvulPFsQYVx6Spcx5nY6hA2h6P+wSPg OMB7PlAIBCaaFPmnM611p8iZzFCNOQHsp72dtKLhK4PL7a02QSD5wSkzIz0j73sTOMTC lL7g== X-Gm-Message-State: AHYfb5hn2Pz+vuUaSdPXD+MU9LhKSmITqWweemhsGPRJF37drgN/F/d5 4sBrpo0u/QhVh3GiTJxZJRgXcLd30g== X-Google-Smtp-Source: ADKCNb4704ChbajL/IMvg+s5iw2VEXkkzEd05Sqw4Ia6LRd3Pv8bjitlcFgvdMZNFJAMy9I7itjZL3QXLCqGAJ1LRGs= X-Received: by 10.176.65.230 with SMTP id 93mr208634uap.187.1504070660647; Tue, 29 Aug 2017 22:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.18.67 with HTTP; Tue, 29 Aug 2017 22:24:00 -0700 (PDT) In-Reply-To: <08A18D2C-794D-4272-9DF3-5F1FB449D5F5@gmail.com> References: <23B4CF16-6E26-4674-B128-DCB3FCC5A97F@azet.org> <08A18D2C-794D-4272-9DF3-5F1FB449D5F5@gmail.com> From: Tony Arcieri Date: Tue, 29 Aug 2017 22:24:00 -0700 Message-ID: To: Yoav Nir Cc: Bill Cox , IRTF CFRG , prz@acm.org, Werner Koch , Moxie Marlinspike Content-Type: multipart/alternative; boundary="001a114ea68871f1f70557f1bd11" Archived-At: Subject: Re: [Cfrg] Word-lists for Diffie-Hellman and Fingerprints X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 05:24:23 -0000 --001a114ea68871f1f70557f1bd11 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 29, 2017 at 10:01 PM, Yoav Nir wrote: > Why not re-use the list of words from appendix A of RFC 1751? I can't give a concrete answer, however as someone who's a bit obsessive about comparing various wordlists, granted in an entirely ad hoc way of generating random samples and making a more or less ad hoc judgement about how often I was presented random samples I liked, I really like the EFF's (English) wordlist, and am not a super big fan of RFC 1751. Granted that's a completely non-quantitative opinion, more like one based in aesthetics. I'm sure YMMV... -- Tony Arcieri --001a114ea68871f1f70557f1bd11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 29, 2017 at 10:01 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Why not re-use the list of word= s from appendix A of RFC 1751?

I can't = give a concrete answer, however as someone who's a bit obsessive about = comparing various wordlists, granted in an entirely ad hoc way of generatin= g random samples and making a more or less ad hoc judgement about how often= I was presented random samples I liked, I really like the EFF's (Engli= sh) wordlist, and am not a super big fan of RFC 1751. Granted that's a = completely non-quantitative opinion, more like one based in aesthetics. I&#= 39;m sure YMMV...

--
Tony Arcieri
--001a114ea68871f1f70557f1bd11--