The protocol consists of little more than a Diffie–Hellman key exchange where the Diffie-Hellman generator g is created from a hash of the password.

Here is one simple form of SPEKE:

1. Alice and Bob agree to use an appropriately large and randomly selected safe prime p, as well as a hash function H().
2. Alice and Bob agree on a shared password π.
3. Alice and Bob both construct g = H(π)² mod p. (Squaring makes g a generator of the prime order subgroup of the multiplicative group of integers modulo p.)
4. Alice chooses a secret random integer a, then sends Bob g^a mod p.
5. Bob chooses a secret random integer b, then sends Alice g^b mod p.
6. Alice and Bob each abort if their received values are not in the range [2,p-2], to prevent small subgroup confinement attack.
7. Alice computes K = (g^b mod p)^a mod p.
8. Bob computes K = (g^a mod p)^b mod p.

Both Alice and Bob will arrive at the same value for K if and only if they use the same value for π. Once Alice and Bob compute the shared secret K they can use it in a key confirmation protocol to prove to each other that they know the same password π, and to derive a shared secret encryption key for sending secure and authenticated messages to each other. The use of a key confirmation protocol is optional, as specified in the IEEE P1363.2 and ISO/IEC 11770-4 standards.

Unlike unauthenticated Diffie-Hellman, SPEKE prevents man-in-the-middle attack by the incorporation of the password. An attacker who is able to read and modify all messages between Alice and Bob cannot learn the shared key K and cannot make more than one guess for the password in each interaction with a party that knows it.

In general, SPEKE can use any prime order group that is suitable for public key cryptography, including elliptic-curve cryptography. However, when SPEKE is realized by using Elliptic-curve cryptography, the protocol is essentially changed by requiring an additional primitive that must securely map a password onto a random point on the designated elliptic curve. (This primitive is called the IOP or Integer-to-Point function in IEEE P1363.2 and ISO/IEC 11770-4.)

SPEKE is one of the older and well-known protocols in the relatively new field of password-authenticated key exchange. It was first described by David Jablon in 1996.^[1] In this publication Jablon also suggested a variant where, in step 2 of the protocol, g is calculated as g = g_q^S with a constant g_q. However, this construction turned out to be insecure against dictionary attacks and was therefore not recommended anymore in a revised version of the paper. In 1997 Jablon refined and enhanced SPEKE with additional variations, including an augmented password-authenticated key agreement method called B-SPEKE.^[2] A paper published by MacKenzie in 2001 presents a proof in the random oracle model that SPEKE is a secure PAKE protocol (using a somewhat relaxed definition) based on a variation of the Decision Diffie-Hellman assumption.^[3] However, the proof treats the key confirmation function in SPEKE as mandatory, which is not how SPEKE is specified in the IEEE P1363.2 and ISO/IEC 11770-4 standards.

Since 1999, the protocol has been used by several companies in a variety of products, typically supplementing other cryptographic techniques.

In 2014, two attacks are identified against the SPEKE protocol as specified in the original Jablon's 1996 paper and in the IEEE P1363.2 (D26) and ISO/IEC 11770-4 (2006) standards.^[4] The first attack allows an active attacker to impersonate a user without knowing the password by launching two parallel sessions with the victim. The second attack allows a man-in-the-middle attacker to manipulate the session key between two honest users without being detected. The first attack indicates a practical weakness of the protocol while the second attack has theoretical implications on security proofs of SPEKE. During the ISO/IEC JTC 1/SC 27 meeting in Mexico City in October 2014, the two attacks were discussed by the technical committee in ISO/IEC SC 27/Work Group 2, and it had been agreed that the SPEKE specification in ISO/IEC 11770-4 (2006) should be revised to address the identified issues. The proposed patch involves explicitly defining session identities, and including those identities into the key derivation function in a way that does not change the symmetry of the protocol. The patched SPEKE has been published in ISO/IEC 11770-4 (2017).^[5] However, the SPEKE specification in IEEE P1363.2 remains unpatched.

U.S. patent 6,226,383 describes several variations of the method. This patent expired in March 2017.

Standards that describe SPEKE include IEEE P1363.2 and ISO/IEC 11770-4. In the latest ISO/IEC 11770-4 (2017) standard, the SPEKE specification is revised from the previous one in ISO/IEC 11770-4 (2006) to address the two attacks reported by Hao and Shahandashti in 2014.^[4]

• Links for password-based cryptography
• IETF - SPEKE methods (work in progress)