sc00bz
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).
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.
(Sorry for the history lesson)
P.S. SPAKE2 is a balanced PAKE vs augmented PAKE (or unbalanced PAKE) like OPAQUE and SPAKE2+ (and SPAKE2+EE).
> 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".
"TL;DR: do https://gist.github.com/Sc00bz/ec1f5fcfd18533bf0d6bf31d1211d... instead of SRP."
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.
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.
My win was legit, but there's no way for me to prove that. Well if this was a PR stunt then I should of @defcon or at least #defcon to get a larger audience, but in all reality I'm banned from PayPal and haven't used Bitcoin. Which is why I said I'll settle for a beer, but I should of asked for zcoin after it launches... shit now this is all a PR stunt for "Zooko money".
Anyway if anyone working at PayPal sees this and wants to hook me up by unbanning me that would be nice.
Yes this is a known bug since August 2013. When I found it and reported it. This was "patched" but if Mallory controls the server it is still possible. There were three ways to do this: block (which just doesn't send messages to blocked users), silent drop when invalid MAC, and silent drop when invalid tag. Block was turned into ignore and these three cases now display a warning message stating something about integrity.
I seem to not be able to find me or anyone stating that "if Mallory controls the server it is still possible". So I guess it was only said in person. Technically it's known but not publicly known :).
P.S. This was a "clamp the artery until the mpOTR protocol is finished".