How can I validate generated session keys in SRP-6a protocol

Question

I have genereted two equal session keys on client and server successfully. But I couldn't understand how each other should validate that they have same session keys.

On the client I generated a SHA1 hash with equation p = SHA1(A | B | S) where A and B are public keys of client and server and S is the SHA1 hash of the session key. Then I sent this hash without any encryption to the server.

Server then calculates p with its own hash of session key and compare with the incoming one.

Is that the supposed way of validating keys in SRP ?

And while client is connecting to other server in cluster, what is the best way to authenticate connection ?

Answer 1

Nimbus or Thinbus are two popular SRP implementations in Java and Javascript compute the proof of password as you describe H(A|B|S) where you can supply your own hash functions such as SHA1 or SHA256 or stronger.

The actual protocol design document states H(H(N) xor H(g), H(I), s, A, B, K) where K=H(S) so that expands to H(H(N) xor H(g)|H(I)|s|A|B|H(S)). The longer approach includes N, g, s which is the safe prime, it's generator and I the user identity and s the users salt. Those are not secret. The secret is S and adding more bits into the hash is done to protect leaking information about that secret. The secret is also the only component which is derived from the password if you are talking to an attacking server so needs to be well hashed. So both approaches involve A which is the secure random chosen by the client to conceal the secret.

In the protocol design document the server then responds with H(A|p|K) which expands to H(A|p|H(S)). The p is the value used to check the client holds the password which has already computed to check the client.

Once again all the proofs, including the server proof, include A which is the random chosen by the client. If that is a secure random it provides protection against a fake server attacker which may be supplying a not random B and a bad salt as part of an attack.

So why would Nimbus and Thinbus go with H(A|B|S) rather than the more complex password proof using more bits from the public values? (Nimbus will actually let you plugin your own proof function but that is the default). The original SRP RFC was using SHA1 which is now considered weak one can see why it might throw more bytes into the hash and also double hash the S to better protect it. With Nimbus and Thinbus the recommended hash function is SHA256 or higher. So the random numbers used to generate A and B will be that many bits. The choice of a more secure hash algorithm and larger random numbers is considered enough to protect from leaking information about S which may leak information about the password.