Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1C61A009B for ; Wed, 28 Jan 2015 06:14:48 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 Chugyx1bFjSD for ; Wed, 28 Jan 2015 06:14:44 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748D31A0084 for ; Wed, 28 Jan 2015 06:14:44 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp4so19271612obc.1 for ; Wed, 28 Jan 2015 06:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OKMIveEvMHLGAyRZmNslNJNlReuoTPIq/D544A7DC8I=; b=FtCQdltKAiCXeGPPBymDooVbnYCJPxdleTJhqwlr9xZuayhyFh8HUbpKaT9iP+staa YklOt9xEYi/VGSnq/+/BI27+RJ+xXywoqw2kUd2Xuna6PqPj+cGO5ws7BDeWgq+TS8TE FE6yWtIm32F3+rtwgMjy6liyACXkt+RybXfNwTSw9HFvHSslXB6ZYuKjsMbwowC+OQmb JGMnJGKthsAZsLwDFE0il76mFkLq8RDEJrw3SfGN8jcRoWgrpxUn+DTNiiEocsV6Un99 Vm6MAIxY96zs2ssjeDKAa5Ot2d6N8d9yf69y1eWWCaw8c3ApiIVa5tiDrfvUsjC6JL6k Tzkg== MIME-Version: 1.0 X-Received: by 10.182.18.66 with SMTP id u2mr2201784obd.33.1422454483574; Wed, 28 Jan 2015 06:14:43 -0800 (PST) Received: by 10.182.5.103 with HTTP; Wed, 28 Jan 2015 06:14:43 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 18:14:43 +0400 Message-ID: From: "Stanislav V. Smyshlyaev" To: Alyssa Rowan , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a11c2bda833e4a7050db6fe1f Archived-At: Subject: Re: [Cfrg] 512-bit twisted Edwards curve and curve generation methods in Russian standardization X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 14:14:48 -0000 --001a11c2bda833e4a7050db6fe1f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Alyssa, As we believe (and as it has been mentioned earlier during discussion at CFRG), the initital seed value doesn't have to be chosen explicitly in case of trust in basic hash function properties =E2=80=93 to gain some "backdoor= -type" properties of the curve with d =3D hash(W), one has either to combine such algebraic properties of a curve with properties of a hash function (for a trivial example, to have an ability to obtain a hash preimage) or to choose a very probable "backdoor-type" property of a curve (such that it is possible to obtain by random choice of a curve). We believe that there really cannot be a higher level of "proven randomness" than using d with a known hash preimage (regarding to properties of hash function, of course). The only one option to get a "backdoored" curve with our method that I understand is the existence of some large publicly unknown class of "bad" ("backdoored", subverted) curves. But if such a class exists, who can guarantee that any of your generated curves doesn't belong to this class?.. P.S.: Nevertheless, for that exact twisted Edwards curve we have also a preimage value of first 512 bits of W (we did this only to organize process of candidate curve generation in parallel, without too much need also though), but I had to mention this (pretty useless) fact. Best regards, Stanislav V. Smyshlyaev, Ph.D., Head of Information Security Department, CryptoPro LLC 2015-01-28 16:28 GMT+03:00 Alyssa Rowan : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 27 January 2015 15:57:40 GMT+00:00, "=D0=A1=D1=82=D0=B0=D0=BD=D0=B8=D1= =81=D0=BB=D0=B0=D0=B2 =D0=A1=D0=BC=D1=8B=D1=88=D0=BB=D1=8F=D0=B5=D0=B2" < > smyshsv@gmail.com> wrote: > > >The curve parameters have been generated using random nonce W in such wa= y > that e =3D 1, d =3D hash(W), where hash() is Russian national standard GO= ST R > 34.11-2012 hash function (also known as =E2=80=9CStreebog=E2=80=9D, > https://www.streebog.net/en/). The seed value W is equal to: > >W =3D 1F BB 79 69 B9 1B 3E A0 81 17 FB 10 74 BF BF 55 49 DD 66 07 63 F6 = A5 > AF 09 57 77 5B 66 4C B1 13 CF CB 91 C4 A7 7D 27 98 06 BC F2 4A 56 77 F2 5= E > AF FE C6 67 76 70 2E E2 C7 AA 84 16 07 50 DA 1D D1 50 AE D2 8C 30 26 AC 7= E > D6 D1 9B 97 AC 2C B5 82 7C 00 03 18 47 13 53 5B FA 65 24 B3 E4 60 83, > > ...and the million-rouble question, if I may be the first to ask: > > How was that seed W generated, and under what criteria? > > There is now a strong preference for open curve generation processes whos= e > criteria are all explicitly shown, chosen for clearly-defined "rigid" > reasons, and whose generation can be replicated and verified. > > I can't see the procedure you show here has that property, due to the > unexplained seed; a property it shares with the US standard NIST curves > we've been asked to replace, so I'm not too sure as to the merits of your > curve? > > - -- > /akr > -----BEGIN PGP SIGNATURE----- > Version: APG v1.1.1 > > iQI3BAEBCgAhBQJUyOPlGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE > jtkWi2t6rbAP/0/Cz+7r1IIf8spVLUVeAxtrgdsuKvtRt6Dpz5vkNiiS/pwRXpVF > /70MbeBQA4M2ak7enzYGnRI/I2hGAv6nV6ybTwwnPDjq33iBS6F16sV7KsBaLRcy > 7KmUTYKIT7oTncTWTDO0zlgo2k+/Hy1G/ChmnOLBFH6peKSwgt8OJgEPe0rZbg8E > pTukrmr8lDw18MiGPhoqnj7Ug46ydJhqqZkP0aT3xtSF8Y+lVEpn7O36QV03QnAU > d/0oQCQHkHJBfcI9w2W6tiyI6iHFH40U3c78kdASLdWjHyOfYZ/P00BasQudWcvD > kgqYVGrZMXkrIQvn1JnMt5PD5Wl+XN6/6csAkeUOBr9oTwwWnX9xmvT+Ly14TFw2 > fw5/WaMKYht9K//qPh0hQLHCZuG0NEx/0pcoTTgYSGyXOIlAx19gDSbybmd/+ssj > 9/ttSN+t9eENghr1IcXRMCrPcxbwnQRS2dQYGzCmqohf0ZS3DIzYAI2ChMT5eLNl > lD9iSluaf7ss2/qlzwu+4kw25qDR/JwgKL8gmC0jhDE1ID4e8P4/ovpj3EwlW47S > 2tRBD1XhRR0L1ZLiA5za+LLHPg9kUgFVnZ9kMhpm0ATE/bZzAujwFG1rlHmhLxiC > RsU3euvrcb8QPcdLkNLunoCv71QSiCyABeUIG0jFKdU+oA4VoTkP+LWV > =3DBuQY > -----END PGP SIGNATURE----- > > --001a11c2bda833e4a7050db6fe1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Alyssa,

As we believe (and as it has been= mentioned earlier during discussion at CFRG), the initital seed value does= n't have to be chosen explicitly in case of trust in basic hash functio= n properties =E2=80=93 to gain some "backdoor-type" properties of= the curve with d =3D hash(W), one has either to combine such algebraic pro= perties of a curve with properties of a hash function (for a trivial exampl= e, to have an ability to obtain a hash preimage) or to choose a very probab= le "backdoor-type" property of a curve (such that it is possible = to obtain by random choice of a curve).

We believe that there really= cannot be a higher level of "proven randomness" than using d wit= h a known hash preimage (regarding to properties of hash function, of cours= e).

The only one option to get a "backdoored" curve with o= ur method that I understand is the existence of some large publicly unknown= class of "bad" ("backdoored", subverted) curves. But i= f such a class exists, who can guarantee that any of your generated curves = doesn't belong to this class?..

P.S.:
Nevertheless, fo= r that exact twisted Edwards curve we have also a preimage value of first 5= 12 bits of W (we did this only to organize process of candidate curve gener= ation in parallel, without too much need also though), but I had to mention= this (pretty useless) fact.

Best regards,
Stanislav V. Smyshlyaev, Ph= .D.,
Head of Information Security Department, CryptoPro LLC=C2=A0
<= div class=3D"gmail_extra">

2015-01-28 16:28 GMT+03:00 Alyssa Rowan <akr@akr.io>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 27 January 2015 15:57:40 GMT+00:00, "=D0=A1=D1=82=D0=B0=D0=BD=D0=B8= =D1=81=D0=BB=D0=B0=D0=B2 =D0=A1=D0=BC=D1=8B=D1=88=D0=BB=D1=8F=D0=B5=D0=B2&q= uot; <smyshsv@gmail.com> wro= te:

>The curve parameters have been generated using random nonce W in such w= ay that e =3D 1, d =3D hash(W), where hash() is Russian national standard G= OST R 34.11-2012 hash function (also known as =E2=80=9CStreebog=E2=80=9D, <= a href=3D"https://www.streebog.net/en/" target=3D"_blank">https://www.stree= bog.net/en/). The seed value W is equal to:
>W =3D 1F BB 79 69 B9 1B 3E A0 81 17 FB 10 74 BF BF 55 49 DD 66 07 63 F6= A5 AF 09 57 77 5B 66 4C B1 13 CF CB 91 C4 A7 7D 27 98 06 BC F2 4A 56 77 F2= 5E AF FE C6 67 76 70 2E E2 C7 AA 84 16 07 50 DA 1D D1 50 AE D2 8C 30 26 AC= 7E D6 D1 9B 97 AC 2C B5 82 7C 00 03 18 47 13 53 5B FA 65 24 B3 E4 60 83,
...and the million-rouble question, if I may be the first to ask:
How was that seed W generated, and under what criteria?

There is now a strong preference for open curve generation processes whose = criteria are all explicitly shown, chosen for clearly-defined "rigid&q= uot; reasons, and whose generation can be replicated and verified.

I can't see the procedure you show here has that property, due to the u= nexplained seed; a property it shares with the US standard NIST curves we&#= 39;ve been asked to replace, so I'm not too sure as to the merits of yo= ur curve?

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJUyOPlGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6rbAP/0/Cz+7r1IIf8spVLUVeAxtrgdsuKvtRt6Dpz5vkNiiS/pwRXpVF
/70MbeBQA4M2ak7enzYGnRI/I2hGAv6nV6ybTwwnPDjq33iBS6F16sV7KsBaLRcy
7KmUTYKIT7oTncTWTDO0zlgo2k+/Hy1G/ChmnOLBFH6peKSwgt8OJgEPe0rZbg8E
pTukrmr8lDw18MiGPhoqnj7Ug46ydJhqqZkP0aT3xtSF8Y+lVEpn7O36QV03QnAU
d/0oQCQHkHJBfcI9w2W6tiyI6iHFH40U3c78kdASLdWjHyOfYZ/P00BasQudWcvD
kgqYVGrZMXkrIQvn1JnMt5PD5Wl+XN6/6csAkeUOBr9oTwwWnX9xmvT+Ly14TFw2
fw5/WaMKYht9K//qPh0hQLHCZuG0NEx/0pcoTTgYSGyXOIlAx19gDSbybmd/+ssj
9/ttSN+t9eENghr1IcXRMCrPcxbwnQRS2dQYGzCmqohf0ZS3DIzYAI2ChMT5eLNl
lD9iSluaf7ss2/qlzwu+4kw25qDR/JwgKL8gmC0jhDE1ID4e8P4/ovpj3EwlW47S
2tRBD1XhRR0L1ZLiA5za+LLHPg9kUgFVnZ9kMhpm0ATE/bZzAujwFG1rlHmhLxiC
RsU3euvrcb8QPcdLkNLunoCv71QSiCyABeUIG0jFKdU+oA4VoTkP+LWV
=3DBuQY
-----END PGP SIGNATURE-----


--001a11c2bda833e4a7050db6fe1f--