PBKDF integration?

[baryluk]

Hi,

I understand that for most parts SRP do not need costly KDF for password, but I think some way to impose some additional CPU or RAM cost on the client (but not server), would be beneficial to implement a active brute force prevention mechanism without requiring extensive state on the server side.

PBKDF2, scrypt, Catena, Lyra2, Argon2id sounds like reasonable choices, but AFAIK they can't be readily applied to SRP, because, even if key is randomized (and provided by server), the server have no way to verify computations, as the resulting key would have no correspondence to the data stored on server (verifiers). Storing passwords on server too defeats the purpose, and would make other problems (i.e. opening to brute force attacks from data observed passively by adversary).

Also they would make incur same CPU and RAM cost on both sides, which is undesirable. My favorite of asymetric proof of work is Cuckoo Cycle finding, which is memory (storage and random access) intensive and CPU intensive (but not deterministic, only expected runtime) on the client side, but very cheap (almost no RAM and CPU used, few orders of magnitude less than on client side, and constant time/deterministic/bounded) on the verifier side.

I am not sure, maybe just addition of a phase 0, beyond SRP protocol is a solution here, like just proving computations where made before starting SRP, to prevent DoS. But that adds roundtrips, or alternatively opens solution probe to replay attack.

[baryluk]

I just learned about OPAQUE that is addressing this issue:

https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/

https://eprint.iacr.org/2018/163.pdf

It also solves a problem of offline precomputation attack, by not revealing salt to attacker.

[baryluk]

Specific protocol draft - https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-00 , it was published just 2 weeks ago ;)