SRP

1pwuser31547

SRP is very a very clever protocol.
I appreciate the many security layers, including this interesting one, that you offer.

After reading your white paper, I did some more reading and discovered that there's a somewhat new PAKE called OPAQUE that has one unique advantage over SRP in that the salt is not revealed, thus preventing pre-computation attacks.
Additionally, SRP, as I understand it, is not supported in (the current version of) TLS 1.3.

Just curious, for my understanding, what do you think about OPAQUE? Is this something you are considering for the future and what do you think about TLS 1.3 apparent incompatibility with SRP?

Thanks!

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

jpgoldberg

My first reaction when I read the OPAQUE paper back in Spring 2018 was ...

So, I am definitely with you @1pwuser31547 in principle.

But it is important to understand why we went with SRP in the first place (back in 2016). It's not because SRP was the best PAKE out there at the time. But it was the best PAKE out there which we could implement in all of our clients. Because of the diversity of our client platforms, we effectively needed to "roll our own" implementation. That is not something we would normally like to do, but it was the only way to get a PAKE at the time. Keep in mind that one of our clients is a web client. So among other criteria, we strongly preferred a PAKE that worked on integer fields instead of elliptic curves, as the math is easier to get right given the tools we have available.

These reasons still apply, but to a lesser extent. We are getting closer to the point where we are less constrained by what is natively available in browsers, and there are more well-developed libraries that we can use for some of our clients, but it will still take time before we are ready to upgrade our PAKE and key derivation function (KDF). And whatever we do, will need to be rolled out to all clients before we can start creating accounts with any new systems.

1pwuser31547

Thanks so much for the explanation-really appreciate the follow up.
Too bad SRP isn't used more extensively, especially for sensitive sites (although I've read that Apple also uses SRP).
Like the pic!

jpgoldberg

Too bad SRP [or other PAKEs] isn't used more extensively,

I haven't studied the history carefully enough to say this with any certainty, but I suspect that some of this is due to patents. Another reason we went with SRP when we did is because there at the time we were exploring this it looked like the safest to use from a patent point of view. Since then, some of the other patents that could apply to PAKEs have expired.

So really, the world should have been using these sorts of technologies for decades. I can't say for sure that patents are the reason why these are only coming into use now, but I do suspect that that is part of the story.

I've read that Apple also uses SRP

Yes. And their implementation in core crypto is available to the public (though it wasn't at the time that we first started building our use of SRP.)

1pwuser31547

Thank you again for clarifying- very helpful.

Ben

On behalf of Goldberg, you're very welcome. :)

Ben