Super fun fact: Blizzard's (ie World of Warcraft's) safe prime was 256 bits which was known to be broken at the time, but no one really knew this until they got hacked and their database got leaked.
Super-duper fun fact: Before Blizzard moved to SRP, they fubared SHA1 by shifting 1 by a variable vs shifting a variable by 1. This meant that after the shift it was one of 32 values. Which let's one crack or collide the "XSHA1" hash in seconds. I was going to say just google "XSHA1" and you'll get my website with attack code but I think Google de-listed it... maybe I should link to Github vs a zip with code and a .exe... or make my site mobile friendly (for better ranking).
P.S. I thought Blizzard used SRP6a... although I'm not familiar with every SRP version. I looked at the early versions of SRP (I think I got to v3) and they were obviously broken (from the understanding of what a PAKE threat model should be).
> Apparently, it's based on "aPAKE" which stands for "Asymmetric PAKE"
It is an "aPAKE" which stands for "augmented PAKE". An aPAKE is client-server vs peer-to-peer. The original PAKE was peer-to-peer then augmented to be client-server. A peer-to-peer PAKE is called PAKE or balanced PAKE, but "PAKE" could be use generally to mean client-server and/or peer-to-peer PAKE. aPAKEs are sometimes called unbalanced PAKEs.
I've heard people say asymmetric PAKE and symmetric PAKE (for client-server and peer-to-peer), but this causes confusion with asymmetric and symmetric cryptography. Thus should not be used. And was likely from a misunderstanding around what "a" meant in "aPAKE".
Oh there is a "double augmented PAKE" which I recently figured out a use case for that, WiFi. Also technically OPAQUE is a "double augmented PAKE", but only defined as an augmented PAKE.
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".
This was recently broken then fixed. I heard about it because of that then looked at it and broke it again. I only checked one thing and it was wrong. I would not trust this. Also SPEKE based PAKEs are better.
PAKEs are secure over insecure channels. Also I'm pretty sure for RFC2289 the server stores a password equivalent. If you neither care about creating an encrypted session nor being secure over an insecure channel, then you should use SCRAM. With SCRAM, the server stores a password hash equivalent. Meaning an attacker needs to crack the password before they can login as them.
The context was someone implementing SRP6a because they didn't have Ristretto255. This is actually what made me write this article.
----
Anyway, if it was that short then one wouldn't have learned as much about PAKEs, how they work, and some properties of them. One of the things I knew about PAKEs but never like formed it into a thought was "The basic idea of a PAKE is to hide something. The three main things one can hide are the ephemeral public key[s] (like SRP6a), the generator, and/or (for aPAKEs) the salt." Every PAKE falls into one of those categories. Well besides maybe J-PAKE that's a "commit-reveal". Which is hiding the thing being committed. I don't know what's being committed or how it's be committed or revealed. So it might fit in one of the categories. I have notes on J-PAKE from reading the paper but stopped at "now read this other paper to find out what the 6 'NIZK' functions calls do". J-PAKE makes VTBPEKE look like a good PAKE. VTBPEKE hides the generator and also has a commit-reveal. It's designed like this either because of patents or proofs... or both.
Related but you should be doing this regardless. Ctrl+Shift+Del and clear everything since forever ago. I do "Ctrl+Shift+Del, Enter" several times a day and use 2 browsers: stuff I'm logged into and everything else. Sometimes 3 browsers to segment logged in accounts.
P.S. If you have Chrome installed (on Windows) set this folder "C:\Users\*\AppData\Local\Google\Chrome\User Data\SwReporter\" to deny all access for each group and user.
Super-duper fun fact: Before Blizzard moved to SRP, they fubared SHA1 by shifting 1 by a variable vs shifting a variable by 1. This meant that after the shift it was one of 32 values. Which let's one crack or collide the "XSHA1" hash in seconds. I was going to say just google "XSHA1" and you'll get my website with attack code but I think Google de-listed it... maybe I should link to Github vs a zip with code and a .exe... or make my site mobile friendly (for better ranking).
P.S. I thought Blizzard used SRP6a... although I'm not familiar with every SRP version. I looked at the early versions of SRP (I think I got to v3) and they were obviously broken (from the understanding of what a PAKE threat model should be).