RFC 5054
Using the Secure Remote Password (SRP) Protocol for TLS Authentication
RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication ✨
okay bestie, this one is the RFC that gives TLS a password login that doesn't leak the password 🔐💖 It's Request for Comments 5054, and it came out in November 2007. The category is Informational, so it's sharing info and it's not a formal Internet standard 🌸
The authors are D. Taylor (Independent), T. Wu (Cisco), N. Mavrogiannopoulos (Independent), and T. Perrin (Independent) 👑 The header doesn't list any "Obsoletes" or "Updates" lines, so this doc doesn't replace or update anything else 🦋 The network group it's from is the Network Working Group.
Status of This Memo 🧚
This memo gives info to the Internet community. It is not an Internet standard of any kind, and distribution of it is totally unlimited 💅
Abstract 🎀
This memo shows how to use the Secure Remote Password protocol as an authentication method for Transport Layer Security (TLS) 🔥
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SRP Authentication in TLS . . . . . . . . . . . . . . . . . . 3
2.1. Notation and Terminology . . . . . . . . . . . . . . . . . 3
2.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 4
2.3. Text Preparation . . . . . . . . . . . . . . . . . . . . . 5
2.4. SRP Verifier Creation . . . . . . . . . . . . . . . . . . 5
2.5. Changes to the Handshake Message Contents . . . . . . . . 5
2.5.1. Client Hello . . . . . . . . . . . . . . . . . . . . . 6
2.5.2. Server Certificate . . . . . . . . . . . . . . . . . . 7
2.5.3. Server Key Exchange . . . . . . . . . . . . . . . . . 7
2.5.4. Client Key Exchange . . . . . . . . . . . . . . . . . 8
2.6. Calculating the Premaster Secret . . . . . . . . . . . . . 8
2.7. Ciphersuite Definitions . . . . . . . . . . . . . . . . . 9
2.8. New Message Structures . . . . . . . . . . . . . . . . . . 9
2.8.1. Client Hello . . . . . . . . . . . . . . . . . . . . . 10
2.8.2. Server Key Exchange . . . . . . . . . . . . . . . . . 10
2.8.3. Client Key Exchange . . . . . . . . . . . . . . . . . 11
2.9. Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
3.1. General Considerations for Implementors . . . . . . . . . 12
3.2. Accepting Group Parameters . . . . . . . . . . . . . . . . 12
3.3. Protocol Characteristics . . . . . . . . . . . . . . . . . 12
3.4. Hash Function Considerations . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Normative References . . . . . . . . . . . . . . . . . . . 14
5.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. SRP Group Parameters . . . . . . . . . . . . . . . . 16
Appendix B. SRP Test Vectors . . . . . . . . . . . . . . . . . . 21
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 221. Introduction ✨
okay so, when this was written, TLS [TLS] could only do authentication with public key certificates, pre-shared keys, or Kerberos 🫶
Those methods aren't a great fit for some apps that are now being wired up to use TLS, like [IMAP] 😭 Lots of protocols are built around the classic user name and password login, so being able to use those safely is a much easier path to extra security 💜
SRP ([SRP], [SRP-6]) is an authentication method that lets you use user names and passwords over channels that aren't encrypted, and the password never gets revealed to an eavesdropper 🙈 SRP also gives you a shared secret at the end of the auth exchange, and that secret can be used to make encryption keys 🔑 It's giving security genius.
This doc explains how to use SRP as an authentication method for TLS 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ] 🎀
2. SRP Authentication in TLS 💅
2.1. Notation and Terminology 🌈
The version of SRP used here is sometimes called "SRP-6" [SRP-6]. It's a slight improvement over "SRP-3", which was described in [SRP] and [SRP-RFC]. To keep things simple, this doc and [SRP-RFC] include the details you need to implement SRP-6, and [SRP-6] is only cited for info 📚
This doc uses these variable names from [SRP-6]:
N,g: group parameters (prime and generator)s: saltB,b: server's public and private valuesA,a: client's public and private valuesI: user name (aka "identity")P: passwordv: verifierk: SRP-6 multiplier
The | symbol means string concatenation, the ^ operator is exponentiation, and the % operator is the integer remainder operation 🧮
Converting between integers and byte-strings assumes the most significant bytes are stored first, like in [TLS] and [SRP-RFC] 💖 In the text that follows, if an integer gets turned into a byte-string implicitly, the most significant byte in the resulting byte-string MUST be non-zero. If the conversion is explicitly specified with the operator PAD(), the integer gets converted implicitly first, and then the byte-string is left-padded with zeros (if needed) until its length equals the implicitly-converted length of N ✨
2.2. Handshake Protocol Overview 🦋
The arrival of [SRP-6] means SRP can be implemented using the standard sequence of handshake messages defined in [TLS] 🫶
Here's how the parameters for each message fit together 👇
Client Server
Client Hello (I) -------->
Server Hello
Certificate*
Server Key Exchange (N, g, s, B)
<-------- Server Hello Done
Client Key Exchange (A) -------->
[Change cipher spec]
Finished -------->
[Change cipher spec]
<-------- Finished
Application Data <-------> Application Data
* Indicates an optional message that is not always sent.
Figure 12.3. Text Preparation 🌸
The user name and password strings SHALL be UTF-8 encoded Unicode, prepared using the [SASLPREP] profile of [STRINGPREP] 🔥
2.4. SRP Verifier Creation 🧚
The verifier is calculated the way Section 3 of [SRP-RFC] describes. We repeat the algorithm here for convenience 💜
The verifier (v) is computed from the salt (s), user name (I), password (P), and group parameters (N, g). The computation uses the [SHA1] hash algorithm:
x = SHA1(s | SHA1(I | ":" | P))
v = g^x % N2.5. Changes to the Handshake Message Contents 🍓
This section covers the changes to the TLS handshake message contents when SRP is used for authentication. The definitions of the new message contents and the on-the-wire changes are in Section 2.8 👑
2.5.1. Client Hello 🎀
The user name gets appended to the standard client hello message using the extension mechanism from [TLSEXT] (see Section 2.8.1). This user name extension is from now on called the "SRP extension" 💅 The subsections below give the details of how it's used.
2.5.1.1. Session Resumption 🌈
When a client tries to resume a session that uses SRP authentication, the client MUST include the SRP extension in the client hello message. That's in case the server can't or won't allow session resumption, which means a full handshake is required 🔄
If the server does agree to resume an existing session, the server MUST ignore the information in the SRP extension of the client hello message, except for including it in the finished message hashes. This makes sure attackers can't swap out the authenticated identity without supplying the proper authentication info 🛡️
2.5.1.2. Missing SRP Extension 🦋
The client may offer SRP cipher suites in the hello message but leave out the SRP extension. If the server would like to select an SRP cipher suite in this case, the server SHOULD send a fatal unknown_psk_identity alert (see Section 2.9) right after processing the client hello message 🙈
A client that gets this alert MAY choose to reconnect and resend the hello message, this time with the SRP extension. This lets the client say it supports SRP without having to prompt the user for their user name and password, and without exposing the user name in the clear, unless that's actually necessary 🫶
2.5.1.3. Unknown SRP User Name 💀
If the server doesn't have a verifier for the user name in the SRP extension, the server MAY abort the handshake with an unknown_psk_identity alert (see Section 2.9). Or, if the server wants to hide the fact that this user name doesn't have a verifier, the server MAY simulate the protocol as if a verifier existed, and then reject the client's finished message with a bad_record_mac alert, as if the password were wrong 🎭
To simulate an entry for each user name, the server must consistently return the same salt (s) and group (N, g) values for the same user name. For example, the server could store a secret "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to generate the salts [HMAC]. For B, the server can return a random value between 1 and N-1 inclusive. However, the server should take care to simulate computation delays. One way to do this is to generate a fake verifier using the "seed key" approach, and then carry on with the protocol as usual 🧠
2.5.2. Server Certificate 🔐
The server MUST send a certificate if it agrees to an SRP cipher suite that requires the server to provide extra authentication in the form of a digital signature. Section 2.7 has the details on which cipher suites defined in this doc require a server certificate to be sent 👑
okay that's the end of part 1 bestie 🥹💖 Sections 2.5.3 onward (Server Key Exchange, Client Key Exchange, the premaster secret math, ciphersuites, message structures, error alerts, and the security stuff) are coming in the next part, so stay tuned 💅✨
2.5.3. Server Key Exchange 🎀
okay so the server key exchange message carries the prime (N), the generator (g), and the salt value (s). The server pulls those from the SRP password file based on the user name (I) it got in the client hello extension. 🔐
It also carries the server's public value (B) 💖. The server works that out as B = k*v + g^b % N, where b is a random number that SHOULD be at least 256 bits in length, and k = SHA1(N | PAD(g)).
If the server has sent a certificate message, the server key exchange message MUST be signed. no cap, this part is non-negotiable 🫶
The group parameters (N, g) sent in this message MUST have N as a safe prime (a prime of the form N=2q+1, where q is also prime). The integers from 1 to N-1 form a group under multiplication % N, and g MUST be a generator of this group. On top of that, the group parameters MUST NOT be specially chosen to allow efficient computation of discrete logarithms. this is the main character energy of crypto params ✨
The SRP group parameters in Appendix A meet all of the above requirements, so the client SHOULD accept any parameters from that appendix that have a large enough N value to meet her security requirements 💅
The client MAY accept other group parameters from the server, as long as the client has reason to believe those parameters satisfy the above requirements and have a large enough N value. For example, if the parameters the server sends match parameters on a "known-good" list, the client may choose to accept them 🌸 See Section 3 for additional security considerations relevant to accepting group parameters.
Group parameters that aren't accepted through one of the above methods MUST be rejected with an "insufficient_security" alert (see Section 2.9). rejected, no debate 🙅♀️
The client MUST abort the handshake with an "illegal_parameter" alert if B % N = 0. 💀
2.5.4. Client Key Exchange 🦋
The client key exchange message carries the client's public value (A). The client works it out as A = g^a % N, where a is a random number that SHOULD be at least 256 bits in length. ✨
The server MUST abort the handshake with an "illegal_parameter" alert if A % N = 0. same energy as before, bestie 🙈
2.6. Calculating the Premaster Secret 🍓
The client calculates the premaster secret like this:
I, P = <read from user>
N, g, s, B = <read from server>
a = random()
A = g^a % N
u = SHA1(PAD(A) | PAD(B))
k = SHA1(N | PAD(g))
x = SHA1(s | SHA1(I | ":" | P))
<premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % NAnd the server calculates it like this:
N, g, s, v = <read from password file>
b = random()
k = SHA1(N | PAD(g))
B = k*v + g^b % N
A = <read from client>
u = SHA1(PAD(A) | PAD(B))
<premaster secret> = (A * v^u) ^ b % NThe finished messages do the same job as the client and server evidence messages (M1 and M2) specified in [SRP-RFC]. If either the client or the server works out an incorrect premaster secret, the finished messages won't decrypt properly, and the other party will send back a "bad_record_mac" alert. 😭
If a client application gets a "bad_record_mac" alert while doing an SRP handshake, it should tell the user that the user name and password they typed in are incorrect. 🙈
2.7. Ciphersuite Definitions 👑
The following cipher suites are added by this document. The use of Advanced Encryption Standard (AES) cipher suites is as defined in [AESCIPH].
CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS require the server to send a certificate message containing a certificate with the specified type of public key, and to sign the server key exchange message using a matching private key. ✍️
Cipher suites that don't include a digital signature algorithm identifier assume that the server is authenticated by its possession of the SRP verifier. ✨
Implementations conforming to this specification MUST implement the TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA cipher suite, SHOULD implement the TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA cipher suites, and MAY implement the remaining cipher suites. the 3DES one is the bare minimum, babe 🎀
2.8. New Message Structures 🧚
This section shows the structure of the messages passed during a handshake that uses SRP for authentication. The representation language is the same one used in [TLS]. 💜
2.8.1. Client Hello
A new extension "srp", with value 12, has been added to the enumerated ExtensionType defined in [TLSEXT]. This value MUST be used as the extension number for the SRP extension. 🌈
The "extension_data" field of the SRP extension SHALL contain:
opaque srp_I<1..2^8-1>;where srp_I is the user name, encoded per Section 2.3.
2.8.2. Server Key Exchange
A new value, "srp", has been added to the enumerated KeyExchangeAlgorithm originally defined in [TLS].
When the value of KeyExchangeAlgorithm is set to "srp", the server's SRP parameters are sent in the server key exchange message, encoded in a ServerSRPParams structure.
If a certificate is sent to the client, the server key exchange message must be signed.
enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case srp: /* new entry */
ServerSRPParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
opaque srp_N<1..2^16-1>;
opaque srp_g<1..2^16-1>;
opaque srp_s<1..2^8-1>;
opaque srp_B<1..2^16-1>;
} ServerSRPParams; /* SRP parameters */2.8.3. Client Key Exchange
When the value of KeyExchangeAlgorithm is set to "srp", the client's public value (A) is sent in the client key exchange message, encoded in a ClientSRPPublic structure.
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
case srp: ClientSRPPublic; /* new entry */
} exchange_keys;
} ClientKeyExchange;
struct {
opaque srp_A<1..2^16-1>;
} ClientSRPPublic;2.9. Error Alerts 🚨
This document introduces four new uses of alerts:
- "unknown_psk_identity" (115) - this alert MAY be sent by a server that would like to select an offered SRP cipher suite, if the SRP extension is absent from the client's hello message. This alert is always fatal. See Section 2.5.1.2 for details. 🙃
- "unknown_psk_identity" (115) - this alert MAY be sent by a server that receives an unknown user name. This alert is always fatal. See Section 2.5.1.3 for details.
- "insufficient_security" (71) - this alert MUST be sent by a client that receives unknown or untrusted (N, g) values. This alert is always fatal. See Section 2.5.3 for details.
- "illegal_parameter" (47) - this alert MUST be sent by a client or server that receives a key exchange message with
A % N = 0orB % N = 0. This alert is always fatal. See Section 2.5.3 and Section 2.5.4 and for details.
The "insufficient_security" and "illegal_parameter" alerts are defined in [TLS]. The "unknown_psk_identity" alert is defined in [PSK]. 📜
3. Security Considerations 🔥
3.1. General Considerations for Implementors
The checks described in Section 2.5.3 and Section 2.5.4 on the received values for A and B are CRUCIAL for security and MUST be performed. this is not optional, bestie 🚫
The private values a and b SHOULD be at least 256-bit random numbers, to give approximately 128 bits of security against certain methods of calculating discrete logarithms. See [TLS], Section D.1, for advice on choosing cryptographically secure random numbers. 🔐
3.2. Accepting Group Parameters
An attacker who could calculate discrete logarithms % N could compromise user passwords, and could also compromise the confidentiality and integrity of TLS sessions. Clients MUST ensure that the received parameter N is large enough to make calculating discrete logarithms computationally infeasible. 💀
An attacker may try to send a prime value N that is large enough to be secure, but that has a special form for which the attacker can more easily compute discrete logarithms (e.g., using the algorithm discussed in [TRAPDOOR]). If the client executes the protocol using such a prime, the client's password could be compromised. Because checking for such primes in real time is hard, clients SHOULD only accept group parameters that come from a trusted source, such as those listed in Appendix A, or parameters configured locally by a trusted administrator. 🛡️
3.3. Protocol Characteristics
If an attacker learns a user's SRP verifier (e.g., by gaining access to a server's password file), the attacker can masquerade as the real server to that user, and can also attempt a dictionary attack to recover that user's password. 😱
An attacker could repeatedly contact an SRP server and try to guess a legitimate user's password. Servers SHOULD take steps to prevent this, such as limiting the rate of authentication attempts from a particular IP address or against a particular user name. 🚧
The client's user name is sent in the clear in the Client Hello message. To avoid sending the user name in the clear, the client could first open a conventional anonymous or server-authenticated connection, then renegotiate an SRP-authenticated connection with the handshake protected by the first connection. 🙈
If the client receives an "unknown_psk_identity" alert in response to a client hello, this alert may have been inserted by an attacker. The client should be careful about making any decisions, or forming any conclusions, based on receiving this alert. 👀
It's possible to choose a (user name, password) pair such that the resulting verifier also matches other, related, (user name, password) pairs. So anyone using verifiers should be careful not to assume that only a single (user name, password) pair matches the verifier. 🫣
3.4. Hash Function Considerations ✨
okay so this protocol uses SHA-1 to derive three values 🧚 and each one has its own job:
uprevents an attacker who learns a user's verifier from being able to authenticate as that user (see [SRP-6]).kprevents an attacker who can select group parameters from being able to launch a 2-for-1 guessing attack (see [SRP-6]).xcontains the user's password mixed with a salt.
cryptanalytic attacks against SHA-1 that only hit its collision-resistance don't break these uses 💅 but if attacks are found that do break these uses, new cipher suites should be specified to use a different hash algorithm. no cap, that's the plan B 🫶
in that situation, clients could send a Client Hello message with new and/or old SRP cipher suites plus a single SRP extension. then the server could pick the right cipher suite based on the type of verifier it has stored for that user. iconic flexibility 🦋
4. IANA Considerations 🎀
this document defines a new TLS extension "srp" (value 12), and its value has been assigned from the TLS ExtensionType Registry defined in [TLSEXT] 💖
this document also defines nine new cipher suites, whose values have been assigned from the TLS Ciphersuite registry defined in [TLS]. here's the whole squad 👑
CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };5. References 📚
5.1. Normative References
- [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol version 1.1", RFC 4346, April 2006.
- [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
- [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
- [SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user names and passwords", RFC 4013, February 2005.
- [SRP-RFC] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
- [SHA1] "Secure Hash Standard (SHS)", FIPS 180-2, August 2002.
- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [AESCIPH] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
- [PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
- [MODP] Kivinen, T. and M. Kojo, "More Modular Exponentiation (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
5.2. Informative References
- [IMAP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
- [SRP-6] Wu, T., "SRP-6: Improvements and Refinements to the Secure Remote Password Protocol", Submission to IEEE P1363.2 working group, October 2002,
<http://grouper.ieee.org/groups/1363/>. - [SRP] Wu, T., "The Secure Remote Password Protocol", Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium pp. 97-111, March 1998.
- [TRAPDOOR] Gordon, D., "Designing and Detecting Trapdoors for Discrete Log Cryptosystems", Springer-Verlag Advances in Cryptology - Crypto '92, pp. 66-75, 1993.
Appendix A. SRP Group Parameters 💖
okay so this is the appendix where the actual numbers live 🧚✨ the 1024-, 1536-, and 2048-bit groups come from software Tom Wu and Eugene Jhong made for the Stanford SRP distribution, and they were later proven to be prime 🔥 the bigger primes are borrowed from [MODP], BUT the generators here were calculated to be primitive roots of N, which is NOT what [MODP] does 👀 so the generators are different, bestie 💅
The 1024-bit and 1536-bit groups MUST be supported. 🫶
1. 1024-bit Group 🌸
The hexadecimal value for the prime is:
EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
FD5138FE 8376435B 9FC61D2F C0EB06E3The generator is: 2.
2. 1536-bit Group 🦋
The hexadecimal value for the prime is:
9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BBThe generator is: 2.
3. 2048-bit Group 🎀
The hexadecimal value for the prime is:
AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
9E4AFF73The generator is: 2.
4. 3072-bit Group ✨
This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFFThe generator is: 5.
5. 4096-bit Group 👑
This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] + 240904 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
FFFFFFFF FFFFFFFFThe generator is: 5.
6. 6144-bit Group 🌈
This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] + 929484 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
6DCC4024 FFFFFFFF FFFFFFFFThe generator is: 5.
7. 8192-bit Group 🧚
This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] + 4743158 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
60C980DD 98EDD3DF FFFFFFFF FFFFFFFFThe generator is: 19 (decimal).
Appendix B. SRP Test Vectors ✨
Okay so bestie, this is the part where we actually run the numbers 🧮💖 These test vectors show how the verifier and the premaster secret get calculated, so anyone building an implementation can check their maths against a known-good answer. Iconic behaviour, honestly 💅
The inputs are:
I = "alice"
P = "password123"
s = BEB25379 D1A8581E B5A72767 3A2441EE
N, g = <1024-bit parameters from Appendix A>
k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
v =
7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
E955A5E2 9E7AB245 DB2BE315 E2099AFB
a =
60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
DA2D4393
b =
E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
05284D20
A =
61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
B349EF5D 76988A36 72FAC47B 0769447B
B =
BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
EB4012B7 D7665238 A8E3FB00 4B117B58
u =
CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
<premaster secret> =
B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
C346D7E4 74B29EDE 8A469FFE CA686E5AAppendix C. Acknowledgements 🫶
Thanks to all on the IETF TLS mailing list for ideas and analysis. The whole list gets a group hug from me 🌈💜
Authors' Addresses 📬
David Taylor Independent
EMail: dtaylor@gnutls.org
Tom Wu Cisco
EMail: thomwu@cisco.com
Nikos Mavrogiannopoulos Independent
EMail: nmav@gnutls.org URI: http://www.gnutls.org/
Trevor Perrin Independent
EMail: trevp@trevp.net URI: http://trevp.net/
Full Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5054 2007-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms