Subject: [Cfrg] PAKE Selection Process: Round 2, Stage 2

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 9 Dec 2019 15:43:35 +0300

Dear CFRG,

According to the plan of Round 2 of the PAKE selection process, additional
questions for all four remaining candidates have been collected from CFRG
participants (and Crypto Review Panel members) via [email-masked] .

We've obtained the following list of questions:
1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all
existing good properties of PAKE2) with a correspondingly updated security
proof, addressing the issue of a single discrete log relationship necessary
for the security of all sessions (e.g., solution based on using
M=hash2curve(A|B), N=hash2curve(B|A))?
2) (to CPace and AuCPace): Can you propose a modification of CPace and
AuCPace (preserving all existing good properties of these PAKEs) with a
correspondingly updated security proof (maybe, in some other security
models), addressing the issue of requiring the establishment of a session
identifier (sid) during each call of the protocol for the cost of one
additional message?
3) (to all 4 remaining PAKEs) : Can the nominators/developers of the
protocols please re-evaluate possible IPR conflicts between their
candidates protocols and own and foreign patents? Specifically, can you
discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of
march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV,
expected expiration October 2026) on the free use of the RFC-drafts for
OPAQUE?
4) (to all 4 remaining PAKEs) What can be said about the property of
"quantum annoyance" (an attacker with a quantum computer needs to solve
[one or more] DLP per password guess) of the PAKE?
5) (to all 4 remaining PAKEs) What can be said about "post-quantum
preparedness" of the PAKE?

Please let the chairs and the Crypto Review Panel members know (before
December, 17th) if any questions (collected via  [email-masked])
have been lost or misinterpreted (or something needs to be added).

Best regards,
Stanislav,
CFRG Secretary

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Dec 2019 07:41:17 -0800

> M=hash2curve(A|B), N=hash2curve(B|A))?

Yes: See https://github.com/kaduk/spake2/pull/10 and for the security
proof,  https://eprint.iacr.org/2019/1194. I'll submit it shortly, but this
should indicate where we are going.

> expected expiration October 2026) on the free use of the RFC-drafts for

I'm not a patent lawyer, or any kind of lawyer. This sounds like a question
for a patent lawyer, rather then uninformed speculation on the list.

> [one or more] DLP per password guess) of the PAKE?

I'll have to look at the papers some more. Will answer in a few days.

> preparedness" of the PAKE?

There isn't a great answer here for SPAKE2 AKAIK. Postquantum primitives
don't smoothly translate point addition or group laws.

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 9 Dec 2019 18:45:23 +0300

Dear Watson,

Thanks, but we're still collecting the questions, the authors (including
you for SPAKE2) will have time at Stage 3 (December 25th - February, 10th)
to prepare the replies (Stage 3: "The authors of the candidates prepare
their replies to the additional questions/requested clarifications.").

пн, 9 дек. 2019 г. в 18:41, Watson Ladd <[email-masked]>:

>> According to the plan of Round 2 of the PAKE selection process,
>> additional questions for all four remaining candidates have been collected
>> from CFRG participants (and Crypto Review Panel members) via
>> [email-masked] .
>>
> proof,  https://eprint.iacr.org/2019/1194. I'll submit it shortly, but
> this should indicate where we are going.
>
> I'm not a patent lawyer, or any kind of lawyer. This sounds like a
> question for a patent lawyer, rather then uninformed speculation on the
> list.
>

---

From: [email-masked]
Date: Fri, 20 Dec 2019 19:23:51 -0600 (CST)

I am not affiliated with the remaining candidates or the panel, but here are my answers to aid the remaining candidates (except #3 because I don't know patents).

> On December 9, 2019 at 6:43 AM "Stanislav V. Smyshlyaev" <[email-masked]> wrote:
> 
> 
> Dear CFRG,
> 

There is an Elligator edition for SPAKE2 called SPAKE2-EE (not to be confused with SPAKE2+EE the augmented PAKE versions). Most implementations will likely have A as "A", "Alice", or other fixed value and B as "B", "Bob", or other fixed value making "M=hash2curve(A|B)" pointless. Also SPAKE2-EE would be faster: "A = a * G + hashToPoint(k1)" vs "A = a * G + k1 * hashToPoint(A|B)". Lastly SPAKE2-EE is quantum annoying while SPAKE2 and suggested change are not.

Note Elligator edition is a misleading name because you can use SWU or other hash to point algorithms.

> identifier (sid) during each call of the protocol for the cost of one

Only CPace has an extra message. AuCPace with or without sid is the same number of messages. Also I don't see the point of sid in AuCPace since it's acting as a salt but since it's an aPAKE there's already a salt. This is why I say B-SPEKE is better than AuCPace. For CPace the sid I believe is needed. I'm pretty sure I've implemented SPAKE2-EE with a "sid" because I wanted a salt for the password KDF.

> expected expiration October 2026) on the free use of the RFC-drafts for

I didn't read the patents, but SPEKE is prior art for CPace and AuCPace circa October 1996. Since CPace and AuCPace are just salted SPEKE.

> [one or more] DLP per password guess) of the PAKE?

CPace and AuCPace have quantum annoyance.

If SPAKE2 is modified to use the Elligator edition (SPAKE2-EE), then it will have quantum annoyance. Note Elligator edition is a misleading name because you can use SWU or other hash to point algorithms.

OPAQUE needs a complete redesign to gain quantum annoyance.
**** Important ****
This is because OPAQUE has a property I call fragile. Which means if one can solve a static DH oracle (which is the easiest way to attack DH), then it breaks. Also OPAQUE is the worst in a PQ world since you don't need to observe a successful exchange. An attacker acts like they are guessing a wrong password, collect messages, solve the OPRF DLP, and guess passwords offline against the encrypted blob.
**** Important ****

> preparedness" of the PAKE?

Given a PQ OPRF, all these PAKEs are PQ. Also note you can do both a PQ OPRF and a classical OPRF just in case the PQ OPRF turns out to not be secure. For balanced PAKEs, you only need a PQ OPRF.

---

From: [email-masked]
Date: Sat, 28 Dec 2019 12:03:39 -0600 (CST)

Minor note on #5 by "Given a PQ OPRF, all these PAKEs are PQ." I mean over the wire PQ. The server data is not PQ. The balanced PAKEs are fully PQ, but the augmented PAKEs are only over the wire PQ. Since the server verifier (or what not) are a solved DLP away from an attacker being able to masquerade as a client.

> On December 20, 2019 at 7:23 PM [email-masked] wrote:
> 
>