3 ms·

Why did he recommend OPAQUE over others like SPAKE2? Re: Green's question on why it is not more widely deployed, I assume it is since TLS already is common and

Why did he recommend OPAQUE over others like SPAKE2? Re: Green's question on why it is not more widely deployed, I assume it is since TLS already is common and PAKE would be an additional layer of encryption on this? Or is his proposal use PAKE for auth then discard keys, use TLS normally?

tialaramex 5y ago
I don't know why OPAQUE was chosen in this 2018 article, but OPAQUE was eventually selected as CFRG's preferred asymmetric PAKE PAKEs are a fairly specialist protocol. If you don't need to use human memorable passwords then you should not do so. There are cases where you can't bootstrap some other means but you do have, or can agree, a human memorable password and PAKEs are a good choice then. So there are lots of problems where a PAKE would be better than what you have today, but what you have today is rubbish and it makes more sense to do the Right Thing™ instead. I don't want Hacker News to authenticate me with a PAKE instead of crummy password-in-a-form technology, the right thing is WebAuthn. Even for one of the places a PAKE is commonly used today WiFi (WPA3) this is true. The PAKE is used to make the crummy WiFi shared password scheme less broken, and it's an improvement over prior approaches. But just not doing PSKs at all is better. An EduROAM participant from say, CalTech using WiFi on a trip to Rome isn't relying on a PAKE, they are doing full user authentication proxied to CalTech to authorise access to the Roman WiFi.
- sc00bz 5y ago
  OPAQUE was chosen because it was new and had the new "no precomputation" property. Which can be added to better PAKEs by adding an OPRF vs just sending the salt. OPRFs can be added without adding an extra trips to the protocol. > the right thing is WebAuthn. True, but if a good PAKE is added to TLS (it won't) then your logged-in sessions are protected by needing to solve a DLP for every password guess (ie "quantum annoyance", a property of a good PAKE). This does assume quantum computers become a thing. > WiFi (WPA3) They used the worst PAKE available. They even used the wrong class of PAKEs (balanced vs unbalanced (or augmented "aPAKE")). > and it's an improvement over prior approaches. No, it was broken but maybe it's fixed? The original version is basically "WEP 2.0" and they likely have backwards compatibility because "oops, we published a spec with a known to be broken PAKE... but it was an IEEE PAKE, don't blame us".
sc00bz 5y ago
I was team SPAKE2 based PAKEs, but I now know that SPEKE based PAKEs are better. P.S. SPAKE2 is a balanced PAKE vs augmented PAKE (or unbalanced PAKE) like OPAQUE and SPAKE2+ (and SPAKE2+EE).

tialaramex 5y ago

I don't know why OPAQUE was chosen in this 2018 article, but OPAQUE was eventually selected as CFRG's preferred asymmetric PAKE PAKEs are a fairly specialist protocol. If you don't need to use human memorable passwords then you should not do so. There are cases where you can't bootstrap some other means but you do have, or can agree, a human memorable password and PAKEs are a good choice then. So there are lots of problems where a PAKE would be better than what you have today, but what you have today is rubbish and it makes more sense to do the Right Thing™ instead. I don't want Hacker News to authenticate me with a PAKE instead of crummy password-in-a-form technology, the right thing is WebAuthn. Even for one of the places a PAKE is commonly used today WiFi (WPA3) this is true. The PAKE is used to make the crummy WiFi shared password scheme less broken, and it's an improvement over prior approaches. But just not doing PSKs at all is better. An EduROAM participant from say, CalTech using WiFi on a trip to Rome isn't relying on a PAKE, they are doing full user authentication proxied to CalTech to authorise access to the Roman WiFi.

sc00bz 5y ago
OPAQUE was chosen because it was new and had the new "no precomputation" property. Which can be added to better PAKEs by adding an OPRF vs just sending the salt. OPRFs can be added without adding an extra trips to the protocol. > the right thing is WebAuthn. True, but if a good PAKE is added to TLS (it won't) then your logged-in sessions are protected by needing to solve a DLP for every password guess (ie "quantum annoyance", a property of a good PAKE). This does assume quantum computers become a thing. > WiFi (WPA3) They used the worst PAKE available. They even used the wrong class of PAKEs (balanced vs unbalanced (or augmented "aPAKE")). > and it's an improvement over prior approaches. No, it was broken but maybe it's fixed? The original version is basically "WEP 2.0" and they likely have backwards compatibility because "oops, we published a spec with a known to be broken PAKE... but it was an IEEE PAKE, don't blame us".

sc00bz 5y ago

I was team SPAKE2 based PAKEs, but I now know that SPEKE based PAKEs are better. P.S. SPAKE2 is a balanced PAKE vs augmented PAKE (or unbalanced PAKE) like OPAQUE and SPAKE2+ (and SPAKE2+EE).