3

I'm implementing the Secure Remote Password protocol, and similar to this question, I'm wondering if I can use the SHA-512 hash function instead of SHA-1 currently being used. Would this help improve the confidentiality of the Key?

 M = SHA1(A | B | Key) -->
                <-- SHA1(A | M | Key)
Community
  • 1
Robin Rodricks
  • 379
  • 1
  • 4
  • 10

3 Answers3

3

I think it is fine to use SHA1 in SRP. SHA1 is fine for these purposes. Using SHA1 won't hurt the confidentiality of the key.

Some people say that "SHA1 has some weaknesses". However, those weaknesses are relatively minor, and in any case, they affect only SHA1's resistance to collision attacks. Those attacks don't affect or endanger SRP, since SHA1 isn't relying upon SHA1's collision-resistance. Changing to a different hash function isn't likely to improve the confidentiality of the key. For a more detailed discussion, see Section 3.4 of RFC 5054, which discusses the use of SHA1 in the SRP protocol.

I'm a bit leary about making changes to a cryptographic protocol, on general principles. Cryptographic protocols are tricky and little details can make a big difference to security, especially password-authenticated key agreement protocols (where the exact bit layout of some fields can be important to security). My suggestion would be to find an existing, well-vetted specification that gives a complete specification of the SRP protocol, and adopt that exactly. Making changes has the potential to introduce subtle security weaknesses.

However, if you wanted to change the hash function in the way you outlined, I think that would be a relatively reasonable, low-risk change. In fact, Section 3.2 of RFC 2945 (a specification of SRP version 3) does say it is OK to change SHA1 to another cryptographically strong hash function, so changing the hash used in the key confirmation step to SHA256 or SHA512 would probably be OK.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
2

In 2005 sha1 was shown to have some mathmatical weaknesses. It's reccomended that you use a newer hash function. Sha512 is just fine. http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

k to the z
  • 1,115
  • 1
  • 12
  • 25
1

The property of SHA-1 used here is its resistance to preimages: it is computationally infeasible, as far as we know, to compute a message m which yields a given output SHA-1(m), or even to obtain some "information" on m. There are two ways to compute a preimage:

  1. Get lucky. Try a lot of possible images until one is found.
  2. Exploit a weakness is the structure of the hash function.

The "luck" method requires an average of 2n attempts for a hash function with a n-bit output; with SHA-1, n = 160, which makes the "luck attack" cost overly expensive (about one billion billion billions times than what is technologically feasible). As for structural weaknesses, none is known yet (there are known weaknesses in SHA-1, but they affect resistance to collisions, not to preimages). Even MD5 would be fine here, for all its published brokenness (and there is a known structural weakness in MD5 which makes preimages easier to compute than using luck -- still infeasible, but slightly easier).

Therefore, replacing SHA-1 with SHA-256 or SHA-512 would not help -- since SHA-1 is already as secure as you can get, and there is no security level beyond not being broken. On the other hand, any modification to a cryptographic protocol breaks compatibility with existing implementations, and throws you into the dangerous realm of homemade crypto, so it cannot be recommended.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949