View source for Secure Remote Password protocol

{{short description|Augmented password-authenticated key exchange protocol}}
The '''Secure Remote Password protocol''' ('''SRP''') is an augmented [[Password-authenticated key agreement|password-authenticated key exchange]] (PAKE) protocol, specifically designed to work around existing patents.<ref>{{cite web
 | url = http://srp.stanford.edu/whatisit.html
 | title = What is SRP?
 | publisher= [[Stanford University]]
}}</ref>

Like all PAKE protocols, an eavesdropper or [[man-in-the-middle attack|man in the middle]] cannot obtain enough information to be able to [[Brute-force attack|brute-force guess]] a password or apply a [[dictionary attack]] without further interactions with the parties for each guess. Furthermore, being an augmented PAKE protocol, the server does not store password-equivalent data.<ref>{{Citation|last1=Sherman|first1=Alan T.|title=Formal Methods Analysis of the Secure Remote Password Protocol|date=2020|work=Logic, Language, and Security: Essays Dedicated to Andre Scedrov on the Occasion of His 65th Birthday|pages=103–126|editor-last=Nigam|editor-first=Vivek|series=Lecture Notes in Computer Science|place=Cham|publisher=Springer International Publishing|language=en|doi=10.1007/978-3-030-62077-6_9|isbn=978-3-030-62077-6|last2=Lanus|first2=Erin|last3=Liskov|first3=Moses|last4=Zieglar|first4=Edward|last5=Chang|first5=Richard|last6=Golaszewski|first6=Enis|last7=Wnuk-Fink|first7=Ryan|last8=Bonyadi|first8=Cyrus J.|last9=Yaksetig|first9=Mario|editor2-last=Ban Kirigin|editor2-first=Tajana|editor3-last=Talcott|editor3-first=Carolyn|editor4-last=Guttman|editor4-first=Joshua|arxiv=2003.07421}}</ref> This means that an attacker who steals the server data cannot masquerade as the client unless they first perform a brute force search for the password.

In layman's terms, during SRP (or any other PAKE protocol) authentication, one party (the "client" or "user") demonstrates to another party (the "server") that they know the password, without sending the password itself nor any other information from which the password can be derived. The password never leaves the client and is unknown to the server.

Furthermore, the server also needs to know about the password (but not the password itself) in order to instigate the secure connection. This means that the server also authenticates itself to the client which prevents [[phishing]] without reliance on the user parsing complex URLs.

The only mathematically proven security property of SRP is that it is equivalent to Diffie-Hellman against a ''passive'' attacker.<ref>{{cite web |last1=Green |first1=Matthew |title=Should you use SRP? |url=https://blog.cryptographyengineering.com/should-you-use-srp/ |website=A Few Thoughts on Cryptographic Engineering |language=en |date=18 October 2018}} NB: source refers to SRP-6 as SRPv4 for reason unknown.</ref> Newer PAKEs such as AuCPace<ref>{{cite web |last1=Haase |first1=Björn |title=(strong) AuCPace, an augmented PAKE [draft-haase-aucpace-07] |url=https://datatracker.ietf.org/doc/html/draft-haase-aucpace-07 |publisher=Internet Engineering Task Force |access-date=10 June 2023 |date=22 January 2023}}</ref> and OPAQUE offer stronger guarantees.<ref>{{cite conference |author=Stanislaw Jarecki |author2=Hugo Krawczyk |author3=Jiayu Xu |conference=Eurocrypt 2018 |url=https://eprint.iacr.org/2018/163.pdf | title=OPAQUE: An Asymmetric PAKE Protoco lSecure Against Pre-Computation Attacks}}</ref>

== Overview ==

The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to [[dictionary attack]]s mounted by an eavesdropper, and it does not require a [[trusted third party]]. It effectively conveys a [[zero-knowledge password proof]] from the user to the server. In revision 6 of the protocol only one password can be guessed per connection attempt. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision 6a.

The SRP protocol creates a large private key shared between the two parties in a manner similar to [[Diffie–Hellman key exchange]] based on the client side having the user password and the server side having a [[Cryptography|cryptographic]] verifier derived from the password. The shared public key is derived from two random numbers, one generated by the client, and the other generated by the server, which are unique to the login attempt. In cases where encrypted communications as well as authentication are required, the SRP protocol is more secure than the alternative [[Secure Shell|SSH]] protocol and faster than using [[Diffie–Hellman key exchange]] with signed messages. It is also independent of third parties, unlike [[Kerberos (protocol)|Kerberos]].

The SRP protocol, version 3 is described in RFC 2945. SRP version 6a is also used for strong password authentication in [[Transport Layer Security|SSL/TLS]]<ref>{{cite web |last=Taylor |first=David |author2=Tom Wu |author3=Nikos Mavrogiannopoulos |author4=Trevor Perrin |date=November 2007 |title=Using the Secure Remote Password (SRP) Protocol for TLS Authentication |url=http://tools.ietf.org/html/rfc5054}} RFC 5054</ref> (in [[TLS-SRP]]) and other standards such as [[Extensible Authentication Protocol|EAP]]<ref>{{cite web
 | title = EAP SRP-SHA1 Authentication Protocol
 | url = http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03
 | first = James | last = Carlson |author2=Bernard Aboba |author3=Henry Haverinen
 |date=July 2001 | publisher = IETF
}} Draft.</ref> and [[Security Assertion Markup Language|SAML]], and is part of [[IEEE P1363|IEEE 1363.2]] and ISO/IEC 11770-4.

== Protocol ==
The following notation is used in this description of the protocol, version 6:
* ''q'' and ''N'' = 2''q'' + 1 are chosen such that both are prime (which makes ''q'' a [[Sophie Germain prime]] and ''N'' a [[safe prime]]). ''N'' must be large enough so that computing discrete logarithms modulo ''N'' is infeasible.
* All arithmetic is performed in the [[ring of integers]] modulo ''N'', <math>\scriptstyle \mathbb{Z}_N</math>. This means that below ''g''{{sup|{{var|x}}}} should be read as ''g''{{sup|{{var|x}}}}''mod N''
* ''g'' is a [[Multiplicative group of integers modulo n|generator of the multiplicative group <math>\scriptstyle \mathbb{Z}_N^*</math>]].
* ''H''() is a [[Cryptographic hash function|hash]] function; e.g., SHA-256.
* ''k'' is a parameter derived by both sides; in SRP-6, ''k'' = 3, while in SRP-6a it is derived from ''N'' and ''g'' : ''k'' = ''H''(''N'', ''g'').  It is used to prevent a 2-for-1 guess when an active attacker impersonates the server.<ref name=srp6>{{cite tech report
 | url = http://srp.stanford.edu/srp6.ps
 | title = SRP-6: Improvements and Refinements to the Secure Remote Password Protocol
 | first = Tom | last = Wu
 | date=October 29, 2002
}}</ref><ref>{{cite web
 | url = http://srp.stanford.edu/design.html
 | title = SRP Protocol Design
}}</ref>
* ''s'' is a [[salt (cryptography)|salt]].
* {{mvar|I}} is an identifying username.
* ''p'' is the user's password.
* ''v'' is the host's password verifier, ''v'' = ''g''{{sup|{{var|x}}}} where at a minimum ''x'' = ''H''(''s'', ''p''). As ''x'' is only computed on the client it is free to choose a stronger algorithm. An implementation could choose to use {{math|1=''x'' = ''H''(''s'' {{!}} ''I'' {{!}} ''p'')}} without affecting any steps required of the host. The standard [https://tools.ietf.org/html/rfc2945 RFC2945] defines {{math|1=''x'' = ''H''(''s'' {{!}} ''H'' ( ''I'' {{!}} ":" {{!}} ''p'') )}}. Use of {{mvar|I}} within ''x'' avoids a malicious server from being able to learn if [https://crypto.stackexchange.com/a/9430 two users share the same password]. 
* ''A'' and ''B'' are random one time ephemeral keys of the user and host respectively.
* | (pipe) denotes concatenation.

All other variables are defined in terms of these.

First, to establish a password ''p'' with server Steve, client Carol picks a random [[salt (cryptography)|salt]] ''s'', and computes ''x'' = ''H''(''s'', ''p''), ''v'' = ''g''{{sup|{{var|x}}}}.  Steve stores ''v'' and ''s'', indexed by {{mvar|I}}, as Carol's password verifier and salt. Carol must not share ''x'' with anybody, and must safely erase it at this step, because it is [[Pass the hash|equivalent]] to the plaintext password ''p''.  This step is completed before the system is used as part of the user registration with Steve. Note that the salt ''s'' is shared and exchanged to negotiate a session key later so the value could be chosen by either side but is done by Carol so that she can register {{mvar|I}}, ''s'' and ''v'' in a single registration request. The transmission and authentication of the registration request is not covered in SRP.

Then to perform a proof of password at a later date the following exchange protocol occurs:

# Carol → Steve: generate random value ''a''; send {{mvar|I}} and ''A'' = ''g''{{sup|{{var|a}}}}
# Steve → Carol: generate random value ''b''; send ''s'' and ''B'' = ''kv'' + ''g''{{sup|{{var|b}}}}
# Both: ''u'' = ''H''(''A'', ''B'')
# Carol: ''S''<sub>Carol</sub> = (''B'' − ''kg''{{sup|{{var|x}}}})<sup>(''a'' + ''ux'')</sup> = (''kv'' + ''g''{{sup|{{var|b}}}} − ''kg''{{sup|{{var|x}}}})<sup>(''a'' + ''ux'')</sup> = (''kg''{{sup|{{var|x}}}} − ''kg''{{sup|{{var|x}}}} + ''g''{{sup|{{var|b}}}})<sup>(a + ux)</sup> = (''g''{{sup|{{var|b}}}})<sup>(''a'' + ''ux'')</sup>
# Carol: ''K''<sub>Carol</sub> = ''H''(''S''<sub>Carol</sub>)
# Steve: ''S''<sub>Steve</sub> = (''Av''{{sup|{{var|u}}}}){{sup|{{var|b}}}} = (''g''{{sup|{{var|a}}}}''v''{{sup|{{var|u}}}}){{sup|{{var|b}}}} = [''g''{{sup|{{var|a}}}}(''g''{{sup|{{var|x}}}}){{sup|{{var|u}}}}]{{sup|{{var|b}}}} = (''g''<sup>a + ux</sup>){{sup|{{var|b}}}} = (''g''{{sup|{{var|b}}}})<sup>(a + ux)</sup>
# Steve: ''K''<sub>Steve</sub> = ''H''(''S''<sub>Steve</sub>) = ''K''<sub>Carol</sub>

Now the two parties have a shared, strong session key ''K''. To complete authentication, they need to prove to each other that their keys match. One possible way is as follows:

# Carol → Steve: {{math|1=''M''<sub>1</sub> = ''H''[''H''(''N'') [[XOR]] ''H''(''g'') {{!}} ''H''(''I'') {{!}} ''s'' {{!}} ''A'' {{!}} ''B'' {{!}} ''K''<sub>Carol</sub>]}}. Steve verifies ''M''<sub>1</sub>.
# Steve → Carol: {{math|1=''M''<sub>2</sub> = ''H''(''A'' {{!}} ''M''<sub>1</sub> {{!}} ''K''<sub>Steve</sub>)}}. Carol verifies ''M''<sub>2</sub>.

This method requires guessing more of the shared state to be successful in impersonation than just the key.  While most of the additional state is public, private information could safely be added to the inputs to the hash function, like the server private key.{{clarify|Since Carol doesn't know the server's private key, how can she add it to the inputs of the hash function she calculates?|date=February 2014}}

Alternatively, in a password-only proof the calculation of ''K'' can be skipped and the shared ''S'' proven with:

# Carol → Steve: {{math|1=''M''<sub>1</sub> = ''H''(''A'' {{!}} ''B'' {{!}} ''S''<sub>Carol</sub>)}}. Steve verifies ''M''<sub>1</sub>.
# Steve → Carol: {{math|1=''M''<sub>2</sub> = ''H''(''A'' {{!}} ''M''<sub>1</sub> {{!}} ''S''<sub>Steve</sub>)}}. Carol verifies ''M''<sub>2</sub>.

When using SRP to negotiate a shared key ''K'' which will be immediately used after the negotiation, it is tempting to skip the verification steps of ''M''<sub>1</sub> and ''M''<sub>2</sub>. The server will reject the very first request from the client which it cannot decrypt. This can however be dangerous as demonstrated in the Implementation Pitfalls section below.

The two parties also employ the following safeguards:

# Carol will abort if she receives ''B'' = 0 (mod ''N'') or ''u'' = 0.
# Steve will abort if he receives ''A'' (mod ''N'') = 0.
# Carol must show her proof of ''K'' (or ''S'') first. If Steve detects that Carol's proof is incorrect, he must abort without showing his own proof of ''K'' (or ''S'')

=== Example code in Python ===
<syntaxhighlight lang="python">
"""
An example SRP authentication

WARNING: Do not use for real cryptographic purposes beyond testing.
WARNING: This below code misses important safeguards. It does not check A, B, and U are not zero.

based on http://srp.stanford.edu/design.html
"""
import hashlib
import random

# Note: str converts as is, str([1,2,3,4]) will convert to "[1,2,3,4]"
def H(*args) -> int:
    """A one-way hash function."""
    a = ":".join(str(a) for a in args)
    return int(hashlib.sha256(a.encode("utf-8")).hexdigest(), 16)

def cryptrand(n: int = 1024):
    return random.SystemRandom().getrandbits(n) % N

# A large safe prime (N = 2q+1, where q is prime)
# All arithmetic is done modulo N
# (generated using "openssl dhparam -text 1024")
N = """00:c0:37:c3:75:88:b4:32:98:87:e6:1c:2d:a3:32:
       4b:1b:a4:b8:1a:63:f9:74:8f:ed:2d:8a:41:0c:2f:
       c2:1b:12:32:f0:d3:bf:a0:24:27:6c:fd:88:44:81:
       97:aa:e4:86:a6:3b:fc:a7:b8:bf:77:54:df:b3:27:
       c7:20:1f:6f:d1:7f:d7:fd:74:15:8b:d3:1c:e7:72:
       c9:f5:f8:ab:58:45:48:a9:9a:75:9b:5a:2c:05:32:
       16:2b:7b:62:18:e8:f1:42:bc:e2:c3:0d:77:84:68:
       9a:48:3e:09:5e:70:16:18:43:79:13:a8:c3:9c:3d:
       d0:d4:ca:3c:50:0b:88:5f:e3"""
     
N = int("".join(N.split()).replace(":", ""), 16)
g = 2  # A generator modulo N

k = H(N, g) # Multiplier parameter (k=3 in legacy SRP-6)

F = '#0x' # Format specifier

print("#. H, N, g, and k are known beforehand to both client and server:")
print(f'{H = }\n{N = :{F}}\n{g = :{F}}\n{k = :{F}}')

print("\n0. server stores (I, s, v) in its password database")

# The server must first generate the password verifier
I = "person"        # Username
p = "password1234"  # Password
s = cryptrand(64)   # Salt for the user
x = H(s, I, p)      # Private key
v = pow(g, x, N)    # Password verifier

print(f'{I = }\n{p = }\n{s = :{F}}\n{x = :{F}}\n{v = :{F}}')

# 0. server stores(I, s, v) in its password database
# I = 'person'
# p = 'password1234'
# s = 0x67bc8932cfd26a49
# x = 0x98a4bce8dde877762a90222f1a1161eba9248590a47eb83aa9e5bd7ecda5368d
# v = 0xa7e2038e675d577ac0f318999cab67bba7ec2daf45d2d09f7911b1b78d2fc7f963cd0ac8f17851e0516f059e453672c3b70fcecf5f6843180b271abdd01f552ccda7b24fe4719336409cbc1352f8517be651b8935cc0b74ff2819fa07a3f031537d4cfd9f8df7b788a5f2f88e1cd4106b35c38b3d7205a

# <demo> --- stop ---

print("\n1. client sends username I and public ephemeral value A to the server")
a = cryptrand()
A = pow(g, a, N)
print(f"{I = }\n{A = :{F}}")  # client->server (I, A)

# 1. client sends username I and public ephemeral value A to the server
# I = 'person'
# A = 0x678556a7e76581e051af656e8cee57ae46df43f1fce790f7750a3ec5308a85da4ec4051e5cb74d3e463685ee975a2747cf49035be67c931b56e793f23ea3524af8909dcfbc8675d872361025bf884778587ac49454a57c53a011ac2be2839bfb51bf7847a49a483aba870dc7a8b467a81cec91b8ae7813

# <demo> --- stop ---

print("\n2. server sends user's salt s and public ephemeral value B to client")
b = cryptrand()
B = (k * v + pow(g, b, N)) % N
print(f"{s = :{F}}\n{B = :{F}}")  # server->client (s, B)

# 2. server sends user's salt s and public ephemeral value B to client
# s = 0x67bc8932cfd26a49
# B = 0xb615a0a5ea6abf138077bbd869f6a8da37dfc0b7e06a9f5fac5c1e4109c6302cb3e94dcc2cc76da7b3d87d7e9b68a1db998ab239cfde609f3f7a1ece4a491ce3d9a665c20cf4e4f06730daaa8f52ed61e45bbb67cdc337bf648027ffa7f0f215d5ebe43f9f51832518f1142266aae0dfa960e0082b5154


# <demo> --- stop ---

print("\n3. client and server calculate the random scrambling parameter")
u = H(A, B)  # Random scrambling parameter
print(f"{u = :{F}}")

# 3. client and server calculate the random scrambling parameter
# u = 0x796b07e354c04f672af8b76a46560655086355a9bbce11361f01b45d991c0c52

# <demo> --- stop ---

print("\n4. client computes session key")
x = H(s, I, p)
S_c = pow(B - k * pow(g, x, N), a + u * x, N)
K_c = H(S_c)
print(f"{S_c = :{F}}\n{K_c = :{F}}")

# 4. client computes session key
# S_c = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc
# K_c = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e

# <demo> --- stop ---

print("\n5. server computes session key")
S_s = pow(A * pow(v, u, N), b, N)
K_s = H(S_s)
print(f"{S_s = :{F}}\n{K_s = :{F}}")

# 5. server computes session key
# S_s = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc
# K_s = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e

# <demo> --- stop ---

print("\n6. client sends proof of session key to server")
M_c = H(H(N) ^ H(g), H(I), s, A, B, K_c)
print(f"{M_c = :{F}}")
# client->server (M_c) ; server verifies M_c

# 6. client sends proof of session key to server
# M_c = 0x75500df4ea36e06406ac1f8a8241429b8e90a8cba3adda3405c07f19ea3101e8

# <demo> --- stop ---

print("\n7. server sends proof of session key to client")
M_s = H(A, M_c, K_s)
print(f"{M_s = :{F}}")
# server->client (M_s) ;  client verifies M_s

# 7. server sends proof of session key to client
# M_s = 0x182ed24d1ad2fb55d2268c46b42435d1ef02e0fc49f647c03dab8b2a48b0bd3d
</syntaxhighlight>


== Implementation pitfalls ==

=== Offline bruteforce attack with server-first messaging in the absence of key verification ===

If the server sends an encrypted message without waiting for verification from the client then an attacker is able to mount an offline bruteforce attack similar to hash cracking. This can happen if the server sends an encrypted message in the second packet alongside the salt and ''B'' or if key verification is skipped and the server (rather  than the client) sends the first encrypted message. This is tempting as after the very first packet, the server has every information to compute the shared key ''K''.

The attack goes as follow:

# Carol → Steve: generate random value ''a''; send {{mvar|I}} and ''A'' = ''g''{{sup|{{var|a}}}}
# Steve: {{math|1=''u'' = ''H''(''A'', ''B''); ''S''=''Av''{{sup|{{var|u}}}}; ''K''=''H''(''S'')}}
# Steve: generate message ''m'' and encrypts it to produce {{math|1=''c''=ENC(''K'',''m'')}}
# Steve → Carol: generate random value ''b''; send ''s'', {{math|1=''B'' = ''kv'' + ''g''{{sup|{{var|b}}}}}} and ''c''

Carol doesn't know ''x'' or ''v''. But given any password ''p'' she can compute:
* {{math|1=''x''<sub>''p''</sub> = ''H''(salt, ''p'')}}
* {{math|1=''S''<sub>''p''</sub> = (''B'' - ''kg''<sup>''x''<sub>''p''</sub></sup>)<sup>(''a'' + ''ux''<sub>''p''</sub>)</sup>}}
* {{math|1=''K''<sub>p</sub> = ''H''(''S''<sub>p</sub>)}} 

''K''<sub>''p''</sub> is the key that Steve would use if ''p'' was the expected password. All values required to compute ''K''<sub>''p''</sub> are either controlled by Carol or known from the first packet from Steve. Carol can now try to guess the password, generate the corresponding key, and attempt to decrypt Steve's encrypted message ''c'' to verify the key. As protocol messages tend to be structured, it is assumed that identifying that ''c'' was properly decrypted is easy. This allows offline recovery of the password.

This attack would not be possible had Steve waited for Carol to prove she was able to compute the correct key before sending an encrypted message. Proper implementations of SRP are not affected by this attack as the attacker would be unable to pass the key verification step.

=== Offline bruteforce based on timing attack ===

In 2021 Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt published PARASITE,<ref>{{cite web |title=PARASITE: PAssword Recovery Attack against Srp Implementations in ThE wild |url=https://dl.acm.org/doi/10.1145/3460120.3484563 |access-date=8 November 2023}}</ref> a paper in which they demonstrate practical exploitation of a timing attack over the network. This exploits non-constant implementations of modular exponentiation of big numbers and impacted OpenSSL in particular.

== Implementations ==
* [https://github.com/Glusk/srp6-variables SRP-6 Variables] A Java library of cryptographic primitives required to implement the SRP-6 protocol.
* [[OpenSSL]] version 1.0.1 or later.
* [[Botan (programming library)|Botan]] (the C++ crypto library) contains an implementation of SRP-6a
* [[TLS-SRP]] is a set of ciphersuites for [[transport layer security]] that uses SRP.
* [https://github.com/symeapp/srp-client srp-client] SRP-6a implementation in [[JavaScript]] (compatible with RFC 5054), open source, [[Mozilla Public License]] (MPL) licensed.
* The [https://clipperz.is/open_source/javascript_crypto_library JavaScript Crypto Library] includes a JavaScript implementation of the SRP protocol, open source, [[Berkeley Software Distribution|BSD]] licensed.
* [https://www.gnu.org/software/gnu-crypto/ Gnu Crypto] provide a [[Java (programming language)|Java]] implementation licensed under the [[GNU General Public License]] with the "library exception", which permits its use as a library in conjunction with non-Free software.
* [[Bouncy Castle (cryptography)|The Legion of the Bouncy Castle]] provides Java and [[C Sharp (programming language)|C#]] implementations under the [[MIT License]].
* [http://connect2id.com/products/nimbus-srp Nimbus SRP] is a Java library providing a verifier generator, client and server-side sessions. Includes interfaces for custom password key, client and server evidence message routines. No external dependencies. Released under the [[Apache License|Apache 2.0 license]].
* [https://code.google.com/p/srplibcpp/ srplibcpp] is a C++ implement base on [[MIRACL (software)|MIRACL]].
* [https://github.com/slechta/DragonSRP/ DragonSRP] is a C++ modular implementation currently works with [[OpenSSL]].
* [[Json2Ldap]] provides SRP-6a authentication to [[Lightweight Directory Access Protocol|LDAP]] directory servers.
* [https://github.com/cocagne/csrp csrp] SRP-6a implementation in C.
* [http://search.cpan.org/~mik/Crypt-SRP/ Crypt-SRP] SRP-6a implementation in [[Perl]].
* [https://github.com/cocagne/pysrp pysrp] SRP-6a implementation in [[Python (programming language)|Python]] (compatible with [https://code.google.com/p/csrp/ csrp]).
* [https://bitbucket.org/pbleyer/py3srp py3srp] SRP-6a implementation in pure [[Python (programming language)|Python3]].
* [https://pypi.org/project/srptools/ srptools] Tools to implement Secure Remote Password (SRP) authentication in [[Python (programming language)|Python]]. [https://github.com/secure-remote-password/implementations Verified compatible libraries].
* [http://meteor.com/ Meteor] web framework's Accounts system implements SRP for password authentication.
* [https://github.com/lamikae/srp-rb srp-rb] SRP-6a implementation in [[Ruby (programming language)|Ruby]].
* [https://github.com/falkmueller/srp falkmueller] [https://code.falk-m.de/srp/ demo SRP-6a] implementation of the [[Stanford University|Stanford]] SRP Protocol Design in [[JavaScript]] and [[PHP]] under the [[MIT License]].
* [https://github.com/RuslanZavacky/srp-6a-demo srp-6a-demo] SRP-6a implementation in [[PHP]] and [[JavaScript]].
* [https://bitbucket.org/simon_massey/thinbus-srp-js thinbus-srp-js] SRP-6a implementation in [[JavaScript]]. Comes with compatible [[Java (programming language)|Java]] classes which use [http://software.dzhuvinov.com/nimbus-srp.html Nimbus SRP] a demonstration app using [[Spring Security]]. There is also a demonstration application performing authentication to a [[PHP]] server. Released under the [[Apache License]].
* [https://bitwiseshiftleft.github.io/sjcl/ Stanford JavaScript Crypto Library (SJCL)] implements SRP for key exchange.
* [https://github.com/mozilla/node-srp node-srp] is a JavaScript client and server (node.js) implementation of SRP.
* [https://sourceforge.net/projects/srp6-for-csharp-and-java/ SRP6 for C# and Java] implementation in C# and Java.
* [https://github.com/AddAloner/ALOSRPAuth ALOSRPAuth] is an Objective-C implementation of SRP-6a.
* [https://github.com/opencoff/go-srp go-srp] is a Go implementation of SRP-6a.
* [https://github.com/midonet/tssrp6a tssrp6a] is a TypeScript implementation of SRP-6a.
* [https://github.com/theicenet/theicenet-cryptography TheIceNet Cryptography] Java library to develop cryptography-based Spring Boot applications. Implements SRP-6a. Under [[Apache License]].
*[https://github.com/secure-remote-password/srp.net SRP-6a] in .NET implementation of SRP-6a
*[https://support.apple.com/guide/security/homekit-communication-security-sec3a881ccb1/web Apple Homekit] [[Apple Homekit]] uses SRP when pairing with "smart" home accessories & devices
* [https://proton.me/blog/encrypted-email-authentication Proton Mail] Authentication for Email Encryption
* [https://github.com/posterity/srp SRP] is a Go implementation of SRP, used to authenticate users on [https://posterity.life Posterity].

== History ==

The SRP project was started in 1997.<ref>{{cite web |title=SRP: About the Project |url=http://srp.stanford.edu/project.html |website=srp.stanford.edu}}</ref> Two different approaches to fixing a security hole in SRP-1 resulted in SRP-2 and SRP-3.<ref>{{cite web |title=SRP-2: Design Specifications |url=http://srp.stanford.edu/design2.html |website=srp.stanford.edu}}</ref> SRP-3 was first published in 1998 in a conference.<ref>Wu, T., "[http://srp.stanford.edu/ndss.html The Secure Remote Password Protocol]", Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium pp. 97-111, March 1998.</ref> RFC 2945, which describes SRP-3 with SHA1, was published in 2000.<ref>{{cite web |title=SRP: Design Specifications |url=http://srp.stanford.edu/design3.html |website=srp.stanford.edu}}</ref> SRP-6, which fixes "two-for-one" guessing and messaging ordering attacks, was published in 2002.<ref name=srp6/> SRP-6a appeared in the official "libsrp" in version 2.1.0, dated 2005.<ref>CHANGES file in srp-2.1.2.tar.gz, available from http://srp.stanford.edu/download.html</ref> SRP-6a is found in standards as:

* ISO/IEC 11770-4:2006 "Key Agreement Mechanism 2" (calls the method "SRP-6, but has the ''k'' calculation of 6a)
* RFC 5054 TLS-SRP of 2007 (again referred to as "SRP-6", but corrected in erratum<ref>{{cite web |last1=Wang |first1=Mingye |title=RFC Errata Report #7538 |url=https://www.rfc-editor.org/errata/eid7538 |website=RFC Editor |access-date=15 October 2023}}</ref>)
* IEEE Std 1363.2-2008 "DLAPKAS-SRP6" (again referred to as "SRP-6")<ref>IEEE 1363.2-2008: IEEE Standard Specification for Password-Based Public-Key Cryptographic Techniques</ref>

IEEE 1363.2 also includes a description of "SRP5", a variant replacing the discrete logarithm with an [[elliptic curve]] contributed by Yongge Wang in 2001.<ref>Wang, Y., "IEEE P1363.2 Submission / D2001-06-21," [P1363.2-ecsrp-06-21.doc] A contribution by Yongge Wang for P1363.2 giving an elliptic curve version of the SRP protocol, June 21, 2001.</ref> It also describes SRP-3 as found in RFC 2945.

== See also ==
* [[Challenge–response authentication]]
* [[Password-authenticated key agreement]]
* [[Salted Challenge Response Authentication Mechanism]] (SCRAM)
* [[SPEKE|Simple Password Exponential Key Exchange]]
* [[Zero-knowledge password proof]]

== References ==
<references />

== External links ==
* {{Official website|http://srp.stanford.edu}}
* [http://srp.stanford.edu/license.txt SRP License]—BSD like open source.
* [https://patents.google.com/patent/US6539479 US6539479] - SRP Patent (Expired on May 12, 2015 due to failure to pay maintenance fees (according to Google Patents). Originally set to expire in July 2018).

=== Manual pages ===
* [http://ppp.samba.org/pppd.html pppd(8)]: Point-to-Point Protocol Daemon
* [http://man7.org/linux/man-pages/man1/srptool.1.html srptool(1)]: Simple SRP password tool

=== RFCs ===
* {{IETF RFC|2944|link=no}} - Telnet Authentication: SRP
* {{IETF RFC|2945|link=no}} - The SRP Authentication and Key Exchange System (version 3)
* {{IETF RFC|3720|link=no}} - Internet Small Computer Systems Interface (iSCSI)
* {{IETF RFC|3723|link=no}} - Securing Block Storage Protocols over IP
* {{IETF RFC|3669|link=no}} - Guidelines for Working Groups on Intellectual Property Issues
* {{IETF RFC|5054|link=no}} - Using the Secure Remote Password (SRP) Protocol for TLS Authentication

=== Other links ===
* [https://archive.today/20081216020624/http://grouper.ieee.org/groups/1363/ IEEE 1363]
* [http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08027.html SRP Intellectual Property Slides (Dec 2001 - possible deprecated)] The EKE patents mentioned expired in 2011 and 2013.

{{Cryptography navbox | public-key}}

[[Category:Key-agreement protocols]]
[[Category:Password authentication]]