# Why does SRP-6a use k = H(N, g) instead of the k = 3 in SRP-6?

I've been reading up on the Secure Remote Pasword protocol (SRP). There are a couple different versions of the protocol (the original published version being designated SRP-3, with two subsequent enhancements 6 and 6a).

There was a very limited attack on version 3, where the attacker could submit two password guesses per falsified attempt against the server instead of just one. This was because in step 2 where the client submits ($$g^x + g^b$$) to the server, they could in fact set $$b$$ to be a second password guess, and since the server doesn't have the password, it can't tell that $$b$$ isn't randomly chosen (like it's supposed to be). The attack and remedy are detailed in the paper for SRP-6.

The remedy described in SRP-6 is that the client send $$k·g^x + g^b$$ instead, where $$k = 3$$. However, there is also a version SRP-6a (which is the version detailed on the page above), which sets $$k = H(N, g)$$. Since both $$N$$ and $$g$$ are publicly known values ($$N$$ is a large safe prime, and $$g$$ is it's generator), and the $$(g,N)$$ group is used for all transactions in a given SRP system (independent of password, user or session), $$k$$ is still a constant value.

So the question is, what's the justification/benefit of picking this alternate value $$H(N,g)$$ for $$k$$? This value of $$k$$ is used in the TLS/SRP implementation, but I haven't found any explanation for why.

• Might prevent some interactions between instances of the protocol that use different generators. Aug 10, 2012 at 18:53
• @CodesInChaos Maybe... you mean a different (N,g)? Or just a different g for the same N? My understanding is that given an N, g is usually fixed by convention (check the RFC which has defined (N,g) tuples). Aug 11, 2012 at 1:46
• ... fixed by convention (check the RFC which has defined (N,g) tuples). Or are you saying that there might be an attack across different (N,g)'s entirely which reuse the same k? It seems like since k is constant across sessions, any attacks leveraging k would be more relevant using data collected from multiple sessions on the same (N,g,k) (i.e. other users on the same server). Aug 11, 2012 at 1:54
• I suspect in some implementations the server chooses the (N,g) pair freely and can choose it in a way that N is identical to some other sever, and uses a different specific g for some kind of attack. But I have no clue what that attack might be. Aug 11, 2012 at 6:48

• I see, that makes sense. So then by doing $k = H(N,g)$, it makes it very unlikely that log_g(k) is known / trivially calculable. I suppose varying k would be possible (say, salting the hash of (N,g) per session), but not useful, because if the attacker could enable the two-for-one attack by solving log_g(k), he could also factor a from A, or x from v (assuming he could grab the verifiers), which allow him to break the protocol entirely. Aug 14, 2012 at 22:46