3 ms·
> It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP. No, that is not what I'm saying. Th
by cvwright 5y ago
> It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP.
No, that is not what I'm saying. The SRP paper says "Use a hash function to hash the password". When SRP was new, that might plausibly have been MD5, and if not, then probably something else like SHA-1 that is now unsafe. I'm saying, in 2021 use a hash function that doesn't suck for hashing passwords, like bcrypt or argon.
> You're certainly not correct that the article is saying SRP is flawed because it "relies on the discrete log problem", as ECDLP-based PAKEs are also vulnerable to QC.
Hmm good point. I must have interpreted the whole "Quantum annoyance" thing too strongly then.
- tptacek 5y agoNo, that's not what the article is saying. It's saying that in addition to (1) being based on old multiplicative group cryptography, (2) lacking a security proof, and (3) not being built on a construction we already trust (Noise-KN) and instead its own weird protocol, it's also misuse-prone, because an easy state machine misstep that lots of people make gets you a server that allows offline password guesses. Further, there's simply no reason to use it; there are better, equivalently simple protocols available. Even if you wanted to use simple multiplicative group DH math, the article points out, you could just instantiate BS-SPEKE on it; it even provides the formulae. Nobody has "broken" SRP6a, just like nobody has really "broken" DES-EDE, or HMAC-MD5. But you clearly shouldn't be using any of them.
- cvwright 5y agoSRP never got a security proof?!? Wtf man? I guess standards for publication have, uh, evolved a bit over the past 20 years. Thanks for the explanation, this was helpful.