RFC 9383

SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol

Pages: ~25

INDEPENDENT/draft-bar-cfrg-spake2plus-08

Informational

RFCv3-9383

T. Taubert

Apple Inc.

C. A. Wood

–

September 2023

SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol

Abstract

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

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.

RFCv3-9383

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, [RFC 9382], 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.

RFCv3-9383

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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

RFCv3-9383

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 [RFC 6234]. 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 [RFC 8265]. 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 [RFC 7914] function and the Argon2id [RFC 9106] 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 RFC 9106.

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 [RFC 8844]).

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.

RFCv3-9383

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 [RFC 5869] and HMAC [RFC 2104] 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 [RFC 6234]	HKDF-SHA256 [RFC 5869]	HMAC-SHA256 [RFC 2104]
P-256	SHA512 [RFC 6234]	HKDF-SHA512 [RFC 5869]	HMAC-SHA512 [RFC 2104]
P-384	SHA256 [RFC 6234]	HKDF-SHA256 [RFC 5869]	HMAC-SHA256 [RFC 2104]
P-384	SHA512 [RFC 6234]	HKDF-SHA512 [RFC 5869]	HMAC-SHA512 [RFC 2104]
P-521	SHA512 [RFC 6234]	HKDF-SHA512 [RFC 5869]	HMAC-SHA512 [RFC 2104]
edwards25519	SHA256 [RFC 6234]	HKDF-SHA256 [RFC 5869]	HMAC-SHA256 [RFC 2104]
edwards448	SHA512 [RFC 6234]	HKDF-SHA512 [RFC 5869]	HMAC-SHA512 [RFC 2104]
P-256	SHA256 [RFC 6234]	HKDF-SHA256 [RFC 5869]	CMAC-AES-128 [RFC 4493]
P-256	SHA512 [RFC 6234]	HKDF-SHA512 [RFC 5869]	CMAC-AES-128 [RFC 4493]

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 [RFC 8032]. Note that these values are identical to those used in the companion SPAKE2 specification [RFC 9382].

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)

RFCv3-9383

5. IANA Considerations

This document has no IANA actions.

RFCv3-9383

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.

RFCv3-9383

7. References

7.1. Normative References

[RFC2104]: H. Krawczyk, M. Bellare, 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]: S. Bradner, "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]: JH. Song, R. Poovendran, J. Lee, and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006,
<https://www.rfc-editor.org/info/rfc4493>.
[RFC5480]: S. Turner, D. Brown, K. Yiu, R. Housley, 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]: H. Krawczyk, 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]: D. Eastlake 3rd, 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]: S. Josefsson, 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]: B. Leiba, "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]: P. Saint-Andre, 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]: W Ladd, "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", May 2009,
<https://secg.org/sec1-v2.pdf>.
[SPAKE2P-Analysis]: V. Shoup, "Security analysis of SPAKE2+", March 2020,
<https://eprint.iacr.org/2020/313.pdf>.
[TDH]: D Cash, E Kiltz, and V Shoup, "The Twin-Diffie Hellman Problem and Applications", 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]: C. Percival, 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]: M. Thomson, 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]: A. Biryukov, D. Dinu, D. Khovratovich, 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>.

RFCv3-9383

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

RFCv3-9383

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 [RFC 5480] (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 ([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 [RFC 8032], 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 [RFC 8032], 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 RFC 8032:

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

RFCv3-9383

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

RFCv3-9383

Cupertino California 95014

United States of America

Email: ttaubert@apple.com

Christopher A. Wood

Email: caw@heapingbits.net

RFC 9383

SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol

SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol

Abstract

Status of This Memo

Copyright Notice

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

Tim Taubert

Christopher A. Wood