# Does SRP reduce to DH key exchange when shared password is not secret?

I can find JavaScript implementations of SRP (Secure Remote Password protocol), but nothing that inspires confidence for Diffie-Hellmen key exchange. I also have a separate need for SRP later.

I would like to do key exchange under the assumption that I've already done mutual authentication (through some out of band user intervention). And I was wondering whether under these conditions I can use SRP with a non-secret password to do key exchange.

I would like to keep the client in JavaScript as simple as possible, and for SRP I only need a BigInt library, a hash function, and a cryptographically appropriate RNG. (DH wouldn't need the hash function, but I'll be needing SRP later for other stuff).

I'm trying to save myself the trouble of finding a good JavaScript implementation for DH or the danger of trying to write it myself.

-
What does "I've already done mutual authentication" mean in your protocol? Does this protect against a man-in-the-middle? –  Paŭlo Ebermann May 10 '13 at 19:30
Since SRP uses DH as a building block, you need a DH implementation anyways. –  CodesInChaos May 11 '13 at 11:11
And you don't just need a BigInt library for SRP. If you go that way you will most likely be vulnerable to timing attacks. You need a specialized library that does exponentiation in constant time to do DH or SRP. –  CodesInChaos May 11 '13 at 11:14

The SRP paper has this point in its list of security properties:

6. If the user's password itself is compromised, it should not allow the intruder to determine the session key K for past sessions and decrypt them. Even present sessions should at least be protected from passive eavesdropping.

The following section is titled Reduction to Diffie-Hellman and shows that, given an algorithm which retrieves the session key from the transmitted values and the password, you can also solve the computational Diffie-Hellman problem.

So yes, SRP is as secure as Diffie-Hellman for key exchange if the password is known to the attacker (and the other parameters are chosen properly, i.e. uniform random in their respective domains).

On the other hand, SRP with a non-secret password has the same problem as the pure Diffie-Hellman key exchange, when facing an active attack, i.e. a man-in-the-middle or an attacker who impersonates only one of the two parties.

I would like to do key exchange under the assumption that I've already done mutual authentication (through some out of band user intervention).

Sorry, this rings alarm bells. Depending on how this out of band user intervention looks like, it could prove nothing at all about your actual communication going on, or about the non-existence of a man-in-the-middle attack.

Your "out of band authentication" should at least verify some value derived from the negotiated secret $K$, or (if you want it to go on beforehand) negotiate some (real) secret which then goes into the process as a part of the "password", so the attacker actually doesn't know the password, and can't mount a man-in-the-middle attack.

Also, as mentioned by CodesInChaos in a comment, SRP (as DH) does a lot of exponentiating of values by secret exponents. This is prone to timing and power analysis attacks if done naively, so your "default" JavaScript BigInteger implementation will have problems here.

If you want to run this in a Web browser (what JavaScript leads to believe), also take note that this will not more secure than the connection by which the browser got the code (hopefully at least an HTTPS connection), and good random numbers are a critical problem there. Also, side channel attacks are even easier if run on an untrusted platform like a web browser. More details in the article Javascript Cryptography Considered Harmful.

-
Verifying "some value derived from the negotiated secret $K$" seems unnecessarily complicated, when one could instead verify some value derived from the transcript of the negotiation. $\:$ –  Ricky Demer May 11 '13 at 23:13
Hmm, I imagine that out-of-band channel as a telephone call between two humans, and they usually don't want to read long series of numbers to each other. Therefore I imagine it would be easier to derive some hash from $K$ and read/compare this instead of the whole transcript. –  Paŭlo Ebermann May 11 '13 at 23:14
The length of what one should read/compare would not depend on what that was derived from. –  Ricky Demer May 11 '13 at 23:19
(Your first comment didn't have the "derived from".) Of course you can derive something from the whole transcript, but $K$ is already derived from all the relevant values in the transcript, so it seems somehow superfluous. And as long as you got the same session key, everything is fine (unless SRP, i.e. the DL problem or the hash function in question, gets really broken). –  Paŭlo Ebermann May 11 '13 at 23:24
It seems somehow risky, since we must avoid revealing useful information about $K$. $\hspace{.61 in}$ –  Ricky Demer May 11 '13 at 23:32

SRP with the user's key = 0 is identical to DH.

SRP with a publicly known key is identical to DH with a constant multiplier.

For private key $x$, user ephemeral value $a$, server ephemeral value $b$, and $u$ derived from shared values, SRP ends up calculating the value $g^{ab + uxa}$ (which is then typically hashed to get the shared key).

If $x$ is zero, that reduces to $g^{ab}$. If $x$ is non-zero, then you multiply that by $g^{aux}$ (which would be a known constant, as $g^a$ is transmitted, $x$ is known, and $u$ can be calculated from transmitted values).

The only reason to use SRP over DH is for the mutual authentication capability. If all you want is DH, then just use DH, the publicly known value of the key will not strengthen the security in any way.

If you have the routines to do the math for SRP, you have the routines to do DH as well. Just replace $(Av^u)^b$ with $A^b$, $B^{a + ux}$ with $B^a$, and don't bother with the calculations involving $v$, $k$, $x$, or $u$ (the value $B$ is actually transmitted as $B + kv$ in the SRP protocol, that would just be passed as $B = g^b$ when doing DH).

-