Re: [STDS-802-11] changes to hash-to-curve algorithm

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Rob,

On 11/1/19, 12:57 PM, "Rob Sun" <Rob.Sun@xxxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hi Rene:

Glad to hear from you, for long time!

The equation f(b/(n*a)):=b^3/(n*a)^3+ b/n + b, n is representing theta, and theta is nQR (non-quadratic residue), I think the f(u0) is also a nQR over GF(q). Am I missing something here?

The last of the criteria to find z says "is a quadratic residue." That has to be the case because

it's assigned to x1 in the case that m = 0. It has to be square.

regards,

Dan.

Thanks

Rob

From: Rene Struik [mailto:rstruik.ext@xxxxxxxxx]
Sent: Friday, November 1, 2019 10:20 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] changes to hash-to-curve algorithm

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hi Dan:

One more glitch (which is also easy to correct):

In my email of yesterday (see below), I suggested I did not know the rationale for requirement 1)iv) {resp. 2)iv)} of Section 14.4.3.2.3.

I checked the internet draft [1] you referenced and it seems that this specific condition is an escape clause in case one would otherwise divide by zero. The condition is then that for u0:=b/(theta*a), this would indeed be a point of the Weierstrass curve with defining equation y^2=f(x):=x^3+a*x+b or, in other words, that f(u0) would be a square in GF(q). If so, the language in Section 14.4.3.2.3, 1)iv) should read - in your notation - f(b/(n*a)):=b^3/(n*a)^3+ b/n + b is a square in the field in question. {Note the b^3 instead of b here}. Similar changes elsewhere.

BTW - a much simpler escape clause would be to map w:=z*u^2 to a fixed point P0 of the curve in case w is equal to 0 or -1 (or avoid this from happening by constraining the input values for u [if z=-1, this corresponds to avoiding u=0 or u=1]).

Ref: [1] draft-irtf-cfrg-hash-to-curve-04

Best regards, Rene

On 10/31/2019 2:53 PM, Rene Struik wrote:

Hi Dan:

I had a quick look at your document and there seems to be a small error (which is fortunately easy to correct):

To my understanding, the specific pick for the non-quadratic residue theta was to make sure that f(x)=theta would have no solutions in GF(q) or, in other words, that g(x):=f(x)-theta would be irreducible over GF(q). If so, the language in Section 14.4.4.2.3, 1)iii) should replace "is not irreducible" by "is irreducible over the field in question", with similar changes elsewhere (Step 2)iii) below this). I do not know what the rationale for the requirement 1)iv) {resp. 2)iv)} is, so cannot give feedback on whether that fits the intended design criteria.

Best regards, Rene

On 10/31/2019 2:00 PM, Harkins, Daniel wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hello,

I have uploaded 11-19/1817r0 which intends to update REVmd to be consistent with the

Internet-Draft from which we copied the hash-to-curve technique. Please take a look. I'd

like to discuss this on the teleconference tomorrow.

regards,

Dan.

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
-- 
email: rstruik.ext@xxxxxxxxx | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

--

email: rstruik.ext@xxxxxxxxx | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1