]>
SPAKE2+, an Augmented PasswordAuthenticated Key Exchange (PAKE) Protocol
Apple Inc.
One Apple Park Way
Cupertino
California
95014
United States of America
ttaubert@apple.com
caw@heapingbits.net
This document describes SPAKE2+, a PasswordAuthenticated Key Exchange (PAKE) protocol
run between two parties for deriving a strong shared key with no risk of disclosing the password.
SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password.
This method is simple to implement, compatible with any primeorder group, and computationally efficient.
This document was produced outside of the IETF and IRTF and represents the opinions of the authors.
Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement
of SPAKE2+ by the IETF or IRTF.
Introduction
This document describes SPAKE2+, a PasswordAuthenticated Key Exchange (PAKE) protocol
run between two parties for deriving a strong shared key with no risk of disclosing the password.
SPAKE2+ is an augmented PAKE protocol, as only one party makes direct use of the password during the execution of the protocol.
The other party only needs a record corresponding to the first party's registration at the time of the protocol execution instead of the password.
This record can be computed once, during an offline registration phase.
The party using the password directly would typically be a client and would act as a Prover,
while the other party would be a server and would act as a Verifier.
The protocol is augmented in the sense that it provides some resilience against the compromise or extraction of the registration record.
The design of the protocol forces the adversary to recover the password from the record to successfully execute the protocol.
Hence, this protocol can be advantageously combined with a salted Password Hashing Function to increase the cost of the recovery and slow down attacks.
The record cannot be used directly to successfully run the protocol as a Prover,
making this protocol more robust than balanced PAKEs, which don't benefit from Password Hashing Functions to the same extent.
This augmented property is especially valuable in scenarios where the execution of the protocol is constrained
and the adversary cannot query the salt of the Password Hashing Function ahead of the attack.
For example, a constraint may be when physical proximity through a local network is required or when a first authentication factor is required for initiation of the protocol.
This document has content split out from a related document,
, which specifies SPAKE2.
SPAKE2 is a symmetric PAKE protocol, where both parties have knowledge of the password.
SPAKE2+ is the asymmetric or augmented version of SPAKE2, wherein only one party has knowledge of the password.
SPAKE2+ is specified separately in this document because the use cases for symmetric and augmented PAKEs
are different and therefore warrant different technical specifications. Neither SPAKE2 nor SPAKE2+
was selected as the result of the Crypto Forum Research Group (CFRG) PAKE selection competition. However, this passwordbased key exchange
protocol appears in and is proven secure in . It is compatible with any
primeorder group and relies only on group operations, making it simple and computationally efficient.
Thus, it was felt that publication was beneficial to make the protocol available for wider consideration.
This document was produced outside of the IETF and IRTF and represents the opinions of the authors.
Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement
of SPAKE2+ by the IETF or IRTF.
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
when, and only
when, they appear in all capitals, as shown here.
Definition of SPAKE2+
Let G be a group in which the computational DiffieHellman (CDH)
problem is hard. Suppose G has order p*h where p is a large prime;
h will be called the cofactor. Let I be the unit element in
G, e.g., the point at infinity if G is an elliptic curve group. We denote the
operations in the group additively. We assume that there is a representation of
elements of G as byte strings: common choices would be SEC 1
uncompressed or compressed for elliptic curve groups or bigendian integers of a fixed (pergroup) length for prime field DH.
We fix a generator P of the (large) primeorder subgroup of G. P is specified
in the document defining the group, and so we do not repeat it here.
 denotes concatenation of strings. We also let len(S) denote the
length of a string in bytes, represented as an eightbyte littleendian number. Finally, let nil represent an empty string, i.e.,
len(nil) = 0.
KDF is a key derivation function that takes as input a salt, input
keying material (IKM), info string, and derived key length L to derive a
cryptographic key of length L.
MAC is a Message Authentication Code algorithm that takes a secret key and
message as input to produce an output.
Let Hash be a hash function from arbitrary strings to bit strings of a fixed length. Common choices
for Hash are SHA256 or SHA512 .
specifies variants of KDF, MAC, and Hash
suitable for use with the protocols contained herein.
Let there be two parties, a Prover and a Verifier. Their identities, denoted as
idProver and idVerifier, may also have digital representations such as Media Access Control addresses
or other names (hostnames, usernames, etc.). The parties may share additional data
(the context) separate from their identities, which they may want to include in
the protocol transcript.
One example of additional data is a list of supported protocol versions if SPAKE2+ were
used in a higherlevel protocol that negotiates the use of a particular PAKE. Another
example is the inclusion of the application name. Including these data points would ensure that
both parties agree upon the same set of supported protocols and therefore prevents downgrade and
crossprotocol attacks. Specification of precise context values is out of scope for this document.
Protocol Overview
SPAKE2+ is a tworound protocol that establishes a shared secret with an
additional round for key confirmation. Prior to invocation, both parties are
provisioned with information such as the input password needed to run the
protocol. The registration phase may include communicating identities, protocol
version, and other parameters related to the registration record; see
for details.
During the first round, the Prover sends a public share, shareP, to the Verifier, which in turn
responds with its own public share, shareV. Both parties then derive a shared secret
used to produce encryption and authentication keys. The latter are used during the second
round for key confirmation. ( details the key derivation and confirmation steps.)
In particular, the Verifier sends a key confirmation message, confirmV, to the Prover,
which in turn responds with its own key confirmation message, confirmP.
(Note that shareV and confirmV MAY be sent in the same message.)
Both parties MUST NOT consider the protocol complete prior to receipt and
validation of these key confirmation messages.
A sample trace is shown below.

 
 (set up the protocol) 
(compute shareP)  shareP 
>
 shareV  (compute shareV)
<
 
 (derive secrets)  (compute confirmV)
 confirmV 
<
(compute confirmP)  confirmP 
>
]]>
Offline Registration
The registration phase computes the values w0 and w1, as well as the registration
record L=w1*P. w0 and w1 are derived by hashing the password pw with the identities
of the two participants. w0 and the record L are then shared with the Verifier and
stored as part of the registration record associated with the Prover. The Prover
SHOULD derive w0 and w1 from the password before the protocol begins. Both w0 and
w1 are derived using a function with range [0, p1], which is modeled as a random
oracle in .
The registration phase also produces two random elements, M and N, in the primeorder
subgroup of G. The algorithm for selecting M and N is defined in .
Importantly, this algorithm chooses M and N such that their discrete logs are not
known. Precomputed values for M and N are listed in for each
group. Applications MAY use different M and N values, provided they are computed,
e.g., using different input seeds to the algorithm in , as random elements
for which the discrete log is unknown.
Applications using this specification MUST define the method used to compute w0 and w1.
For example, it may be necessary to carry out various forms of normalization of the
password before hashing . This section contains requirements and default
recommendations for computing w0 and w1.
The RECOMMENDED method for generating w0 and w1 is via a PasswordBased Key
Derivation Function (PBKDF), which is a function designed to slow down bruteforce
attackers. Bruteforce resistance may be obtained through various computation hardness
parameters such as memory or CPU cycles and are typically configurable.
The scrypt function and the Argon2id function are common examples of PBKDFs.
Absent an applicationspecific profile, RECOMMENDED parameters (N, r, p)
for scrypt are (32768,8,1), and RECOMMENDED parameters for Argon2id
are in .
Each half of the output of the PBKDF will be interpreted as an integer and reduced
modulo p. To control bias, each half must be of length at least ceil(log2(p)) + k
bits, with k >= 64. Reducing such integers mod p gives bias at most 2^k for any
p; this bias is negligible for any k >= 64.
The minimum total output length of the PBKDF then is 2 * (ceil(log2(p)) + k) bits.
For example, given the prime order of the P256 curve, the output of the PBKDF
SHOULD be at least 640 bits or 80 bytes.
Given a PBKDF, password pw, and identities idProver and idVerifier, the RECOMMENDED
method for computing w0 and w1 is as follows:
If an identity is unknown at the time of computing w0s or w1s, its length is given
as zero and the identity itself is represented as an empty octet string. If both
idProver and idVerifier are unknown, then their lengths are given as zero and both
identities will be represented as empty octet strings. idProver and idVerifier are
included in the transcript TT as part of the protocol flow.
Online Authentication
The online SPAKE2+ protocol runs between the Prover and Verifier to produce a
single shared secret upon completion. To begin, the Prover selects x uniformly
at random from the integers in [0, p1], computes the public share shareP=X,
and transmits it to the Verifier.
Upon receipt of X, the Verifier checks the received element for group membership
and aborts if X is not in the large primeorder subgroup of G; see
for details. The Verifier then selects y uniformly at random from the integers
in [0, p1], computes the public share shareV=Y, and transmits it to the Prover.
Upon receipt of Y, the Prover checks the received element for group membership
and aborts if Y is not in the large primeorder subgroup of G.
Both participants compute Z and V; Z and V are then shared as common values.
The Prover computes:
The Verifier computes:
The multiplication by the cofactor h prevents small subgroup confinement attacks.
All proofs of security hold even if the discrete log of the fixed group element
N is known to the adversary. In particular, one MAY set N=I, i.e., set N to the
unit element in G.
It is essential that both Z and V be used in combination with the transcript to
derive the keying material. The protocol transcript encoding is shown below.
Context is an applicationspecific customization string shared between both
parties and MUST precede the remaining transcript. It might contain the
name and version number of the higherlevel protocol, or simply the name and version
number of the application. The context MAY include additional data such as the
chosen ciphersuite and PBKDF parameters like the iteration count or salt.
The context and its length prefix MAY be omitted.
If an identity is absent, its length is given as zero and the identity itself
is represented as an empty octet string. If both identities are absent, then
their lengths are given as zero and both are represented as empty octet strings.
In applications where identities are not implicit, idProver and idVerifier SHOULD always be
nonempty. Otherwise, the protocol risks unknown keyshare attacks (discussion
of unknown keyshare attacks in a specific protocol is given in ).
Upon completion of this protocol, both parties compute shared secrets K_main,
K_shared, K_confirmP, and K_confirmV as specified in . The Verifier MUST send a key
confirmation message, confirmV, to the Prover so both parties can confirm that they
agree upon these shared secrets. After receipt and verification of the Verifier's
confirmation message, the Prover MUST respond with its confirmation message.
The Verifier MUST NOT send application data to the Prover until it has received
and verified the confirmation message. Key confirmation verification requires
recomputation of confirmP or confirmV and checking for equality against the data that was
received.
Key Schedule and Key Confirmation
The protocol transcript TT, as defined in , is unique and secret to
the participants. Both parties use TT to derive the shared symmetric secret K_main from the
protocol. The length of K_main is equal to the length of the digest output, e.g., 256 bits
for Hash() = SHA256. The confirmation keys K_confirmP and K_confirmV, as well as the shared
key K_shared, are derived from K_main.
Neither K_main nor its derived confirmation keys are used for anything except key
derivation and confirmation and MUST be discarded after the protocol execution.
Applications MAY derive additional keys from K_shared as needed.
The length of each confirmation key is dependent on the MAC function of the chosen
ciphersuite. For HMAC, the RECOMMENDED key length is equal to the output length of
the digest output, e.g., 256 bits for Hash() = SHA256. For CMACAES, each
confirmation key MUST be of length k, where k is the chosen AES key size,
e.g., 128 bits for CMACAES128.
Both endpoints MUST employ a MAC that produces pseudorandom tags for key confirmation.
K_confirmP and K_confirmV are symmetric keys used to compute tags confirmP and
confirmV over the public key shares received from the other peer earlier.
Once key confirmation is complete, applications MAY use K_shared as an authenticated
shared secret as needed. For example, applications MAY derive one or more keys and nonces from K_shared, for use with Authenticated Encryption with Associated Data (AEAD) and subsequent application data encryption.
Ciphersuites
This section documents SPAKE2+ ciphersuite configurations. A ciphersuite
indicates a group, cryptographic hash algorithm, and pair of KDF and MAC functions, e.g.,
P256SHA256HKDFHMACSHA256. This ciphersuite indicates a SPAKE2+ protocol instance over
P256 that uses SHA256 along with HKDF and HMAC
for G, Hash, KDF, and MAC functions, respectively. Since the choice of PBKDF,
its parameters for computing w0 and w1, and the distribution of w0 and w1 do not affect
interoperability, the PBKDF is not included as part of the ciphersuite.
If no MAC algorithm is used in the key confirmation phase, its respective column
in can be ignored and the ciphersuite name will contain no MAC
identifier.
G 
Hash 
KDF 
MAC 
P256 
SHA256 
HKDFSHA256 
HMACSHA256 
P256 
SHA512 
HKDFSHA512 
HMACSHA512 
P384 
SHA256 
HKDFSHA256 
HMACSHA256 
P384 
SHA512 
HKDFSHA512 
HMACSHA512 
P521 
SHA512 
HKDFSHA512 
HMACSHA512 
edwards25519 
SHA256 
HKDFSHA256 
HMACSHA256 
edwards448 
SHA512 
HKDFSHA512 
HMACSHA512 
P256 
SHA256 
HKDFSHA256 
CMACAES128 
P256 
SHA512 
HKDFSHA512 
CMACAES128 
The following points represent permissible point generation seeds for the groups listed
in , using the algorithm presented in . These byte strings are
compressed points as in for curves from and . Note that
these values are identical to those used in the companion SPAKE2 specification .
For P256:
For P384:
For P521:
For edwards25519:
For edwards448:
IANA Considerations
This document has no IANA actions.
Security Considerations
SPAKE2+ appears in and is proven secure in .
The ephemeral randomness used by the Prover and Verifier MUST be
generated using a cryptographically secure Pseudorandom Number Generator (PRNG).
Elements received from a peer MUST be checked for group membership: failure to
properly deserialize and validate group elements can lead to attacks. An endpoint
MUST abort the protocol if any received public value is not a member of the
large primeorder subgroup of G. Multiplication of a public value V by the
cofactor h will yield the identity element I whenever V is an element of a
smallorder subgroup. Consequently, the Prover and Verifier MUST abort the protocol
upon receiving any value V such that V*h = I. Failure to do so may lead to subgroup
confinement attacks.
References
Normative References
The TwinDiffie Hellman Problem and Applications
EUROCRYPT 2008, Lecture Notes in Computer Science, Volume 4965, pages 127145, SpringerVerlag, Berlin, Germany
Security analysis of SPAKE2+
SEC 1: Elliptic Curve Cryptography
Standards for Efficient Cryptography Group
version 2.0
SPAKE2, a PasswordAuthenticated Key Exchange
Informative References
Protocol Flow
This section describes the flow of the SPAKE2+ protocol, including computations
and mandatory checks performed by the Prover and Verifier. The constants M, N,
P, p, and h are defined by the chosen ciphersuite.
Prover
The Prover implements two functions, ProverInit and ProverFinish, which
are described below.
Verifier
The Verifier implements a single function, VerifierFinish, which
is described below.
Transcript Computation
Both the Prover and the Verifier share the same function to compute the protocol
transcript, ComputeTranscript, which is described below.
Key Schedule Computation
Both the Prover and the Verifier share the same function to compute
the key schedule, ComputeKeySchedule, which is described below.
Protocol Run
A full SPAKE2+ protocol run initiated by the Prover will look as follows,
where Transmit and Receive are shorthand for sending and receiving
a message to the peer:
Algorithm Used for Point Generation
This section describes the algorithm that was used to generate
the points M and N in (). This algorithm
produces M and N such that they are indistinguishable from two random
points in the primeorder subgroup of G, where the discrete log
of these points is unknown. See for additional
details on this requirement.
For each curve in , we construct a string
using the curve OID from (as an ASCII
string) or its name,
combined with the needed constant  for instance, "1.3.132.0.35
point generation seed (M)" for P521. This string is turned
into a series of blocks by hashing with SHA256, and hashing that
output again to generate the next 32 bytes, and so on. This
pattern is repeated for each group and value, with the string
modified appropriately.
A byte string of length equal to that of an encoded group
element is constructed by concatenating as many blocks as are
required, starting from the first block, and truncating to the
desired length. The byte string is then formatted as required
for the group. In the case of Weierstrass curves, we take the
desired length as the length for representing a compressed point
()
and use the loworder bit of the first byte as the sign bit.
In order to obtain the correct format, the value of the first
byte is set to 0x02 or 0x03 (clearing the first six bits
and setting the seventh bit), leaving the sign bit as it was
in the byte string constructed by concatenating hash blocks.
For the curves described in , a different procedure is used.
For edwards448, the 57byte input has the leastsignificant 7 bits of the
last byte set to zero, and for edwards25519, the 32byte input is
not modified. For both of the curves described in , the
(modified) input is then interpreted
as the representation of the group element.
If this interpretation yields a valid group element with the
correct order (p), the (modified) byte string is the output. Otherwise,
the initial hash block is discarded and a new byte string constructed
from the remaining hash blocks. The procedure for constructing a
byte string of the appropriate length, formatting it as
required for the curve, and checking to see if it is a valid point of the correct
order is repeated
until a valid element is found.
The following Python snippet generates the above points,
assuming an elliptic curve implementation following the
interface of Edwards25519Point.stdbase() and
Edwards448Point.stdbase() in :
Test Vectors
This section contains various test vectors for SPAKE2+.
(The choice of PBKDF is omitted, and values for w0 and w1 are provided directly.)
All points are encoded using the uncompressed format, i.e., with a 0x04 octet
prefix, specified in . idProver and idVerifier identity strings
are provided in the protocol invocation.
Acknowledgements
Thanks to and , from whom this specification originally emanated.