OPAQUE protocol versus PAKE protocol

[winwisely99]

https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/

I am using croc. What do you think of OPAQUE ?

[Sc00bz]

OPAQUE is an augmented PAKE (aPAKE, client-server) and croc can use a balanced PAKE (peer to peer). Balanced PAKEs are normally faster than aPAKEs. Also OPAQUE is meh. It added one cool thing that can be added to any aPAKE but then created a huge mess with encryption and static DH. Also OPAQUE was created to push a patented AKE called HMQV. If they weren't trying to push this patented algorithm then they would of went with basically "OPAQUE-no-AEAD-Noise-KN" as the official OPAQUE. Also static DH makes OPAQUE fragile. I'd go with an aPAKE that's not fragile and quantum annoying (sort of hard to break even if you have a quantum computer): BS-SPEKE, (strong) AuCPace, or BSPAKE. For a balanced PAKE, like croc needs, I'd go with CPace or SPAKE2-EE (not to be confused with SPAKE2+EE, an aPAKE).

[LRFLEW]

I agree that an augmented PAKE would be a bad fit for croc. The CFRG Pake Competition chose CPace as its choice for a balanced PAKE, with SPAKE2 coming in a very close second, so both would be good alternatives to the PAKE used here. (I haven't heard of SPAKE2-EE, but it sounds like it's probably a sort-of hybrid of the two)

Has there been any significant third-party analysis of the security of the PAKE used here? "PAKE2" is not a very specific name when trying to google it, and adding the authors' names only seems to come up with the same source for the protocol as linked to in the README. If this PAKE is secure, I don't see much reason to change it, but if there's reason to be concerned about it, it might be worth switching to (or at least adding) one of the Go libraries that implements CPace using Ristretto255.

[Sc00bz]

PAKE2 and SPAKE2 are basically the same, if not the same. SPAKE2-EE is not a hybrid of CPace and SPAKE2. CPace is based on SPEKE (hide the generator) and SPAKE2-EE is based on SPAKE2 (hide the ephemeral public key[s]). CPace is better than SPAKE2-EE which is better than SPAKE2 which "is" PAKE2. Oh wait I think SPAKE2 is the elliptic curve version of PAKE2 which is defined on multiplicative groups.

But I do not trust the people behind croc to implement Elligator—LOL. So maybe go with a multiplicative group version of CPace or stay with SPAKE2.

[Sc00bz]

Oh right "SPAKE2-EE" is the "Elligator Edition" of SPAKE2.

If this PAKE is secure, I don't see much reason to change it, but if there's reason to be concerned about it, it might be worth switching to (or at least adding)

The current PAKE is secure, but the others are "more secure" since they are "quantum annoying".

one of the Go libraries that implements CPace using Ristretto255

Oh yeah, use one of those.

[LRFLEW]

PAKE2 and SPAKE2 are basically the same, if not the same.

Oh, I see it now. I had previously skimmed the SPAKE2 draft RFC and got confused by the difference in notation (the linked source for PAKE2 used multiplicative notation, while the RFC used additive notation) and the RFC specifying the key confirmation messages as part of the protocol.

In this case, I'm not too concerned about the security of this. I don't particularly like the hard-coded a and b (U and V in the code, M and N in the RFC), but it's not a huge concern. I don't see much reason for the PAKE to be changed if it is secure as-is, as changing it would create a compatibility break.