Hi all,

sorry for being a bi=
t slow. I agree with Thomas that both errata are correct. One extra detail:=
the original formulas are true in more general situations (for example, in=
the first case, I believe this holds if p =3D 5 mod 8). The proposed errat=
a are correct, as Thomas proved above, but only hold for these specific cho=
ices of p; the second one even relies on u and v being constructed from d a=
nd y rather than just random field elements. (These are things I just check=
ed experimentally in Sage). They are slightly faster, so maybe worth having=
, but perhaps with this caveat added in case people erroneously try to use =
these formulae for computing square roots in other situations.

All the best,

Chloe

On Fri, =
28 Jan 2022 at 13:48, Thomas Pornin <thomas.pornin@nccgroup.com> wrote:

As for efficiency, the gain is slight.= The modular exponentiation (with exponent (p-5)/8) costs at least 250 squa= rings, and an extra dozen multiplications. The proposed formula saves two s= quarings and three multiplications, i.e. we are talking about an improvemen= t of less than 2%. Nothing ground-breaking here.

Thomas

=EF=BB=BFOn 2022-01-28, 08:44, "Crypto-panel on behalf of Thomas Porni= n" <crypto-panel-bounces@irtf.org on behalf of thomas.pornin=3D40nccgroup.com@= dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 OK, the proposed formulas are correct. The original formulas = were correct, too.

=C2=A0 =C2=A0 For p =3D 2^255-19: given u and v in the field, then:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-5)/8))^2 =3D v*(u^2)*(u^((p-5)/4))*(= v^((p-5)/4)) =3D u * (u^((p-1)/4) * v^((p-1)/4))

=C2=A0 =C2=A0 If u/v is a square (and u !=3D 0, v !=3D 0) then u^((p-1)/2) = * v^((p-1)/2) =3D 1 (i.e. both u and v are squares, or both u and v are non= -squares).

=C2=A0 =C2=A0 (u^((p-1)/4) * v^((p-1)/4)) is a square root of (u^((p-1)/2) = * v^((p-1)/2)), so its value can only be 1 or -1, therefore v*x^2 =3D u or = -u. In both cases, this leads to a square root of (u/v) by applying step 3 = of RFC 8032 section 5.1.3: if we got x such that v*x^2 =3D u, then x is a s= quare root of u/v; if x is such that v*x^2 =3D -u, then x*i is a square roo= t of u/v, using i =3D sqrt(-1) (in the RFC, it's given as 2^((p-1)/4), = and it is indeed a square root of -1).

=C2=A0 =C2=A0 Thus, the proposed formula, inserted in the RFC text, indeed = yields a square root of u/v if it exists. It does not necessarily yield the= same square root as the original formula, but that does not matter since s= tep 4 of the decoding process normalizes the solution using the least signi= ficant bit.

=C2=A0 =C2=A0 Note that step 3 of section 5.1.3 includes explicitly checkin= g that v*x^2 =3D u or -u, and if u/v is not a square then there cannot be a= x value that matches that test; thus, the new formula does not incorrectly= return a value for a non-square u/v.

=C2=A0 =C2=A0 For p =3D 2^448 - 2^224 - 1, it is slightly simpler:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-3)/4))^2 =3D u * (u^((p-1)/2) * v^((= p-1)/2)

=C2=A0 =C2=A0 If u/v is a square then u^((p-1)/2) * v^((p-1)/2) =3D 1 (see = above), hence v*x^2 =3D u and x is necessarily a solution. Again, this is t= ested explicitly (step 3 of section 5.2.3) so there is no risk of incorrect= ly accepting a non-square.

=C2=A0 =C2=A0 As noted above, the normalizing step means that it makes no d= ifference which of the two square roots you get, at least in the context of= RFC 8032. I think it has some slight impact in another context, where the = exact choice of the square root can help simplify a formula, but my memory = is a bit hazy here. This may be related to the fact that, with p =3D 2^448 = - 2^224 - 1, exactly one of the two square roots of u/v is itself a square,= and the original RFC formula always returns that one, while the proposed f= ormula may return the square root which is a non-square; again, this does n= ot matter in the case of RFC 8032.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.org> on behal= f of "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 07:45

=C2=A0 =C2=A0 To: Thomas Pornin <thomas.pornin=3D40nccgroup.com@dmarc.ietf.org>

=C2=A0 =C2=A0 Cc: Chloe Martindale <chloemartindale@gmail.com>, "crypto-panel@irtf.org" <cry= pto-panel@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>

=C2=A0 =C2=A0 Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review = of two erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Thank you, Thomas!

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Stanislav

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 15:43, Thomas Pornin <thomas.pornin= =3D40ncc= group.com@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 I will have a look too. This looks weird.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.org> on behal= f of Chloe Martindale <chloemartindale@gmail.com>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 06:24

=C2=A0 =C2=A0 To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>

=C2=A0 =C2=A0 Cc: "crypto-panel@irtf.org" <crypto-panel@irtf.org>, "cfrg-chairs@ietf.org&qu= ot; <cfrg-chai= rs@ietf.org>

=C2=A0 =C2=A0 Subject: EXTERNAL: Re: [Crypto-panel] Request for review of t= wo erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 I can take a look at this.

=C2=A0 =C2=A0 All the best,

=C2=A0 =C2=A0 Chloe

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 06:20, Stanislav V. Smyshlyaev <smyshsv@gmail.com&g= t; wrote:

=C2=A0 =C2=A0 Dear Crypto Review Panel experts,

=C2=A0 =C2=A0 We've received a request to have a closer look at two err= ata opened against RFC 8032: https:= //gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rfc-edito= r.org%2Ferrata%2Feid5758&data=3D04%7C01%7Cthomas.pornin%40nccgroup.= com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62f368e%7= C0%7C0%7C637789742687386303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Dk49Gr2Wu= YIRmJtbPMkL8y8uhUztvAgtHOgZNWo9yOUw%3D&reserved=3D0, https://gbr01.safelinks.protection.outlook.co= m/?url=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5759&data= =3D04%7C01%7Cthomas.pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416a= f%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C3000&sdata=3DB6QR5Z50rB0Vz3XkgFEtteBSLLL7iV1qFjiRWu8LyfE%3= D&reserved=3D0.

=C2=A0 =C2=A0 Previously these two errata were rejected since no mistakes i= n the current text of the draft had been found. At the same time, the two e= rrata might provide more effective ways for square-roots-mod-p.

=C2=A0 =C2=A0 We would like to ask a Crypto Panel expert (or two experts) t= o check the proposed formulas, i.e., to verify that they are correct and mo= re effective (always or in a vast majority of cases).

=C2=A0 =C2=A0 Any volunteers?

=C2=A0 =C2=A0 Best regards,

=C2=A0 =C2=A0 Stanislav (for chairs)

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Cr= ypto-panel@irtf.org

=C2=A0 =C2=A0 https://gb= r01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.irtf.org%2Fma= ilman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.pornin%40nc= cgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62= f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DG= EKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved=3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Cr= ypto-panel@irtf.org

=C2=A0 =C2=A0 https://gb= r01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.irtf.org%2Fma= ilman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.pornin%40nc= cgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62= f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DG= EKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved=3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Cr= ypto-panel@irtf.org

=C2=A0 =C2=A0 https://gb= r01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.irtf.org%2Fma= ilman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.pornin%40nc= cgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62= f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DG= EKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved=3D0

Dear Chloe,

Thank you so much for your =
work!

>> but only hold for these specific ch=
oices of p

Do I understand correctly that for this specific RFC t=
he formulas=C2=A0are always correct (i.e., the text of errata can be used i=
n the updated=C2=A0version of the RFC without additional remarks), but are =
not always correct in other cases?

Regards,

<=
div>StanislavOn Mon, 14 Feb 2022 at 02:39, Chloe Marti=
ndale <chloemartindale@gmai=
l.com> wrote:

--0000000000003763e705d7f3dbc9-- From nobody Mon Feb 14 02:02:59 2022 Return-Path:Hi all,sorry for being= a bit slow. I agree with Thomas that both errata are correct. One extra de= tail: the original formulas are true in more general situations (for exampl= e, in the first case, I believe this holds if p =3D 5 mod 8). The proposed = errata are correct, as Thomas proved above, but only hold for these specifi= c choices of p; the second one even relies on u and v being constructed fro= m d and y rather than just random field elements. (These are things I just = checked experimentally in Sage). They are slightly faster, so maybe worth h= aving, but perhaps with this caveat added in case people erroneously try to= use these formulae for computing square roots in other situations. All the best,ChloeOn = Fri, 28 Jan 2022 at 13:48, Thomas Pornin <thomas.pornin@nccgroup.com> wrote:=As for efficien= cy, the gain is slight. The modular exponentiation (with exponent (p-5)/8) = costs at least 250 squarings, and an extra dozen multiplications. The propo= sed formula saves two squarings and three multiplications, i.e. we are talk= ing about an improvement of less than 2%. Nothing ground-breaking here.

Thomas

=EF=BB=BFOn 2022-01-28, 08:44, "Crypto-panel on behalf of Thomas Porni= n" <crypto-panel-bounces@irtf.org on behalf of thomas.pornin=3D40nccgroup.com@= dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 OK, the proposed formulas are correct. The original formulas = were correct, too.

=C2=A0 =C2=A0 For p =3D 2^255-19: given u and v in the field, then:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-5)/8))^2 =3D v*(u^2)*(u^((p-5)/4))*(= v^((p-5)/4)) =3D u * (u^((p-1)/4) * v^((p-1)/4))

=C2=A0 =C2=A0 If u/v is a square (and u !=3D 0, v !=3D 0) then u^((p-1)/2) = * v^((p-1)/2) =3D 1 (i.e. both u and v are squares, or both u and v are non= -squares).

=C2=A0 =C2=A0 (u^((p-1)/4) * v^((p-1)/4)) is a square root of (u^((p-1)/2) = * v^((p-1)/2)), so its value can only be 1 or -1, therefore v*x^2 =3D u or = -u. In both cases, this leads to a square root of (u/v) by applying step 3 = of RFC 8032 section 5.1.3: if we got x such that v*x^2 =3D u, then x is a s= quare root of u/v; if x is such that v*x^2 =3D -u, then x*i is a square roo= t of u/v, using i =3D sqrt(-1) (in the RFC, it's given as 2^((p-1)/4), = and it is indeed a square root of -1).

=C2=A0 =C2=A0 Thus, the proposed formula, inserted in the RFC text, indeed = yields a square root of u/v if it exists. It does not necessarily yield the= same square root as the original formula, but that does not matter since s= tep 4 of the decoding process normalizes the solution using the least signi= ficant bit.

=C2=A0 =C2=A0 Note that step 3 of section 5.1.3 includes explicitly checkin= g that v*x^2 =3D u or -u, and if u/v is not a square then there cannot be a= x value that matches that test; thus, the new formula does not incorrectly= return a value for a non-square u/v.

=C2=A0 =C2=A0 For p =3D 2^448 - 2^224 - 1, it is slightly simpler:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-3)/4))^2 =3D u * (u^((p-1)/2) * v^((= p-1)/2)

=C2=A0 =C2=A0 If u/v is a square then u^((p-1)/2) * v^((p-1)/2) =3D 1 (see = above), hence v*x^2 =3D u and x is necessarily a solution. Again, this is t= ested explicitly (step 3 of section 5.2.3) so there is no risk of incorrect= ly accepting a non-square.

=C2=A0 =C2=A0 As noted above, the normalizing step means that it makes no d= ifference which of the two square roots you get, at least in the context of= RFC 8032. I think it has some slight impact in another context, where the = exact choice of the square root can help simplify a formula, but my memory = is a bit hazy here. This may be related to the fact that, with p =3D 2^448 = - 2^224 - 1, exactly one of the two square roots of u/v is itself a square,= and the original RFC formula always returns that one, while the proposed f= ormula may return the square root which is a non-square; again, this does n= ot matter in the case of RFC 8032.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.org> on behal= f of "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 07:45

=C2=A0 =C2=A0 To: Thomas Pornin <thomas.pornin=3D40nccgroup.com@dmarc.ietf.org>

=C2=A0 =C2=A0 Cc: Chloe Martindale <chloemartindale@gmail.com>, "crypto-panel@irtf.org" <cry= pto-panel@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>

=C2=A0 =C2=A0 Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review = of two erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Thank you, Thomas!

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Stanislav

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 15:43, Thomas Pornin <thomas.pornin= =3D40ncc= group.com@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 I will have a look too. This looks weird.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.org> on behal= f of Chloe Martindale <chloemartindale@gmail.com>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 06:24

=C2=A0 =C2=A0 To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>

=C2=A0 =C2=A0 Cc: "crypto-panel@irtf.org" <crypto-panel@irtf.org>, "cfrg-chairs@ietf.org&qu= ot; <cfrg-chai= rs@ietf.org>

=C2=A0 =C2=A0 Subject: EXTERNAL: Re: [Crypto-panel] Request for review of t= wo erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 I can take a look at this.

=C2=A0 =C2=A0 All the best,

=C2=A0 =C2=A0 Chloe

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 06:20, Stanislav V. Smyshlyaev <smyshsv@gmail.com&g= t; wrote:

=C2=A0 =C2=A0 Dear Crypto Review Panel experts,

=C2=A0 =C2=A0 We've received a request to have a closer look at two err= ata opened against RFC 8032: https:= //gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rfc-edito= r.org%2Ferrata%2Feid5758&data=3D04%7C01%7Cthomas.pornin%40nccgroup.= com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62f368e%7= C0%7C0%7C637789742687386303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Dk49Gr2Wu= YIRmJtbPMkL8y8uhUztvAgtHOgZNWo9yOUw%3D&reserved=3D0, https://gbr01.safelinks.protection.outlook.co= m/?url=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5759&data= =3D04%7C01%7Cthomas.pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416a= f%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C3000&sdata=3DB6QR5Z50rB0Vz3XkgFEtteBSLLL7iV1qFjiRWu8LyfE%3= D&reserved=3D0.

=C2=A0 =C2=A0 Previously these two errata were rejected since no mistakes i= n the current text of the draft had been found. At the same time, the two e= rrata might provide more effective ways for square-roots-mod-p.

=C2=A0 =C2=A0 We would like to ask a Crypto Panel expert (or two experts) t= o check the proposed formulas, i.e., to verify that they are correct and mo= re effective (always or in a vast majority of cases).

=C2=A0 =C2=A0 Any volunteers?

=C2=A0 =C2=A0 Best regards,

=C2=A0 =C2=A0 Stanislav (for chairs)

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Cr= ypto-panel@irtf.org

=C2=A0 =C2=A0 https://gb= r01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.irtf.org%2Fma= ilman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.pornin%40nc= cgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62= f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DG= EKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved=3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Cr= ypto-panel@irtf.org

=C2=A0 =C2=A0 https://gb= r01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.irtf.org%2Fma= ilman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.pornin%40nc= cgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62= f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DG= EKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved=3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Cr= ypto-panel@irtf.org

=C2=A0 =C2=A0 https://gb= r01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.irtf.org%2Fma= ilman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.pornin%40nc= cgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62= f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DG= EKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved=3D0

Dear Stanislav,

<=
br>Yes they are correct. No remarks are needed for correctness, but for co=
mpleteness I would suggest adding a citation/justification and a comment th=
at these speed ups are possible only in these specific cases. If you prefer=
to keep it simple and just accept based on correctness that's also fin=
e=C2=A0with me.

All the =
best,

Chloe

On Mon,=
14 Feb 2022, 05:40 Stanislav V. Smyshlyaev, <smyshsv@gmail.com> wrote:

Dear Chloe,Thank you so much = for your work!>> but only hold for these sp= ecific choices of pDo I understand correctly that for this speci= fic RFC the formulas=C2=A0are always correct (i.e., the text of errata can = be used in the updated=C2=A0version of the RFC without additional remarks),= but are not always correct in other cases?Regard= s,StanislavOn Mon, 14 Feb 2022 at 02:39, Ch= loe Martindale <chloemartindale@gmail.com> wrote:Hi= all,sorry for being a bit slow. I agree with Tho= mas that both errata are correct. One extra detail: the original formulas a= re true in more general situations (for example, in the first case, I belie= ve this holds if p =3D 5 mod 8). The proposed errata are correct, as Thomas= proved above, but only hold for these specific choices of p; the second on= e even relies on u and v being constructed from d and y rather than just ra= ndom field elements. (These are things I just checked experimentally in Sag= e). They are slightly faster, so maybe worth having, but perhaps with this = caveat added in case people erroneously try to use these formulae for compu= ting square roots in other situations.All the bes= t,ChloeOn Fri, 28 Jan 2022 at 13:48, Th= omas Pornin <thomas.pornin@nccgroup.com> wrote:=As for efficiency, the ga= in is slight. The modular exponentiation (with exponent (p-5)/8) costs at l= east 250 squarings, and an extra dozen multiplications. The proposed formul= a saves two squarings and three multiplications, i.e. we are talking about = an improvement of less than 2%. Nothing ground-breaking here.

Thomas

=EF=BB=BFOn 2022-01-28, 08:44, "Crypto-panel on behalf of Thomas Porni= n" <crypto-panel-bounces@irtf.org on behalf of thoma= s.pornin=3D40nccgroup.com@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 OK, the proposed formulas are correct. The original formulas = were correct, too.

=C2=A0 =C2=A0 For p =3D 2^255-19: given u and v in the field, then:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-5)/8))^2 =3D v*(u^2)*(u^((p-5)/4))*(= v^((p-5)/4)) =3D u * (u^((p-1)/4) * v^((p-1)/4))

=C2=A0 =C2=A0 If u/v is a square (and u !=3D 0, v !=3D 0) then u^((p-1)/2) = * v^((p-1)/2) =3D 1 (i.e. both u and v are squares, or both u and v are non= -squares).

=C2=A0 =C2=A0 (u^((p-1)/4) * v^((p-1)/4)) is a square root of (u^((p-1)/2) = * v^((p-1)/2)), so its value can only be 1 or -1, therefore v*x^2 =3D u or = -u. In both cases, this leads to a square root of (u/v) by applying step 3 = of RFC 8032 section 5.1.3: if we got x such that v*x^2 =3D u, then x is a s= quare root of u/v; if x is such that v*x^2 =3D -u, then x*i is a square roo= t of u/v, using i =3D sqrt(-1) (in the RFC, it's given as 2^((p-1)/4), = and it is indeed a square root of -1).

=C2=A0 =C2=A0 Thus, the proposed formula, inserted in the RFC text, indeed = yields a square root of u/v if it exists. It does not necessarily yield the= same square root as the original formula, but that does not matter since s= tep 4 of the decoding process normalizes the solution using the least signi= ficant bit.

=C2=A0 =C2=A0 Note that step 3 of section 5.1.3 includes explicitly checkin= g that v*x^2 =3D u or -u, and if u/v is not a square then there cannot be a= x value that matches that test; thus, the new formula does not incorrectly= return a value for a non-square u/v.

=C2=A0 =C2=A0 For p =3D 2^448 - 2^224 - 1, it is slightly simpler:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-3)/4))^2 =3D u * (u^((p-1)/2) * v^((= p-1)/2)

=C2=A0 =C2=A0 If u/v is a square then u^((p-1)/2) * v^((p-1)/2) =3D 1 (see = above), hence v*x^2 =3D u and x is necessarily a solution. Again, this is t= ested explicitly (step 3 of section 5.2.3) so there is no risk of incorrect= ly accepting a non-square.

=C2=A0 =C2=A0 As noted above, the normalizing step means that it makes no d= ifference which of the two square roots you get, at least in the context of= RFC 8032. I think it has some slight impact in another context, where the = exact choice of the square root can help simplify a formula, but my memory = is a bit hazy here. This may be related to the fact that, with p =3D 2^448 = - 2^224 - 1, exactly one of the two square roots of u/v is itself a square,= and the original RFC formula always returns that one, while the proposed f= ormula may return the square root which is a non-square; again, this does n= ot matter in the case of RFC 8032.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.o= rg> on behalf of "Stanislav V. Smyshlyaev" <smyshsv@gmai= l.com>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 07:45

=C2=A0 =C2=A0 To: Thomas Pornin <thomas.pornin=3D40nccgroup.c= om@dmarc.ietf.org>

=C2=A0 =C2=A0 Cc: Chloe Martindale <chloemartindale@gmail.com= >, "crypto-panel@irtf.org" <crypto-panel@irtf.or= g>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.or= g>

=C2=A0 =C2=A0 Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review = of two erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Thank you, Thomas!

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Stanislav

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 15:43, Thomas Pornin <thomas.pornin= =3D40nccgroup.com@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 I will have a look too. This looks weird.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.o= rg> on behalf of Chloe Martindale <chloemartindale@gmail.c= om>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 06:24

=C2=A0 =C2=A0 To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com<= /a>>

=C2=A0 =C2=A0 Cc: "crypto-panel@irtf.org" <crypto-pa= nel@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-= chairs@ietf.org>

=C2=A0 =C2=A0 Subject: EXTERNAL: Re: [Crypto-panel] Request for review of t= wo erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 I can take a look at this.

=C2=A0 =C2=A0 All the best,

=C2=A0 =C2=A0 Chloe

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 06:20, Stanislav V. Smyshlyaev <smys= hsv@gmail.com> wrote:

=C2=A0 =C2=A0 Dear Crypto Review Panel experts,

=C2=A0 =C2=A0 We've received a request to have a closer look at two err= ata opened against RFC 8032: https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.rfc-editor.org%2Ferrata%2Feid5758&data=3D04%7C01%7Cthomas.pornin%= 40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee0= 1a62f368e%7C0%7C0%7C637789742687386303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w= LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata= =3Dk49Gr2WuYIRmJtbPMkL8y8uhUztvAgtHOgZNWo9yOUw%3D&reserved=3D0,= https://gbr01.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Ferrata%= 2Feid5759&data=3D04%7C01%7Cthomas.pornin%40nccgroup.com%7C39588fcd6= b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637789= 742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DB6QR5Z50rB0Vz3XkgFEtteB= SLLL7iV1qFjiRWu8LyfE%3D&reserved=3D0.

=C2=A0 =C2=A0 Previously these two errata were rejected since no mistakes i= n the current text of the draft had been found. At the same time, the two e= rrata might provide more effective ways for square-roots-mod-p.

=C2=A0 =C2=A0 We would like to ask a Crypto Panel expert (or two experts) t= o check the proposed formulas, i.e., to verify that they are correct and mo= re effective (always or in a vast majority of cases).

=C2=A0 =C2=A0 Any volunteers?

=C2=A0 =C2=A0 Best regards,

=C2=A0 =C2=A0 Stanislav (for chairs)

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Crypto-panel@irtf.org

=C2=A0 =C2=A0 https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ir= tf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.= pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f6= 8bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DGEKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved= =3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Crypto-panel@irtf.org

=C2=A0 =C2=A0 https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ir= tf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.= pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f6= 8bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DGEKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved= =3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Crypto-panel@irtf.org

=C2=A0 =C2=A0 https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ir= tf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.= pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f6= 8bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DGEKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved= =3D0

Dear=C2=A0Crypto=C2=
=A0Panel=C2=A0Experts,

<=
br>

The chairs would like to ask the=C2=A0Crypto=C2=A0Panel=C2=A0to provide =
a review for version -09 of the "Oblivious Pseudorandom Functions (OPR=
Fs) using Prime-Order Groups" draft, draft-irtf-cfrg-voprf-09 (https:/=
/datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-09).

Any volunteers?

Stanislav (on behalf of the CFRG Cha= irs)

Chloe and Thomas,=C2=A0

=
Thank you so much for your reviews!=C2=A0

We'l=
l mark the errata as "hold for future update", with a comment abo=
ut formulas being only slightly faster than the existing ones.

Thanks again!

Regards,

Stan=
islav (on behalf of CFRG Chairs)

=

--0000000000003731b705d807e7c2--
From nobody Tue Feb 15 02:21:04 2022
Return-Path: On Mon, 14 Feb 2022 at 13:02, Chloe M=
artindale <chloemartindale@=
gmail.com> wrote:

Dear Stanislav,Yes they are correct. No remarks are needed for correctness,= but for completeness I would suggest adding a citation/justification and a= comment that these speed ups are possible only in these specific cases. If= you prefer to keep it simple and just accept based on correctness that'= ;s also fine=C2=A0with me. All the best,ChloeOn Mon, 14 Feb 2022, 05:40 Stanislav V. Smyshlyaev, <smyshsv@gmail.com> wrote:D= ear Chloe,Thank you so much for your work!>> but only hold for these specific choices of pDo I understand correctly that for this specific RFC the formulas=C2=A0a= re always correct (i.e., the text of errata can be used in the updated=C2= =A0version of the RFC without additional remarks), but are not always corre= ct in other cases? Regards,StanislavOn Mon, 14 Feb 2022 at 02:39, Chloe Martindale <chloemartindale@gmail.com> wrote:Hi all,sorry for being a bit slow. I agree with Thomas that both errata are = correct. One extra detail: the original formulas are true in more general s= ituations (for example, in the first case, I believe this holds if p =3D 5 = mod 8). The proposed errata are correct, as Thomas proved above, but only h= old for these specific choices of p; the second one even relies on u and v = being constructed from d and y rather than just random field elements. (The= se are things I just checked experimentally in Sage). They are slightly fas= ter, so maybe worth having, but perhaps with this caveat added in case peop= le erroneously try to use these formulae for computing square roots in othe= r situations.All the best,ChloeOn Fri, 28 Jan 2022 at 13:48, Thomas Pornin <thomas.pornin@nccgroup.com> wrote:As for efficiency, the gain is slight. The modul= ar exponentiation (with exponent (p-5)/8) costs at least 250 squarings, and= an extra dozen multiplications. The proposed formula saves two squarings a= nd three multiplications, i.e. we are talking about an improvement of less = than 2%. Nothing ground-breaking here.

Thomas

=EF=BB=BFOn 2022-01-28, 08:44, "Crypto-panel on behalf of Thomas Porni= n" <crypto-panel-bounces@irtf.org on behalf of thoma= s.pornin=3D40nccgroup.com@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 OK, the proposed formulas are correct. The original formulas = were correct, too.

=C2=A0 =C2=A0 For p =3D 2^255-19: given u and v in the field, then:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-5)/8))^2 =3D v*(u^2)*(u^((p-5)/4))*(= v^((p-5)/4)) =3D u * (u^((p-1)/4) * v^((p-1)/4))

=C2=A0 =C2=A0 If u/v is a square (and u !=3D 0, v !=3D 0) then u^((p-1)/2) = * v^((p-1)/2) =3D 1 (i.e. both u and v are squares, or both u and v are non= -squares).

=C2=A0 =C2=A0 (u^((p-1)/4) * v^((p-1)/4)) is a square root of (u^((p-1)/2) = * v^((p-1)/2)), so its value can only be 1 or -1, therefore v*x^2 =3D u or = -u. In both cases, this leads to a square root of (u/v) by applying step 3 = of RFC 8032 section 5.1.3: if we got x such that v*x^2 =3D u, then x is a s= quare root of u/v; if x is such that v*x^2 =3D -u, then x*i is a square roo= t of u/v, using i =3D sqrt(-1) (in the RFC, it's given as 2^((p-1)/4), = and it is indeed a square root of -1).

=C2=A0 =C2=A0 Thus, the proposed formula, inserted in the RFC text, indeed = yields a square root of u/v if it exists. It does not necessarily yield the= same square root as the original formula, but that does not matter since s= tep 4 of the decoding process normalizes the solution using the least signi= ficant bit.

=C2=A0 =C2=A0 Note that step 3 of section 5.1.3 includes explicitly checkin= g that v*x^2 =3D u or -u, and if u/v is not a square then there cannot be a= x value that matches that test; thus, the new formula does not incorrectly= return a value for a non-square u/v.

=C2=A0 =C2=A0 For p =3D 2^448 - 2^224 - 1, it is slightly simpler:

=C2=A0 =C2=A0 v*x^2 =3D v*(u*(u*v)^((p-3)/4))^2 =3D u * (u^((p-1)/2) * v^((= p-1)/2)

=C2=A0 =C2=A0 If u/v is a square then u^((p-1)/2) * v^((p-1)/2) =3D 1 (see = above), hence v*x^2 =3D u and x is necessarily a solution. Again, this is t= ested explicitly (step 3 of section 5.2.3) so there is no risk of incorrect= ly accepting a non-square.

=C2=A0 =C2=A0 As noted above, the normalizing step means that it makes no d= ifference which of the two square roots you get, at least in the context of= RFC 8032. I think it has some slight impact in another context, where the = exact choice of the square root can help simplify a formula, but my memory = is a bit hazy here. This may be related to the fact that, with p =3D 2^448 = - 2^224 - 1, exactly one of the two square roots of u/v is itself a square,= and the original RFC formula always returns that one, while the proposed f= ormula may return the square root which is a non-square; again, this does n= ot matter in the case of RFC 8032.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.o= rg> on behalf of "Stanislav V. Smyshlyaev" <smyshsv@gmai= l.com>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 07:45

=C2=A0 =C2=A0 To: Thomas Pornin <thomas.pornin=3D40nccgroup.c= om@dmarc.ietf.org>

=C2=A0 =C2=A0 Cc: Chloe Martindale <chloemartindale@gmail.com= >, "crypto-panel@irtf.org" <crypto-panel@irtf.org= >, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org= >

=C2=A0 =C2=A0 Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review = of two erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Thank you, Thomas!

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Stanislav

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 15:43, Thomas Pornin <thomas.pornin= =3D40nccgroup.com@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 I will have a look too. This looks weird.

=C2=A0 =C2=A0 Thomas

=C2=A0 =C2=A0 From: Crypto-panel <crypto-panel-bounces@irtf.o= rg> on behalf of Chloe Martindale <chloemartindale@gmail.c= om>

=C2=A0 =C2=A0 Date: Friday, January 28, 2022 at 06:24

=C2=A0 =C2=A0 To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com<= /a>>

=C2=A0 =C2=A0 Cc: "crypto-panel@irtf.org" <crypto-pa= nel@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-cha= irs@ietf.org>

=C2=A0 =C2=A0 Subject: EXTERNAL: Re: [Crypto-panel] Request for review of t= wo erratas opened against RFC 8032 (EdDSA)

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 I can take a look at this.

=C2=A0 =C2=A0 All the best,

=C2=A0 =C2=A0 Chloe

=C2=A0 =C2=A0 On Fri, 28 Jan 2022 at 06:20, Stanislav V. Smyshlyaev <smys= hsv@gmail.com> wrote:

=C2=A0 =C2=A0 Dear Crypto Review Panel experts,

=C2=A0 =C2=A0 We've received a request to have a closer look at two err= ata opened against RFC 8032: https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.rfc-editor.org%2Ferrata%2Feid5758&data=3D04%7C01%7Cthomas.pornin%= 40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee0= 1a62f368e%7C0%7C0%7C637789742687386303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w= LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata= =3Dk49Gr2WuYIRmJtbPMkL8y8uhUztvAgtHOgZNWo9yOUw%3D&reserved=3D0,= https://gbr01.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Ferrata%= 2Feid5759&data=3D04%7C01%7Cthomas.pornin%40nccgroup.com%7C39588fcd6= b3a4eb2a2e408d9e26416af%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637789= 742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DB6QR5Z50rB0Vz3XkgFEtteB= SLLL7iV1qFjiRWu8LyfE%3D&reserved=3D0.

=C2=A0 =C2=A0 Previously these two errata were rejected since no mistakes i= n the current text of the draft had been found. At the same time, the two e= rrata might provide more effective ways for square-roots-mod-p.

=C2=A0 =C2=A0 We would like to ask a Crypto Panel expert (or two experts) t= o check the proposed formulas, i.e., to verify that they are correct and mo= re effective (always or in a vast majority of cases).

=C2=A0 =C2=A0 Any volunteers?

=C2=A0 =C2=A0 Best regards,

=C2=A0 =C2=A0 Stanislav (for chairs)

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Crypto-panel@irtf.org

=C2=A0 =C2=A0 https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ir= tf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.= pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f6= 8bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DGEKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved= =3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Crypto-panel@irtf.org

=C2=A0 =C2=A0 https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ir= tf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.= pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f6= 8bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DGEKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved= =3D0

=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 Crypto-panel mailing list

=C2=A0 =C2=A0 Crypto-panel@irtf.org

=C2=A0 =C2=A0 https://gbr01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ir= tf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&data=3D04%7C01%7Cthomas.= pornin%40nccgroup.com%7C39588fcd6b3a4eb2a2e408d9e26416af%7Ca41111be486b45f6= 8bd0ee01a62f368e%7C0%7C0%7C637789742687542555%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DGEKFMaVjuISqEdKPktiXnkMwk87FtwrgNIxdYTqa0gA%3D&reserved= =3D0

>> I would like to review this draft.

=
Thank you, Virendra!

Yes, three weeks (or so) is a fi=
ne time period for review.

Thank you, we'l=
l be waiting for a review! Please send it to cfrg@irtf.org (CC'ing cf=
rg-chairs@ietf.org and draft-irtf-cfrg-voprf@ietf.org), when it is ready.

Regards,

Stanislav

On Tue, 15 Feb 2022=
at 13:20, Virendra Kumar <=
virendra@qti.qualcomm.com> wrote:

Hi Stanislav,

=C2=A0I would like to review this draft. In terms of time,= this and the next week are extremely busy for me, so the earliest I could = do would be Friday, March 11

^{th}. Please let me know if that would= work.

=C2=A0Regards,

Virendra

=C2=A0

From:Crypto-panel <crypto-panel-bounces@irtf.org<= /a>>On Behalf OfStanislav V. Smyshlyaev

Sent:Tuesday, February 15, 2022 12:34 AM

To:crypt= o-panel@irtf.org

Cc:cfrg-c= hairs@ietf.org

Subject:[Crypto-panel] Request for review: OPRFs using Prime-Order = Groups

=C2=A0

WA= RNING:This email originated from outside of Qualcomm. Please be wary of any link= s or attachments, and do not enable macros.Dear=C2=A0Crypto=C2=A0Panel=C2=A0Experts,

=C2=A0The chairs would like to ask the=C2=A0Crypto=C2=A0Panel=C2=A0to provide a review for= version -09 of the "Oblivious Pseudorandom Functions (OPRFs) using Pr= ime-Order Groups" draft, draft-irtf-cfrg-voprf-09 (https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-v= oprf-09).

=C2=A0

Any volunteers?

Stanislav (on behalf of the CFRG Chairs)

=C2=A0

-02 and -0=
3 address the Crypto Panel review by Thomas Pornin. Notes inline below.

https://mailarchi=
ve.ietf.org/arch/msg/crypto-panel/isgCxg9ddxoPkNnOdGbwK2Z2_Cw/

Some discussion on the changes.

Latest HTML and diff from the reviewed version.<=
br>

The ristretto255 and decaf448 = Groupsdraft-irtf-cfrg-ristretto255-decaf448-01

<= /div>Overall I find this draft to be well-written an= d reasonable; my comments below are mostly cosmetic in nature.=page 3: "fastest known formulas curve operations" -&= gt; I could disputethat, at least for point doubling. I s= uggest: "[...] and formulas amongthe fastest known for cu= rve operations".

Done.

<= /div>

= expect this reference to be, indeed, a reference to an entry in section = 11("Informative References"), where the URL would be, ins= tead of havingthe URL directly inlined (twice!) in the te= xt. (If you don't use areference, the RFC editor will pro= bably be very cross.)

Done.

page 4: about curve= names: it might be worth including somewhere thatwhat is= described as "Curve25519" here is what is called "edwards25519"in RFC 7748 (which uses "Curve25519" to designate the Montgomery = curve).

Done.

page 4: "the Curve25519 prime 2^2= 55 - 19 or the edwards448 prime" -> forsymmetry of exp= ression, if you include the value of the Curve25519 prime= (2^255 - 19), then you should also include the value of the edwards448prime (2^448 - 2^224 - 1).

<= /div>

Done.

p= age 4: "array[A:B]" -> maybe also specify that array indices start at= 0?

Done.

page 5: the American spelling of "beh= avior" is used (and also on page 17),whereas the British = spelling ("behaviour") was used on page 3.

Done.

page 5: "bytestring" -> this term is not defined in the draft; it's= not

defined either in RFC 7748 or 8032. This is not an ut=
terly obscure term,

but it is still a neologism (plain Eng=
lish would use "byte string" in

two words); moreover, comm=
unication protocol standards tend to prefer

the use of "oc=
tet" rather than "byte", the latter being historically

imp=
recise. I suggest adding a definition in section 2, e.g. something

like: "In this document, a byte is an 8-bit entity (also known =
as

"octet") and a bytestring is an ordered sequence of byt=
es."

Defined "byte string" and=
"N-byte string" in Section 2, and used throughout.

page 6: "using Curve25519 points as i= nternal representations" -> I thinkit should be "repre= sentation" here.

I think the n=
umber of "representations" is supposed to match the number of "points"?<=
br>

page 6: "encoding= " is a sequence of octets (a "bytestring") but herewe see= a sequence of eight 8-digit hexadecimal integers. This notationis slightly ambiguous because it does not say whether each 8-digi= t