PAKE¶

Password-authenticated key exchange (PAKE)
PAKE is a method in which two or more parties, based only on their knowledge of a shared password, establish a cryptographic key using an exchange of messages, such that an unauthorized party (one who controls the communication channel but does not possess the password) cannot participate in the method and is constrained as much as possible from brute-force guessing the password. (The optimal case yields exactly one guess per run exchange.)

Password-authenticated key agreement generally encompasses methods such as:

Balanced password-authenticated key exchange
Augmented password-authenticated key exchange
Password-authenticated key retrieval
Multi-server methods
Multi-party methods

Balanced PAKE¶

Balanced PAKE assumes the two parties in either a client-client or client-server situation use the same secret password to negotiate and authenticate a shared key.[1] Examples of these are:

Encrypted Key Exchange (EKE)
PAK and PPK
SPEKE (Simple password exponential key exchange)
Elliptic Curve based Secure Remote Password protocol (EC-SRP or SRP5)
Dragonfly – IEEE Std 802.11-2012, RFC 5931, RFC 6617
CPace
SPAKE1 and SPAKE2
SESPAKE – RFC 8133
J-PAKE (Password Authenticated Key Exchange by Juggling) – ISO/IEC 11770-4 (2017), RFC 8236
ITU-T Recommendation X.1035
"Advanced modular handshake for key agreement and optional authentication"

Augmented PAKE¶

Augmented PAKE is a variation applicable to client/server scenarios, in which the server does not store password-equivalent data. This means that an attacker that stole the server data still cannot masquerade as the client unless they first perform a brute force search for the password. Some augmented PAKE systems use an oblivious pseudorandom function to mix the user’s secret password with the server’s secret salt value, so that the user never learns the server’s secret salt value and the server never learns the user’s password (or password-equivalent value) or the final key.

Examples include:

AMP Augmented-EKE B-SPEKE PAK-X SRP AugPAKE OPAQUE AuCPace SPAKE2+ “Advanced modular handshake for key agreement and optional authentication”

Key retrieval¶

Password-authenticated key retrieval is a process in which a client obtains a static key in a password-based negotiation with a server that knows data associated with the password, such as the Ford and Kaliski methods. In the most stringent setting, one party uses only a password in conjunction with N (two or more) servers to retrieve a static key. This is completed in a way that protects the password (and key) even if N − 1 of the servers are completely compromised.

Brief history¶

The first successful password-authenticated key agreement methods were Encrypted Key Exchange methods described by Steven M. Bellovin and Michael Merritt in 1992. Although several of the first methods were flawed, the surviving and enhanced forms of EKE effectively amplify a shared password into a shared key, which can then be used for encryption and/or message authentication.
The first provably-secure PAKE protocols were given in work by M. Bellare, D. Pointcheval, and P. Rogaway (Eurocrypt 2000) and V. Boyko, P. MacKenzie, and S. Patel (Eurocrypt 2000). These protocols were proven secure in the so-called random oracle model (or even stronger variants),
The first protocols proven secure under standard assumptions were those of O. Goldreich and Y. Lindell (Crypto 2001) which serves as a plausibility proof but is not efficient, and J. Katz, R. Ostrovsky, and M. Yung (Eurocrypt 2001) which is practical.
The first password-authenticated key retrieval methods were described by Ford and Kaliski in 2000.
A considerable number of alternative, secure PAKE protocols were given in work by M. Bellare, D. Pointcheval, and P. Rogaway, variations, and security proofs have been proposed in this growing class of password-authenticated key agreement methods. Current standards for these methods include IETF RFC 2945, RFC 5054, RFC 5931, RFC 5998, RFC 6124, RFC 6617, RFC 6628 and RFC 6631, IEEE Std 1363.2-2008, ITU-T X.1035 and ISO-IEC 11770-4:2006.