# Should you use SRP?

This page has some askew notes about the Secure Remote Password protocol. TL ; DR : I don ’ thymine like it. It ’ south besides not obviously break. But it ’ s ineffective and you should use OPAQUE .
Like most PAKE protocols, SRP has two phases. In the sign-up phase, the user registers a “ password voucher ” with the server. This prize is not actually the password itself. It ’ s not even the hash password. It ’ s actually a one-way affair of the hash password, of the human body $g^{Hash(salt, password)}$ computed using a Diffie-Hellman-like serve .
frankincense the login process looks something like this :

### The SRP (v4) protocol

To generate the voucher, the customer first picks some salt, and then computes the postdate. The values $g, p, k$ are constants specified as separate of the protocol. We ’ ll assume that Hash ( ) is a solid password hashing officiate like scrypt .

```  x = Hash(salt, passwd)    (salt is chosen randomly)
v = g^x                   (computes password verifier)```

The server stores the voucher ( five, strategic arms limitation talks ) in its database, along with the User ID. To run the actual PAKE protocol, the client and server execute the stick to steps using the ( waiter ) ’ sulfur stored voucher $(v, salt)$. eminence that in this description, g^a is shorthand for “ gravitational constant raised to the baron a modulo phosphorus ” .

```Client -> Svr:  User ID, A = g^a            (identifies self, a = random number)
Svr -> Client:  salt, B = kv + g^b          (sends salt, b = random number)

Both:  u = H(A, B)

Client:  x = Hash(salt, passwd)         (user enters password)
Client:  S = (B - kg^x) ^ (a + ux)      (computes session key)
Client:  K = H(S)

Svr:  S = (Av^u) ^ b              (computes session key)
Svr:  K = H(S)```

If the protocol above is successful — that is, the client used the right password — the customer and server should immediately share a session key K. To verify that this is the case, the SRP specification recommends they send two extra “ check ” messages :

```Client -> Svr:  M = H(H(N) xor H(g), H(I), salt, A, B, K)
Svr -> Client:  H(A, M, K)
```

Both parties should have all the ingredients to check the correctness of the measure sent by the early party, and that ’ s the ball game .

### What the hell is going on here?

I ’ ll be honest, that even to a cryptanalyst, the design rationale for SRP is not in truth authorize. I mean, there are pieces that I recognize, and obviously some things make sense. then there ’ s loads of outlandishness .
The foremost thing you should notice is that SRP is, at its heart, basically an extension of the Diffie-Hellman protocol. The server picks a value $A = g^a$, the customer picks $B=g^b$, and the two end up with some function of $g^{ab}$. Since Diffie-Hellman is generally viewed to be secure against passive attackers, this means SRP is about surely going to inherit that property. This is good .
The adjacent thing you ’ ll notification is that the waiter ’ second first message to the customer is :
salt, B = kv + g^b
Which is pretty significant, because this individual message actually embeds two different sensitive values that the server stores, and should not leak to an attacker pretend to be the customer. The first sensitive value is the salt. possibly this is all right, since salt international relations and security network ’ t precisely required to be secret — however, giving it away ( to a thus-far wholly untrusted customer ) international relations and security network ’ t a very the best idea either. It allows an attacker to perform pre-computation : i, the attacker can build a dictionary of candidate password hashes prior to compromising the server ’ south database .
In this set, however, the verifier value $v$ is actually the crown jewels. thankfully in the first message of SRP this value is obscured due to the fact that it is multiplied by a constant $k$ ( which does nothing ), and is then added to $g^b$, where $b$ is chosen at random. Provided that both of $g, p$ are chosen correctly, this should serve to protect it sanely well. here ’ s the intuitive argument :
If is distributed uniformly within $\{0,1, \dots, p-1\}$, then $kv+g^b~mod~p$ should be basically a “ one time slog ” encoding of $kv$, which means international relations and security network ’ thymine leaked ( in this first message, at least ) .
This argument doesn ’ thymine quite hold up, for the childlike argue that \$ latex g^b \$ can never be equal to 0, so there is a bantam ( negligible ) bias. It might hold up if we were using multiplication alternatively of addition, since in that case the $0$ output would not be possible. But this wonkyness begs the wonder : why are we using addition in the foremost target ? This will come improving again late.

however, even if we ignore the minor bias, using this occupation of reasoning requires us to choose $g,p$ highly cautiously. For example, if $g$ merely generated a subgroup of ( as around half the potential elements of the group will ), then you could run a dictionary attack that — over many consecutive rounds of the protocol — would gradually reveal and hence. fortunately, the SRP designers seem to have noticed this problem, and the specification mandates that you use alone approve values, each of which is tuned to generate precisely the right group .
note that you can not safely use standard Diffie-Hellman groups with SRP ! so be aware of that .
Another possible concern is that a malicious server could attempt to craft a message $B = kv+g^b$ that would, when processed by the client into a shared secret $S$, reveal something about the node ’ sulfur password. This besides seems quite unmanageable to pull off, since in drill the node learns lone a hash ( of the hash ) of, though it could again happen if the group is chosen ill so that it has many modest subgroups. This seems not to be the subject .
Lest you think these positive results are all by invention, I would note that there are three anterior versions (Update: no, it ’ mho five prior versions, oy vey ) of the SRP protocol, each of which contains vulnerabilities. So the current status seems to have arrived through a process of attrition, more than design .

### What claims does the SRP security analysis make?

The original SRP paper claims contains a section discussing the security of the protocol. unfortunately, this analysis doesn ’ thymine truly contain a proof of security. rather, it largely talks about attacks. ( Recall that several protocol flaws were discovered subsequent to the initial publication, which illustrates the helplessness of the don ’ t-prove-security access. ) here ’ s an example of the kind of thing the original SRP newspaper says :
“ SRP has been carefully designed to thwart the active voice attacks illustrated in Sections 3.2.3 and 3.2.4. Although it is unmanageable to determine conclusively whether or not these precautions bulletproof the protocol completely from all possible active attacks, SRP resists all the long-familiar attacks that have plagued existing authentication mechanisms, such as the Denning-Sacco attack mentioned previously ”
The paper does include a ball reduction from SRP to the Diffie-Hellman protocol — which means SRP is no worse to a passive voice attacker than Diffie-Hellman. unfortunately, all this proves is that the protocol stands up to passive attacks, not that it can handle any sort of active attacks. That ’ randomness nice, but not precisely utilitarian .
The fact of the matter is that SRP is a relatively simple PAKE protocol. It should be possible to provide a strong security proof, and however SRP has none. This is not a commodity situation for a widely-used protocol to be in .