We study the internal structure of the SRP key exchange protocol and experiment with it. SRP establishes a shared encryption key between communicating parties using passwords that were shared out-of-band. We perform basic cryptanalysis of SRP using open-source implementations. We present a demo of how SRP was compromised due to an implementation bug, allowing the attacker to login without the password. The author of the Go-SRP library promptly fixed the issue on the very same day we reported the vulnerability.

1. An Analysis of Secure Remote Password
Dr. Dharma Ganesan, Ph.D.,

2. Background
● Secure Remote Password (SRP) is a secure client-server protocol
● In SRP, password has to be shared up-front between the client and server
● Using SRP, the client and server arrive at the shared session key K
○ Client and Server can authenticate each other in this process
● Of course, SRP does not send password over the channel
○ Using Diffie-Hellman style, both parties convince each other that they know the password
● SRP is part of TLS 1.2 (but not in TLS 1.3 as far as we know)
● Without digital certificates, SRP creates a secure communication channel
2

3. Objectives
● Demonstrate how the Secure Remote Password (SRP) protocol works
○ SRP uses nifty ideas of Diffie-Hellman key negotiation
● Demonstrate one implementation attack on SRP
○ Implementation misses a basic check of public key values
● We will break this implementation (https://github.com/opencoff/go-srp/blob/master/srp.go)
○ They fixed it on the same day we reported the issue
● An evil client will successfully authenticate with the server
○ The evil client does not know the password, but will successfully trick the server
3

4. 4
Pick a random number a Pick a random number b
Compute A = ga
Compute B = gb
Secret K = Ba
Secret K = Ab
Send A to Bob Send B to Alice
Both Alice and Bob have
the same secret key Eve sees A and B,
but not a, b, or K
Diffie-Hellman Key Negotiation - Core Idea
(assume that g and prime N are public - in mod N)

5. SRP vs Diffie-Hellman (DH) Key Negotiation
● DH key negotiation algorithm does not have authentication
○ Alice is not sure whether it is Bob or someone else and vice-versa
● SRP uses DH, but, function(password) is mixed with the server’s public key
● The client will remove the password from the public key
● Afterwards, both the client and server perform basic DH operations
○ They both arrive at the shared key (with authentication support)
● Note that the password is never stored on the server side
● The client never sends the password either
5

6. 6
Client Server x = Hash(salt, passwd)
v = gx
User ID, A = ga
salt, B = kv + gb
u = Hash(A, B)
x = Hash(salt,passwd)
S = (B - gx
)(a + ux)
K = Hash(S)
u = Hash(A, B)
S = (Avu
)b
K = Hash(S)
SRP Protocol: Phase 1 - Key Agreement
(SRP defines the constants g, k, and N (prime); all computation in mod N)

7. 7
Client Server
M2
= H(A, M1
, K)
SRP Protocol: Phase 2 - Mutual Authentication
M1
= H(H(N) xor H(g), H(I), salt, A, B, K)
Is M1
valid?
If yes, send M2Is M2
valid?
If not, abort

8. Safeguards recommended by SRP
8
The two parties also employ the following safeguards:
1. The client will abort if it receives B == 0 (mod N) or u == 0
2. The server will abort if it detects that A == 0 (mod N)
3. The client must show his proof of K first. If the server detects that the client's
proof is incorrect, it must abort without showing its own proof of K.

9. 9
Why B ≠ 0 mod N?
● B ≠ 0 safeguards against offline dictionary attacks
● Recall that the client performs the following steps
● salt, g, A, B, u, and M1
are public but not x which is derived from the passwd
● The attacker can derive x by comparing against M1
using a dictionary
u = Hash(A, B)
x = Hash(salt,passwd)
S = (B - gx
)(a + ux)
= (-gx
)a+ux
K = Hash(S)
M1
= H(H(N) xor H(g), H(I), salt, A, B, K)

10. 10
Why u should not be equal to zero?
● u ≠ 0 safeguards against attackers that had stolen gx
from the server
● If an attacker managed to steal gx
, then the attacker can break SRP
● Recall that the client performs the following 4 steps
● If u = 0, then, without knowing the password, the session key is generated
u = Hash(A, B)
x = Hash(salt,passwd)
S = (B - gx
)(a + ux)
= (B - gx
)a
K = Hash(S)

11. 11
Evil Client Server x = Hash(salt, passwd)
v = gx
User ID, A = N
salt, B = kv + gb
S = 0
K = Hash(0)
u = Hash(A, B)
S = (Avu
)b
= (Nvu
)b
= 0 (mod N)
K = Hash(0)
Why A ≠ 0 mod N?
(SRP defines the constants g, k, and N (prime); all computation in mod N)
Evil Client doesn’t have
the password but sends her
public key A = 0 mod N

12. 12
● There are several
implementations of SRP
○ See,
https://en.wikipedia.org/wiki/Secure_Rem
ote_Password_protocol

13. Implementations without safeguards
13
● We analyzed a few of these implementations for conformance to SRP
● In this demo, we will exploit one of the Go implementations of SRP
○ https://github.com/opencoff/go-srp/blob/master/srp.go
● It claims “This implementation is accurate as of Aug 2012 edition of the SRP
specification...”
● But, we will show that this claim is not accurate - we will break it
○ The SRP spec introduced the safeguard back in 2000
● This implementation missed the safeguard (A ≠ 0 mod N) of the SRP spec

14. Checking the value of B
14
func (c *Client) Generate(srv string) (string, error) {
. . .
zero := big.NewInt(0)
z := big.NewInt(0).Mod(B, pf.N)
if zero.Cmp(z) == 0 {
return "", fmt.Errorf("invalid server public key")
}
. . .
}
Fortunately, it does check the value of B
Otherwise, we would have performed offline dictionary attacks using the authentication hash

15. Vulnerable code (A is the public key of Client)
15
// NewServer constructs a Server instance for computing a shared secret.
func (s *SRP) NewServer(v *Verifier, A *big.Int) (*Server, error) {
...
t0 = big.NewInt(0).Mul(A, big.NewInt(0).Exp(sx.v, u, pf.N))
S := big.NewInt(0).Exp(t0, b, pf.N)
...
}
What if the evil client send A = 0 (mod N)?
Then, the evil client can set the Shared Key!
The Server will compute only the Hash(0)

16. Demo
16
N =
0xEEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D67
4DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B4
6154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726
CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
This implementation uses the above safe prime N
Evil client will just send a malicious public key A such that A = 0 mod N
For example, A = N is one such malicious key

17. Evil client logged in - without the password
17
~/crypto/srp/srp-example$ ./example
Client Begin; <I, A> --> server:
I: b8fd39a36525c3a6aa40660f6093b2ae5024d23dcd1d9da9421ad53989fb07f8
A:
eeaf0ab9adb38dd69c33f80afa8fc5e86072618775ff3c0b9ea2314c9c256576d674df7496ea81d3383b4813
d692c6e0e0d5d8e250b98be48e495c1d6089dad15dc7d7b46154d6b6ce8ef4ad69b15d4982559b297bcf1
885c529f566660e57ec68edbc3c05726cc02fd4cbf4976eaa9afd5138fe8376435b9fc61d2fc0eb06e3
Client Key: 0e5751c026e543b2e8ab2eb06099daa1d1e5df47778f7787faab45cdf12fe3a8
Server Key: 0e5751c026e543b2e8ab2eb06099daa1d1e5df47778f7787faab45cdf12fe3a8
Since the keys matched, the server thought the client knows the password!

18. Go-SRP - Fixed the Bug
18
● We reported the issue to Go-SRP
● They fixed the issue on the same day
● That is, they check whether A = 0 mod (N), if true they reject the public key
● We thank Go-SRP for this informal collaboration

19. Closing Remarks
19
● SRP is a novel protocol for authenticated key negotiation (certificateless)
● A common criticism of SRP is that there is no security proof for it
● SRP is vulnerable to active attacks (subgroup confinement problem)
○ Not discussed in this presentation
● SRP implementations must safeguard against public key values
● Failure to safeguard will allow evil users to take over the server or client
● Future work: Analyze certificateless protocols (e.g., OPAQUE, TLS-PWD, PSK)
○ https://en.wikipedia.org/wiki/Password-authenticated_key_agreement

20. References
1. http://srp.stanford.edu/design.html
2. https://eprint.iacr.org/2010/149.pdf
3. https://blog.cryptographyengineering.com/should-you-use-srp/
4. https://github.com/opencoff/go-srp/blob/master/srp.go
5. https://github.com/opencoff/go-srp/commit/a2c3544e176ef2e75667efa27c322
6cfc9a11c3d
20