RFC 2945
The SRP Authentication and Key Exchange System
The SRP Authentication and Key Exchange System 🎀
RFC 2945 📜 is from the Network Working Group, and its author is T. Wu of Stanford University 🎓.
It's a Standards Track document, dated September 2000 🗓️. The title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any earlier RFC 💅.
Status of this Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📋. Distribution of this memo is unlimited 🌸.
Copyright Notice 🔒
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract 🦋
Okay so this document describes a cryptographically strong network authentication mechanism called the Secure Remote Password (SRP) protocol 🔐. It's built for setting up secure connections with a password the user picks, and it gets rid of the security problems that usually come with reusable passwords 🙅♀️.
The system also does a secure key exchange during authentication, so security layers (privacy and/or integrity protection) can be turned on for the session 🔑✨. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys 🙌. SRP beats existing challenge-response techniques on both security and deployment, which makes it an ideal drop-in replacement anywhere secure password authentication is needed 👑.
1. Introduction 💖
It's giving "long-standing problem" 😭. Most Internet protocols in use right now have had a hard time pairing secure authentication with easy-to-use authentication. There are two sides to it: users want passwords they can actually remember, but most password-based authentication systems barely protect against even passive attackers, especially when weak, easy-to-guess passwords are used 🙈.
Eavesdropping on a TCP/IP network is super easy and super effective against protocols that send passwords in the clear 👀. Even so-called "challenge-response" techniques like the one described in [RFC 2095] and [RFC 1760], which are designed to stop simple sniffing attacks, can be broken by a "dictionary attack" 💀. That happens when an attacker captures the messages from a legit run of the protocol and uses them to check a bunch of guessed passwords from a precompiled "dictionary" of common passwords. It works because users tend to pick simple, easy-to-remember passwords, and those are also easy to guess 🍓.
Lots of existing mechanisms also need the password database on the host to stay secret, because the password P or some private hash h(P) is stored there and would compromise security if revealed 🫣. That approach often turns into "security through obscurity" and goes against the UNIX convention of keeping a "public" password file whose contents can be revealed without destroying system security 🙃.
SRP meets the strictest requirements laid down in [RFC 1704] for a non-disclosing authentication protocol 🏆. It offers complete protection against both passive and active attacks, and it does this efficiently with a single Diffie-Hellman-style round of computation, so it works for both interactive and non-interactive authentication across a wide range of Internet protocols 🔥. It keeps its security even with low-entropy passwords, so it can slot right into existing user applications 🧚.
2. Conventions and Terminology ✨
The protocol in this document is sometimes called "SRP-3" for historical purposes 📚. This particular protocol is described in [SRP] and is believed to have very good logical and cryptographic resistance to both eavesdropping and active attacks 🛡️.
This document doesn't try to describe SRP in the context of any particular Internet protocol 🙅♀️. Instead, it describes an abstract protocol that can be easily fitted to a particular application. For example, the specific format of messages (including padding) is not specified 🎀. Those choices are left to the protocol implementor 💅.
The one implementation issue worth specifying here is the mapping between strings and integers 🔢. Internet protocols are byte-oriented, but SRP does algebraic operations on its messages, so it makes sense to define at least one way to turn integers into a string of bytes and back 🦋.
An n-byte string S can be converted to an integer like this:
i = S[n-1] + 256 * S[n-2] + 256^2 * S[n-3] + ... + 256^(n-1) * S[0]where i is the integer and S[x] is the value of the x'th byte of S 🧮. In human terms, the string of bytes is the integer written in base 256, with the most significant digit first 💜. When converting back to a string, S[0] must be non-zero (padding is considered to be a separate, independent process) ⭐. This conversion method works for file storage, in-memory representation, and network transmission of large integer values 🌈. Unless otherwise specified, this mapping will be assumed 🫶.
If implementations need to pad a string that represents an integer value, it is recommended that they use zero bytes and add them to the beginning of the string 🌸. The conversion back to an integer automatically discards leading zero bytes, which makes this padding scheme less prone to error 🙌.
When this document says SHA, it means the SHA-1 message digest algorithm described in [SHA1] 🔐.
3. The SRP-SHA1 mechanism 🔑
This section describes an implementation of the SRP authentication and key-exchange protocol that uses the SHA hash function to generate session keys and authentication proofs 🦋.
The host stores user passwords as triplets of the form:
{ <username>, <password verifier>, <salt> }Password entries are generated like this:
<salt> = random()
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
<password verifier> = v = g^x % NThe | symbol means string concatenation, the ^ operator is exponentiation, and the % operator is the integer remainder operation 🧠. Most implementations do the exponentiation and remainder in a single stage so they don't end up with unwieldy intermediate results 💅. Note that the 160-bit output of SHA is implicitly converted to an integer before it gets operated on 🔢.
Authentication is usually started by the client 🚀. Here's how the messages go:
Client Host
-------- ------
U = <username> -->
<-- s = <salt from passwd file>Once the client identifies itself to the host, it receives the salt stored on the host under its username 🫶.
a = random()
A = g^a % N -->
v = <stored password verifier>
b = random()
<-- B = (v + g^b) % N
p = <raw password>
x = SHA(s | SHA(U | ":" | p))
S = (B - g^x) ^ (a + u * x) % N S = (A * v^u) ^ b % N
K = SHA_Interleave(S) K = SHA_Interleave(S)
(this function is described
in the next section)The client generates a random number, raises g to that power modulo the field prime, and sends the result to the host 🎲. The host does the same thing, and it also adds the public verifier before sending its value to the client 🤝. Then both sides build the shared session key from their own formulas 🗝️✨.
The parameter u is a 32-bit unsigned integer 🔢. Its value comes from the first 32 bits of the SHA1 hash of B, MSB first 🧩.
The client MUST abort authentication if B % N is zero 🚫.
The host MUST abort the authentication attempt if A % N is zero 🚫. The host MUST send B after receiving A from the client, never before 🙅♀️.
At this point, the client and server should have a common session key that is secure (i.e. not known to an outside party) 🔐. To finish authentication, they have to prove to each other that their keys are identical 👯♀️. The proofs look like this:
M = H(H(N) XOR H(g) | H(U) | s | A | B | K)
-->
<-- H(A | M | K)The server calculates M using its own K and compares it against the client's response 🧐. If they don't match, the server MUST abort and signal an error before it tries to answer the client's challenge 🚨. Skipping that step could compromise the security of the user's password 💀.
If the server gets a correct response, it sends its own proof to the client 🤍. The client computes the expected response using its own K to verify that the server is authentic 🕵️♀️. If the client responded correctly, the server MUST respond with its hash value 💖.
The transactions in this protocol description don't necessarily line up one-to-one with actual protocol messages 🎀. The description is only meant to show how the different parameters relate to each other and how they're computed 🧚. For example, an implementation of the SRP-SHA1 mechanism could combine some of the flows like this:
Client Host
-------- ------
U, A -->
<-- s, B
H(H(N) XOR H(g) | H(U) | s | A | B | K)
-->
<-- H(A | M | K)The values of N and g used in this protocol must be agreed upon by the two parties 🤝. They can be set in advance, or the host can supply them to the client 🌟. In the latter case, the host should send the parameters in the first message, along with the salt 📨. For maximum security, N should be a safe prime (i.e. a number of the form N = 2q + 1, where q is also prime) 💎. Also, g should be a generator modulo N (see [SRP] for details), which means that for any X where 0 < X < N, there exists a value x for which g^x % N == X 🌈.
3.1. Interleaved SHA 🧶
The SHA_Interleave function used in SRP-SHA1 generates a session key that's twice as long as the 160-bit output of SHA1 💅. To compute it, first remove all leading zero bytes from the input 🧹. If the length of the resulting string is odd, also remove the first byte 🙈. Call the resulting string T 🏷️. Then pull the even-numbered bytes into a string E and the odd-numbered bytes into a string F 👯♀️:
E = T[0] | T[2] | T[4] | ...
F = T[1] | T[3] | T[5] | ...Both E and F should be exactly half the length of T 📏. Hash each one with regular SHA1 🔐:
G = SHA(E)
H = SHA(F)Last step: interleave the two hashes back together to form the output 🧵:
result = G[0] | H[0] | G[1] | H[1] | ... | G[19] | H[19]The result will be 40 bytes (320 bits) long 🎉.
3.2. Other Hash Algorithms ✨
okay so SRP is not picky 💅 you can totally use hash functions other than SHA! 🦋 if the hash spits out something a different length than SHA (that's 20 bytes, bestie), it may change how long some of the messages in the protocol are, but the core operation stays exactly the same 🫶
fun history moment: earlier versions of SRP used MD5, which is described in [RFC 1321]. 🌸 keyed hash transforms are also RECOMMENDED for use with SRP 🔥 one possible construction uses HMAC [RFC 2104], where you use K to key the hash in each direction instead of concatenating it with the other parameters. it's giving clean and intentional 👑
any hash function you use with SRP SHOULD produce an output of at least 16 bytes 💀 and it needs the property that small changes in the input cause significant nonlinear changes in the output. ngl that's the whole avalanche vibe 🧚 [SRP] goes way deeper on all of this if you want the lore 📚
4. Security Considerations 🔐
okay this section is the most important one, so pls read it like it's your group chat's safety plan 😭
this entire memo is about an authentication and key-exchange system that protects passwords and exchanges keys across an UNTRUSTED network 🫣 it's giving secure because it removes the need to send cleartext passwords over the network, and it enables encryption through its secure key-exchange mechanism 🎀
the private values for a and b are roughly like the private values in a Diffie-Hellman exchange, and they have similar constraints of length and entropy 🧠 implementations MAY choose to increase the length of the parameter u, as long as both client and server agree, but it is NOT RECOMMENDED that it be shorter than 32 bits ⚠️
SRP was designed not only to counter casual password-sniffing, but also to stop a determined attacker with a dictionary of passwords from guessing passwords using captured network traffic 🕵️♀️ the SRP protocol itself also resists active network attacks, and implementations can use the securely exchanged keys to protect the session against hijacking and provide confidentiality 🔒 main character energy, literally 👑
SRP also has the added advantage of letting the host store passwords in a form that isn't directly useful to an attacker 🙈 even if the host's password database got publicly revealed, the attacker would still need an expensive dictionary search to get any passwords. the exponential computation needed to validate a guess here is WAY more time-consuming than the hash most UNIX systems use right now 💀 hosts are still ADVISED, though, to try their absolute best to keep their password files secure 🫶
5. References 📚
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC 1704] Haller, N. and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
1760, Feburary 1995.
[RFC 2095] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2095, January 1997.
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[SHA1] National Institute of Standards and Technology (NIST),
"Announcing the Secure Hash Standard", FIPS 180-1, U.S.
Department of Commerce, April 1995.
[SRP] T. Wu, "The Secure Remote Password Protocol", In
Proceedings of the 1998 Internet Society Symposium on
Network and Distributed Systems Security, San Diego, CA,
pp. 97-111.6. Author's Address 🧑💻
Thomas Wu
Stanford University
Stanford, CA 94305
EMail: tjw@cs.Stanford.EDU7. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved.
this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. however, this document itself may NOT be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process MUST be followed), or as required to translate it into languages other than English 🌈
the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️
this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society 🎀
📦 where this page comes from
- ietf: rfc2945 2000-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms