Secure remote password protocol

The Secure Remote Password Protocol (SRP) is a password-authenticated key agreement protocol which allows a user to authenticate herself to a server, which is resistant to dictionary attacks mounted by an eavesdropper, and does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server. Even if the server is successfully attacked, an attacker would still have some difficulty extracting a password — they will be able to use the captured information to impersonate a server, but not a client. Only one password can be guessed at per attempt in revision 6 of the protocol. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision six.

The SRP protocol creates a private key shared between the two parties, then tests to see if the two keys are identical. In cases where encrypted communications as well as authentication are required, the SRP protocol is more secure than the alternate SSH protocol and faster than using Diffie-Hellman with signed messages. It is also independent of third parties, unlike Kerberos (protocol). The SRP protocol, version 3 is described in RFC 2945. SRP version 6 is also used for strong password authentication in SSL/TLS and other standards such as EAP and SAML, and is being standardized in IEEE P1363 and ISO/IEC 11770-4.

In this description of the protocol, version 6,

N and q = ( N -1)/2 are both prime ( N is a safe prime and q is a Sophie Germain prime). All arithmetic is performed modulo N .

g is a generator of the multiplicative group modulo N ,

k is a parameter derived by both sides, for example k = H ( N , g ).

s is a salt,

I is a username,

p is the cleartext password,

H () is a hash function

v is the host s password verifier, v = g x, x = H ( s , p )

u , a and b are random.

and | denotes concatenation

All other variables are defined in terms of these. To establish a password p with Steve, Carol picks a random salt s, and computes x = H ( s , p ), v = g x. Steve stores v and s, indexed by I, as Carol s password verifier and salt. x is discarded because it is equivalent to the plaintext password p.

Carol -> Steve: I | A ,with A = g a

Steve -> Carol: s | B , with B = kv + g b

Both: u = H ( A , B )

Carol: S Carol = ( B - kg x)(a + ux)

Carol: K Carol = H ( S )

Steve: S Steve = ( Av u)b

Steve: K Steve = H ( S )

Now the two parties have a shared, strong session key K . To complete authentication, they need to prove to each other that their keys match. One possible way is:

Carol -> Steve: M 1 = H ( H ( N ) XOR H ( g ) | H ( I ) | s | A | B | K Carol). Steve verifies M 1.

Steve -> Carol: M 2 = H ( A | M | K Steve). Carol verifies M 2.

This method requires guessing more of the shared state to be successful in impersonation than just the key. While most of the additional state is public, private information could safely be added to the inputs to the hash function, like the server private key. The two parties also employ the following safeguards: 1. Carol will abort if she receives B == 0 (mod N ) or u == 0 . 2. Steve will abort if he detects that A == 0 (mod N ). 3. Carol must show her proof of K first. If Steve detects that Carol s proof is incorrect, he must abort without showing its own proof of K .

=External links=

*[http://srp.stanford.edu Official Site] *[http://www.ietf.org/rfc/rfc2945.txt RFC 2945] *[http://grouper.ieee.org/groups/1363/ IEEE 1363]

=See also=

Password-authenticated key agreement