diff options
Diffstat (limited to 'doc/rfc/rfc9383.txt')
| -rw-r--r-- | doc/rfc/rfc9383.txt | 1283 |
1 files changed, 1283 insertions, 0 deletions
diff --git a/doc/rfc/rfc9383.txt b/doc/rfc/rfc9383.txt new file mode 100644 index 0000000..cbe97d1 --- /dev/null +++ b/doc/rfc/rfc9383.txt @@ -0,0 +1,1283 @@ + + + + +Independent Submission T. Taubert +Request for Comments: 9383 Apple Inc. +Category: Informational C. A. Wood +ISSN: 2070-1721 September 2023 + + + SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) + Protocol + +Abstract + + This document describes SPAKE2+, a Password-Authenticated Key + Exchange (PAKE) protocol run between two parties for deriving a + strong shared key with no risk of disclosing the password. SPAKE2+ + is an augmented PAKE protocol, as only one party has knowledge of the + password. This method is simple to implement, compatible with any + prime-order group, and computationally efficient. + + This document was produced outside of the IETF and IRTF and + represents the opinions of the authors. Publication of this document + as an RFC in the Independent Submissions Stream does not imply + endorsement of SPAKE2+ by the IETF or IRTF. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9383. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Requirements Notation + 3. Definition of SPAKE2+ + 3.1. Protocol Overview + 3.2. Offline Registration + 3.3. Online Authentication + 3.4. Key Schedule and Key Confirmation + 4. Ciphersuites + 5. IANA Considerations + 6. Security Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Appendix A. Protocol Flow + A.1. Prover + A.2. Verifier + A.3. Transcript Computation + A.4. Key Schedule Computation + A.5. Protocol Run + Appendix B. Algorithm Used for Point Generation + Appendix C. Test Vectors + Acknowledgements + Authors' Addresses + +1. Introduction + + This document describes SPAKE2+, a Password-Authenticated Key + Exchange (PAKE) protocol run between two parties for deriving a + strong shared key with no risk of disclosing the password. SPAKE2+ + is an augmented PAKE protocol, as only one party makes direct use of + the password during the execution of the protocol. The other party + only needs a record corresponding to the first party's registration + at the time of the protocol execution instead of the password. This + record can be computed once, during an offline registration phase. + The party using the password directly would typically be a client and + would act as a Prover, while the other party would be a server and + would act as a Verifier. + + The protocol is augmented in the sense that it provides some + resilience against the compromise or extraction of the registration + record. The design of the protocol forces the adversary to recover + the password from the record to successfully execute the protocol. + Hence, this protocol can be advantageously combined with a salted + Password Hashing Function to increase the cost of the recovery and + slow down attacks. The record cannot be used directly to + successfully run the protocol as a Prover, making this protocol more + robust than balanced PAKEs, which don't benefit from Password Hashing + Functions to the same extent. + + This augmented property is especially valuable in scenarios where the + execution of the protocol is constrained and the adversary cannot + query the salt of the Password Hashing Function ahead of the attack. + For example, a constraint may be when physical proximity through a + local network is required or when a first authentication factor is + required for initiation of the protocol. + + This document has content split out from a related document, + [RFC9382], which specifies SPAKE2. SPAKE2 is a symmetric PAKE + protocol, where both parties have knowledge of the password. SPAKE2+ + is the asymmetric or augmented version of SPAKE2, wherein only one + party has knowledge of the password. SPAKE2+ is specified separately + in this document because the use cases for symmetric and augmented + PAKEs are different and therefore warrant different technical + specifications. Neither SPAKE2 nor SPAKE2+ was selected as the + result of the Crypto Forum Research Group (CFRG) PAKE selection + competition. However, this password-based key exchange protocol + appears in [TDH] and is proven secure in [SPAKE2P-Analysis]. It is + compatible with any prime-order group and relies only on group + operations, making it simple and computationally efficient. Thus, it + was felt that publication was beneficial to make the protocol + available for wider consideration. + + This document was produced outside of the IETF and IRTF and + represents the opinions of the authors. Publication of this document + as an RFC in the Independent Submissions Stream does not imply + endorsement of SPAKE2+ by the IETF or IRTF. + +2. Requirements Notation + + 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. + +3. Definition of SPAKE2+ + + Let G be a group in which the computational Diffie-Hellman (CDH) + problem is hard. Suppose G has order p*h where p is a large prime; h + will be called the cofactor. Let I be the unit element in G, e.g., + the point at infinity if G is an elliptic curve group. We denote the + operations in the group additively. We assume that there is a + representation of elements of G as byte strings: common choices would + be SEC 1 uncompressed or compressed [SEC1] for elliptic curve groups + or big-endian integers of a fixed (per-group) length for prime field + DH. We fix a generator P of the (large) prime-order subgroup of G. + P is specified in the document defining the group, and so we do not + repeat it here. + + || denotes concatenation of strings. We also let len(S) denote the + length of a string in bytes, represented as an eight-byte little- + endian number. Finally, let nil represent an empty string, i.e., + len(nil) = 0. + + KDF is a key derivation function that takes as input a salt, input + keying material (IKM), info string, and derived key length L to + derive a cryptographic key of length L. MAC is a Message + Authentication Code algorithm that takes a secret key and message as + input to produce an output. Let Hash be a hash function from + arbitrary strings to bit strings of a fixed length. Common choices + for Hash are SHA256 or SHA512 [RFC6234]. Section 4 specifies + variants of KDF, MAC, and Hash suitable for use with the protocols + contained herein. + + Let there be two parties, a Prover and a Verifier. Their identities, + denoted as idProver and idVerifier, may also have digital + representations such as Media Access Control addresses or other names + (hostnames, usernames, etc.). The parties may share additional data + (the context) separate from their identities, which they may want to + include in the protocol transcript. One example of additional data + is a list of supported protocol versions if SPAKE2+ were used in a + higher-level protocol that negotiates the use of a particular PAKE. + Another example is the inclusion of the application name. Including + these data points would ensure that both parties agree upon the same + set of supported protocols and therefore prevents downgrade and + cross-protocol attacks. Specification of precise context values is + out of scope for this document. + +3.1. Protocol Overview + + SPAKE2+ is a two-round protocol that establishes a shared secret with + an additional round for key confirmation. Prior to invocation, both + parties are provisioned with information such as the input password + needed to run the protocol. The registration phase may include + communicating identities, protocol version, and other parameters + related to the registration record; see Section 3.2 for details. + + During the first round, the Prover sends a public share, shareP, to + the Verifier, which in turn responds with its own public share, + shareV. Both parties then derive a shared secret used to produce + encryption and authentication keys. The latter are used during the + second round for key confirmation. (Section 3.4 details the key + derivation and confirmation steps.) In particular, the Verifier + sends a key confirmation message, confirmV, to the Prover, which in + turn responds with its own key confirmation message, confirmP. (Note + that shareV and confirmV MAY be sent in the same message.) Both + parties MUST NOT consider the protocol complete prior to receipt and + validation of these key confirmation messages. + + A sample trace is shown below. + + Prover Verifier + + | (registration) | + |<- - - - - - - - - - - - ->| + | | + | (set up the protocol) | + (compute shareP) | shareP | + |-------------------------->| + | shareV | (compute shareV) + |<--------------------------| + | | + | (derive secrets) | (compute confirmV) + | confirmV | + |<--------------------------| + (compute confirmP) | confirmP | + |-------------------------->| + +3.2. Offline Registration + + The registration phase computes the values w0 and w1, as well as the + registration record L=w1*P. w0 and w1 are derived by hashing the + password pw with the identities of the two participants. w0 and the + record L are then shared with the Verifier and stored as part of the + registration record associated with the Prover. The Prover SHOULD + derive w0 and w1 from the password before the protocol begins. Both + w0 and w1 are derived using a function with range [0, p-1], which is + modeled as a random oracle in [SPAKE2P-Analysis]. + + The registration phase also produces two random elements, M and N, in + the prime-order subgroup of G. The algorithm for selecting M and N + is defined in Appendix B. Importantly, this algorithm chooses M and + N such that their discrete logs are not known. Precomputed values + for M and N are listed in Section 4 for each group. Applications MAY + use different M and N values, provided they are computed, e.g., using + different input seeds to the algorithm in Appendix B, as random + elements for which the discrete log is unknown. + + Applications using this specification MUST define the method used to + compute w0 and w1. For example, it may be necessary to carry out + various forms of normalization of the password before hashing + [RFC8265]. This section contains requirements and default + recommendations for computing w0 and w1. + + The RECOMMENDED method for generating w0 and w1 is via a Password- + Based Key Derivation Function (PBKDF), which is a function designed + to slow down brute-force attackers. Brute-force resistance may be + obtained through various computation hardness parameters such as + memory or CPU cycles and are typically configurable. The scrypt + [RFC7914] function and the Argon2id [RFC9106] function are common + examples of PBKDFs. Absent an application-specific profile, + RECOMMENDED parameters (N, r, p) for scrypt are (32768,8,1), and + RECOMMENDED parameters for Argon2id are in Section 4 of [RFC9106]. + + Each half of the output of the PBKDF will be interpreted as an + integer and reduced modulo p. To control bias, each half must be of + length at least ceil(log2(p)) + k bits, with k >= 64. Reducing such + integers mod p gives bias at most 2^-k for any p; this bias is + negligible for any k >= 64. + + The minimum total output length of the PBKDF then is 2 * + (ceil(log2(p)) + k) bits. For example, given the prime order of the + P-256 curve, the output of the PBKDF SHOULD be at least 640 bits or + 80 bytes. + + Given a PBKDF, password pw, and identities idProver and idVerifier, + the RECOMMENDED method for computing w0 and w1 is as follows: + + w0s || w1s = PBKDF(len(pw) || pw || + len(idProver) || idProver || + len(idVerifier) || idVerifier) + w0 = w0s mod p + w1 = w1s mod p + + If an identity is unknown at the time of computing w0s or w1s, its + length is given as zero and the identity itself is represented as an + empty octet string. If both idProver and idVerifier are unknown, + then their lengths are given as zero and both identities will be + represented as empty octet strings. idProver and idVerifier are + included in the transcript TT as part of the protocol flow. + +3.3. Online Authentication + + The online SPAKE2+ protocol runs between the Prover and Verifier to + produce a single shared secret upon completion. To begin, the Prover + selects x uniformly at random from the integers in [0, p-1], computes + the public share shareP=X, and transmits it to the Verifier. + + x <- [0, p-1] + X = x*P + w0*M + + Upon receipt of X, the Verifier checks the received element for group + membership and aborts if X is not in the large prime-order subgroup + of G; see Section 6 for details. The Verifier then selects y + uniformly at random from the integers in [0, p-1], computes the + public share shareV=Y, and transmits it to the Prover. Upon receipt + of Y, the Prover checks the received element for group membership and + aborts if Y is not in the large prime-order subgroup of G. + + y <- [0, p-1] + Y = y*P + w0*N + + Both participants compute Z and V; Z and V are then shared as common + values. The Prover computes: + + Z = h*x*(Y - w0*N) + V = h*w1*(Y - w0*N) + + The Verifier computes: + + Z = h*y*(X - w0*M) + V = h*y*L + + The multiplication by the cofactor h prevents small subgroup + confinement attacks. All proofs of security hold even if the + discrete log of the fixed group element N is known to the adversary. + In particular, one MAY set N=I, i.e., set N to the unit element in G. + + It is essential that both Z and V be used in combination with the + transcript to derive the keying material. The protocol transcript + encoding is shown below. + + TT = len(Context) || Context + || len(idProver) || idProver + || len(idVerifier) || idVerifier + || len(M) || M + || len(N) || N + || len(shareP) || shareP + || len(shareV) || shareV + || len(Z) || Z + || len(V) || V + || len(w0) || w0 + + Context is an application-specific customization string shared + between both parties and MUST precede the remaining transcript. It + might contain the name and version number of the higher-level + protocol, or simply the name and version number of the application. + The context MAY include additional data such as the chosen + ciphersuite and PBKDF parameters like the iteration count or salt. + The context and its length prefix MAY be omitted. + + If an identity is absent, its length is given as zero and the + identity itself is represented as an empty octet string. If both + identities are absent, then their lengths are given as zero and both + are represented as empty octet strings. In applications where + identities are not implicit, idProver and idVerifier SHOULD always be + non-empty. Otherwise, the protocol risks unknown key-share attacks + (discussion of unknown key-share attacks in a specific protocol is + given in [RFC8844]). + + Upon completion of this protocol, both parties compute shared secrets + K_main, K_shared, K_confirmP, and K_confirmV as specified in + Section 3.4. The Verifier MUST send a key confirmation message, + confirmV, to the Prover so both parties can confirm that they agree + upon these shared secrets. After receipt and verification of the + Verifier's confirmation message, the Prover MUST respond with its + confirmation message. The Verifier MUST NOT send application data to + the Prover until it has received and verified the confirmation + message. Key confirmation verification requires recomputation of + confirmP or confirmV and checking for equality against the data that + was received. + +3.4. Key Schedule and Key Confirmation + + The protocol transcript TT, as defined in Section 3.3, is unique and + secret to the participants. Both parties use TT to derive the shared + symmetric secret K_main from the protocol. The length of K_main is + equal to the length of the digest output, e.g., 256 bits for Hash() = + SHA-256. The confirmation keys K_confirmP and K_confirmV, as well as + the shared key K_shared, are derived from K_main. + + K_main = Hash(TT) + K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys") + K_shared = KDF(nil, K_main, "SharedKey") + + Neither K_main nor its derived confirmation keys are used for + anything except key derivation and confirmation and MUST be discarded + after the protocol execution. Applications MAY derive additional + keys from K_shared as needed. + + The length of each confirmation key is dependent on the MAC function + of the chosen ciphersuite. For HMAC, the RECOMMENDED key length is + equal to the output length of the digest output, e.g., 256 bits for + Hash() = SHA-256. For CMAC-AES, each confirmation key MUST be of + length k, where k is the chosen AES key size, e.g., 128 bits for + CMAC-AES-128. + + Both endpoints MUST employ a MAC that produces pseudorandom tags for + key confirmation. K_confirmP and K_confirmV are symmetric keys used + to compute tags confirmP and confirmV over the public key shares + received from the other peer earlier. + + confirmP = MAC(K_confirmP, shareV) + confirmV = MAC(K_confirmV, shareP) + + Once key confirmation is complete, applications MAY use K_shared as + an authenticated shared secret as needed. For example, applications + MAY derive one or more keys and nonces from K_shared, for use with + Authenticated Encryption with Associated Data (AEAD) and subsequent + application data encryption. + +4. Ciphersuites + + This section documents SPAKE2+ ciphersuite configurations. A + ciphersuite indicates a group, cryptographic hash algorithm, and pair + of KDF and MAC functions, e.g., P256-SHA256-HKDF-HMAC-SHA256. This + ciphersuite indicates a SPAKE2+ protocol instance over P-256 that + uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash, + KDF, and MAC functions, respectively. Since the choice of PBKDF, its + parameters for computing w0 and w1, and the distribution of w0 and w1 + do not affect interoperability, the PBKDF is not included as part of + the ciphersuite. + + If no MAC algorithm is used in the key confirmation phase, its + respective column in Table 1 can be ignored and the ciphersuite name + will contain no MAC identifier. + + +==============+==================+=============+==============+ + | G | Hash | KDF | MAC | + +==============+==================+=============+==============+ + | P-256 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 | + | | | [RFC5869] | [RFC2104] | + +--------------+------------------+-------------+--------------+ + | P-256 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | + | | | [RFC5869] | [RFC2104] | + +--------------+------------------+-------------+--------------+ + | P-384 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 | + | | | [RFC5869] | [RFC2104] | + +--------------+------------------+-------------+--------------+ + | P-384 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | + | | | [RFC5869] | [RFC2104] | + +--------------+------------------+-------------+--------------+ + | P-521 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | + | | | [RFC5869] | [RFC2104] | + +--------------+------------------+-------------+--------------+ + | edwards25519 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 | + | | | [RFC5869] | [RFC2104] | + +--------------+------------------+-------------+--------------+ + | edwards448 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | + | | | [RFC5869] | [RFC2104] | + +--------------+------------------+-------------+--------------+ + | P-256 | SHA256 [RFC6234] | HKDF-SHA256 | CMAC-AES-128 | + | | | [RFC5869] | [RFC4493] | + +--------------+------------------+-------------+--------------+ + | P-256 | SHA512 [RFC6234] | HKDF-SHA512 | CMAC-AES-128 | + | | | [RFC5869] | [RFC4493] | + +--------------+------------------+-------------+--------------+ + + Table 1 + + The following points represent permissible point generation seeds for + the groups listed in Table 1, using the algorithm presented in + Appendix B. These byte strings are compressed points as in [SEC1] + for curves from [SEC1] and [RFC8032]. Note that these values are + identical to those used in the companion SPAKE2 specification + [RFC9382]. + + For P-256: + + M = + 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f + seed: 1.2.840.10045.3.1.7 point generation seed (M) + + N = + 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 + seed: 1.2.840.10045.3.1.7 point generation seed (N) + + For P-384: + + M = + 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc + 36f15314739074d2eb8613fceec2853 + seed: 1.3.132.0.34 point generation seed (M) + + N = + 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb + 252c5490214cf9aa3f0baab4b665c10 + seed: 1.3.132.0.34 point generation seed (N) + + For P-521: + + M = + 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608 + cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa + seed: 1.3.132.0.35 point generation seed (M) + + N = + 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25 + 32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25 + seed: 1.3.132.0.35 point generation seed (N) + + For edwards25519: + + M = + d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf + seed: edwards25519 point generation seed (M) + + N = + d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab + seed: edwards25519 point generation seed (N) + + For edwards448: + + M = + b6221038a775ecd007a4e4dde39fd76ae91d3cf0cc92be8f0c2fa6d6b66f9a12 + 942f5a92646109152292464f3e63d354701c7848d9fc3b8880 + seed: edwards448 point generation seed (M) + + N = + 6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db + f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600 + seed: edwards448 point generation seed (N) + +5. IANA Considerations + + This document has no IANA actions. + +6. Security Considerations + + SPAKE2+ appears in [TDH] and is proven secure in [SPAKE2P-Analysis]. + + The ephemeral randomness used by the Prover and Verifier MUST be + generated using a cryptographically secure Pseudorandom Number + Generator (PRNG). + + Elements received from a peer MUST be checked for group membership: + failure to properly deserialize and validate group elements can lead + to attacks. An endpoint MUST abort the protocol if any received + public value is not a member of the large prime-order subgroup of G. + Multiplication of a public value V by the cofactor h will yield the + identity element I whenever V is an element of a small-order + subgroup. Consequently, the Prover and Verifier MUST abort the + protocol upon receiving any value V such that V*h = I. Failure to do + so may lead to subgroup confinement attacks. + +7. References + +7.1. Normative References + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + DOI 10.17487/RFC2104, February 1997, + <https://www.rfc-editor.org/info/rfc2104>. + + [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>. + + [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The + AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June + 2006, <https://www.rfc-editor.org/info/rfc4493>. + + [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Elliptic Curve Cryptography Subject Public Key + Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, + <https://www.rfc-editor.org/info/rfc5480>. + + [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC 5869, + DOI 10.17487/RFC5869, May 2010, + <https://www.rfc-editor.org/info/rfc5869>. + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + <https://www.rfc-editor.org/info/rfc6234>. + + [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital + Signature Algorithm (EdDSA)", RFC 8032, + DOI 10.17487/RFC8032, January 2017, + <https://www.rfc-editor.org/info/rfc8032>. + + [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>. + + [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, + Enforcement, and Comparison of Internationalized Strings + Representing Usernames and Passwords", RFC 8265, + DOI 10.17487/RFC8265, October 2017, + <https://www.rfc-editor.org/info/rfc8265>. + + [RFC9382] Ladd, W., "SPAKE2, a Password-Authenticated Key Exchange", + RFC 9382, DOI 10.17487/RFC9382, September 2023, + <https://www.rfc-editor.org/info/rfc9382>. + + [SEC1] Standards for Efficient Cryptography Group, "SEC 1: + Elliptic Curve Cryptography", version 2.0, May 2009, + <https://secg.org/sec1-v2.pdf>. + + [SPAKE2P-Analysis] + Shoup, V., "Security analysis of SPAKE2+", March 2020, + <https://eprint.iacr.org/2020/313.pdf>. + + [TDH] Cash, D., Kiltz, E., and V. Shoup, "The Twin-Diffie + Hellman Problem and Applications", EUROCRYPT 2008, Lecture + Notes in Computer Science, Volume 4965, pages 127-145, + Springer-Verlag, Berlin, Germany, + DOI 10.1007/978-3-540-78967-3_8, April 2008, + <https://doi.org/10.1007/978-3-540-78967-3_8>. + +7.2. Informative References + + [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based + Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, + August 2016, <https://www.rfc-editor.org/info/rfc7914>. + + [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on + Uses of TLS with the Session Description Protocol (SDP)", + RFC 8844, DOI 10.17487/RFC8844, January 2021, + <https://www.rfc-editor.org/info/rfc8844>. + + [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. + Josefsson, "Argon2 Memory-Hard Function for Password + Hashing and Proof-of-Work Applications", RFC 9106, + DOI 10.17487/RFC9106, September 2021, + <https://www.rfc-editor.org/info/rfc9106>. + +Appendix A. Protocol Flow + + This section describes the flow of the SPAKE2+ protocol, including + computations and mandatory checks performed by the Prover and + Verifier. The constants M, N, P, p, and h are defined by the chosen + ciphersuite. + +A.1. Prover + + The Prover implements two functions, ProverInit and ProverFinish, + which are described below. + + def ProverInit(w0): + // Compute Prover key share + x <- [0, p-1] + X = x*P + w0*M + return (x, X) + + def ProverFinish(w0, w1, x, Y): + if not_in_subgroup(Y): + raise "invalid input" + + // Compute shared values + Z = h*x*(Y - w0*N) + V = h*w1*(Y - w0*N) + + return (Y, Z, V) + +A.2. Verifier + + The Verifier implements a single function, VerifierFinish, which is + described below. + + def VerifierFinish(w0, L, X): + if not_in_subgroup(X): + raise "invalid input" + + // Compute Verifier key share + y <- [0, p-1] + Y = y*P + w0*N + + // Compute shared values + Z = h*y*(X - w0*M) + V = h*y*L + + return (Z, V) + +A.3. Transcript Computation + + Both the Prover and the Verifier share the same function to compute + the protocol transcript, ComputeTranscript, which is described below. + + def ComputeTranscript(Context, idProver, idVerifier, + shareP, shareV, Z, V, w0): + TT = len(Context) || Context + || len(idProver) || idProver + || len(idVerifier) || idVerifier + || len(M) || M + || len(N) || N + || len(shareP) || shareP + || len(shareV) || shareV + || len(Z) || Z + || len(V) || V + || len(w0) || w0 + +A.4. Key Schedule Computation + + Both the Prover and the Verifier share the same function to compute + the key schedule, ComputeKeySchedule, which is described below. + + def ComputeKeySchedule(TT): + K_main = Hash(TT) + K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys") + K_shared = KDF(nil, K_main, "SharedKey") + return K_confirmP, K_confirmV, K_shared + +A.5. Protocol Run + + A full SPAKE2+ protocol run initiated by the Prover will look as + follows, where Transmit and Receive are shorthand for sending and + receiving a message to the peer: + + Prover(Context, idProver, idVerifier, w0, w1): + (x, X) = ProverInit(w0) + Transmit(X) + Y = Receive() + (Z, V) = ProverFinish(w0, w1, x, Y) + TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, + Z, V, w0) + (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT) + expected_confirmV = MAC(K_confirmV, X) + confirmV = Receive() + if not_equal_constant_time(expected_confirmV, confirmV): + raise "invalid confirmation message" + + confirmP = MAC(K_confirmP, Y) + Transmit(confirmP) + + return K_shared + + Verifier(Context, idProver, idVerifier, w0, L): + X = Receive() + (Y, Z, V) = VerifierFinish(w0, L, X) + Transmit(Y) + TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, + Z, V, w0) + (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT) + confirmV = MAC(K_confirmV, X) + Transmit(confirmV) + + expected_confirmP = MAC(K_confirmP, Y) + confirmP = Receive() + if not_equal_constant_time(expected_confirmP, confirmP): + raise "invalid confirmation message" + + return K_shared + +Appendix B. Algorithm Used for Point Generation + + This section describes the algorithm that was used to generate the + points M and N in Table 1 (Section 4). This algorithm produces M and + N such that they are indistinguishable from two random points in the + prime-order subgroup of G, where the discrete log of these points is + unknown. See [SPAKE2P-Analysis] for additional details on this + requirement. + + For each curve in Table 1, we construct a string using the curve OID + from [RFC5480] (as an ASCII string) or its name, combined with the + needed constant -- for instance, "1.3.132.0.35 point generation seed + (M)" for P-521. This string is turned into a series of blocks by + hashing with SHA256, and hashing that output again to generate the + next 32 bytes, and so on. This pattern is repeated for each group + and value, with the string modified appropriately. + + A byte string of length equal to that of an encoded group element is + constructed by concatenating as many blocks as are required, starting + from the first block, and truncating to the desired length. The byte + string is then formatted as required for the group. In the case of + Weierstrass curves, we take the desired length as the length for + representing a compressed point (Section 2.3.4 of [SEC1]) and use the + low-order bit of the first byte as the sign bit. In order to obtain + the correct format, the value of the first byte is set to 0x02 or + 0x03 (clearing the first six bits and setting the seventh bit), + leaving the sign bit as it was in the byte string constructed by + concatenating hash blocks. For the curves described in [RFC8032], a + different procedure is used. For edwards448, the 57-byte input has + the least-significant 7 bits of the last byte set to zero, and for + edwards25519, the 32-byte input is not modified. For both of the + curves described in [RFC8032], the (modified) input is then + interpreted as the representation of the group element. If this + interpretation yields a valid group element with the correct order + (p), the (modified) byte string is the output. Otherwise, the + initial hash block is discarded and a new byte string constructed + from the remaining hash blocks. The procedure for constructing a + byte string of the appropriate length, formatting it as required for + the curve, and checking to see if it is a valid point of the correct + order is repeated until a valid element is found. + + The following Python snippet generates the above points, assuming an + elliptic curve implementation following the interface of + Edwards25519Point.stdbase() and Edwards448Point.stdbase() in + Appendix A of [RFC8032]: + + def iterated_hash(seed, n): + h = seed + for i in range(n): + h = hashlib.sha256(h).digest() + return h + + def bighash(seed, start, sz): + n = -(-sz // 32) + hashes = [iterated_hash(seed, i) for i in range(start, start + n)] + return b''.join(hashes)[:sz] + + def canon_pointstr(ecname, s): + if ecname == 'edwards25519': + return s + elif ecname == 'edwards448': + return s[:-1] + bytes([s[-1] & 0x80]) + else: + return bytes([(s[0] & 1) | 2]) + s[1:] + + def gen_point(seed, ecname, ec): + for i in range(1, 1000): + hval = bighash(seed, i, len(ec.encode())) + pointstr = canon_pointstr(ecname, hval) + try: + p = ec.decode(pointstr) + if p != ec.zero_elem() and p * p.l() == ec.zero_elem(): + return pointstr, i + except Exception: + pass + +Appendix C. Test Vectors + + This section contains various test vectors for SPAKE2+. (The choice + of PBKDF is omitted, and values for w0 and w1 are provided directly.) + All points are encoded using the uncompressed format, i.e., with a + 0x04 octet prefix, specified in [SEC1]. idProver and idVerifier + identity strings are provided in the protocol invocation. + + [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors + '] + [idProver=b'client'] + [idVerifier=b'server'] + w0 = 0xbb8e1bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad9549 + 1b3 + w1 = 0x7e945f34d78785b8a3ef44d0df5a1a97d6b3b460409a345ca7830387a74b1 + dba + L = 0x04eb7c9db3d9a9eb1f8adab81b5794c1f13ae3e225efbe91ea487425854c7f + c00f00bfedcbd09b2400142d40a14f2064ef31dfaa903b91d1faea7093d835966efd + x = 0xd1232c8e8693d02368976c174e2088851b8365d0d79a9eee709c6a05a2fad5 + 39 + shareP = 0x04ef3bd051bf78a2234ec0df197f7828060fe9856503579bb17330090 + 42c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab97a79c7193e3 + 41727 + y = 0x717a72348a182085109c8d3917d6c43d59b224dc6a7fc4f0483232fa6516d8 + b3 + shareV = 0x04c0f65da0d11927bdf5d560c69e1d7d939a05b0e88291887d679fcad + ea75810fb5cc1ca7494db39e82ff2f50665255d76173e09986ab46742c798a9a6843 + 7b048 + Z = 0x04bbfce7dd7f277819c8da21544afb7964705569bdf12fb92aa388059408d5 + 0091a0c5f1d3127f56813b5337f9e4e67e2ca633117a4fbd559946ab474356c41839 + V = 0x0458bf27c6bca011c9ce1930e8984a797a3419797b936629a5a937cf2f11c8 + b9514b82b993da8a46e664f23db7c01edc87faa530db01c2ee405230b18997f16b68 + TT = 0x38000000000000005350414b45322b2d503235362d5348413235362d484b4 + 4462d5348413235362d484d41432d534841323536205465737420566563746f72730 + 600000000000000636c69656e7406000000000000007365727665724100000000000 + 00004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12 + f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410 + 000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f9 + 8baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e6 + 56edbe7410000000000000004ef3bd051bf78a2234ec0df197f7828060fe98565035 + 79bb1733009042c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab + 97a79c7193e341727410000000000000004c0f65da0d11927bdf5d560c69e1d7d939 + a05b0e88291887d679fcadea75810fb5cc1ca7494db39e82ff2f50665255d76173e0 + 9986ab46742c798a9a68437b048410000000000000004bbfce7dd7f277819c8da215 + 44afb7964705569bdf12fb92aa388059408d50091a0c5f1d3127f56813b5337f9e4e + 67e2ca633117a4fbd559946ab474356c4183941000000000000000458bf27c6bca01 + 1c9ce1930e8984a797a3419797b936629a5a937cf2f11c8b9514b82b993da8a46e66 + 4f23db7c01edc87faa530db01c2ee405230b18997f16b682000000000000000bb8e1 + bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad95491b3 + K_main = 0x4c59e1ccf2cfb961aa31bd9434478a1089b56cd11542f53d3576fb6c2 + a438a29 + K_confirmP = 0x871ae3f7b78445e34438fb284504240239031c39d80ac23eb5ab9 + be5ad6db58a + K_confirmV = 0xccd53c7c1fa37b64a462b40db8be101cedcf838950162902054e6 + 44b400f1680 + HMAC(K_confirmP, shareV) = 0x926cc713504b9b4d76c9162ded04b5493e89109 + f6d89462cd33adc46fda27527 + HMAC(K_confirmV, shareP) = 0x9747bcc4f8fe9f63defee53ac9b07876d907d55 + 047e6ff2def2e7529089d3e68 + K_shared = 0x0c5f8ccd1413423a54f6c1fb26ff01534a87f893779c6e68666d772 + bfd91f3e7 + + [Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors + '] + [idProver=b'client'] + [idVerifier=b'server'] + w0 = 0x1cc5207d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c + 8cc + w1 = 0x4279649e62532b01dc27d2ed39100ba350518fb969672061a01edce752d0e + 672 + L = 0x043a348ad475d2200d46df876f1eb2e136056da31dafff52cc7762bf3be84d + e0097c4e69b0b9321326af1f0af4a14561a9c7b640cb5afd6822d14cb34830fc4511 + x = 0xb586ab83f175c1a2b56b6a1b6a283523f88a9befcf11e22efb48e2ee1fe69a + 23 + shareP = 0x04a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9745a4180c946 + 57a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5365375c62e09 + def4a + y = 0xac1fb828f041782d452ea9cc00c3fa34a55fa8f7f98c04be45a3d607b092d4 + 41 + shareV = 0x04498c29e37dbd53ebf8db76679901d90c6be3af57f46ac3025b32420 + 839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad23eba13197c9d96a5b1027 + 5e35d + Z = 0x04a81e31be54283cee81bf7bdc877764b6b2ac6a399f1176380aac8a82172c + 18051aa17dfcf438896ad253f53b52cd45ec2c7399488a919bcfcfecc0261cbf5284 + V = 0x04de0a53f96cbe4abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d + 518bb2d9734b1d2dfce3fd916e991ab9dc3a2760d439c083eb39b65408857d2bb4aa + TT = 0x38000000000000005350414b45322b2d503235362d5348413531322d484b4 + 4462d5348413531322d484d41432d534841353132205465737420566563746f72730 + 600000000000000636c69656e7406000000000000007365727665724100000000000 + 00004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12 + f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410 + 000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f9 + 8baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e6 + 56edbe7410000000000000004a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9 + 745a4180c94657a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5 + 365375c62e09def4a410000000000000004498c29e37dbd53ebf8db76679901d90c6 + be3af57f46ac3025b32420839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad + 23eba13197c9d96a5b10275e35d410000000000000004a81e31be54283cee81bf7bd + c877764b6b2ac6a399f1176380aac8a82172c18051aa17dfcf438896ad253f53b52c + d45ec2c7399488a919bcfcfecc0261cbf5284410000000000000004de0a53f96cbe4 + abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d518bb2d9734b1d2dfce3f + d916e991ab9dc3a2760d439c083eb39b65408857d2bb4aa20000000000000001cc52 + 07d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c8cc + K_main = 0x527613439c279a375c116342a4216a8d92441d2fe1921dd1e60f140b2 + 855916ccac7db4dbf22bd56e344a8cd506d08949bde1e9d83c24d68ff4246458dc14 + 288 + K_confirmP = 0x0aa129d7b82067c2a9607677c9c4fdedc1cd7cfed9ff72c54c0ae + bb2b1a8aa915b96834b2986725c6040852ceaafbb17d638a715198f795654eac89bf + 0739878 + K_confirmV = 0xa1f1038de30a8c12d43d06c27d362daa9699249e941faa2d5cbc5 + 9a9683bf42aed9537818245677fdb54b5274506542994f4a83455f6d7b3af5ec017f + aa58f61 + HMAC(K_confirmP, shareV) = 0x6b2469b56cf8ac3f94a8d0b533380ea6b3d0f46 + b3e12ee82550d49e129c2412728c9437a64ee5f80c8cdc5e8a30faa0a6deb8a52513 + 46ba81bb6fc955b2304fc + HMAC(K_confirmV, shareP) = 0x154174fc278a935e290b3352ba877e179fa9281 + c0a76928faea703c72d383b267511a5cf084cb07147efece94e3cfd91944e7baab85 + 6858fbebc087167b0f409 + K_shared = 0x11887659d9e002f34fa6cc270d33570f001b2a3fc0522b643c07327 + d09a4a9f47aab85813d13c585b53adf5ac9de5707114848f3dc31a4045f69a2cc197 + 2b098 + + [Context=b'SPAKE2+-P384-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors + '] + [idProver=b'client'] + [idVerifier=b'server'] + w0 = 0x097a61cbb1cee72bb654be96d80f46e0e3531151003903b572fc193f23377 + 2c23c22228884a0d5447d0ab49a656ce1d2 + w1 = 0x18772816140e6c3c3938a693c600b2191118a34c7956e1f1cd5b0d519b56e + a5858060966cfaf27679c9182129949e74f + L = 0x04f27dd5384d6b9beb4c5022c94b1978d632779e1d3abe458611e734a529d0 + 04e25053398e5dc9eeaa4ffa59743ca7ddbc0e7ce69155295cb2b846da83ee6a4449 + 0dd8e96bb0b0f6645281bfd978dd5f6836561ea0d8b2c045ff04cef2e5873d2c + x = 0x2f1bdbeda162ff2beba0293d3cd3ae95f663c53663378c7e18ee8f56a4a48b + 00d31ce0ef43606548da485058f12e8e73 + shareP = 0x049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc245149be0 + 9571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d61da5 + ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b048fc + f + y = 0xbbcaf02404a16ed4fa73b183f703a8d969386f3d34f5e98b3a904e760512f1 + 1757f07dfcf87a2ada8fc6d028445bd53e + shareV = 0x0493b1c1f6a30eac4ac4a15711e44640bae3576787627ee2541104298 + 1e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb32219e1337c + e94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55993287f32e + d + Z = 0x048cd880e5147e49b42b5754c1bc6d2091ad414789bc3b030f2d787ea480f3 + e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99ab35b99e359a205cea56bb + a8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748db99b24f646ea7b37 + V = 0x041c3c9cc38b03a06a49cf17cc5e7754cf1ccbbc6fffc0ddf1a6e23f57294a + 25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76a62385434ed2b6e95521b41eff3 + c4ce93ecf8fb32005dd76335d0a7c78153257288d7fde1a22d404f5d73d068e2 + TT = 0x38000000000000005350414b45322b2d503338342d5348413235362d484b4 + 4462d5348413235362d484d41432d534841323536205465737420566563746f72730 + 600000000000000636c69656e7406000000000000007365727665726100000000000 + 000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3 + dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0 + 119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd6100000 + 00000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518 + f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a79 + 7c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406 + 100000000000000049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc24514 + 9be09571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d6 + 1da5ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b0 + 48fcf61000000000000000493b1c1f6a30eac4ac4a15711e44640bae3576787627ee + 25411042981e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb3 + 2219e1337ce94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55 + 993287f32ed6100000000000000048cd880e5147e49b42b5754c1bc6d2091ad41478 + 9bc3b030f2d787ea480f3e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99a + b35b99e359a205cea56bba8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748 + db99b24f646ea7b376100000000000000041c3c9cc38b03a06a49cf17cc5e7754cf1 + ccbbc6fffc0ddf1a6e23f57294a25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76 + a62385434ed2b6e95521b41eff3c4ce93ecf8fb32005dd76335d0a7c78153257288d + 7fde1a22d404f5d73d068e23000000000000000097a61cbb1cee72bb654be96d80f4 + 6e0e3531151003903b572fc193f233772c23c22228884a0d5447d0ab49a656ce1d2 + K_main = 0x61370f8bf65e0df7e9a7b2c2289be1ee4b5dd6c21f4b85165730700c4 + 4ce30af + K_confirmP = 0x2c8940419d94e53d5d240801e702c4658531aa7a9f14ec75f0d67 + f12fa84196c + K_confirmV = 0x8e74afe16c53a44590ad6bf43aa89324978b8f20014336675f618 + 387f99f3fdc + HMAC(K_confirmP, shareV) = 0x7ae825e242a5a1f86ad7db172c2c12fcb458b6a + 2b1ddfc96b2b7cfd2eed5f7ab + HMAC(K_confirmV, shareP) = 0x1581062167d6a3d14493447cd170d408f6fdc58 + e31225438db86214167426a7a + K_shared = 0x99758e838ae1a856589689fb55b6befe4e2382e6ebbeca1a6232a68 + f9dc04c1a + + [Context=b'SPAKE2+-P384-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors + '] + [idProver=b'client'] + [idVerifier=b'server'] + w0 = 0xb8d44a0982b88abe19b724d4bdafba8c90dc93130e0bf4f8062810992326d + a126fd01db53e40250ca33a3ff302044cb0 + w1 = 0x2373e2071c3bb2a6d53ece57830d56f8080189816803c22375d6a4a514f9d + 161b64d0f05b97735b98b348f9b33cc2e30 + L = 0x049ca7217ff6456bb2e2bcf71b31d9b1e5ed6e0c9700936ae617e990cee87e + e1ce3a03629dd5532948c39b89f38b39f13c7f513c5b1ada00f6533a4a8b02b9cd04 + e1b2a5db1f24ec5fe959198a19666037e04b768cc02e75ac9da0048736db6e5b + x = 0x5a835d52714f30d2ef539268b89df9558628400063dfa0e41eb979066f4caf + 409bbf7aab3ddddea13f1b070a1827d3d4 + shareP = 0x042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c762c + 69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688ad3c + 5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108d55e + e + y = 0xc883ee5b08cf7ba122038c279459ab1a730f85f2d624a02732d519faab56a4 + 98e773a8dec6c447ed02d5c00303a18bc4 + shareV = 0x04d72e11eee332305062454c0a058b8103a3304785d445510cd8d101e + 9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c880bff2f4b + 291fafafc748cb4115824e66732bdeba7fae176388e228ab9d7546255994ca3fb5a5 + 2 + Z = 0x043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554caab3790329184c45ed69 + c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10508e5de6db157305badf8 + 20fa28d68742d8287fb201383a8deec70d5bcf2a61498a481290ed8cc94ab3a0 + V = 0x0468604d188f4da560ddaaece126abe40f5de255f8af093c7c3aff71f95d90 + 92804426127d73d46a817085e9095de6bcf30733a5124a98f567148efe92a7134994 + 0c7244623247d33a8b78cbc9a53cd45bb22430f318a635084d1840c905f236c8 + TT = 0x38000000000000005350414b45322b2d503338342d5348413531322d484b4 + 4462d5348413531322d484d41432d534841353132205465737420566563746f72730 + 600000000000000636c69656e7406000000000000007365727665726100000000000 + 000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3 + dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0 + 119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd6100000 + 00000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518 + f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a79 + 7c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406 + 100000000000000042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c + 762c69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688 + ad3c5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108 + d55ee610000000000000004d72e11eee332305062454c0a058b8103a3304785d4455 + 10cd8d101e9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c + 880bff2f4b291fafafc748cb4115824e66732bdeba7fae176388e228ab9d75462559 + 94ca3fb5a526100000000000000043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554 + caab3790329184c45ed69c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10 + 508e5de6db157305badf820fa28d68742d8287fb201383a8deec70d5bcf2a61498a4 + 81290ed8cc94ab3a061000000000000000468604d188f4da560ddaaece126abe40f5 + de255f8af093c7c3aff71f95d9092804426127d73d46a817085e9095de6bcf30733a + 5124a98f567148efe92a71349940c7244623247d33a8b78cbc9a53cd45bb22430f31 + 8a635084d1840c905f236c83000000000000000b8d44a0982b88abe19b724d4bdafb + a8c90dc93130e0bf4f8062810992326da126fd01db53e40250ca33a3ff302044cb0 + K_main = 0x571af2e9a0bf4b354cca18d713f8a84315a46c999ceb92ca6a88b8a6d + 615795140862dbccd6fdc0abecc5956c43f8ab40343a22fc1b91752cb7c2737dab90 + 41e + K_confirmP = 0x6c8c7fc6becf3bc07f081b4f7f867bec76fd8eeddbd7968356723 + bae701e04f35f800e647dfa013b2876958efe0ce68e7595ba46f1de0b17adfc02dfe + 3f18a18 + K_confirmV = 0x2d0c9702a0f5536bacddd596eb6ea365d17f176db30081b97b83e + 05bb87e9a36c0565b7616251c93bc76c76fc5c3531a28db40779d986d4e7b71a24c4 + 3fbc731 + HMAC(K_confirmP, shareV) = 0x7f806ae56ea3e49a8b16ffee528086489418913 + 641f529d50ff92aa456ad4648e522f9540b403bff6bd94ee1adc95c7d1b2666f7ba6 + f9c10748bc7bfb4181d27 + HMAC(K_confirmV, shareP) = 0x8daa262decb79cceda4421f4f8dacf22ec027c0 + 8e036f071beea563c8e00813a29807963ff9d7d6bbff48dd5bdcdd9ca9fd7ffc272b + 162258d981913f7253dcb + K_shared = 0x31e0075a823b9269af5769d71ef3b2f5001cbfe044584fe8551124a + 217dad078415630bf3eda16b5a38341d418a6d72b3960f818a0926f0de88784b59d6 + a694b + + [Context=b'SPAKE2+-P521-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors + '] + [idProver=b'client'] + [idVerifier=b'server'] + w0 = 0x009c79bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863 + f60b5aeb3c101731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72 + f5f + w1 = 0x01632c15f51fcd916cd79e19075f8a69b72b0099922ad62ff8d540b469569 + f0aa027047aed2b3f242ea0ac4288b4e4db6a4e5946d8ad32b42192c5aa66d9ef8e1 + b33 + L = 0x040135072d0fa36f9e80031294cef5c3c35b882a0efa2c66570d64a49f8bec + 6c66435bf65bb7c7b2a3e7dece491e02b4d567e7087dbc32fe0fae8af417dcb50be6 + d704012a194588b690e6d3db492656f72ddea01fc1c7fcec0f5d34a5af0102939f6f + deae39c20cff74fcdb7f09855f0fc9520d20b0520b0b096b8d42c7c3d68b4a66f751 + x = 0x00b69e3bb15df82c9fa0057461334e2c66ab92fc9b8d3662eec81216ef5ddc + 4a43f19e90dedaa2d72502f69673a115984ffcf88e03a9364b07102114c5602cd93c + 69 + shareP = 0x0400a14431edf6852ff5fe868f8683e16e9e0a45d9e27f9a96442285a + c6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812df00a91dbae0 + 9e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b2eb889d09d9f + 11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b39b9fbfc7b37 + a60ab + y = 0x0056d01c5246fbde964c0493934b7ece89eafd943eb27d357880a2a2202249 + 9e249528c5707b1afe8794c8a1d60ceedaeed96dd0dd904ea075f096c9fec5da7de4 + 96 + shareV = 0x0401aa5af0f3027f63b7170572db5ff06dd1f3d6ea8ea771b26b434fb + bc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e95037a85ed7598e415a2591 + 26365e89500d0f2156b551b70416d719944736990f346f6f9ba4fbaf2f63e0987369 + 0bcf730582e0a7b03ffede50f5787b631d5021a94287f0a29a081b62b9f5a3bf393b + 001b3 + Z = 0x0401e3015bf2811891a518d342c63541294dc80e0ee210e8220a5b9cab010d + 77945724ef1185d739a62847fdada9da9b1bca6b9fa173fa551185c6084c3db26d3a + f0ac01f9356d01beebebd5ff026ca19f9df5d614355f3498816ac20b63bc936eed82 + 8a7039d1e17dba740471d9afc0e0b4427d65b2d27a57a87e42300004e2b4620c23c9 + V = 0x0401058b21ca71e4439281579d6df3b86ae874d70742fe8eae2de60e77e07e + 6e1c31b9c277de36b38531f5b769e9e4030ba09258f510c83c5c21957610355ce920 + 1fe600672db35efd1d0903bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a + 749f560e31b9c404624d24e68010f064101d4a1154e77be8f2105dbeb8b0349adb0e + TT = 0x38000000000000005350414b45322b2d503532312d5348413531322d484b4 + 4462d5348413531322d484d41432d534841353132205465737420566563746f72730 + 600000000000000636c69656e7406000000000000007365727665728500000000000 + 00004003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d856 + 08cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7a + a01bdd179a3d547610892e9b96dea1eab10bdd7ac5ae0cf75aa0f853bfd185cf782f + 894301998b11d1898ede2701dca37a2bb50b4f519c3d89a7d054b51fb84912192850 + 00000000000000400c7924b9ec017f3094562894336a53c50167ba8c596387688054 + 2bc669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 + 9d95575cd2501c62bee650c9287a651bb75c7f39a2006873347b769840d261d17760 + b107e29f091d556a82a2e4cde0c40b84b95b878db2489ef760206424b3fe7968aa8e + 0b1f33485000000000000000400a14431edf6852ff5fe868f8683e16e9e0a45d9e27 + f9a96442285ac6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812 + df00a91dbae09e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b + 2eb889d09d9f11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b + 39b9fbfc7b37a60ab85000000000000000401aa5af0f3027f63b7170572db5ff06dd + 1f3d6ea8ea771b26b434fbbc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e9 + 5037a85ed7598e415a259126365e89500d0f2156b551b70416d719944736990f346f + 6f9ba4fbaf2f63e09873690bcf730582e0a7b03ffede50f5787b631d5021a94287f0 + a29a081b62b9f5a3bf393b001b385000000000000000401e3015bf2811891a518d34 + 2c63541294dc80e0ee210e8220a5b9cab010d77945724ef1185d739a62847fdada9d + a9b1bca6b9fa173fa551185c6084c3db26d3af0ac01f9356d01beebebd5ff026ca19 + f9df5d614355f3498816ac20b63bc936eed828a7039d1e17dba740471d9afc0e0b44 + 27d65b2d27a57a87e42300004e2b4620c23c985000000000000000401058b21ca71e + 4439281579d6df3b86ae874d70742fe8eae2de60e77e07e6e1c31b9c277de36b3853 + 1f5b769e9e4030ba09258f510c83c5c21957610355ce9201fe600672db35efd1d090 + 3bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a749f560e31b9c404624d2 + 4e68010f064101d4a1154e77be8f2105dbeb8b0349adb0e4200000000000000009c7 + 9bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863f60b5aeb3c10 + 1731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72f5f + K_main = 0xf672a73216568d20cc3433247bc43a3b875a421cbdba76cf1db8bfe57 + 2b658bf3f7a4ef8cc9ff1f6a2827ff7b19860454b775a4097009040f3b36b7420407 + 16e + K_confirmP = 0xa211c60ea8d4b3b294bd6ca9515663b77f3caac28af3658b34fe1 + 512f25077f2f64b8de426caa662b4cbbdc9c2f8f12347993c8d57fdf68c177732d7d + da7277b + K_confirmV = 0x0e9bf6b9a37339144cb32a78a872f50b10839f81eda6c09a827dd + bb158c47162bec274af920cdf809f162b98fa701efebada26cdfbeac408b5a35b052 + d18f0c6 + HMAC(K_confirmP, shareV) = 0xf0f5c903dfa42fe367659656a26058cd984b76a + 8e91ae4d0fa4c13db149008e2ae57713fb230a627761174fefd263b9c10e9a4b6a37 + 46cde59c5943040c17133 + HMAC(K_confirmV, shareP) = 0xa8f7ab43f3a800171d3a3fb26d742e1ed236c2d + 5804ecd328f220a7d245cd2e3bfb6c0526983bff9229c94f70fe64ba9bb5a4d0dc10 + afcda64a4c96d4c3d81ad + K_shared = 0xd1c170e4e55efacb9db8abad286293ebd1dcf24f13973427b9632bb + c323e42e447afca2aa7f74f2af3fb5f51684ec543db854b7002cde6799c330b032ba + 8820a + + [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-CMAC-AES-128 Test Vector + s'] + [idProver=b'client'] + [idVerifier=b'server'] + w0 = 0x9aad90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47e + d61 + w1 = 0x872be859cec1e78d191882bd9c2f032af018a25016813788fe8954bfffc58 + c8e + L = 0x04d79a53698c5dd79e14b426e73b4a7f1b42469815fe24e8f53ce01579e902 + eb198d59f05bc451c41826b88e3db5476a69e197fdf474c75b387f6d40361c3fda35 + x = 0x9d39a3511a007a7d3fe6af5555cf60301bcda503f2bf6634b2caf9e4fd0743 + a1 + shareP = 0x04788218027ba4b17f7279ef0aef47a8733cf88b5bf65d6127ecadc78 + b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2082362b6c2ca14 + a8e53 + y = 0x9c3219841626325c68d89c22fb6c55611e3136442daa8b9b784db7242afff3 + ed + shareV = 0x04c05953ea9d1cd6248b8c61becd7d55e46237526d8b1e23495ea7566 + b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509b1cfdd1ef8f8195fa8bf2bd5 + ca1e5 + Z = 0x049444a17ad5909548a084fa182275a89a496ec6669bd08892aa9c64a512d4 + 0212147e6005bf1d510e3bbcfee8efc38243acaf4c5f2decffa009341b1e330b0442 + V = 0x0457a8919af393e2da1de209a01fdda275eab0a682d8931b0e6ee1b9339794 + 63a25ccbcda1956a6a555706f0b062aa880617bd219d09391ad8576d3a73e9233f57 + TT = 0x39000000000000005350414b45322b2d503235362d5348413235362d484b4 + 4462d5348413235362d434d41432d4145532d313238205465737420566563746f727 + 30600000000000000636c69656e74060000000000000073657276657241000000000 + 0000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa + 12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d204 + 10000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4 + f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1 + e656edbe7410000000000000004788218027ba4b17f7279ef0aef47a8733cf88b5bf + 65d6127ecadc78b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2 + 082362b6c2ca14a8e53410000000000000004c05953ea9d1cd6248b8c61becd7d55e + 46237526d8b1e23495ea7566b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509 + b1cfdd1ef8f8195fa8bf2bd5ca1e54100000000000000049444a17ad5909548a084f + a182275a89a496ec6669bd08892aa9c64a512d40212147e6005bf1d510e3bbcfee8e + fc38243acaf4c5f2decffa009341b1e330b044241000000000000000457a8919af39 + 3e2da1de209a01fdda275eab0a682d8931b0e6ee1b933979463a25ccbcda1956a6a5 + 55706f0b062aa880617bd219d09391ad8576d3a73e9233f5720000000000000009aa + d90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47ed61 + K_main = 0x6002da6b2740056f2836ac0316ae9e02e2b24c5c109883136e90ed868 + b2fcf62 + K_confirmP = 0x857d0db7f5e06385853bf4b8abd43b5a + K_confirmV = 0x268c75933332157118063550c6bfe846 + CMAC(K_confirmP, shareV) = 0xd340bc94a03feafd14491e316514ca5f + CMAC(K_confirmV, shareP) = 0x2b42d0fe76bcf9ccc208d06d60082f96 + K_shared = 0xe832094adfc028bf288e49ab902fc208b7eeff084f259da7613c047 + 9869d4fc9 + + [Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-CMAC-AES-128 Test Vector + s'] + [idProver=b'client'] + [idVerifier=b'server'] + w0 = 0x56e0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50e + b90 + w1 = 0x462fe5b522a17d3d35b27323113bdd252de9cbfdd6f264b35721bf59a9a74 + f0b + L = 0x040540332ffec8a2faa8d17ae6da5973c11e078b8c10c89fd6af996726b802 + 3513eff2914c3ced64fbedd4e261438fb0ea6ef9fc1faef4ba1ead780636faac1bc1 + x = 0x254dd22780eeb6af2464dd6a2bd026b46a34966d6933607f1be956314f74b0 + ea + shareP = 0x049661cfdb0f7bd24b637f8d1d0f464c17f0b9c15129ea31156dcc581 + da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036eb2dedaf26e511a + 24a48 + y = 0x695beec24305fbd5660bc200228598e7c891fdf60a55df4bdd3a57debc3847 + 4a + shareV = 0x0461f580eb3eb4b2f412d5c07491f360ad6e4492d8f23e346f0ba999f + bbcb9715a3c2485c3b250a6672e6698da3c9a9725645f607ee90a9b1b34fd44b9df6 + e551a + Z = 0x0406f77a4bca254219dc3eeca9989f377037407105540bfddc5bdeff3d27a8 + 7d68442e69d543a000077bd4c42e33930f890d29fb4be5e8dcc627f6811ace96c274 + V = 0x0442952a531a2937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b14 + 6f5c2249e727e374de03f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133d + TT = 0x39000000000000005350414b45322b2d503235362d5348413531322d484b4 + 4462d5348413531322d434d41432d4145532d313238205465737420566563746f727 + 30600000000000000636c69656e74060000000000000073657276657241000000000 + 0000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa + 12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d204 + 10000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4 + f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1 + e656edbe74100000000000000049661cfdb0f7bd24b637f8d1d0f464c17f0b9c1512 + 9ea31156dcc581da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036e + b2dedaf26e511a24a4841000000000000000461f580eb3eb4b2f412d5c07491f360a + d6e4492d8f23e346f0ba999fbbcb9715a3c2485c3b250a6672e6698da3c9a9725645 + f607ee90a9b1b34fd44b9df6e551a41000000000000000406f77a4bca254219dc3ee + ca9989f377037407105540bfddc5bdeff3d27a87d68442e69d543a000077bd4c42e3 + 3930f890d29fb4be5e8dcc627f6811ace96c27441000000000000000442952a531a2 + 937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b146f5c2249e727e374de0 + 3f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133d200000000000000056e + 0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50eb90 + K_main = 0x111790ae23de3fc5bb43bdc1f63106461dbd8d86360adf056bf117164 + 8bfb231503853db2625275b7136b5a823dd5a94482514fce7f791c4daca2b21c7bde + 756 + K_confirmP = 0xb234d2e152a03168b76c6474d5322070 + K_confirmV = 0x683d62024626fe0c5126ef4df58b88ee + CMAC(K_confirmP, shareV) = 0x0dc514d262e37470eb43e058e0d615f4 + CMAC(K_confirmV, shareP) = 0xde076589efcd5d96c2ea6061d96772d9 + K_shared = 0x488a34663d6be5e02590bb8e9ad9ad3e0f580dec41e8b99ed4ae4b7 + 34da49287638cac4c9f17fe3c3ae18dda0d6d7f14c17e4640d5a2aaab959efa0cbea + 4e546 + +Acknowledgements + + Thanks to Ben Kaduk and Watson Ladd, from whom this specification + originally emanated. + +Authors' Addresses + + Tim Taubert + Apple Inc. + One Apple Park Way + Cupertino, California 95014 + United States of America + Email: ttaubert@apple.com + + + Christopher A. Wood + Email: caw@heapingbits.net |