Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.

share|improve this question
1  
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
add comment

1 Answer

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.

share|improve this answer
    
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
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.