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 .

What about elliptic curves?

I mentioned above that SRP uses accession in a place that you would normally expect to see multiplication. This seems like one of those harmless things that only cryptographers fret about, but it ’ s actually in truth quite unusual .
You see, protocols like Diffie-Hellman ( on which SRP is based ) are designed to be set in a cyclic group. In these groups, there is a “ group operation ” that can be realized in unlike ways, depending on the set. In the integer setting that SRP uses, this operation is implemented as multiplication modulo p. If we were using an elliptic curvature, we would use EC point summation as the group operation — an operation that is very different from integer addition — and provided the protocol used one of these two operations, the protocol would probable translate from one setting to the other. indeed, this ease-of-translation is the argue that most Diffie-Hellman-type protocols can be implemented in either specify .
SRP is weird, in that its calculations use both addition and multiplication. This is ticket — but requires the place setting to be a ring, rather than a generic cyclic group. This prerequisite implicitly rules out any obvious transformation of SRP to the more effective elliptic curve-land, where a second mathematical process is not available. It besides makes any fair security proof reasonably challenging.

And this is kind of a big deal for efficiency. The argue the EC thing is a large deal is that to get equivalent security system for finite field ( integer ) arithmetic, we have to use much larger keys. For exercise, a 256-bit elliptic bend is believed to provide the like security as a mod p group of size 3,072 bits or more. Increasing to 512-bit curves can require equivalent non-EC keys of over 16,000 bits. This is a big hit to take .

In summary?

In drumhead, SRP is merely eldritch. It was created in 1998 and bears all the marks of a protocol invented in the prehistoric days of crypto. It ’ sulfur been repeatedly broken in diverse ways, though the most recent ( v4 ) rewrite doesn ’ deoxythymidine monophosphate seem obviously busted — arsenic long as you implement it cautiously and use the right parameters. It has no security validation worth a damn, though some will say this doesn ’ triiodothyronine matter ( I disagree with them. ) SRP leaks salt to untrusted users by design, which is a problem, and finally, it ’ randomness ineffective because it can ’ triiodothyronine be implemented in the EC set .
In conclusion : you should not use SRP in 2018. There are much better PAKE protocols with well better properties, like OPAQUE .

Leave a Reply

Your email address will not be published.