RFC 8236

J-PAKE: Password-Authenticated Key Exchange by Juggling

📅 published September 2017, from ietf

RFC 8236: J-PAKE: Password-Authenticated Key Exchange by Juggling 🎀✨

Okay bestie, let's get into it 💖 This one is an Independent Submission written by F. Hao, Ed. from Newcastle University (UK), dated September 2017. It's Informational, which means it's published for us to read and learn from, not a mandatory Internet Standard 🌸 It obsoletes nothing and updates nothing, so it's a totally standalone doc 🦋 The ISSN is 2070-1721 if you ever need to look it up 💅

Here's the vibe: J-PAKE is a way for two people to set up a secure, end-to-end channel over an insecure network using just a shared password 🔐 No PKI, no trusted third party, nothing extra. Lowkey iconic 😭

Status of This Memo 🌈

This doc is not an Internet Standards Track spec, it's just being shared for info 💜 It's a contribution to the RFC Series, independent of any other stream. The RFC Editor chose to publish it at their discretion and makes no claims about whether you should implement or deploy it 🙈 Documents approved by the RFC Editor aren't candidates for any level of Internet Standard, so check Section 2 of RFC 7841 for the deets ✨

For the current status, errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc8236 🧚

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💅 This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read those carefully, because they spell out your rights and restrictions 🫶

1. Introduction ✨

Okay so PAKE (Password-Authenticated Key Exchange) is the whole genre here 💖 The goal is to set up secure comms between two remote parties using only their shared password, no PKI or trusted third party needed [BM92]. The first ever PAKE was EKE (Encrypted Key Exchange), proposed by Steven Bellovin and Michael Merritt in 1992 [BM92] 👑

Other famous PAKEs include SPEKE (Simple Password Exponential Key Exchange) by David Jablon in 1996 [Jab96], and SRP (Secure Remote Password) by Tom Wu in 1998 [Wu98]. SRP got revised a bunch of times to fix security and efficiency problems 😭 The big one, SRP-6, is specified in [RFC5054] 🔥

This document specifies J-PAKE (Password-Authenticated Key Exchange by Juggling), designed by Feng Hao and Peter Ryan in 2008 [HR08] 🦋 Why is it so cool? Let me count the ways 💅

First, J-PAKE has security proofs, and EKE, SPEKE and SRP-6 don't have equivalent ones 🙈 Second, it's built totally differently from every other PAKE and runs on a well-established Zero Knowledge Proof primitive, the Schnorr NIZK proof [RFC8235] 🧠 Third, it uses clever engineering tricks to optimise the ZKP use, so it's efficient enough for real life 🌸 Fourth, it works generically in both finite field and elliptic curve settings (basically DSA and ECDSA-like groups) 🍓

Unlike SPEKE, it doesn't need an extra primitive to hash passwords onto an elliptic curve ✨ Unlike SPAKE2 [AP05] and SESPAKE [SOAA15], it doesn't need a trusted setup (the so-called common reference model) to define generators whose discrete log must be unknown 💜 Finally, it's been used at a big scale in the real world: Firefox sync [MOZILLA], Pale Moon sync [PALEMOON], and Google Nest products [ABM15] 😭 It's also in widely used open source libraries like OpenSSL [BOINC], Network Security Services (NSS) [MOZILLA_NSS], and Bouncy Castle [BOUNCY] 👑 Since 2015 it's been in Thread [THREAD] as a standard key agreement mechanism for IoT applications, and it's also in ISO/IEC 11770-4:2017 [ISO.11770-4] 🌈

1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅

1.2. Notation 🧚

Here's the notation we're working with, bestie 📝

  • Alice: the assumed identity of the prover in the protocol 🌸
  • Bob: the assumed identity of the verifier in the protocol 🌸
  • s: a low-entropy secret shared between Alice and Bob 🔑
  • a | b: a divides b 🍓
  • a || b: concatenation of a and b 🍓
  • [a, b]: the interval of integers between and including a and b 🍓
  • H: a secure cryptographic hash function 🔐
  • p: a large prime 🦋
  • q: a large prime divisor of p-1, i.e., q | p-1 🦋
  • *Zp**: a multiplicative group of integers modulo p 🦋
  • Gq: a subgroup of Zp* with prime order q 🦋
  • g: a generator of Gq ✨
  • g^d: g raised to the power of d ✨
  • a mod b: a modulo b ✨
  • Fp: a finite field of p elements, where p is a prime 🌈
  • E(Fp): an elliptic curve defined over Fp 🌈
  • G: a generator of the subgroup over E(Fp) with prime order n 🌈
  • n: the order of G 🌈
  • h: the cofactor of the subgroup generated by G, which is equal to the order of the elliptic curve divided by n 🌈
  • P x [b]: multiplication of a point P with a scalar b over E(Fp) 🌈
  • KDF(a): Key Derivation Function with input a 💜
  • MAC(MacKey, MacData): MAC function with MacKey as the key and MacData as the input data 💜

2. J-PAKE over Finite Field 💖

2.1. Protocol Setup 🌸

When you run J-PAKE over a finite field, you can use the same group parameters as DSA [FIPS186-4] 🦋 So let p and q be two large primes such that q | p-1. Let Gq be a subgroup of Zp* with prime order q, and let g be a generator for Gq 💅 Any non-identity element in Gq can be a generator 🫶 Alice and Bob both agree on (p, q, g), which can be hard-wired into the software code 🔥 They can also use the method in NIST FIPS 186-4, Appendix A [FIPS186-4] to generate (p, q, g) ✨ DSA group parameters are only an example though, and other cryptographically suitable multiplicative groups work too, like the ones defined in [RFC4419] 🌈 A group setting that provides 128-bit security or above is RECOMMENDED, hmm, wait, let me be precise: the original says it is recommended, so here it is: a group setting that provides 128-bit security or above is recommended 💜 The security proof of J-PAKE depends on the Decisional Diffie-Hellman (DDH) problem being intractable in the group you pick 🧠

Next up, s is a secret value derived from a low-entropy password shared between Alice and Bob 🔑 The value of s is REQUIRED to fall within [1, q-1] 😭 (Note that s must not be 0 for any non-empty secret 🙈) This range is a necessary condition in [HR08] for proving "on-line dictionary attack resistance", because s, s+q, s+2q, ... are all treated as equivalent values as far as the protocol spec is concerned 🧚 In a practical implementation you can get s by taking a cryptographic hash of the password and wrapping the result modulo q 💅 Or you can treat the password as an octet string and convert it to an integer modulo q using the method in Section 2.3.8 of [SEC1] 🌸 Either way, one MUST ensure s is not equal to 0 modulo q 🚨

Heads up, bestie: that last bit is a MUST, so don't skip it! 💀

(This is part 1 of 4. More parts are coming, so stay tuned 🦋✨)

2.2. Two-Round Key Exchange

okay so ROUND 1 is where the vibes start 💖 Alice picks an ephemeral private key x1 uniformly at random from [0, q-1] and another one, x2, uniformly at random from [1, q-1]. Bob does the same thing with x3 and x4 🫶

  • Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p and ZKPs for x1 and x2
  • Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p and ZKPs for x3 and x4

in this round the sender must send zero knowledge proofs to show they actually know the ephemeral private keys 🔐 the go-to move is the Schnorr NIZK proof [RFC8235] ✨ say you want to prove you know the exponent for D = g^d mod p. the generated Schnorr NIZK proof will contain {UserID, V = g^v mod p, r = v - d * c mod q}, where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [0, q-1], and c = H(g || V || D || UserID).

now the "uniqueness" of UserID is defined from the user's perspective -- so like, if Alice is talking to a bunch of different people, she shall give each one a unique identity 💅 when Alice gets a Schnorr NIZK proof, she shall check that the prover's UserID is a valid identity and is different from her own identity 🙈 and during the J-PAKE exchange, each party shall make sure the other party has been consistently using the same identity the whole way through. all the nitty gritty about generating and verifying the Schnorr NIZK proof lives in [RFC8235] 📚

when round 1 wraps up, Alice verifies the received ZKPs as specified in [RFC8235] and also checks that g4 != 1 mod p. Bob does the mirror version: he verifies the ZKPs and checks that g2 != 1 mod p. if any of these checks fails, this session should be aborted 💀

Round 2:

  • Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s
  • Bob -> Alice: B = (g1*g2*g3)^(x4*s) mod p and a ZKP for x4*s

in round 2 the Schnorr NIZK proof is made the same way as last round, except the generator is different 🦋 for Alice it's (g1*g3*g4) instead of g, and for Bob it's (g1*g2*g3) instead of g. since any non-identity element in Gq can work as a generator, Alice and Bob just need to make sure g1*g3*g4 != 1 mod p and g1*g2*g3 != 1 mod p. with overwhelming probability these inequalities are statistically guaranteed, even when the user is talking to an adversary (aka an active attack) 😭 but for absolute guarantee, the receiving party shall explicitly check if these inequalities hold, and abort the session if a check fails 🔥

when the second round finishes, Alice and Bob verify the received ZKPs. if the verification fails, the session is aborted. otherwise, the two parties compute the common key material like this:

  • Alice computes Ka = (B/g4^(x2*s))^x2 mod p
  • Bob computes Kb = (A/g2^(x4*s))^x4 mod p

and here's the payoff ✨ Ka = Kb = g^((x1+x3)*x2*x4*s) mod p. Let K denote the same key material held by both parties. using K as input, Alice and Bob apply a Key Derivation Function (KDF) to derive a common session key k. if the secure communication that follows uses a symmetric cipher in an authenticated mode (say AES-GCM), then one key is enough, i.e., k = KDF(K). otherwise, the session key should comprise an encryption key (for confidentiality) and a MAC key (for integrity), i.e., k = k_enc || k_mac, where k_enc = KDF(K || "JPAKE_ENC") and k_mac = KDF(K || "JPAKE_MAC"). the exact choice of KDF is left to specific applications to define 🌸

2.3. Computational Cost

the cost is estimated by counting modular exponentiations, since those are the biggest cost factors 🧮 it takes one exponentiation to generate a Schnorr NIZK proof and two to verify it [RFC8235]. for Alice, that's 8 exponentiations in the first round, 4 in the second round, and 2 in the final session key computation. so that's 14 modular exponentiations in total 💜 by symmetry, Bob's cost is exactly the same ✨

3. J-PAKE over Elliptic Curve

3.1. Protocol Setup

J-PAKE works basically the same way in the elliptic curve (EC) setting, except the underlying multiplicative group over a finite field gets swapped out for an additive group over an elliptic curve 🦋 the EC version is specified here for completeness.

when J-PAKE runs over an elliptic curve, it may use the same EC parameters as ECDSA [FIPS186-4]. the FIPS 186-4 standard [FIPS186-4] defines three kinds of curves suitable for ECDSA: pseudorandom curves over prime fields, pseudorandom curves over binary fields, and special curves over binary fields called Koblitz curves or anomalous binary curves. all the curves that work for ECDSA can also be used for J-PAKE. however, for illustration purposes, only curves over prime fields are described in this document. typically those curves include NIST P-256, P-384, and P-521. when choosing a curve, a level of 128-bit security or above is recommended 🔐 Let E(Fp) be an elliptic curve defined over a finite field Fp, where p is a large prime. Let G be a generator for the subgroup over E(Fp) of prime order n. the NIST curves are only used as an example here. other secure curves such as Curve25519 are also suitable for implementation 🌈 the security proof of J-PAKE relies on the assumption that the DDH problem is intractable in the considered group.

as before, let s denote the shared secret between Alice and Bob. the value of s falls within [1, n-1]. in particular, note that s MUST not be equal to 0 mod n ⚠️

3.2. Two-Round Key Exchange

Round 1: Alice selects ephemeral private keys x1 and x2 uniformly at random from [1, n-1]. Bob similarly selects ephemeral private keys x3 and x4 uniformly at random from [1, n-1] 💖

  • Alice -> Bob: G1 = G x [x1], G2 = G x [x2] and ZKPs for x1 and x2
  • Bob -> Alice: G3 = G x [x3], G4 = G x [x4] and ZKPs for x3 and x4

when this round finishes, Alice and Bob verify the received ZKPs as specified in [RFC8235]. for example, to prove knowledge of the discrete logarithm of D = G x [d] with respect to the base point G, the ZKP contains {UserID, V = G x [v], r = v - d * c mod n}, where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [1, n-1], and c = H(G || V || D || UserID) 🧚

the verifier shall check that the prover's UserID is a valid identity and is different from its own identity. if the ZKP verification fails, the session is aborted 💅

Round 2:

  • Alice -> Bob: A = (G1 + G3 + G4) x [x2*s] and a ZKP for x2*s
  • Bob -> Alice: B = (G1 + G2 + G3) x [x4*s] and a ZKP for x4*s

when the second round finishes, Alice and Bob verify the received ZKPs. the ZKPs are computed the same way as in the previous round, except the generator is different 🎀 for Alice the new generator is G1 + G3 + G4, and for Bob it's G1 + G2 + G3. Alice and Bob shall check that these new generators are not points at infinity. if any of these checks fails, the session is aborted. otherwise, the two parties compute the common key material like so:

  • Alice computes Ka = (B - (G4 x [x2*s])) x [x2]
  • Bob computes Kb = (A - (G2 x [x4*s])) x [x4]

ta-da 👑 Ka = Kb = G x [(x1+x3)*(x2*x4*s)]. Let K denote the same key material held by both parties. using K as input, Alice and Bob apply a Key Derivation Function (KDF) to derive a common session key k.

3.3. Computational Cost

in the EC setting, the cost of J-PAKE is estimated by counting scalar multiplications over the elliptic curve 🍓 it takes one multiplication to generate a Schnorr NIZK proof and one to verify it [RFC8235]. for Alice, that's 6 multiplications in the first round, 3 in the second round, and 2 in the final session key computation. so that's 11 multiplications in total. by symmetry, Bob's cost is exactly the same 🌟

4. Three-Pass Variant

the two-round J-PAKE protocol is completely symmetric, which makes the security analysis way simpler 🧠 in practice though, one party usually starts the conversation and the other party responds. in that case the protocol finishes in three passes instead of two rounds. the two-round J-PAKE protocol can be trivially changed to three passes without losing security. let's use the finite field setting as an example, and assume Alice initiates the key exchange. the three-pass variant goes like this:

  1. Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p, ZKPs for x1 and x2.
  2. Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p, B = (g1*g2*g3)^(x4*s) mod p, ZKPs for x3, x4, and x4*s.
  3. Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s.

both parties compute the session keys in exactly the same way as before ✨

5. Key Confirmation 🔐

Okay so the two-round J-PAKE protocol (or the three-pass variant) gives you a cryptographic guarantee that only the authenticated party who used the same password at the other end can compute the same session key 💖. Right now the authentication is only implicit ✨. The key confirmation is implicit too [Stinson06]. Both parties can use the derived key straight away to start secure communication by encrypting messages in an authenticated mode 🎀. Only the party with the same derived session key can decrypt and read those messages.

For explicit authentication, you need an additional key confirmation procedure 🦋. This gives you explicit assurance that the other party has actually derived the same key. Once that's done, the key confirmation is explicit [Stinson06] 💅.

In J-PAKE, explicit key confirmation is recommended whenever the network bandwidth allows it 🌸. It's so worth it because you get explicit and immediate confirmation that the two parties derived the same key, which means they're authenticated to each other. This lets a practical J-PAKE implementation effectively detect online dictionary attacks (if any) and stop them by setting a threshold for consecutively failed connection attempts 🙈.

There are several methods for achieving explicit key confirmation 💜. They work for all key exchange protocols, not just J-PAKE. In general, it is recommended that a different key from the session key be used for key confirmation, say k' = KDF(K || "JPAKE_KC") 🧚. The advantage is that the session key stays indistinguishable from random after the key confirmation process. (Honestly though, this perceived advantage is subtle and only theoretical 🙃.) Two explicit key confirmation methods are presented here.

The first method is based on the one used in the SPEKE protocol [Jab96] 🍓. Say Alice initiates the key confirmation. Alice sends Bob H(H(k')), which Bob will verify. If the verification succeeds, Bob sends back H(k') to Alice, who will verify it too. This procedure takes two rounds, as shown below.

  1. Alice -> Bob: H(H(k'))
  2. Bob -> Alice: H(k')

This needs two rounds instead of one because the second message depends on the first. If both parties try to send the first message at the same time without an agreed order, they can't tell whether the message they receive is a genuine challenge or a replayed message 😭, and they may end up in a deadlock 💀.

The second method is based on the unilateral key confirmation scheme specified in NIST SP 800-56A Revision 1 [BJS07] 👑. Alice and Bob send each other a MAC tag, and each verifies the tag they receive. This can be completed in one round ⭐.

In the finite field setting, it works like this:

o  Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || g1
   || g2 || g3 || g4)

o  Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || g3
   || g4 || g1 || g2)

In the EC setting, the key confirmation works basically the same way 🌈.

o  Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || G1
   || G2 || G3 || G4)

o  Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || G3
   || G4 || G1 || G2)

The second method assumes an additional secure MAC function (for example, one may use HMAC) and is a bit more complex than the first method 🫶. But it can be completed within one round, and it preserves the overall symmetry of the protocol implementation ✨. That's why the second method is RECOMMENDED 💖.

6. Security Considerations 🛡️

A PAKE protocol is designed to provide two functions in one protocol execution 💅. The first is zero-knowledge authentication of a password. It's called "zero knowledge" because at the end of the protocol, the two communicating parties learn nothing more than one bit of information: whether the passwords supplied at the two ends are equal 🤫. So a PAKE protocol is naturally resistant against phishing attacks 🎣. The second function is session key establishment, if the two passwords are equal. The session key protects the confidentiality and integrity of the subsequent communication 🔥.

More concretely, a secure PAKE protocol shall satisfy the following security requirements [HR10] 👑.

  1. Offline dictionary attack resistance: It does not leak any information that allows a passive or active attacker to perform an offline exhaustive search of the password.
  2. Forward secrecy: It produces session keys that remain secure even when the password is later disclosed.
  3. Known-key security: It prevents a disclosed session key from affecting the security of other sessions.
  4. Online dictionary attack resistance: It limits an active attacker to testing only one password per protocol execution.

First, a PAKE protocol must resist offline dictionary attacks 🙈. A password is inherently weak. It typically has only about 20-30 bits of entropy, and that level of security is subject to exhaustive search 😬. So in the PAKE protocol, the communication must not reveal any data that lets an attacker learn the password through offline exhaustive search.

Second, a PAKE protocol must provide forward secrecy 🦋. The key exchange is authenticated based on a shared password, but there is no guarantee on the long-term secrecy of the password. A secure PAKE scheme shall protect past session keys even when the password is later disclosed. This property also implies that if an attacker knows the password but only passively observes the key exchange, they cannot learn the session key 🧚.

Third, a PAKE protocol must provide known-key security 🌸. A session key lasts throughout the session. An exposed session key must not cause any global impact on the system or affect the security of other sessions.

Finally, a PAKE protocol must resist online dictionary attacks 💀. If the attacker is directly engaging in the key exchange, there's no way to stop them from trying a random guess of the password. Still, a secure PAKE scheme should minimize the effect of the online attack. In the best case, the attacker can only guess exactly one password per impersonation attempt. Consecutively failed attempts can be easily detected, and the subsequent attempts shall be thwarted accordingly 🚫. It is recommended that the false authentication counter be handled so that any error (one that causes the session to fail during the key exchange or key confirmation) leads to incrementing the false authentication counter 🔢.

It has been proven in [HR10] that J-PAKE satisfies all four requirements, based on the assumptions that the Decisional Diffie-Hellman problem is intractable and the underlying Schnorr NIZK proof is secure 🚨.

An independent study that proves the security of J-PAKE in a model with algebraic adversaries and random oracles can be found in [ABM15] 📖. By comparison, EKE is known to have the problem of leaking partial information about the password to a passive attacker, so it does not satisfy the first requirement [Jas96] 😤. For SPEKE and SRP-6, an attacker may be able to test more than one password in one online dictionary attack (see [Zha04] and [Hao10]), so they do not satisfy the fourth requirement in the strict theoretical sense 🤏. Furthermore, SPEKE is found vulnerable to an impersonation attack and a key-malleability attack [HS14] 😱. These two attacks affect the SPEKE protocol specified in Jablon's original 1996 paper [Jab96], as well as the D26 draft of IEEE P1363.2 and the ISO/IEC 11770-4:2006 standard. As a result, the specification of SPEKE in ISO/IEC 11770-4:2006 has been revised to address the identified problems 🎀.

7. IANA Considerations 🌷

This document does not require any IANA actions 🍰.

8. References 📚

8.1. Normative References 💜

[ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security of the J-PAKE Password-Authenticated Key Exchange Protocol", 2015 IEEE Symposium on Security and Privacy, DOI 10.1109/sp.2015.41, May 2015.

[BM92] Bellovin, S. and M. Merrit, "Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks", IEEE Symposium on Security and Privacy, DOI 10.1109/risp.1992.213269, May 1992.

[HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange by Juggling", Lecture Notes in Computer Science, pp. 159-171, from 16th Security Protocols Workshop (SPW '08), DOI 10.1007/978-3-642-22137-8_23, 2011.

[HR10] Hao, F. and P. Ryan, "J-PAKE: Authenticated Key Exchange Without PKI", Transactions on Computational Science XI, pp. 192-206, DOI 10.1007/978-3-642-17697-5_10, 2010.

[HS14] Hao, F. and S. Shahandashti, "The SPEKE Protocol Revisited", Security Standardisation Research, pp. 26-38, DOI 10.1007/978-3-319-14054-4_2, December 2014.

[Jab96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM SIGCOMM Computer Communication Review, Vol. 26, pp. 5-26, DOI 10.1145/242896.242897, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2007, <https://www.rfc-editor.org/info/rfc5054>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero Knowledge Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, <https://www.rfc-editor.org/info/rfc8235>.

[SEC1] "Standards for Efficient Cryptography. SEC 1: Elliptic Curve Cryptography", SECG SEC1-v2, May 2009, <http://www.secg.org/sec1-v2.pdf>.

[Stinson06] Stinson, D., "Cryptography: Theory and Practice", 3rd Edition, CRC, 2006.

[Wu98] Wu, T., "The Secure Remote Password Protocol", Internet Society Symposium on Network and Distributed System Security, March 1998.

8.2. Informative References ✨

Okay bestie, these are the informative references, aka the sources that back up the spec without being required reading 📚🫶

Acknowledgements 🙏

The editor would like to thank Dylan Clarke, Siamak Shahandashti, Robert Cragie, Stanislav Smyshlyaev, and Russ Housley for many useful comments. This work is supported by EPSRC First Grant (EP/J011541/1) and ERC Starting Grant (No. 306994). 🌸

Author's Address 💌

Feng Hao (editor) Newcastle University (UK) Urban Sciences Building, School of Computing, Newcastle University Newcastle Upon Tyne United Kingdom

Phone: +44 (0)191-208-6384 Email: feng.hao@ncl.ac.uk

📦 where this page comes from