Which authentication at the end of the Secure Remote Password protocol?

Question

For the the client and server to prove to each other that they have the same premaster shared key, the original author suggests this:

M = H(A | B | K) -->
                 <-- H(A | M | K)

The RFC 2945 recommends this:

M = H(H(N) XOR H(g) | H(U) | s | A | B | K) -->
                                            <-- H(A | M | K)

How many of these concatenations actually increase security? Also, how much freedom do I have to alter it without reducing security? I would imagine that it would be just as secure for to one replace the XOR with concatenation, for example.

• A - public, random every time, determined by the client
• B - public, random every time, determined by the server
• U - private in my implementation, username (salted hash and salt are public)
• s - public, associated with the user account password, determined by server
• N and g - public, constants, determined by programmer
• K - private, random every time, secret key between the server and client

Which definition should I use? The difference between the two is that more public values determined by the server are concatenated into the second hash. Is this actually worthwhile, since any attacker knows H(N) XOR H(g) | H(U) | s | A | B just as well as A | B?

EDIT: Uppercase U is actually the username. I was reading it as lowercase. Obviously not big on C#'s case-sensitivity.

Answer 1

At the end of SRP, client and server are implicitly authenticated to each other. "Implicit" means: "I do not know if I talked with someone who really knows the shared secret, but I know that he knows the symmetric key I just got from the protocol only if he knows the shared secret". If you want to make sure of that, challenge the peer: have it use the symmetric key.

Now it is not as easy as it seems. In particular, an attacker could try to make a machine talk to itself. To ensure security, you shall derive several symmetric keys from the one which was produced by SRP: one key to encrypt from client to server, another distinct key from server to client. And a pair of keys for integrity checks, too. This is hard to get right, so it is highly suggested to use a protocol where all those details were painfully tuned through years of attacks and counterattacks -- namely, TLS. Did I talk about RFC 5054 ? TLS includes the Finished messages which are, basically, the challenges I am talking about. When a machine has received a Finished message from the peer, and it could be processed (proper MAC, proper value when decrypted), then the peer is duly, explicitly authenticated.

Answer 2

"How many of these concatenations actually increase security?"

By security I assume you mean confidentiality of K.

K is being protected by not sending it directly. Obviously if you send K as plaintext on an insecure channel, it will be intercepted, and any encryption using K will be compromised.

K could be sent encrypted, but that would require another key and doesn't get us anywhere.

So the protocol sends a hashed version of K. Hashes can be defeated using brute force or rainbow table attacks. If H(K) was sent, a successful attack on H(K) may reveal K to the attacker. Since there may be collisions for a hash, a successful attack on H(K) may produce a value other than K. Adding input data to a hash makes it harder to successfully attack the hash because there is a larger domain of values to attempt. The larger the input to the hash, the harder it is to attack successfully. So the answer is that every concatenation increases security.

"I would imagine that it would be just as secure for to one replace the XOR with concatenation, for example."

I do not know the purpose of the XOR. There are weaknesses in SHA1 and I suspect that the XOR of H(N) and H(g) is meant to mitigate the weakness. I think that since K is a hash of a function of B, g, x, a, u, and N that g and N are hashed and XORed to prevent some pattern from connecting parts of the input data. Theoretically you would like as much input as possible going into the hash function and XORing two values reduces the input data size compared to concatenating two values. Since N and g are publicly known the XOR is not attempting to protect those values in case of a successful attack on the hash.

"how much freedom do I have to alter it without reducing security?"

It is not possible to tell intuitively when a change on order or operation will improve or reduce security. The safe assumption is that any change will reduce security. Take note of the frequency of announcements about changes in algorithms which improve security versus the frequency of announcements about attacks breaking algorithms. Improving algorithm security is hard. Read How to break MD5 and other hash functions, and then find any mistakes the authors made. Wang's sufficient conditions of MD5 are not sufficient is at least one paper critical of the first papers findings.

Answer 3

As Thomas Pornin noted, you should prefer the RFC(engineer's specification) over the paper(cryptographer's specification). If RFC5054 does not work for you, use 2945.

From the little that I know of cryptographic protocols, values A,B,M are critical to prevent the adversary from modifying the order of messages and their replay in the same or parallel connections with the same or other hosts.

Values H(N) and H(g) are not used in the original paper because I think they are common parameters there, while in practice these group parameters are selected by some initial protocol negotiation. Hence, attacks can be possible if the parameter suddenly change. A real-life server may even have multiple SRP verifier values for each user for each of the supported (g,N), or even multiple verifier values for each with different salts 's'. I suppose Tom Wu integrated these into the hash to assure that the protocol's security is independent of such strange settings, which is how such protocols should be designed. Maybe he did not even identify a specific attack but only did it for "good form".

Maybe, hopefully, you only forgot to fix your explanation of U, but:

You write that U is "private" in your case but that salted hash and salt are public. The last bit, that the verifier value is public, is very strange and not intended in SRP. Public verifier values only happen after compromise of the server. In this case, SRP is as secure as a standard hash-based challenge-response exchange: The verifier value is vulnerable to offline bruteforce.

If the password (P?) is very strong, this is no concern, otherwise it is a big problem. In either case, you are no better off than with standard challenge response.

U cannot be "private", it is transferred in clear in the very first step.