Secure password-authenticated key exchange that allows for passwords to be stored as hashes, but does not make the hashes password-equivalent

Question

Are there any secure password-authenticated key exchange that allows for passwords to be stored as hashes, but does not make the hashes password-equivalent? This would be useful for many authentication applications.

Answer 1

Are there any secure password-authenticated key exchange that allows for passwords to be stored as hashes, but does not make the hashes password-equivalent?

Yes, they are called augmented or asymmetric password-authenticated key exchanges (aPAKE). They generally build on the scenario that the user knows a password and the server may only store a "verifier" that should at most admit off-line brute-force search of the password and the key exchange should only succeed if the right password is match with the right verifier.

There are extensions to this approach which also consider cases where the user has a second device (e.g. a smart card or a phone) and a connection between his primary and secondary device, for an overview of the protocols, see here.

The most notable standard aPAKE is currently OPAQUE, which has already been announced to soon get an IRTF / CFRG draft and hopefully someday become an RFC, see this email thread.

The basic idea of OPAQUE goes as follows:

1. Upon registration the server generates a random key $k$ and two DH key-pairs and stores one of the private key as well as the random key and the two public keys in clear and computes $H(pw,H'(pw)^k)$ with the random key to get an encryption key which is used to perform an authenticated encryption over the complete second DH key and its own DH public key.
2. Upon a login request the client chooses its own DH public key as well as a random key which is used to exponentiate the inner hash of the of the password, ie $H(pw)$.
3. The server then retrieves the data stored on registration, generates a fresh DH keypair, exponentiates the received exponentiated hash with the stored $k$ and computes a key-exchange (HMQV is recommended) over its long-term secret DH key, its short-term DH secret key, the received short-term DH public key and the stored long-term DH public key.
4. The client undoes the exponentiation from 2. and evaluates $H(pw,X)$ on the result. This can e.g. be a memory-hard hash function taking the second input as the salt. It uses the resulting key to decrypt the stored ciphertext and itself computes the key-exchange.