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

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" <smyshsv@gmail.com> wrote:
> 
> 
> 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 crypto-panel@irtf.org .
> 
> 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))?

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.

> 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?

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.

> 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?

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.

> 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?

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 ****

> 5) (to all 4 remaining PAKEs) What can be said about "post-quantum
> 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.

> 
> Please let the chairs and the Crypto Review Panel members know (before
> December, 17th) if any questions (collected via  crypto-panel@irtf.org)
> have been lost or misinterpreted (or something needs to be added).
> 
> Best regards,
> Stanislav,
> CFRG Secretary
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg