So the two main problems with SRP, according to this post, are:
1. It exposes the salt and verifier to the adversary, enabling a brute-force search for the password
2. It relies on the discrete log problem, and is thus vulnerable to quantum computers
In practice, I don't buy the argument that either one of these is a deal breaker, as long as you do SRP in a "modern" way, ie you're not tied verbatim to some 1997 version of the spec.
For #1, if you hash the password with a decent password hashing function (bcrypt/scrypt/argon2) with a reasonable work factor, then only the dumbest/worst passwords are at risk of being cracked in any reasonable amount of time. Notice that the password hashing happens entirely on the client, so you can crank that work factor up pretty high.
For #2, if somebody builds a huge quantum computer big enough to take on these problems, then we are so freaking screwed in so many other ways. SRP logins will be the least of our concerns.
Not to take away from EKE and its derivatives in any way. I've been a huge fan of the original Bellovin & Merritt construction since I first read about it 20 years ago.
I don't understand what you're trying to say here. 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.
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.
> 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.
No, 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.
1. It exposes the salt and verifier to the adversary, enabling a brute-force search for the password
2. It relies on the discrete log problem, and is thus vulnerable to quantum computers
In practice, I don't buy the argument that either one of these is a deal breaker, as long as you do SRP in a "modern" way, ie you're not tied verbatim to some 1997 version of the spec.
For #1, if you hash the password with a decent password hashing function (bcrypt/scrypt/argon2) with a reasonable work factor, then only the dumbest/worst passwords are at risk of being cracked in any reasonable amount of time. Notice that the password hashing happens entirely on the client, so you can crank that work factor up pretty high.
For #2, if somebody builds a huge quantum computer big enough to take on these problems, then we are so freaking screwed in so many other ways. SRP logins will be the least of our concerns.
Not to take away from EKE and its derivatives in any way. I've been a huge fan of the original Bellovin & Merritt construction since I first read about it 20 years ago.