| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Rob, On 8/2/19, 12:48 PM, "Rob Sun" <Rob.Sun@xxxxxxxxxx> wrote: Hi Dan: Thanks for your updated “SAE with SSWU” proposal, I have a few questions and comments : Q1: I have noticed you updated the PT generation from previous version with:
PT(m) := SSWU(h1(m)) + SSWU(h2(m)) (1),
rather PT(m) := SWU(h1(m)) + h2(m) * G (2) , Which was in your previous version of submission. I would assume equation (1) can be expanded as: PT(m) := SSWU(h1(m)) + SSWU(h2(m)) = SWU(h1(m))+ h1(m)*G + SWU(h2(m))+h2(m)*G, with SSWU denotes Brier’s simplified SWU construction, where both the addition are the points addition on the
curve. There are two observations: No, there's no expansion. It is just equation (1). You call SSWU() twice with different "u" values and sum their output. (2) was necessary because the SWU method required some finesse to be provable in the ROM without it but the Simplified SWU now being proposed does not have that problem. SSWU() is not the same as SWU().
i)
Equation (1) involves 3 points additions vs 1 point addition in Equation (2), hence overhead is my concern.
ii)
From indistinguishability point of view, equation (1) is essentially equivalent to (2) in terms of the Random Oracle Encodings.
My question is any particular reasons to update the PT generation from (2) to (1)? From my perspective, equation (1) doesn’t provide any enhancement from (1) in indistinguishability.
Q2: Related to Q1, I think equation (1) is another type of simple hash to curve construction in Brier’s paper, but he admits that using construction (similar to equation (1)) convert to SWU wouldn’t be that
simple (equation (1) is more suitable for Icart’s function ( Page 3 of Brier’s paper).
It's not SWU, it's the "Simplified SWU" and that can be used as (1). SWU cannot and that's why the previous version of the submission had the (2) construct, because it was plain-jane SWU. This is not plain-jane SWU, it is the "Simplified SWU".
Q3: I am yet on the same page of PWE generation needs to be ROM (Random Oracle Model) proof. My understanding is the PWE generation is merely a function of mapping a arbitrary bit string to a curve point,
then the SAE (Dragonfly) protocol part provides the ROM proof. SSWU generation is proved to be ROM encoding in Brier’s paper. In another words, should there be simpler solution than the SWU? i.e the naïve encoding by H(m)*G which is also running in constant
time and efficient. Well yes, there is a simpler solution than SWU. It's the "Simplified SWU" that I am proposing in r9! Feel free to generate your own proof of the protocol that does not require PWE generation in the ROM. In the meantime, I think it is most prudent to go with what's in the submission. regards, Dan. From: Harkins, Daniel [mailto:daniel.harkins@xxxxxxx]
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hello, I have updated 11-19/1173 to do the "Simplified SWU" method of hashing to a curve. This supports all the curves possible with SAE and is more efficient that the previous version. It can be implemented in constant time which will mitigate the side channel and timing attacks described in the recent "Dragonblood" paper. In addition, it mitigates a group downgrade attack (also described in that paper).
https://mentor.ieee.org/802.11/dcn/19/11-19-1173-09-000m-pwe-in-constant-time.docx Please take a look. I have implemented this so I know it works. The question is, though, is this specified in a clear enough way for others to implement.
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 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 |