rfc9383.original   rfc9383.txt 
Network Working Group T. Taubert Independent Submission T. Taubert
Internet-Draft Apple Inc. Request for Comments: 9383 Apple Inc.
Intended status: Informational C. A. Wood Category: Informational C. A. Wood
Expires: 6 November 2022 5 May 2022 ISSN: 2070-1721 September 2023
SPAKE2+, an Augmented PAKE SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE)
draft-bar-cfrg-spake2plus-08 Protocol
Abstract Abstract
This document describes SPAKE2+, a Password Authenticated Key This document describes SPAKE2+, a Password-Authenticated Key
Exchange (PAKE) protocol run between two parties for deriving a Exchange (PAKE) protocol run between two parties for deriving a
strong shared key with no risk of disclosing the password. SPAKE2+ strong shared key with no risk of disclosing the password. SPAKE2+
is an augmented PAKE protocol, as only one party has knowledge of the is an augmented PAKE protocol, as only one party has knowledge of the
password. This method is simple to implement, compatible with any password. This method is simple to implement, compatible with any
prime order group and is computationally efficient. prime-order group, and computationally efficient.
This document was produced outside of the IETF and IRTF, and This document was produced outside of the IETF and IRTF and
represents the opinions of the authors. Publication of this document represents the opinions of the authors. Publication of this document
as an RFC in the Independent Submissions Stream does not imply as an RFC in the Independent Submissions Stream does not imply
endorsement of SPAKE2+ by the IETF or IRTF. endorsement of SPAKE2+ by the IETF or IRTF.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/chris-wood/draft-bar-cfrg-spake2plus.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 6 November 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9383.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation
3. Definition of SPAKE2+ . . . . . . . . . . . . . . . . . . . . 4 3. Definition of SPAKE2+
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Overview
3.2. Offline Registration . . . . . . . . . . . . . . . . . . 6 3.2. Offline Registration
3.3. Online Authentication . . . . . . . . . . . . . . . . . . 7 3.3. Online Authentication
3.4. Key Schedule and Key Confirmation . . . . . . . . . . . . 9 3.4. Key Schedule and Key Confirmation
4. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Ciphersuites
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Protocol Flow
Appendix A. Protocol Flow . . . . . . . . . . . . . . . . . . . 15 A.1. Prover
A.1. Prover . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.2. Verifier
A.2. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 16 A.3. Transcript Computation
A.3. Transcript Computation . . . . . . . . . . . . . . . . . 16 A.4. Key Schedule Computation
A.4. Key Schedule Computation . . . . . . . . . . . . . . . . 17 A.5. Protocol Run
A.5. Protocol Run . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Algorithm Used for Point Generation
Appendix B. Algorithm used for Point Generation . . . . . . . . 18 Appendix C. Test Vectors
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 20 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses
1. Introduction 1. Introduction
This document describes SPAKE2+, a Password Authenticated Key This document describes SPAKE2+, a Password-Authenticated Key
Exchange (PAKE) protocol run between two parties for deriving a Exchange (PAKE) protocol run between two parties for deriving a
strong shared key with no risk of disclosing the password. SPAKE2+ strong shared key with no risk of disclosing the password. SPAKE2+
is an augmented PAKE protocol, as only one party makes direct use of is an augmented PAKE protocol, as only one party makes direct use of
the password during the execution of the protocol. The other party the password during the execution of the protocol. The other party
only needs a record corresponding to the other party's registration only needs a record corresponding to the first party's registration
at the time of the protocol execution instead of the password. This at the time of the protocol execution instead of the password. This
record can be computed once, during an offline registration phase. record can be computed once, during an offline registration phase.
The party using the password directly would typically be a client, The party using the password directly would typically be a client and
and acts as a prover, while the other party would be a server, and would act as a Prover, while the other party would be a server and
acts as verifier. would act as a Verifier.
The protocol is augmented in the sense that it provides some The protocol is augmented in the sense that it provides some
resilience to the compromise or extraction of the registration resilience against the compromise or extraction of the registration
record. The design of the protocol forces the adversary to recover record. The design of the protocol forces the adversary to recover
the password from the record to successfully execute the protocol. the password from the record to successfully execute the protocol.
Hence this protocol can be advantageously combined with a salted Hence, this protocol can be advantageously combined with a salted
Password Hashing Function to increase the cost of the recovery and Password Hashing Function to increase the cost of the recovery and
slow down attacks. The record cannot be used directly to slow down attacks. The record cannot be used directly to
successfully run the protocol as a prover, making this protocol more successfully run the protocol as a Prover, making this protocol more
robust than balanced PAKEs which don't benefit from Password Hashing robust than balanced PAKEs, which don't benefit from Password Hashing
Functions to the same extent. Functions to the same extent.
This augmented property is especially valuable in scenarios where the This augmented property is especially valuable in scenarios where the
execution of the protocol is constrained and the adversary cannot execution of the protocol is constrained and the adversary cannot
query the salt of the password hash function ahead of the attack. query the salt of the Password Hashing Function ahead of the attack.
Constraints may consist in being in physical proximity through a For example, a constraint may be when physical proximity through a
local network or when initiation of the protocol requires a first local network is required or when a first authentication factor is
authentication factor. required for initiation of the protocol.
This document has content split out from a related document This document has content split out from a related document,
specifying SPAKE2 [I-D.irtf-cfrg-spake2], which is a symmetric PAKE [RFC9382], which specifies SPAKE2. SPAKE2 is a symmetric PAKE
protocol, where both parties have knowledge of the password. SPAKE2+ protocol, where both parties have knowledge of the password. SPAKE2+
is the asymmetric or augmented version of SPAKE2, wherein only one is the asymmetric or augmented version of SPAKE2, wherein only one
party has knowledge of the password. SPAKE2+ is specified separately party has knowledge of the password. SPAKE2+ is specified separately
in this document because the use cases for symmetric and augmented in this document because the use cases for symmetric and augmented
PAKEs are different, and therefore warrant different technical PAKEs are different and therefore warrant different technical
specifications. Neither SPAKE2 nor SPAKE2+ was selected as the specifications. Neither SPAKE2 nor SPAKE2+ was selected as the
result of the CFRG PAKE selection competition. However, this result of the Crypto Forum Research Group (CFRG) PAKE selection
password-based key exchange protocol appears in [TDH] and is proven competition. However, this password-based key exchange protocol
secure in [SPAKE2P-Analysis]. It is compatible with any prime-order appears in [TDH] and is proven secure in [SPAKE2P-Analysis]. It is
group and relies only on group operations, making it simple and compatible with any prime-order group and relies only on group
computationally efficient. Thus, it was felt that publication was operations, making it simple and computationally efficient. Thus, it
beneficial to make the protocol available for wider consideration. 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 This document was produced outside of the IETF and IRTF and
represents the opinions of the authors. Publication of this document represents the opinions of the authors. Publication of this document
as an RFC in the Independent Submissions Stream does not imply as an RFC in the Independent Submissions Stream does not imply
endorsement of SPAKE2+ by the IETF or IRTF. endorsement of SPAKE2+ by the IETF or IRTF.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definition of SPAKE2+ 3. Definition of SPAKE2+
Let G be a group in which the computational Diffie-Hellman (CDH) 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 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., 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 the point at infinity if G is an elliptic curve group. We denote the
operations in the group additively. We assume there is a operations in the group additively. We assume that there is a
representation of elements of G as byte strings: common choices would representation of elements of G as byte strings: common choices would
be SEC1 uncompressed or compressed [SEC1] for elliptic curve groups be SEC 1 uncompressed or compressed [SEC1] for elliptic curve groups
or big endian integers of a fixed (per-group) length for prime field or big-endian integers of a fixed (per-group) length for prime field
DH. We fix a generate P of (large) prime-order subgroup of G. P is DH. We fix a generator P of the (large) prime-order subgroup of G.
specified in the document defining the group, and so we do not repeat P is specified in the document defining the group, and so we do not
it here. repeat it here.
|| denotes concatenation of strings. We also let len(S) denote the || denotes concatenation of strings. We also let len(S) denote the
length of a string in bytes, represented as an eight-byte little length of a string in bytes, represented as an eight-byte little-
endian number. Finally, let nil represent an empty string, i.e., endian number. Finally, let nil represent an empty string, i.e.,
len(nil) = 0. len(nil) = 0.
KDF is a key-derivation function that takes as input a salt, KDF is a key derivation function that takes as input a salt, input
intermediate keying material (IKM), info string, and derived key keying material (IKM), info string, and derived key length L to
length L to derive a cryptographic key of length L. MAC is a Message derive a cryptographic key of length L. MAC is a Message
Authentication Code algorithm that takes a secret key and message as Authentication Code algorithm that takes a secret key and message as
input to produce an output. Let Hash be a hash function from input to produce an output. Let Hash be a hash function from
arbitrary strings to bit strings of a fixed length. Common choices arbitrary strings to bit strings of a fixed length. Common choices
for Hash are SHA256 or SHA512 [RFC6234]. Section 4 specifies for Hash are SHA256 or SHA512 [RFC6234]. Section 4 specifies
variants of KDF, MAC, and Hash suitable for use with the protocols variants of KDF, MAC, and Hash suitable for use with the protocols
contained herein. contained herein.
Let there be two parties, a prover and a verifier. Their identities, Let there be two parties, a Prover and a Verifier. Their identities,
denoted as idProver and idVerifier, may also have digital denoted as idProver and idVerifier, may also have digital
representations such as Media Access Control addresses or other names representations such as Media Access Control addresses or other names
(hostnames, usernames, etc). The parties may share additional data (hostnames, usernames, etc.). The parties may share additional data
(the context) separate from their identities which they may want to (the context) separate from their identities, which they may want to
include in the protocol transcript. One example of additional data include in the protocol transcript. One example of additional data
is a list of supported protocol versions if SPAKE2+ were used in a is a list of supported protocol versions if SPAKE2+ were used in a
higher-level protocol which negotiates the use of a particular PAKE. higher-level protocol that negotiates the use of a particular PAKE.
Another example is the inclusion of the application name. Including Another example is the inclusion of the application name. Including
those would ensure that both parties agree upon the same set of these data points would ensure that both parties agree upon the same
supported protocols and therefore prevent downgrade and cross- set of supported protocols and therefore prevents downgrade and
protocol attacks. Specification of precise context values is out of cross-protocol attacks. Specification of precise context values is
scope for this document. out of scope for this document.
3.1. Protocol Overview 3.1. Protocol Overview
SPAKE2+ is a two round protocol that establishes a shared secret with SPAKE2+ is a two-round protocol that establishes a shared secret with
an additional round for key confirmation. Prior to invocation, both an additional round for key confirmation. Prior to invocation, both
parties are provisioned with information such as the input password parties are provisioned with information such as the input password
needed to run the protocol. The registration phase may include needed to run the protocol. The registration phase may include
communicating identities, protocol version and other parameters communicating identities, protocol version, and other parameters
related to the registration record; see Section 3.2 for details. related to the registration record; see Section 3.2 for details.
During the first round, the prover sends a public share shareP to the During the first round, the Prover sends a public share, shareP, to
verifier, which in turn responds with its own public share shareV. the Verifier, which in turn responds with its own public share,
Both parties then derive a shared secret used to produce encryption shareV. Both parties then derive a shared secret used to produce
and authentication keys. The latter are used during the second round encryption and authentication keys. The latter are used during the
for key confirmation. (Section 3.4 details the key derivation and second round for key confirmation. (Section 3.4 details the key
confirmation steps.) In particular, the verifier sends a key derivation and confirmation steps.) In particular, the Verifier
confirmation message confirmV to the prover, which in turn responds sends a key confirmation message, confirmV, to the Prover, which in
with its own key confirmation message confirmP. (Note that shareV turn responds with its own key confirmation message, confirmP. (Note
and confirmV MAY be sent in the same message.) Both parties MUST NOT that shareV and confirmV MAY be sent in the same message.) Both
consider the protocol complete prior to receipt and validation of parties MUST NOT consider the protocol complete prior to receipt and
these key confirmation messages. validation of these key confirmation messages.
A sample trace is shown below. A sample trace is shown below.
Prover Verifier Prover Verifier
| (registration) | | (registration) |
|<- - - - - - - - - - - - ->| |<- - - - - - - - - - - - ->|
| | | |
| (setup protocol) | | (set up the protocol) |
(compute shareP) | shareP | (compute shareP) | shareP |
|-------------------------->| |-------------------------->|
| shareV | (compute shareV) | shareV | (compute shareV)
|<--------------------------| |<--------------------------|
| | | |
| (derive secrets) | (compute confirmV) | (derive secrets) | (compute confirmV)
| confirmV | | confirmV |
|<--------------------------| |<--------------------------|
(compute confirmP) | confirmP | (compute confirmP) | confirmP |
|-------------------------->| |-------------------------->|
3.2. Offline Registration 3.2. Offline Registration
The registration phase computes the values w0 and w1, as well as the 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 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 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 record L are then shared with the Verifier and stored as part of the
registration record associated with the prover. The prover SHOULD registration record associated with the Prover. The Prover SHOULD
derive w0 and w1 from the password before the protocol begins. Both 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 w0 and w1 are derived using a function with range [0, p-1], which is
modeled as a random oracle in [SPAKE2P-Analysis]. modeled as a random oracle in [SPAKE2P-Analysis].
The registration phase also produces two random elements M and N in 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 the prime-order subgroup of G. The algorithm for selecting M and N
is defined in Appendix B. Importantly, this algorithm chooses M and is defined in Appendix B. Importantly, this algorithm chooses M and
N such that their discrete logs are not known. Pre-computed values 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 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 use different M and N values, provided they are computed, e.g., using
different input seeds to the algorithm in Appendix B, as random different input seeds to the algorithm in Appendix B, as random
elements for which the discrete log is unknown. elements for which the discrete log is unknown.
Applications using this specification MUST define the method used to Applications using this specification MUST define the method used to
compute w0 and w1. For example, it may be necessary to carry out compute w0 and w1. For example, it may be necessary to carry out
various forms of normalization of the password before hashing various forms of normalization of the password before hashing
[RFC8265]. This section contains requirements and default [RFC8265]. This section contains requirements and default
recommendations for computing w0 and w1. recommendations for computing w0 and w1.
The RECOMMENDED method for generating w0 and w1 is via a Password- The RECOMMENDED method for generating w0 and w1 is via a Password-
Based Key Derivation Function (PBKDF), which is a function designed Based Key Derivation Function (PBKDF), which is a function designed
to slow down brute-force attackers. Brute-force resistance may be to slow down brute-force attackers. Brute-force resistance may be
obtained through various computation hardness parameters such as obtained through various computation hardness parameters such as
memory or CPU cycles, and are typically configurable. Scrypt memory or CPU cycles and are typically configurable. The scrypt
[RFC7914] function and the Argon2id [RFC9106] function are common
[RFC7914] and Argon2id [RFC9106] are common examples of PBKDFs. examples of PBKDFs. Absent an application-specific profile,
Absent an application-specific profile, RECOMMENDED parameters (N, r, RECOMMENDED parameters (N, r, p) for scrypt are (32768,8,1), and
p) for Scrypt are (32768,8,1), and RECOMMENDED parameters for RECOMMENDED parameters for Argon2id are in Section 4 of [RFC9106].
Argon2id are in Section 4 of [RFC9106].
Each half of the output of the PBKDF will be interpreted as an 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 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 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 integers mod p gives bias at most 2^-k for any p; this bias is
negligible for any k >= 64. negligible for any k >= 64.
The minimum total output length of the PBKDF then is 2 * The minimum total output length of the PBKDF then is 2 *
(ceil(log2(p)) + k) bits. For example, given the prime order of the (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 P-256 curve, the output of the PBKDF SHOULD be at least 640 bits or
skipping to change at page 7, line 31 skipping to change at line 279
Given a PBKDF, password pw, and identities idProver and idVerifier, Given a PBKDF, password pw, and identities idProver and idVerifier,
the RECOMMENDED method for computing w0 and w1 is as follows: the RECOMMENDED method for computing w0 and w1 is as follows:
w0s || w1s = PBKDF(len(pw) || pw || w0s || w1s = PBKDF(len(pw) || pw ||
len(idProver) || idProver || len(idProver) || idProver ||
len(idVerifier) || idVerifier) len(idVerifier) || idVerifier)
w0 = w0s mod p w0 = w0s mod p
w1 = w1s mod p w1 = w1s mod p
If an identity is unknown at the time of computing w0s or w1s, its 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 the length is given as zero and the identity itself is represented as an
empty octet string. If both idProver and idVerifier are unknown, empty octet string. If both idProver and idVerifier are unknown,
then their lengths are given as zero and both identities will be then their lengths are given as zero and both identities will be
represented as empty octet strings. idProver and idVerifier are represented as empty octet strings. idProver and idVerifier are
included in the transcript TT as part of the protocol flow. included in the transcript TT as part of the protocol flow.
3.3. Online Authentication 3.3. Online Authentication
The online SPAKE2+ protocol runs between the prover and verifier to The online SPAKE2+ protocol runs between the Prover and Verifier to
produce a single shared secret upon completion. To begin, the prover produce a single shared secret upon completion. To begin, the Prover
selects x uniformly at random from the integers in [0, p-1], computes selects x uniformly at random from the integers in [0, p-1], computes
the public share shareP=X, and transmits it to the verifier. the public share shareP=X, and transmits it to the Verifier.
x <- [0, p-1] x <- [0, p-1]
X = x*P + w0*M X = x*P + w0*M
Upon receipt of X, the verifier checks the received element for group
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 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 of G; see Section 6 for details. The Verifier then selects y
uniformly at random from the integers in [0, p-1], computes the uniformly at random from the integers in [0, p-1], computes the
public share shareV=Y and transmits it to the prover. Upon receipt public share shareV=Y, and transmits it to the Prover. Upon receipt
of Y, the prover checks the received element for group membership and 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. aborts if Y is not in the large prime-order subgroup of G.
y <- [0, p-1] y <- [0, p-1]
Y = y*P + w0*N Y = y*P + w0*N
Both participants compute Z and V that are now shared as common Both participants compute Z and V; Z and V are then shared as common
values. The prover computes: values. The Prover computes:
Z = h*x*(Y - w0*N) Z = h*x*(Y - w0*N)
V = h*w1*(Y - w0*N) V = h*w1*(Y - w0*N)
The verifier computes: The Verifier computes:
Z = h*y*(X - w0*M) Z = h*y*(X - w0*M)
V = h*y*L V = h*y*L
The multiplication by the cofactor h prevents small subgroup The multiplication by the cofactor h prevents small subgroup
confinement attacks. All proofs of security hold even if the confinement attacks. All proofs of security hold even if the
discrete log of the fixed group element N is known to the adversary. 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. 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 It is essential that both Z and V be used in combination with the
transcript to derive the keying material. The protocol transcript transcript to derive the keying material. The protocol transcript
encoding is shown below. encoding is shown below.
TT = len(Context) || Context TT = len(Context) || Context
|| len(idProver) || idProver || len(idProver) || idProver
|| len(idVerifier) || idVerifier || len(idVerifier) || idVerifier
|| len(M) || M || len(M) || M
|| len(N) || N || len(N) || N
skipping to change at page 9, line 14 skipping to change at line 346
Context is an application-specific customization string shared Context is an application-specific customization string shared
between both parties and MUST precede the remaining transcript. It between both parties and MUST precede the remaining transcript. It
might contain the name and version number of the higher-level might contain the name and version number of the higher-level
protocol, or simply the name and version number of the application. protocol, or simply the name and version number of the application.
The context MAY include additional data such as the chosen The context MAY include additional data such as the chosen
ciphersuite and PBKDF parameters like the iteration count or salt. ciphersuite and PBKDF parameters like the iteration count or salt.
The context and its length prefix MAY be omitted. The context and its length prefix MAY be omitted.
If an identity is absent, its length is given as zero and the If an identity is absent, its length is given as zero and the
identity itself is represented as the empty octet string. If both identity itself is represented as an empty octet string. If both
identities are absent, then their lengths are given as zero and both identities are absent, then their lengths are given as zero and both
are represented as empty octet strings. In applications where are represented as empty octet strings. In applications where
identities are not implicit, idProver and idVerifier SHOULD always be identities are not implicit, idProver and idVerifier SHOULD always be
non-empty. Otherwise, the protocol risks Unknown Key Share attacks non-empty. Otherwise, the protocol risks unknown key-share attacks
(discussion of Unknown Key Share attacks in a specific protocol is (discussion of unknown key-share attacks in a specific protocol is
given in [RFC8844]). given in [RFC8844]).
Upon completion of this protocol, both parties compute shared secrets Upon completion of this protocol, both parties compute shared secrets
K_main, K_shared, K_confirmP, and K_confirmV as specified in K_main, K_shared, K_confirmP, and K_confirmV as specified in
Section 3.4. The verifier MUST send a key confirmation message Section 3.4. The Verifier MUST send a key confirmation message,
confirmV to the prover so both parties can confirm that they agree confirmV, to the Prover so both parties can confirm that they agree
upon these shared secrets. After receipt and verification of the upon these shared secrets. After receipt and verification of the
verifier's confirmation message, the prover MUST respond with its Verifier's confirmation message, the Prover MUST respond with its
confirmation message. The verifier MUST NOT send application data to confirmation message. The Verifier MUST NOT send application data to
the prover until it has received and verified the confirmation the Prover until it has received and verified the confirmation
message. Key confirmation verification requires recomputation of message. Key confirmation verification requires recomputation of
confirmP or confirmV and checking for equality against that which was confirmP or confirmV and checking for equality against the data that
received. was received.
3.4. Key Schedule and Key Confirmation 3.4. Key Schedule and Key Confirmation
The protocol transcript TT, as defined in Section 3.3, is unique and 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 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 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() = 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 SHA-256. The confirmation keys K_confirmP and K_confirmV, as well as
the shared key K_shared are derived from K_main. the shared key K_shared, are derived from K_main.
K_main = Hash(TT) K_main = Hash(TT)
K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys") K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys")
K_shared = KDF(nil, K_main, "SharedKey") K_shared = KDF(nil, K_main, "SharedKey")
Neither K_main nor its derived confirmation keys are used for Neither K_main nor its derived confirmation keys are used for
anything except key derivation and confirmation and MUST be discarded anything except key derivation and confirmation and MUST be discarded
after the protocol execution. Applications MAY derive additional after the protocol execution. Applications MAY derive additional
keys from K_shared as needed. keys from K_shared as needed.
skipping to change at page 10, line 22 skipping to change at line 401
Both endpoints MUST employ a MAC that produces pseudorandom tags for Both endpoints MUST employ a MAC that produces pseudorandom tags for
key confirmation. K_confirmP and K_confirmV are symmetric keys used key confirmation. K_confirmP and K_confirmV are symmetric keys used
to compute tags confirmP and confirmV over the public key shares to compute tags confirmP and confirmV over the public key shares
received from the other peer earlier. received from the other peer earlier.
confirmP = MAC(K_confirmP, shareV) confirmP = MAC(K_confirmP, shareV)
confirmV = MAC(K_confirmV, shareP) confirmV = MAC(K_confirmV, shareP)
Once key confirmation is complete, applications MAY use K_shared as Once key confirmation is complete, applications MAY use K_shared as
an authenticated shared secret as needed. For example, applications an authenticated shared secret as needed. For example, applications
MAY derive one or more AEAD keys and nonces from K_shared for MAY derive one or more keys and nonces from K_shared, for use with
subsequent application data encryption. Authenticated Encryption with Associated Data (AEAD) and subsequent
application data encryption.
4. Ciphersuites 4. Ciphersuites
This section documents SPAKE2+ ciphersuite configurations. A This section documents SPAKE2+ ciphersuite configurations. A
ciphersuite indicates a group, cryptographic hash algorithm, and pair ciphersuite indicates a group, cryptographic hash algorithm, and pair
of KDF and MAC functions, e.g., P256-SHA256-HKDF-HMAC-SHA256. This of KDF and MAC functions, e.g., P256-SHA256-HKDF-HMAC-SHA256. This
ciphersuite indicates a SPAKE2+ protocol instance over P-256 that ciphersuite indicates a SPAKE2+ protocol instance over P-256 that
uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash, uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash,
KDF, and MAC functions, respectively. Since the choice of PBKDF and KDF, and MAC functions, respectively. Since the choice of PBKDF, its
its parameters for computing w0 and w1 and distributing does not parameters for computing w0 and w1, and the distribution of w0 and w1
affect interoperability, the PBKDF is not included as part of the do not affect interoperability, the PBKDF is not included as part of
ciphersuite. the ciphersuite.
If no MAC algorithm is used in the key confirmation phase, its If no MAC algorithm is used in the key confirmation phase, its
respective column in Table 1 can be ignored and the ciphersuite name respective column in Table 1 can be ignored and the ciphersuite name
will contain no MAC identifier. will contain no MAC identifier.
+==============+==================+=============+==============+ +==============+==================+=============+==============+
| G | Hash | KDF | MAC | | G | Hash | KDF | MAC |
+==============+==================+=============+==============+ +==============+==================+=============+==============+
| P-256 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 | | P-256 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 |
| | | [RFC5869] | [RFC2104] | | | | [RFC5869] | [RFC2104] |
skipping to change at page 11, line 40 skipping to change at line 456
| | | [RFC5869] | [RFC4493] | | | | [RFC5869] | [RFC4493] |
+--------------+------------------+-------------+--------------+ +--------------+------------------+-------------+--------------+
| P-256 | SHA512 [RFC6234] | HKDF-SHA512 | CMAC-AES-128 | | P-256 | SHA512 [RFC6234] | HKDF-SHA512 | CMAC-AES-128 |
| | | [RFC5869] | [RFC4493] | | | | [RFC5869] | [RFC4493] |
+--------------+------------------+-------------+--------------+ +--------------+------------------+-------------+--------------+
Table 1 Table 1
The following points represent permissible point generation seeds for The following points represent permissible point generation seeds for
the groups listed in Table 1, using the algorithm presented in the groups listed in Table 1, using the algorithm presented in
Appendix B. These bytestrings are compressed points as in [SEC1] for Appendix B. These byte strings are compressed points as in [SEC1]
curves from [SEC1] and [RFC8032]. Note that these values are for curves from [SEC1] and [RFC8032]. Note that these values are
identical to those used in the companion SPAKE2 specification identical to those used in the companion SPAKE2 specification
[I-D.irtf-cfrg-spake2]. [RFC9382].
For P256: For P-256:
M = M =
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
seed: 1.2.840.10045.3.1.7 point generation seed (M) seed: 1.2.840.10045.3.1.7 point generation seed (M)
N = N =
03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
seed: 1.2.840.10045.3.1.7 point generation seed (N) seed: 1.2.840.10045.3.1.7 point generation seed (N)
For P384: For P-384:
M = M =
030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc
36f15314739074d2eb8613fceec2853 36f15314739074d2eb8613fceec2853
seed: 1.3.132.0.34 point generation seed (M) seed: 1.3.132.0.34 point generation seed (M)
N = N =
02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb
252c5490214cf9aa3f0baab4b665c10 252c5490214cf9aa3f0baab4b665c10
seed: 1.3.132.0.34 point generation seed (N) seed: 1.3.132.0.34 point generation seed (N)
For P521: For P-521:
M = M =
02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608
cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa
seed: 1.3.132.0.35 point generation seed (M) seed: 1.3.132.0.35 point generation seed (M)
N = N =
0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25
32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25 32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25
seed: 1.3.132.0.35 point generation seed (N) seed: 1.3.132.0.35 point generation seed (N)
skipping to change at page 13, line 17 skipping to change at line 519
942f5a92646109152292464f3e63d354701c7848d9fc3b8880 942f5a92646109152292464f3e63d354701c7848d9fc3b8880
seed: edwards448 point generation seed (M) seed: edwards448 point generation seed (M)
N = N =
6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db 6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db
f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600 f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600
seed: edwards448 point generation seed (N) seed: edwards448 point generation seed (N)
5. IANA Considerations 5. IANA Considerations
No IANA action is required. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
SPAKE2+ appears in [TDH] and is proven secure in [SPAKE2P-Analysis]. SPAKE2+ appears in [TDH] and is proven secure in [SPAKE2P-Analysis].
The ephemeral randomness used by the prover and verifier MUST be The ephemeral randomness used by the Prover and Verifier MUST be
generated using a cryptographically secure PRNG. generated using a cryptographically secure Pseudorandom Number
Generator (PRNG).
Elements received from a peer MUST be checked for group membership: Elements received from a peer MUST be checked for group membership:
failure to properly deserialize and validate group elements can lead failure to properly deserialize and validate group elements can lead
to attacks. An endpoint MUST abort the protocol if any received 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. 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 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 identity element I whenever V is an element of a small-order
subgroup. Consequently, prover and verifier MUST abort the protocol subgroup. Consequently, the Prover and Verifier MUST abort the
upon of any received value V such that V*h = I. Failure to do so may protocol upon receiving any value V such that V*h = I. Failure to do
lead to subgroup confinement attacks. so may lead to subgroup confinement attacks.
7. Acknowledgements
Thanks to Ben Kaduk and Watson Ladd, from which this specification
originally emanated.
8. References
8.1. Normative References 7. References
[I-D.irtf-cfrg-spake2] 7.1. Normative References
Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", Work in Progress,
Internet-Draft, draft-irtf-cfrg-spake2-26, 8 February
2022, <https://datatracker.ietf.org/doc/html/draft-irtf-
cfrg-spake2-26>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/rfc/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/rfc/rfc4493>. 2006, <https://www.rfc-editor.org/info/rfc4493>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/rfc/rfc5480>. <https://www.rfc-editor.org/info/rfc5480>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/rfc/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 8265, Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017, DOI 10.17487/RFC8265, October 2017,
<https://www.rfc-editor.org/rfc/rfc8265>. <https://www.rfc-editor.org/info/rfc8265>.
[SEC1] "Elliptic Curve Cryptography, Standards for Efficient [RFC9382] Ladd, W., "SPAKE2, a Password-Authenticated Key Exchange",
Cryptography Group, ver. 2", 2009, RFC 9382, DOI 10.17487/RFC9382, September 2023,
<https://www.rfc-editor.org/info/rfc9382>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", version 2.0, May 2009,
<https://secg.org/sec1-v2.pdf>. <https://secg.org/sec1-v2.pdf>.
[SPAKE2P-Analysis] [SPAKE2P-Analysis]
"Security analysis of SPAKE2+", 2020, Shoup, V., "Security analysis of SPAKE2+", March 2020,
<https://eprint.iacr.org/2020/313.pdf>. <https://eprint.iacr.org/2020/313.pdf>.
[TDH] "The Twin-Diffie Hellman Problem and Applications", [TDH] Cash, D., Kiltz, E., and V. Shoup, "The Twin-Diffie
EUROCRYPT 2008, Volume 4965 of Lecture notes in Computer Hellman Problem and Applications", EUROCRYPT 2008, Lecture
Science, pages 127-145, Springer-Verlag, Berlin, Germany , Notes in Computer Science, Volume 4965, pages 127-145,
2008. Springer-Verlag, Berlin, Germany,
DOI 10.1007/978-3-540-78967-3_8, April 2008,
<https://doi.org/10.1007/978-3-540-78967-3_8>.
8.2. Informative References 7.2. Informative References
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <https://www.rfc-editor.org/rfc/rfc7914>. August 2016, <https://www.rfc-editor.org/info/rfc7914>.
[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
Uses of TLS with the Session Description Protocol (SDP)", Uses of TLS with the Session Description Protocol (SDP)",
RFC 8844, DOI 10.17487/RFC8844, January 2021, RFC 8844, DOI 10.17487/RFC8844, January 2021,
<https://www.rfc-editor.org/rfc/rfc8844>. <https://www.rfc-editor.org/info/rfc8844>.
[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "Argon2 Memory-Hard Function for Password Josefsson, "Argon2 Memory-Hard Function for Password
Hashing and Proof-of-Work Applications", RFC 9106, Hashing and Proof-of-Work Applications", RFC 9106,
DOI 10.17487/RFC9106, September 2021, DOI 10.17487/RFC9106, September 2021,
<https://www.rfc-editor.org/rfc/rfc9106>. <https://www.rfc-editor.org/info/rfc9106>.
Appendix A. Protocol Flow Appendix A. Protocol Flow
This section describes the flow of the SPAKE2+ protocol, including This section describes the flow of the SPAKE2+ protocol, including
computations and mandatory checks performed by the prover and computations and mandatory checks performed by the Prover and
verifier. The constants M, N, P, p, and h are defined by the chosen Verifier. The constants M, N, P, p, and h are defined by the chosen
ciphersuite. ciphersuite.
A.1. Prover A.1. Prover
The Prover's behavior consists of two functions, ProverInit and The Prover implements two functions, ProverInit and ProverFinish,
ProverFinish, which are described below. which are described below.
def ProverInit(w0): def ProverInit(w0):
// Compute prover key share // Compute Prover key share
x <- [0, p-1] x <- [0, p-1]
X = x*P + w0*M X = x*P + w0*M
return (x, X) return (x, X)
def ProverFinish(w0, w1, x, Y): def ProverFinish(w0, w1, x, Y):
if not_in_subgroup(Y): if not_in_subgroup(Y):
raise "invalid input" raise "invalid input"
// Compute shared values // Compute shared values
Z = h*x*(Y - w0*N) Z = h*x*(Y - w0*N)
V = h*w1*(Y - w0*N) V = h*w1*(Y - w0*N)
return (Y, Z, V) return (Y, Z, V)
A.2. Verifier A.2. Verifier
The Verifier's behavior consists of a single function, The Verifier implements a single function, VerifierFinish, which is
VerifierFinish, which is described below. described below.
def VerifierFinish(w0, L, X): def VerifierFinish(w0, L, X):
if not_in_subgroup(X): if not_in_subgroup(X):
raise "invalid input" raise "invalid input"
// Compute verifier key share // Compute Verifier key share
y <- [0, p-1] y <- [0, p-1]
Y = y*P + w0*N Y = y*P + w0*N
// Compute shared values // Compute shared values
Z = h*y*(X - w0*M) Z = h*y*(X - w0*M)
V = h*y*L V = h*y*L
return (Z, V) return (Z, V)
A.3. Transcript Computation A.3. Transcript Computation
Both Prover and Verifier share the same function to compute the Both the Prover and the Verifier share the same function to compute
protocol transcript, ComputeTranscript, which is described below. the protocol transcript, ComputeTranscript, which is described below.
def ComputeTranscript(Context, idProver, idVerifier, shareP, shareV, Z, V, w0): def ComputeTranscript(Context, idProver, idVerifier,
TT = len(Context) || Context shareP, shareV, Z, V, w0):
|| len(idProver) || idProver TT = len(Context) || Context
|| len(idVerifier) || idVerifier || len(idProver) || idProver
|| len(M) || M || len(idVerifier) || idVerifier
|| len(N) || N || len(M) || M
|| len(shareP) || shareP || len(N) || N
|| len(shareV) || shareV || len(shareP) || shareP
|| len(Z) || Z || len(shareV) || shareV
|| len(V) || V || len(Z) || Z
|| len(w0) || w0 || len(V) || V
|| len(w0) || w0
A.4. Key Schedule Computation A.4. Key Schedule Computation
Both Prover and Verifier share the same function to compute the key Both the Prover and the Verifier share the same function to compute
schedule, ComputeKeySchedule, which is described below. the key schedule, ComputeKeySchedule, which is described below.
def ComputeKeySchedule(TT): def ComputeKeySchedule(TT):
K_main = Hash(TT) K_main = Hash(TT)
K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys") K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys")
K_shared = KDF(nil, K_main, "SharedKey") K_shared = KDF(nil, K_main, "SharedKey")
return K_confirmP, K_confirmV, K_shared return K_confirmP, K_confirmV, K_shared
A.5. Protocol Run A.5. Protocol Run
A full SPAKE2+ protocol run initiated by the prover will look as A full SPAKE2+ protocol run initiated by the Prover will look as
follows, where Transmit and Receive are shorthand for sending and follows, where Transmit and Receive are shorthand for sending and
receiving a message to the peer: receiving a message to the peer:
Prover(Context, idProver, idVerifier, w0, w1): Prover(Context, idProver, idVerifier, w0, w1):
(x, X) = ProverInit(w0) (x, X) = ProverInit(w0)
Transmit(X) Transmit(X)
Y = Receive() Y = Receive()
(Z, V) = ProverFinish(w0, w1, x, Y) (Z, V) = ProverFinish(w0, w1, x, Y)
TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, V, w0) TT = ComputeTranscript(Context, idProver, idVerifier, X, Y,
(K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT) Z, V, w0)
expected_confirmV = MAC(K_confirmV, X) (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT)
confirmV = Receive() expected_confirmV = MAC(K_confirmV, X)
if not_equal_constant_time(expected_confirmV, confirmV): confirmV = Receive()
raise "invalid confirmation message" if not_equal_constant_time(expected_confirmV, confirmV):
raise "invalid confirmation message"
confirmP = MAC(K_confirmP, Y) confirmP = MAC(K_confirmP, Y)
Transmit(confirmP) Transmit(confirmP)
return K_shared return K_shared
Verifier(Context, idProver, idVerifier, w0, L): Verifier(Context, idProver, idVerifier, w0, L):
X = Receive() X = Receive()
(Y, Z, V) = VerifierFinish(w0, L, X) (Y, Z, V) = VerifierFinish(w0, L, X)
Transmit(Y) Transmit(Y)
TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, V, w0) TT = ComputeTranscript(Context, idProver, idVerifier, X, Y,
(K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT) Z, V, w0)
confirmV = MAC(K_confirmV, X) (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT)
Transmit(confirmV) confirmV = MAC(K_confirmV, X)
Transmit(confirmV)
expected_confirmP = MAC(K_confirmP, Y) expected_confirmP = MAC(K_confirmP, Y)
confirmP = Receive() confirmP = Receive()
if not_equal_constant_time(expected_confirmP, confirmP): if not_equal_constant_time(expected_confirmP, confirmP):
raise "invalid confirmation message" raise "invalid confirmation message"
return K_shared return K_shared
Appendix B. Algorithm used for Point Generation Appendix B. Algorithm Used for Point Generation
This section describes the algorithm that was used to generate the This section describes the algorithm that was used to generate the
points M and N in the table in Section 4. This algorithm produces M points M and N in Table 1 (Section 4). This algorithm produces M and
and N such that they are indistinguishable from two random points in N such that they are indistinguishable from two random points in the
the prime-order subgroup of G, where the discrete log of these points prime-order subgroup of G, where the discrete log of these points is
is unknown. See [SPAKE2P-Analysis] for additional details on this unknown. See [SPAKE2P-Analysis] for additional details on this
requirement. requirement.
For each curve in the table below, we construct a string using the For each curve in Table 1, we construct a string using the curve OID
curve OID from [RFC5480] (as an ASCII string) or its name, combined from [RFC5480] (as an ASCII string) or its name, combined with the
with the needed constant, for instance "1.3.132.0.35 point generation needed constant -- for instance, "1.3.132.0.35 point generation seed
seed (M)" for P-512. This string is turned into a series of blocks (M)" for P-521. This string is turned into a series of blocks by
by hashing with SHA256, and hashing that output again to generate the hashing with SHA256, and hashing that output again to generate the
next 32 bytes, and so on. This pattern is repeated for each group next 32 bytes, and so on. This pattern is repeated for each group
and value, with the string modified appropriately. and value, with the string modified appropriately.
A byte string of length equal to that of an encoded group element is A byte string of length equal to that of an encoded group element is
constructed by concatenating as many blocks as are required, starting constructed by concatenating as many blocks as are required, starting
from the first block, and truncating to the desired length. The byte 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 string is then formatted as required for the group. In the case of
Weierstrass curves, we take the desired length as the length for Weierstrass curves, we take the desired length as the length for
representing a compressed point (section 2.3.4 of [SEC1]), and use representing a compressed point (Section 2.3.4 of [SEC1]) and use the
the low-order bit of the first byte as the sign bit. In order to low-order bit of the first byte as the sign bit. In order to obtain
obtain the correct format, the value of the first byte is set to 0x02 the correct format, the value of the first byte is set to 0x02 or
or 0x03 (clearing the first six bits and setting the seventh bit), 0x03 (clearing the first six bits and setting the seventh bit),
leaving the sign bit as it was in the byte string constructed by leaving the sign bit as it was in the byte string constructed by
concatenating hash blocks. For the [RFC8032] curves a different concatenating hash blocks. For the curves described in [RFC8032], a
procedure is used. For edwards448 the 57-byte input has the least- different procedure is used. For edwards448, the 57-byte input has
significant 7 bits of the last byte set to zero, and for edwards25519 the least-significant 7 bits of the last byte set to zero, and for
the 32-byte input is not modified. For both the [RFC8032] curves the edwards25519, the 32-byte input is not modified. For both of the
(modified) input is then interpreted as the representation of the curves described in [RFC8032], the (modified) input is then
group element. If this interpretation yields a valid group element interpreted as the representation of the group element. If this
with the correct order (p), the (modified) byte string is the output. interpretation yields a valid group element with the correct order
Otherwise, the initial hash block is discarded and a new byte string (p), the (modified) byte string is the output. Otherwise, the
constructed from the remaining hash blocks. The procedure of initial hash block is discarded and a new byte string constructed
constructing a byte string of the appropriate length, formatting it from the remaining hash blocks. The procedure for constructing a
as required for the curve, and checking if it is a valid point of the byte string of the appropriate length, formatting it as required for
correct order, is repeated until a valid element is found. 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 The following Python snippet generates the above points, assuming an
elliptic curve implementation following the interface of elliptic curve implementation following the interface of
Edwards25519Point.stdbase() and Edwards448Point.stdbase() in Edwards25519Point.stdbase() and Edwards448Point.stdbase() in
Appendix A of [RFC8032]: Appendix A of [RFC8032]:
def iterated_hash(seed, n): def iterated_hash(seed, n):
h = seed h = seed
for i in range(n): for i in range(n):
h = hashlib.sha256(h).digest() h = hashlib.sha256(h).digest()
return h return h
skipping to change at page 20, line 37 skipping to change at line 818
pointstr = canon_pointstr(ecname, hval) pointstr = canon_pointstr(ecname, hval)
try: try:
p = ec.decode(pointstr) p = ec.decode(pointstr)
if p != ec.zero_elem() and p * p.l() == ec.zero_elem(): if p != ec.zero_elem() and p * p.l() == ec.zero_elem():
return pointstr, i return pointstr, i
except Exception: except Exception:
pass pass
Appendix C. Test Vectors Appendix C. Test Vectors
This section contains various test vectors for SPAKE2+. (Choice of This section contains various test vectors for SPAKE2+. (The choice
PBKDF is omitted and values for w0 and w1 are provided directly.) 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 All points are encoded using the uncompressed format, i.e., with a
0x04 octet prefix, specified in [SEC1]. idProver and idVerifier 0x04 octet prefix, specified in [SEC1]. idProver and idVerifier
identity strings are provided in the protocol invocation. identity strings are provided in the protocol invocation.
[Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors
'] ']
[idProver=b'client'] [idProver=b'client']
[idVerifier=b'server'] [idVerifier=b'server']
w0 = 0xbb8e1bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad9549 w0 = 0xbb8e1bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad9549
1b3 1b3
w1 = 0x7e945f34d78785b8a3ef44d0df5a1a97d6b3b460409a345ca7830387a74b1 w1 = 0x7e945f34d78785b8a3ef44d0df5a1a97d6b3b460409a345ca7830387a74b1
dba dba
skipping to change at page 29, line 49 skipping to change at line 1263
8bfb231503853db2625275b7136b5a823dd5a94482514fce7f791c4daca2b21c7bde 8bfb231503853db2625275b7136b5a823dd5a94482514fce7f791c4daca2b21c7bde
756 756
K_confirmP = 0xb234d2e152a03168b76c6474d5322070 K_confirmP = 0xb234d2e152a03168b76c6474d5322070
K_confirmV = 0x683d62024626fe0c5126ef4df58b88ee K_confirmV = 0x683d62024626fe0c5126ef4df58b88ee
CMAC(K_confirmP, shareV) = 0x0dc514d262e37470eb43e058e0d615f4 CMAC(K_confirmP, shareV) = 0x0dc514d262e37470eb43e058e0d615f4
CMAC(K_confirmV, shareP) = 0xde076589efcd5d96c2ea6061d96772d9 CMAC(K_confirmV, shareP) = 0xde076589efcd5d96c2ea6061d96772d9
K_shared = 0x488a34663d6be5e02590bb8e9ad9ad3e0f580dec41e8b99ed4ae4b7 K_shared = 0x488a34663d6be5e02590bb8e9ad9ad3e0f580dec41e8b99ed4ae4b7
34da49287638cac4c9f17fe3c3ae18dda0d6d7f14c17e4640d5a2aaab959efa0cbea 34da49287638cac4c9f17fe3c3ae18dda0d6d7f14c17e4640d5a2aaab959efa0cbea
4e546 4e546
Acknowledgements
Thanks to Ben Kaduk and Watson Ladd, from whom this specification
originally emanated.
Authors' Addresses Authors' Addresses
Tim Taubert Tim Taubert
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014
United States of America United States of America
Email: ttaubert@apple.com Email: ttaubert@apple.com
Christopher A. Wood Christopher A. Wood
Email: caw@heapingbits.net Email: caw@heapingbits.net
 End of changes. 111 change blocks. 
286 lines changed or deleted 284 lines changed or added

This html diff was produced by rfcdiff 1.48.