Movatterモバイル変換


[0]ホーム

URL:


RFC 9383spake2plusSeptember 2023
Taubert & WoodInformational[Page]
Stream:
Independent Submission
RFC:
9383
Category:
Informational
Published:
ISSN:
2070-1721
Authors:
T. Taubert
Apple Inc.
C. A. Wood

RFC 9383

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

Abstract

This document describes SPAKE2+, a Password-Authenticated Key Exchange (PAKE) protocolrun 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 endorsementof 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 athttps://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

This document describes SPAKE2+, a Password-Authenticated Key Exchange (PAKE) protocolrun 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 constrainedand 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 PAKEsare 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 exchangeprotocol appears in[TDH] and is proven secure in[SPAKE2P-Analysis]. It is compatible with anyprime-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 endorsementof 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 inG, e.g., the point at infinity if G is an elliptic curve group. We denote theoperations in the group additively. We assume that there is a representation ofelements of G as byte strings: common choices would be SEC 1uncompressed 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 specifiedin the document defining the group, and so we do not repeat it here.

|| denotes concatenation of strings. We also let len(S) denote thelength 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, inputkeying material (IKM), info string, and derived key length L to derive acryptographic key of length L.MAC is a Message Authentication Code algorithm that takes a secret key andmessage as input to produce an output.Let Hash be a hash function from arbitrary strings to bit strings of a fixed length. Common choicesfor Hash are SHA256 or SHA512[RFC6234].Section 4 specifies variants of KDF, MAC, and Hashsuitable for use with the protocols contained herein.

Let there be two parties, a Prover and a Verifier. Their identities, denoted asidProver and idVerifier, may also have digital representations such as Media Access Control addressesor other names (hostnames, usernames, etc.). The parties may share additional data(the context) separate from their identities, which they may want to include inthe protocol transcript.One example of additional data is a list of supported protocol versions if SPAKE2+ wereused in a higher-level protocol that negotiates the use of a particular PAKE. Anotherexample is the inclusion of the application name. Including these data points would ensure thatboth parties agree upon the same set of supported protocols and therefore prevents downgrade andcross-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 anadditional round for key confirmation. Prior to invocation, both parties areprovisioned with information such as the input password needed to run theprotocol. The registration phase may include communicating identities, protocolversion, and other parameters related to the registration record; seeSection 3.2 for details.

During the first round, the Prover sends a public share, shareP, to the Verifier, which in turnresponds with its own public share, shareV. Both parties then derive a shared secretused to produce encryption and authentication keys. The latter are used during the secondround 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 confirmVMAY be sent in the same message.)Both partiesMUST NOT consider the protocol complete prior to receipt andvalidation 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 registrationrecord L=w1*P.  w0 and w1 are derived by hashing the password pw with the identitiesof the two participants.  w0 and the record L are then shared with the Verifier andstored as part of the registration record associated with the Prover. The ProverSHOULD derive w0 and w1 from the password before the protocol begins. Both w0 andw1 are derived using a function with range [0, p-1], which is modeled as a randomoracle in[SPAKE2P-Analysis].

The registration phase also produces two random elements, M and N, in the prime-ordersubgroup of G. The algorithm for selecting M and N is defined inAppendix B.Importantly, this algorithm chooses M and N such that their discrete logs are notknown. Precomputed values for M and N are listed inSection 4 for eachgroup. ApplicationsMAY use different M and N values, provided they are computed,e.g., using different input seeds to the algorithm inAppendix B, as random elementsfor which the discrete log is unknown.

Applications using this specificationMUST define the method used to compute w0 and w1.For example, it may be necessary to carry out various forms of normalization of thepassword before hashing[RFC8265]. This section contains requirements and defaultrecommendations for computing w0 and w1.

TheRECOMMENDED method for generating w0 and w1 is via a Password-Based KeyDerivation Function (PBKDF), which is a function designed to slow down brute-forceattackers. Brute-force resistance may be obtained through various computation hardnessparameters 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), andRECOMMENDED parameters for Argon2idare inSection 4 of [RFC9106].

Each half of the output of the PBKDF will be interpreted as an integer and reducedmodulo p. To control bias, each half must be of length at least ceil(log2(p)) + kbits, with k >= 64. Reducing such integers mod p gives bias at most 2^-k for anyp; 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 PBKDFSHOULD be at least 640 bits or 80 bytes.

Given a PBKDF, password pw, and identities idProver and idVerifier, theRECOMMENDEDmethod for computing w0 and w1 is as follows:

w0s || w1s = PBKDF(len(pw) || pw ||                   len(idProver) || idProver ||                   len(idVerifier) || idVerifier)w0 = w0s mod pw1 = w1s mod p

If an identity is unknown at the time of computing w0s or w1s, its length is givenas zero and the identity itself is represented as an empty octet string. If bothidProver and idVerifier are unknown, then their lengths are given as zero and bothidentities will be represented as empty octet strings.  idProver and idVerifier areincluded 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 asingle shared secret upon completion. To begin, the Prover selects x uniformlyat 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 membershipand aborts if X is not in the large prime-order subgroup of G; seeSection 6for details. The Verifier then selects y uniformly at random from the integersin [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 membershipand 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 elementN is known to the adversary. In particular, oneMAY set N=I, i.e., set N to theunit element in G.

It is essential that both Z and V be used in combination with the transcript toderive 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 bothparties andMUST precede the remaining transcript. It might contain thename and version number of the higher-level protocol, or simply the name and versionnumber of the application. The contextMAY include additional data such as thechosen ciphersuite and PBKDF parameters like the iteration count or salt.The context and its length prefixMAY be omitted.

If an identity is absent, its length is given as zero and the identity itselfis represented as an empty octet string. If both identities are absent, thentheir lengths are given as zero and both are represented as empty octet strings.In applications where identities are not implicit, idProver and idVerifierSHOULD always benon-empty. Otherwise, the protocol risks unknown key-share attacks (discussionof 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 inSection 3.4. The VerifierMUST send a keyconfirmation message, confirmV, to the Prover so both parties can confirm that theyagree upon these shared secrets. After receipt and verification of the Verifier'sconfirmation message, the ProverMUST respond with its confirmation message.The VerifierMUST NOT send application data to the Prover until it has receivedand verified the confirmation message. Key confirmation verification requiresrecomputation of confirmP or confirmV and checking for equality against the data that wasreceived.

3.4.Key Schedule and Key Confirmation

The protocol transcript TT, as defined inSection 3.3, is unique and secret tothe participants. Both parties use TT to derive the shared symmetric secret K_main from theprotocol. The length of K_main is equal to the length of the digest output, e.g., 256 bitsfor Hash() = SHA-256. The confirmation keys K_confirmP and K_confirmV, as well as the sharedkey 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 keyderivation and confirmation andMUST be discarded after the protocol execution.ApplicationsMAY derive additional keys from K_shared as needed.

The length of each confirmation key is dependent on the MAC function of the chosenciphersuite. For HMAC, theRECOMMENDED key length is equal to the output length ofthe digest output, e.g., 256 bits for Hash() = SHA-256. For CMAC-AES, eachconfirmation keyMUST be of length k, where k is the chosen AES key size,e.g., 128 bits for CMAC-AES-128.

Both endpointsMUST employ a MAC that produces pseudorandom tags for key confirmation.K_confirmP and K_confirmV are symmetric keys used to compute tags confirmP andconfirmV 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, applicationsMAY use K_shared as an authenticatedshared secret as needed. For example, applicationsMAY 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 ciphersuiteindicates 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 overP-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 affectinteroperability, the PBKDF is not included as part of the ciphersuite.

If no MAC algorithm is used in the key confirmation phase, its respective columninTable 1 can be ignored and the ciphersuite name will contain no MACidentifier.

Table 1
GHashKDFMAC
P-256SHA256[RFC6234]HKDF-SHA256[RFC5869]HMAC-SHA256[RFC2104]
P-256SHA512[RFC6234]HKDF-SHA512[RFC5869]HMAC-SHA512[RFC2104]
P-384SHA256[RFC6234]HKDF-SHA256[RFC5869]HMAC-SHA256[RFC2104]
P-384SHA512[RFC6234]HKDF-SHA512[RFC5869]HMAC-SHA512[RFC2104]
P-521SHA512[RFC6234]HKDF-SHA512[RFC5869]HMAC-SHA512[RFC2104]
edwards25519SHA256[RFC6234]HKDF-SHA256[RFC5869]HMAC-SHA256[RFC2104]
edwards448SHA512[RFC6234]HKDF-SHA512[RFC5869]HMAC-SHA512[RFC2104]
P-256SHA256[RFC6234]HKDF-SHA256[RFC5869]CMAC-AES-128[RFC4493]
P-256SHA512[RFC6234]HKDF-SHA512[RFC5869]CMAC-AES-128[RFC4493]

The following points represent permissible point generation seeds for the groups listedinTable 1, using the algorithm presented inAppendix B. These byte strings arecompressed points as in[SEC1] for curves from[SEC1] and[RFC8032]. Note thatthese values are identical to those used in the companion SPAKE2 specification[RFC9382].

For P-256:

M =02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12fseed: 1.2.840.10045.3.1.7 point generation seed (M)N =03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49seed: 1.2.840.10045.3.1.7 point generation seed (N)

For P-384:

M =030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc36f15314739074d2eb8613fceec2853seed: 1.3.132.0.34 point generation seed (M)N =02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb252c5490214cf9aa3f0baab4b665c10seed: 1.3.132.0.34 point generation seed (N)

For P-521:

M =02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aaseed: 1.3.132.0.35 point generation seed (M)N =0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25seed: 1.3.132.0.35 point generation seed (N)

For edwards25519:

M =d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdafseed: edwards25519 point generation seed (M)N =d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4abseed: edwards25519 point generation seed (N)

For edwards448:

M =b6221038a775ecd007a4e4dde39fd76ae91d3cf0cc92be8f0c2fa6d6b66f9a12942f5a92646109152292464f3e63d354701c7848d9fc3b8880seed: edwards448 point generation seed (M)N =6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4dbf97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600seed: 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 VerifierMUST begenerated using a cryptographically secure Pseudorandom Number Generator (PRNG).

Elements received from a peerMUST be checked for group membership: failure toproperly deserialize and validate group elements can lead to attacks. An endpointMUST abort the protocol if any received public value is not a member of thelarge prime-order subgroup of G. Multiplication of a public value V by thecofactor h will yield the identity element I whenever V is an element of asmall-order subgroup. Consequently, the Prover and VerifierMUST abort the protocolupon receiving any value V such that V*h = I. Failure to do so may lead to subgroupconfinement attacks.

7.References

7.1.Normative References

[RFC2104]
Krawczyk, H.,Bellare, M., andR. Canetti,"HMAC: Keyed-Hashing for Message Authentication",RFC 2104,DOI 10.17487/RFC2104,,<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,,<https://www.rfc-editor.org/info/rfc2119>.
[RFC4493]
Song, JH.,Poovendran, R.,Lee, J., andT. Iwata,"The AES-CMAC Algorithm",RFC 4493,DOI 10.17487/RFC4493,,<https://www.rfc-editor.org/info/rfc4493>.
[RFC5480]
Turner, S.,Brown, D.,Yiu, K.,Housley, R., andT. Polk,"Elliptic Curve Cryptography Subject Public Key Information",RFC 5480,DOI 10.17487/RFC5480,,<https://www.rfc-editor.org/info/rfc5480>.
[RFC5869]
Krawczyk, H. andP. Eronen,"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)",RFC 5869,DOI 10.17487/RFC5869,,<https://www.rfc-editor.org/info/rfc5869>.
[RFC6234]
Eastlake 3rd, D. andT. Hansen,"US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)",RFC 6234,DOI 10.17487/RFC6234,,<https://www.rfc-editor.org/info/rfc6234>.
[RFC8032]
Josefsson, S. andI. Liusvaara,"Edwards-Curve Digital Signature Algorithm (EdDSA)",RFC 8032,DOI 10.17487/RFC8032,,<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,,<https://www.rfc-editor.org/info/rfc8174>.
[RFC8265]
Saint-Andre, P. andA. Melnikov,"Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords",RFC 8265,DOI 10.17487/RFC8265,,<https://www.rfc-editor.org/info/rfc8265>.
[RFC9382]
Ladd, W.,"SPAKE2, a Password-Authenticated Key Exchange",RFC 9382,DOI 10.17487/RFC9382,,<https://www.rfc-editor.org/info/rfc9382>.
[SEC1]
Standards for Efficient Cryptography Group,"SEC 1: Elliptic Curve Cryptography",version 2.0,,<https://secg.org/sec1-v2.pdf>.
[SPAKE2P-Analysis]
Shoup, V.,"Security analysis of SPAKE2+",,<https://eprint.iacr.org/2020/313.pdf>.
[TDH]
Cash, D.,Kiltz, E., andV. 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,,<https://doi.org/10.1007/978-3-540-78967-3_8>.

7.2.Informative References

[RFC7914]
Percival, C. andS. Josefsson,"The scrypt Password-Based Key Derivation Function",RFC 7914,DOI 10.17487/RFC7914,,<https://www.rfc-editor.org/info/rfc7914>.
[RFC8844]
Thomson, M. andE. Rescorla,"Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)",RFC 8844,DOI 10.17487/RFC8844,,<https://www.rfc-editor.org/info/rfc8844>.
[RFC9106]
Biryukov, A.,Dinu, D.,Khovratovich, D., andS. Josefsson,"Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications",RFC 9106,DOI 10.17487/RFC9106,,<https://www.rfc-editor.org/info/rfc9106>.

Appendix A.Protocol Flow

This section describes the flow of the SPAKE2+ protocol, including computationsand 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, whichare 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, whichis 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 protocoltranscript, 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 computethe 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 receivinga 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_sharedVerifier(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 generatethe points M and N inTable 1 (Section 4). This algorithmproduces M and N such that they are indistinguishable from two randompoints in the prime-order subgroup of G, where the discrete logof these points is unknown. See[SPAKE2P-Analysis] for additionaldetails on this requirement.

For each curve inTable 1, we construct a stringusing the curve OID from[RFC5480] (as an ASCIIstring) or its name,combined with the needed constant -- for instance, "1.3.132.0.35point generation seed (M)" for P-521. This string is turnedinto a series of blocks by hashing with SHA256, and hashing thatoutput again to generate the next 32 bytes, and so on. Thispattern is repeated for each group and value, with the stringmodified appropriately.

A byte string of length equal to that of an encoded groupelement is constructed by concatenating as many blocks as arerequired, starting from the first block, and truncating to thedesired length. The byte string is then formatted as requiredfor the group. In the case of Weierstrass curves, we take thedesired 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 firstbyte is set to 0x02 or 0x03 (clearing the first six bitsand setting the seventh bit), leaving the sign bit as it wasin 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 thelast byte set to zero, and for edwards25519, the 32-byte input isnot modified. For both of the curves described in[RFC8032], the(modified) input is then interpretedas the representation of the group element.If this interpretation yields a valid group element with thecorrect order (p), the (modified) byte string is the output. Otherwise,the initial hash block is discarded and a new byte string constructedfrom the remaining hash blocks. The procedure for constructing abyte string of the appropriate length, formatting it asrequired for the curve, and checking to see if it is a valid point of the correctorder is repeateduntil a valid element is found.

The following Python snippet generates the above points,assuming an elliptic curve implementation following theinterface of Edwards25519Point.stdbase() andEdwards448Point.stdbase() inAppendix A of [RFC8032]:

def iterated_hash(seed, n):  h = seed  for i in range(n):    h = hashlib.sha256(h).digest()  return hdef 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 octetprefix, specified in[SEC1].  idProver and idVerifier identity stringsare provided in the protocol invocation.

[Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors'][idProver=b'client'][idVerifier=b'server']w0 = 0xbb8e1bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad95491b3w1 = 0x7e945f34d78785b8a3ef44d0df5a1a97d6b3b460409a345ca7830387a74b1dbaL = 0x04eb7c9db3d9a9eb1f8adab81b5794c1f13ae3e225efbe91ea487425854c7fc00f00bfedcbd09b2400142d40a14f2064ef31dfaa903b91d1faea7093d835966efdx = 0xd1232c8e8693d02368976c174e2088851b8365d0d79a9eee709c6a05a2fad539shareP = 0x04ef3bd051bf78a2234ec0df197f7828060fe9856503579bb1733009042c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab97a79c7193e341727y = 0x717a72348a182085109c8d3917d6c43d59b224dc6a7fc4f0483232fa6516d8b3shareV = 0x04c0f65da0d11927bdf5d560c69e1d7d939a05b0e88291887d679fcadea75810fb5cc1ca7494db39e82ff2f50665255d76173e09986ab46742c798a9a68437b048Z = 0x04bbfce7dd7f277819c8da21544afb7964705569bdf12fb92aa388059408d50091a0c5f1d3127f56813b5337f9e4e67e2ca633117a4fbd559946ab474356c41839V = 0x0458bf27c6bca011c9ce1930e8984a797a3419797b936629a5a937cf2f11c8b9514b82b993da8a46e664f23db7c01edc87faa530db01c2ee405230b18997f16b68TT = 0x38000000000000005350414b45322b2d503235362d5348413235362d484b44462d5348413235362d484d41432d534841323536205465737420566563746f72730600000000000000636c69656e740600000000000000736572766572410000000000000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e656edbe7410000000000000004ef3bd051bf78a2234ec0df197f7828060fe9856503579bb1733009042c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab97a79c7193e341727410000000000000004c0f65da0d11927bdf5d560c69e1d7d939a05b0e88291887d679fcadea75810fb5cc1ca7494db39e82ff2f50665255d76173e09986ab46742c798a9a68437b048410000000000000004bbfce7dd7f277819c8da21544afb7964705569bdf12fb92aa388059408d50091a0c5f1d3127f56813b5337f9e4e67e2ca633117a4fbd559946ab474356c4183941000000000000000458bf27c6bca011c9ce1930e8984a797a3419797b936629a5a937cf2f11c8b9514b82b993da8a46e664f23db7c01edc87faa530db01c2ee405230b18997f16b682000000000000000bb8e1bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad95491b3K_main = 0x4c59e1ccf2cfb961aa31bd9434478a1089b56cd11542f53d3576fb6c2a438a29K_confirmP = 0x871ae3f7b78445e34438fb284504240239031c39d80ac23eb5ab9be5ad6db58aK_confirmV = 0xccd53c7c1fa37b64a462b40db8be101cedcf838950162902054e644b400f1680HMAC(K_confirmP, shareV) = 0x926cc713504b9b4d76c9162ded04b5493e89109f6d89462cd33adc46fda27527HMAC(K_confirmV, shareP) = 0x9747bcc4f8fe9f63defee53ac9b07876d907d55047e6ff2def2e7529089d3e68K_shared = 0x0c5f8ccd1413423a54f6c1fb26ff01534a87f893779c6e68666d772bfd91f3e7
[Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors'][idProver=b'client'][idVerifier=b'server']w0 = 0x1cc5207d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c8ccw1 = 0x4279649e62532b01dc27d2ed39100ba350518fb969672061a01edce752d0e672L = 0x043a348ad475d2200d46df876f1eb2e136056da31dafff52cc7762bf3be84de0097c4e69b0b9321326af1f0af4a14561a9c7b640cb5afd6822d14cb34830fc4511x = 0xb586ab83f175c1a2b56b6a1b6a283523f88a9befcf11e22efb48e2ee1fe69a23shareP = 0x04a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9745a4180c94657a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5365375c62e09def4ay = 0xac1fb828f041782d452ea9cc00c3fa34a55fa8f7f98c04be45a3d607b092d441shareV = 0x04498c29e37dbd53ebf8db76679901d90c6be3af57f46ac3025b32420839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad23eba13197c9d96a5b10275e35dZ = 0x04a81e31be54283cee81bf7bdc877764b6b2ac6a399f1176380aac8a82172c18051aa17dfcf438896ad253f53b52cd45ec2c7399488a919bcfcfecc0261cbf5284V = 0x04de0a53f96cbe4abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d518bb2d9734b1d2dfce3fd916e991ab9dc3a2760d439c083eb39b65408857d2bb4aaTT = 0x38000000000000005350414b45322b2d503235362d5348413531322d484b44462d5348413531322d484d41432d534841353132205465737420566563746f72730600000000000000636c69656e740600000000000000736572766572410000000000000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e656edbe7410000000000000004a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9745a4180c94657a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5365375c62e09def4a410000000000000004498c29e37dbd53ebf8db76679901d90c6be3af57f46ac3025b32420839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad23eba13197c9d96a5b10275e35d410000000000000004a81e31be54283cee81bf7bdc877764b6b2ac6a399f1176380aac8a82172c18051aa17dfcf438896ad253f53b52cd45ec2c7399488a919bcfcfecc0261cbf5284410000000000000004de0a53f96cbe4abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d518bb2d9734b1d2dfce3fd916e991ab9dc3a2760d439c083eb39b65408857d2bb4aa20000000000000001cc5207d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c8ccK_main = 0x527613439c279a375c116342a4216a8d92441d2fe1921dd1e60f140b2855916ccac7db4dbf22bd56e344a8cd506d08949bde1e9d83c24d68ff4246458dc14288K_confirmP = 0x0aa129d7b82067c2a9607677c9c4fdedc1cd7cfed9ff72c54c0aebb2b1a8aa915b96834b2986725c6040852ceaafbb17d638a715198f795654eac89bf0739878K_confirmV = 0xa1f1038de30a8c12d43d06c27d362daa9699249e941faa2d5cbc59a9683bf42aed9537818245677fdb54b5274506542994f4a83455f6d7b3af5ec017faa58f61HMAC(K_confirmP, shareV) = 0x6b2469b56cf8ac3f94a8d0b533380ea6b3d0f46b3e12ee82550d49e129c2412728c9437a64ee5f80c8cdc5e8a30faa0a6deb8a5251346ba81bb6fc955b2304fcHMAC(K_confirmV, shareP) = 0x154174fc278a935e290b3352ba877e179fa9281c0a76928faea703c72d383b267511a5cf084cb07147efece94e3cfd91944e7baab856858fbebc087167b0f409K_shared = 0x11887659d9e002f34fa6cc270d33570f001b2a3fc0522b643c07327d09a4a9f47aab85813d13c585b53adf5ac9de5707114848f3dc31a4045f69a2cc1972b098
[Context=b'SPAKE2+-P384-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors'][idProver=b'client'][idVerifier=b'server']w0 = 0x097a61cbb1cee72bb654be96d80f46e0e3531151003903b572fc193f233772c23c22228884a0d5447d0ab49a656ce1d2w1 = 0x18772816140e6c3c3938a693c600b2191118a34c7956e1f1cd5b0d519b56ea5858060966cfaf27679c9182129949e74fL = 0x04f27dd5384d6b9beb4c5022c94b1978d632779e1d3abe458611e734a529d004e25053398e5dc9eeaa4ffa59743ca7ddbc0e7ce69155295cb2b846da83ee6a44490dd8e96bb0b0f6645281bfd978dd5f6836561ea0d8b2c045ff04cef2e5873d2cx = 0x2f1bdbeda162ff2beba0293d3cd3ae95f663c53663378c7e18ee8f56a4a48b00d31ce0ef43606548da485058f12e8e73shareP = 0x049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc245149be09571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d61da5ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b048fcfy = 0xbbcaf02404a16ed4fa73b183f703a8d969386f3d34f5e98b3a904e760512f11757f07dfcf87a2ada8fc6d028445bd53eshareV = 0x0493b1c1f6a30eac4ac4a15711e44640bae3576787627ee25411042981e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb32219e1337ce94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55993287f32edZ = 0x048cd880e5147e49b42b5754c1bc6d2091ad414789bc3b030f2d787ea480f3e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99ab35b99e359a205cea56bba8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748db99b24f646ea7b37V = 0x041c3c9cc38b03a06a49cf17cc5e7754cf1ccbbc6fffc0ddf1a6e23f57294a25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76a62385434ed2b6e95521b41eff3c4ce93ecf8fb32005dd76335d0a7c78153257288d7fde1a22d404f5d73d068e2TT = 0x38000000000000005350414b45322b2d503338342d5348413235362d484b44462d5348413235362d484d41432d534841323536205465737420566563746f72730600000000000000636c69656e7406000000000000007365727665726100000000000000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd610000000000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a797c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406100000000000000049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc245149be09571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d61da5ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b048fcf61000000000000000493b1c1f6a30eac4ac4a15711e44640bae3576787627ee25411042981e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb32219e1337ce94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55993287f32ed6100000000000000048cd880e5147e49b42b5754c1bc6d2091ad414789bc3b030f2d787ea480f3e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99ab35b99e359a205cea56bba8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748db99b24f646ea7b376100000000000000041c3c9cc38b03a06a49cf17cc5e7754cf1ccbbc6fffc0ddf1a6e23f57294a25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76a62385434ed2b6e95521b41eff3c4ce93ecf8fb32005dd76335d0a7c78153257288d7fde1a22d404f5d73d068e23000000000000000097a61cbb1cee72bb654be96d80f46e0e3531151003903b572fc193f233772c23c22228884a0d5447d0ab49a656ce1d2K_main = 0x61370f8bf65e0df7e9a7b2c2289be1ee4b5dd6c21f4b85165730700c44ce30afK_confirmP = 0x2c8940419d94e53d5d240801e702c4658531aa7a9f14ec75f0d67f12fa84196cK_confirmV = 0x8e74afe16c53a44590ad6bf43aa89324978b8f20014336675f618387f99f3fdcHMAC(K_confirmP, shareV) = 0x7ae825e242a5a1f86ad7db172c2c12fcb458b6a2b1ddfc96b2b7cfd2eed5f7abHMAC(K_confirmV, shareP) = 0x1581062167d6a3d14493447cd170d408f6fdc58e31225438db86214167426a7aK_shared = 0x99758e838ae1a856589689fb55b6befe4e2382e6ebbeca1a6232a68f9dc04c1a
[Context=b'SPAKE2+-P384-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors'][idProver=b'client'][idVerifier=b'server']w0 = 0xb8d44a0982b88abe19b724d4bdafba8c90dc93130e0bf4f8062810992326da126fd01db53e40250ca33a3ff302044cb0w1 = 0x2373e2071c3bb2a6d53ece57830d56f8080189816803c22375d6a4a514f9d161b64d0f05b97735b98b348f9b33cc2e30L = 0x049ca7217ff6456bb2e2bcf71b31d9b1e5ed6e0c9700936ae617e990cee87ee1ce3a03629dd5532948c39b89f38b39f13c7f513c5b1ada00f6533a4a8b02b9cd04e1b2a5db1f24ec5fe959198a19666037e04b768cc02e75ac9da0048736db6e5bx = 0x5a835d52714f30d2ef539268b89df9558628400063dfa0e41eb979066f4caf409bbf7aab3ddddea13f1b070a1827d3d4shareP = 0x042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c762c69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688ad3c5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108d55eey = 0xc883ee5b08cf7ba122038c279459ab1a730f85f2d624a02732d519faab56a498e773a8dec6c447ed02d5c00303a18bc4shareV = 0x04d72e11eee332305062454c0a058b8103a3304785d445510cd8d101e9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c880bff2f4b291fafafc748cb4115824e66732bdeba7fae176388e228ab9d7546255994ca3fb5a52Z = 0x043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554caab3790329184c45ed69c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10508e5de6db157305badf820fa28d68742d8287fb201383a8deec70d5bcf2a61498a481290ed8cc94ab3a0V = 0x0468604d188f4da560ddaaece126abe40f5de255f8af093c7c3aff71f95d9092804426127d73d46a817085e9095de6bcf30733a5124a98f567148efe92a71349940c7244623247d33a8b78cbc9a53cd45bb22430f318a635084d1840c905f236c8TT = 0x38000000000000005350414b45322b2d503338342d5348413531322d484b44462d5348413531322d484d41432d534841353132205465737420566563746f72730600000000000000636c69656e7406000000000000007365727665726100000000000000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd610000000000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a797c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406100000000000000042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c762c69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688ad3c5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108d55ee610000000000000004d72e11eee332305062454c0a058b8103a3304785d445510cd8d101e9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c880bff2f4b291fafafc748cb4115824e66732bdeba7fae176388e228ab9d7546255994ca3fb5a526100000000000000043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554caab3790329184c45ed69c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10508e5de6db157305badf820fa28d68742d8287fb201383a8deec70d5bcf2a61498a481290ed8cc94ab3a061000000000000000468604d188f4da560ddaaece126abe40f5de255f8af093c7c3aff71f95d9092804426127d73d46a817085e9095de6bcf30733a5124a98f567148efe92a71349940c7244623247d33a8b78cbc9a53cd45bb22430f318a635084d1840c905f236c83000000000000000b8d44a0982b88abe19b724d4bdafba8c90dc93130e0bf4f8062810992326da126fd01db53e40250ca33a3ff302044cb0K_main = 0x571af2e9a0bf4b354cca18d713f8a84315a46c999ceb92ca6a88b8a6d615795140862dbccd6fdc0abecc5956c43f8ab40343a22fc1b91752cb7c2737dab9041eK_confirmP = 0x6c8c7fc6becf3bc07f081b4f7f867bec76fd8eeddbd7968356723bae701e04f35f800e647dfa013b2876958efe0ce68e7595ba46f1de0b17adfc02dfe3f18a18K_confirmV = 0x2d0c9702a0f5536bacddd596eb6ea365d17f176db30081b97b83e05bb87e9a36c0565b7616251c93bc76c76fc5c3531a28db40779d986d4e7b71a24c43fbc731HMAC(K_confirmP, shareV) = 0x7f806ae56ea3e49a8b16ffee528086489418913641f529d50ff92aa456ad4648e522f9540b403bff6bd94ee1adc95c7d1b2666f7ba6f9c10748bc7bfb4181d27HMAC(K_confirmV, shareP) = 0x8daa262decb79cceda4421f4f8dacf22ec027c08e036f071beea563c8e00813a29807963ff9d7d6bbff48dd5bdcdd9ca9fd7ffc272b162258d981913f7253dcbK_shared = 0x31e0075a823b9269af5769d71ef3b2f5001cbfe044584fe8551124a217dad078415630bf3eda16b5a38341d418a6d72b3960f818a0926f0de88784b59d6a694b
[Context=b'SPAKE2+-P521-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors'][idProver=b'client'][idVerifier=b'server']w0 = 0x009c79bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863f60b5aeb3c101731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72f5fw1 = 0x01632c15f51fcd916cd79e19075f8a69b72b0099922ad62ff8d540b469569f0aa027047aed2b3f242ea0ac4288b4e4db6a4e5946d8ad32b42192c5aa66d9ef8e1b33L = 0x040135072d0fa36f9e80031294cef5c3c35b882a0efa2c66570d64a49f8bec6c66435bf65bb7c7b2a3e7dece491e02b4d567e7087dbc32fe0fae8af417dcb50be6d704012a194588b690e6d3db492656f72ddea01fc1c7fcec0f5d34a5af0102939f6fdeae39c20cff74fcdb7f09855f0fc9520d20b0520b0b096b8d42c7c3d68b4a66f751x = 0x00b69e3bb15df82c9fa0057461334e2c66ab92fc9b8d3662eec81216ef5ddc4a43f19e90dedaa2d72502f69673a115984ffcf88e03a9364b07102114c5602cd93c69shareP = 0x0400a14431edf6852ff5fe868f8683e16e9e0a45d9e27f9a96442285ac6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812df00a91dbae09e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b2eb889d09d9f11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b39b9fbfc7b37a60aby = 0x0056d01c5246fbde964c0493934b7ece89eafd943eb27d357880a2a22022499e249528c5707b1afe8794c8a1d60ceedaeed96dd0dd904ea075f096c9fec5da7de496shareV = 0x0401aa5af0f3027f63b7170572db5ff06dd1f3d6ea8ea771b26b434fbbc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e95037a85ed7598e415a259126365e89500d0f2156b551b70416d719944736990f346f6f9ba4fbaf2f63e09873690bcf730582e0a7b03ffede50f5787b631d5021a94287f0a29a081b62b9f5a3bf393b001b3Z = 0x0401e3015bf2811891a518d342c63541294dc80e0ee210e8220a5b9cab010d77945724ef1185d739a62847fdada9da9b1bca6b9fa173fa551185c6084c3db26d3af0ac01f9356d01beebebd5ff026ca19f9df5d614355f3498816ac20b63bc936eed828a7039d1e17dba740471d9afc0e0b4427d65b2d27a57a87e42300004e2b4620c23c9V = 0x0401058b21ca71e4439281579d6df3b86ae874d70742fe8eae2de60e77e07e6e1c31b9c277de36b38531f5b769e9e4030ba09258f510c83c5c21957610355ce9201fe600672db35efd1d0903bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a749f560e31b9c404624d24e68010f064101d4a1154e77be8f2105dbeb8b0349adb0eTT = 0x38000000000000005350414b45322b2d503532312d5348413531322d484b44462d5348413531322d484d41432d534841353132205465737420566563746f72730600000000000000636c69656e740600000000000000736572766572850000000000000004003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa01bdd179a3d547610892e9b96dea1eab10bdd7ac5ae0cf75aa0f853bfd185cf782f894301998b11d1898ede2701dca37a2bb50b4f519c3d89a7d054b51fb8491219285000000000000000400c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd2501c62bee650c9287a651bb75c7f39a2006873347b769840d261d17760b107e29f091d556a82a2e4cde0c40b84b95b878db2489ef760206424b3fe7968aa8e0b1f33485000000000000000400a14431edf6852ff5fe868f8683e16e9e0a45d9e27f9a96442285ac6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812df00a91dbae09e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b2eb889d09d9f11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b39b9fbfc7b37a60ab85000000000000000401aa5af0f3027f63b7170572db5ff06dd1f3d6ea8ea771b26b434fbbc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e95037a85ed7598e415a259126365e89500d0f2156b551b70416d719944736990f346f6f9ba4fbaf2f63e09873690bcf730582e0a7b03ffede50f5787b631d5021a94287f0a29a081b62b9f5a3bf393b001b385000000000000000401e3015bf2811891a518d342c63541294dc80e0ee210e8220a5b9cab010d77945724ef1185d739a62847fdada9da9b1bca6b9fa173fa551185c6084c3db26d3af0ac01f9356d01beebebd5ff026ca19f9df5d614355f3498816ac20b63bc936eed828a7039d1e17dba740471d9afc0e0b4427d65b2d27a57a87e42300004e2b4620c23c985000000000000000401058b21ca71e4439281579d6df3b86ae874d70742fe8eae2de60e77e07e6e1c31b9c277de36b38531f5b769e9e4030ba09258f510c83c5c21957610355ce9201fe600672db35efd1d0903bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a749f560e31b9c404624d24e68010f064101d4a1154e77be8f2105dbeb8b0349adb0e4200000000000000009c79bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863f60b5aeb3c101731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72f5fK_main = 0xf672a73216568d20cc3433247bc43a3b875a421cbdba76cf1db8bfe572b658bf3f7a4ef8cc9ff1f6a2827ff7b19860454b775a4097009040f3b36b742040716eK_confirmP = 0xa211c60ea8d4b3b294bd6ca9515663b77f3caac28af3658b34fe1512f25077f2f64b8de426caa662b4cbbdc9c2f8f12347993c8d57fdf68c177732d7dda7277bK_confirmV = 0x0e9bf6b9a37339144cb32a78a872f50b10839f81eda6c09a827ddbb158c47162bec274af920cdf809f162b98fa701efebada26cdfbeac408b5a35b052d18f0c6HMAC(K_confirmP, shareV) = 0xf0f5c903dfa42fe367659656a26058cd984b76a8e91ae4d0fa4c13db149008e2ae57713fb230a627761174fefd263b9c10e9a4b6a3746cde59c5943040c17133HMAC(K_confirmV, shareP) = 0xa8f7ab43f3a800171d3a3fb26d742e1ed236c2d5804ecd328f220a7d245cd2e3bfb6c0526983bff9229c94f70fe64ba9bb5a4d0dc10afcda64a4c96d4c3d81adK_shared = 0xd1c170e4e55efacb9db8abad286293ebd1dcf24f13973427b9632bbc323e42e447afca2aa7f74f2af3fb5f51684ec543db854b7002cde6799c330b032ba8820a
[Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-CMAC-AES-128 Test Vectors'][idProver=b'client'][idVerifier=b'server']w0 = 0x9aad90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47ed61w1 = 0x872be859cec1e78d191882bd9c2f032af018a25016813788fe8954bfffc58c8eL = 0x04d79a53698c5dd79e14b426e73b4a7f1b42469815fe24e8f53ce01579e902eb198d59f05bc451c41826b88e3db5476a69e197fdf474c75b387f6d40361c3fda35x = 0x9d39a3511a007a7d3fe6af5555cf60301bcda503f2bf6634b2caf9e4fd0743a1shareP = 0x04788218027ba4b17f7279ef0aef47a8733cf88b5bf65d6127ecadc78b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2082362b6c2ca14a8e53y = 0x9c3219841626325c68d89c22fb6c55611e3136442daa8b9b784db7242afff3edshareV = 0x04c05953ea9d1cd6248b8c61becd7d55e46237526d8b1e23495ea7566b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509b1cfdd1ef8f8195fa8bf2bd5ca1e5Z = 0x049444a17ad5909548a084fa182275a89a496ec6669bd08892aa9c64a512d40212147e6005bf1d510e3bbcfee8efc38243acaf4c5f2decffa009341b1e330b0442V = 0x0457a8919af393e2da1de209a01fdda275eab0a682d8931b0e6ee1b933979463a25ccbcda1956a6a555706f0b062aa880617bd219d09391ad8576d3a73e9233f57TT = 0x39000000000000005350414b45322b2d503235362d5348413235362d484b44462d5348413235362d434d41432d4145532d313238205465737420566563746f72730600000000000000636c69656e740600000000000000736572766572410000000000000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e656edbe7410000000000000004788218027ba4b17f7279ef0aef47a8733cf88b5bf65d6127ecadc78b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2082362b6c2ca14a8e53410000000000000004c05953ea9d1cd6248b8c61becd7d55e46237526d8b1e23495ea7566b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509b1cfdd1ef8f8195fa8bf2bd5ca1e54100000000000000049444a17ad5909548a084fa182275a89a496ec6669bd08892aa9c64a512d40212147e6005bf1d510e3bbcfee8efc38243acaf4c5f2decffa009341b1e330b044241000000000000000457a8919af393e2da1de209a01fdda275eab0a682d8931b0e6ee1b933979463a25ccbcda1956a6a555706f0b062aa880617bd219d09391ad8576d3a73e9233f5720000000000000009aad90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47ed61K_main = 0x6002da6b2740056f2836ac0316ae9e02e2b24c5c109883136e90ed868b2fcf62K_confirmP = 0x857d0db7f5e06385853bf4b8abd43b5aK_confirmV = 0x268c75933332157118063550c6bfe846CMAC(K_confirmP, shareV) = 0xd340bc94a03feafd14491e316514ca5fCMAC(K_confirmV, shareP) = 0x2b42d0fe76bcf9ccc208d06d60082f96K_shared = 0xe832094adfc028bf288e49ab902fc208b7eeff084f259da7613c0479869d4fc9
[Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-CMAC-AES-128 Test Vectors'][idProver=b'client'][idVerifier=b'server']w0 = 0x56e0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50eb90w1 = 0x462fe5b522a17d3d35b27323113bdd252de9cbfdd6f264b35721bf59a9a74f0bL = 0x040540332ffec8a2faa8d17ae6da5973c11e078b8c10c89fd6af996726b8023513eff2914c3ced64fbedd4e261438fb0ea6ef9fc1faef4ba1ead780636faac1bc1x = 0x254dd22780eeb6af2464dd6a2bd026b46a34966d6933607f1be956314f74b0eashareP = 0x049661cfdb0f7bd24b637f8d1d0f464c17f0b9c15129ea31156dcc581da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036eb2dedaf26e511a24a48y = 0x695beec24305fbd5660bc200228598e7c891fdf60a55df4bdd3a57debc38474ashareV = 0x0461f580eb3eb4b2f412d5c07491f360ad6e4492d8f23e346f0ba999fbbcb9715a3c2485c3b250a6672e6698da3c9a9725645f607ee90a9b1b34fd44b9df6e551aZ = 0x0406f77a4bca254219dc3eeca9989f377037407105540bfddc5bdeff3d27a87d68442e69d543a000077bd4c42e33930f890d29fb4be5e8dcc627f6811ace96c274V = 0x0442952a531a2937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b146f5c2249e727e374de03f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133dTT = 0x39000000000000005350414b45322b2d503235362d5348413531322d484b44462d5348413531322d434d41432d4145532d313238205465737420566563746f72730600000000000000636c69656e740600000000000000736572766572410000000000000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e656edbe74100000000000000049661cfdb0f7bd24b637f8d1d0f464c17f0b9c15129ea31156dcc581da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036eb2dedaf26e511a24a4841000000000000000461f580eb3eb4b2f412d5c07491f360ad6e4492d8f23e346f0ba999fbbcb9715a3c2485c3b250a6672e6698da3c9a9725645f607ee90a9b1b34fd44b9df6e551a41000000000000000406f77a4bca254219dc3eeca9989f377037407105540bfddc5bdeff3d27a87d68442e69d543a000077bd4c42e33930f890d29fb4be5e8dcc627f6811ace96c27441000000000000000442952a531a2937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b146f5c2249e727e374de03f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133d200000000000000056e0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50eb90K_main = 0x111790ae23de3fc5bb43bdc1f63106461dbd8d86360adf056bf1171648bfb231503853db2625275b7136b5a823dd5a94482514fce7f791c4daca2b21c7bde756K_confirmP = 0xb234d2e152a03168b76c6474d5322070K_confirmV = 0x683d62024626fe0c5126ef4df58b88eeCMAC(K_confirmP, shareV) = 0x0dc514d262e37470eb43e058e0d615f4CMAC(K_confirmV, shareP) = 0xde076589efcd5d96c2ea6061d96772d9K_shared = 0x488a34663d6be5e02590bb8e9ad9ad3e0f580dec41e8b99ed4ae4b734da49287638cac4c9f17fe3c3ae18dda0d6d7f14c17e4640d5a2aaab959efa0cbea4e546

Acknowledgements

Thanks toBen Kaduk andWatson Ladd, from whom this specification originally emanated.

Authors' Addresses

Tim Taubert
Apple Inc.
One Apple Park Way
Cupertino,California95014
United States of America
Email:ttaubert@apple.com
Christopher A. Wood
Email:caw@heapingbits.net

[8]ページ先頭

©2009-2025 Movatter.jp