SPAKE2+, an Augmented PAKE
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
ttaubert@apple.com
caw@heapingbits.net
InternetDraft
This document describes SPAKE2+, a Password Authenticated Key Exchange (PAKE) protocol
run between two parties for deriving a strong shared key with no risk of disclosing the password.
SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password.
This method is simple to implement, compatible with any prime order group and is computationally efficient.
Discussion Venues
Source for this draft and an issue tracker can be found at
https://github.com/chriswood/draftbarcfrgspake2plus.
Introduction
This document describes SPAKE2+, a Password Authenticated Key Exchange (PAKE) protocol
run between two parties for deriving a strong shared key with no risk of disclosing the password.
SPAKE2+ is an augmented PAKE protocol, as only one party makes direct use of the password during the execution of the protocol.
The other party only needs a verification value at the time of the protocol execution instead of the password.
The verification value can be computed once, during an offline initialization phase.
The party using the password directly would typically be a client, and acts as a prover,
while the other party would be a server, and acts as verifier.
The protocol is augmented in the sense that it provides some resilience to the compromise or extraction of the verification value.
The design of the protocol forces the adversary to recover the password from the verification value 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 verification value 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 can not query the salt of the password hash function ahead of the attack.
Constraints may consist in being in physical proximity through a local network or
when initiation of the protocol requires a first authentication factor.
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.
Predetermined parameters for a selection of commonly used groups are also provided.
This document has content split out from a related document specifying SPAKE2 .
Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
Definition of SPAKE2+
Offline Initialization
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 there is a representation of
elements of G as byte strings: common choices would be SEC1
uncompressed or compressed for elliptic curve groups or big
endian integers of a fixed (pergroup) length for prime field DH.
We fix two random elements M and N in the primeorder subgroup of G as defined
in the table in this document for common groups, as well as a generator P
of the (large) 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 log is not known. 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 little
endian number. Finally, let nil represent an empty string, i.e.,
len(nil) = 0.
KDF is a keyderivation function that takes as input a salt, intermediate
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 A and B be two parties. A and B may also have digital
representations of the parties' identities such as Media Access Control addresses
or other names (hostnames, usernames, etc). A and B 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 which negotiates the use of a particular PAKE. Another
example is the inclusion of the application name. Including those would ensure that
both parties agree upon the same set of supported protocols and therefore prevent downgrade and
crossprotocol attacks. Specification of precise context values is out of scope for this document.
SPAKE2+
SPAKE2+ is a two round protocol that establishes a shared secret with an
additional round for key confirmation. Prior to invocation, A and B are provisioned with
information such as the input password needed to run the protocol.
A preamble exchange may occur in order to communicate identities,
protocol version and other parameters related to the verification value;
see for details.
During the first round, A, the prover, sends a public share pA
to B, the verifier, and B responds with its own public share pB. Both A and B 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, B sends a key confirmation message cB to A, and A responds
with its own key confirmation message cA. (Note that pB and cB 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.

 
 (setup protocol) 
(compute pA)  pA 
>
 pB  (compute pB)
<
 
 (derive secrets)  (compute cB)
 cB 
<
(compute cA)  cA 
>
]]>
Preamble
The preamble phase computes and distributes two values w0 and w1 between A and B,
where w0 and w1 are derived by hashing the password pw with the identities of
the two participants, A and B. At the end, A stores w0 and w1, whereas B stores
w0 and L=w1*P. Protocols 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.
Both w0 and w1 are computed using a function that is indistinguishable from a
random oracle, which means that w0 and w1 are indistinguishable from two uniformly
random elements in the range [0, p1]. See for details.
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.
Scrypt and Argon2id 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 Section 4 of .
The output length of the PBKDF MUST be at least 64 bits longer than
than that needed to represent p. This is done to remove statistical bias
introduced by the modular reduction. For example, given the prime
order of the P256 curve, the output of the PBKDF can be 320 bits or
larger.
Given a PBKDF, password pw, and identities A and B, the RECOMMENDED
method for computing w0 and w1 is as follows:
If one or both identities A and B are unknown at the time of deriving w0 and w1,
w0s and w1s are computed as if the unknown identities were absent, i.e., the length
of the identity is zero. They however SHOULD be included in the transcript TT if
the parties exchange those prior to or as part of the protocol flow.
For simplicity, if both identities are absent, i.e. len(A) = len(B) = 0, then
w0s  w1s = PBKDF(pw).
Protocol
The online SPAKE2+ protocol runs between A and B to produce a single shared
secret upon completion. To begin, A selects x uniformly at random from the
integers in [0, p), computes the public share pA=X, and transmits it to B.
Upon receipt of X, B computes h*X and aborts if the result is equal to I to ensure
that X is in the large primeorder subgroup of G. B then selects y uniformly at
random from the integers in [0, p), computes the public share pB=Y and transmits
it to A. Upon receipt of Y, A computes h*Y and aborts if the result is equal to I.
Parties A and B compute Z and V that are now shared as common values. Party A computes:
Party B computes:
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
the empty octet string. If both A and B are absent, then both lengths are zero
and both A and B will be empty octet strings. In applications where identities
are not implicit, A and B SHOULD always be nonempty. Otherwise, the protocol
risks Unknown Key Share attacks (discussion of Unknown Key Share attacks in a
specific protocol is given in ).
Upon completion of this protocol, A and B compute shared secrets Ka, Ke, KcA,
and KcB as specified in . B MUST send A a key confirmation message cB
so both parties can confirm that they agree upon these shared secrets. After
receipt and verification of B's confirmation message, A MUST send B a
confirmation message. B MUST NOT send application data to A until it has received
and verified the confirmation message. Key confirmation verification requires
recomputation of cA or cB and checking for equality against that which was received.
Key Schedule and Key Confirmation
The protocol transcript TT, as defined in ,
is unique and secret to A and B. Both parties use TT to derive shared symmetric
secrets Ke and Ka. The length of each key is equal to half of the digest output,
e.g., Ke = Ka = 128 bits for SHA256.
A and B output Ke as the shared secret from the protocol. Ka and its derived
KcA and KcB are not used for anything except key confirmation and MUST be
discarded after the protocol execution.
Both endpoints MUST either exchange cA=KcA and cB=KcB directly, or employ a
secure PRF, acting as a MAC that produces pseudorandom tags, for key confirmation.
In the latter case, KcA and KcB are symmetric keys used to compute tags cA
and cB over data shared between the participants. That data could for example
be an encoding of the key shares exchanged earlier, or simply a fixed string.
Once key confirmation is complete, applications MAY use Ke as an authenticated
shared secret as needed. For example, applications MAY derive one or more AEAD
keys and nonces from Ke for 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
and its parameters for computing w0 and w1 and distributing does 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 the table below can be ignored and the ciphersuite name will contain no MAC
identifier.
G 
Hash 
KDF 
MAC 
P256 
SHA256 
HKDF 
HMACSHA256 
P256 
SHA512 
HKDF 
HMACSHA512 
P384 
SHA256 
HKDF 
HMACSHA256 
P384 
SHA512 
HKDF 
HMACSHA512 
P521 
SHA512 
HKDF 
HMACSHA512 
edwards25519 
SHA256 
HKDF 
HMACSHA256 
edwards448 
SHA512 
HKDF 
HMACSHA512 
P256 
SHA256 
HKDF 
CMACAES128 
P256 
SHA512 
HKDF 
CMACAES128 
The following points represent permissible point generation seeds
for the groups listed in the Table above,
using the algorithm presented in .
These bytestrings are compressed points as in
for curves from .
For P256:
~~~
M =
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
seed: 1.2.840.10045.3.1.7 point generation seed (M)
N =
03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
seed: 1.2.840.10045.3.1.7 point generation seed (N)
~~~
For P384:
~~~
M =
030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc
36f15314739074d2eb8613fceec2853
seed: 1.3.132.0.34 point generation seed (M)
N =
02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb
252c5490214cf9aa3f0baab4b665c10
seed: 1.3.132.0.34 point generation seed (N)
~~~
For P521:
~~~
M =
02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608
cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa
seed: 1.3.132.0.35 point generation seed (M)
N =
0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25
32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25
seed: 1.3.132.0.35 point generation seed (N)
~~~
For edwards25519:
~~~
M =
d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
seed: edwards25519 point generation seed (M)
N =
d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab
seed: edwards25519 point generation seed (N)
~~~
For edwards448:
~~~
M =
b6221038a775ecd007a4e4dde39fd76ae91d3cf0cc92be8f0c2fa6d6b66f9a12
942f5a92646109152292464f3e63d354701c7848d9fc3b8880
seed: edwards448 point generation seed (M)
N =
6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db
f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600
seed: edwards448 point generation seed (N)
~~~
IANA Considerations
No IANA action is required.
Security Considerations
SPAKE2+ appears in and is proven secure in .
Beyond the cofactor multiplication checks to ensure that elements received from
a peer are in the prime order subgroup of G, they also MUST be checked for group
membership as failure to properly validate group elements can lead to attacks.
The choices of random numbers MUST BE uniform. Randomly generated values (e.g., x and y)
MUST NOT be reused; such reuse may permit dictionary attacks on the password.
Acknowledgements
Thanks to Ben Kaduk and Watson Ladd, from which this specification originally emanated.
References
Normative References
The TwinDiffie Hellman Problem and Applications
Security analysis of SPAKE2+
Elliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2
SPAKE2, a PAKE
This document describes SPAKE2 which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and SPAKE2 has a security proof. This document predated the CFRG PAKE competition and it was not selected, however, given existing use of variants in Kerberos and other applications it was felt publication was beneficial. Applications that need a symmetric PAKE and where hashing onto an elliptic curve at execution time is not possible can use SPAKE2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
US Secure Hash Algorithms (SHA and SHAbased HMAC and HKDF)
Federal Information Processing Standard, FIPS
Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.
HMACbased ExtractandExpand Key Derivation Function (HKDF)
This document specifies a simple Hashed Message Authentication Code (HMAC)based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
HMAC: KeyedHashing for Message Authentication
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind
The AESCMAC Algorithm
The National Institute of Standards and Technology (NIST) has recently specified the Cipherbased Message Authentication Code (CMAC), which is equivalent to the OneKey CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128bit Advanced Encryption Standard (AES). This new authentication algorithm is named AESCMAC. The purpose of this document is to make the AESCMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.
Elliptic Curve Cryptography Subject Public Key Information
This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDSTRACK]
EdwardsCurve Digital Signature Algorithm (EdDSA)
This document describes elliptic curve signature scheme Edwardscurve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
Informative References
The scrypt PasswordBased Key Derivation Function
This document specifies the passwordbased key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memoryhard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.
Argon2 MemoryHard Function for Password Hashing and ProofofWork Applications
This document describes the Argon2 memoryhard function for password hashing and proofofwork applications. We provide an implementeroriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
Unknown KeyShare Attacks on Uses of TLS with the Session Description Protocol (SDP)
Mozilla
Mozilla
This document describes unknown keyshare attacks on the use of Datagram Transport Layer Security for the Secure RealTime Transport Protocol (DTLSSRTP). Similar attacks are described on the use of DTLSSRTP with the identity bindings used in Web RealTime Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.
Algorithm used for Point Generation
This section describes the algorithm that was used to generate
the points M and N in the table in . This algorithm
produces M and N such that they are indistinguishable from two random
elements in the primeorder subgroup of G. See
for additional details on this requirement.
For each curve in the table below, 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 P512. This string is turned
into a series of blocks by hashing with SHA256, and hashing that
output again to generate the next 32 bytes, and so on. This
pattern is repeated for each group and value, with the string
modified appropriately.
A byte string of length equal to that of an encoded group
element is constructed by concatenating as many blocks as are
required, starting from the first block, and truncating to the
desired length. The byte string is then formatted as required
for the group. In the case of Weierstrass curves, we take the
desired length as the length for representing a compressed point
(section 2.3.4 of ),
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 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 the curves 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 of constructing a
byte string of the appropriate length, formatting it as
required for the curve, and checking if it is a valid point of the correct
order, is repeated
until a valid element is found.
The following python snippet generates the above points,
assuming an elliptic curve implementation following the
interface of Edwards25519Point.stdbase() and
Edwards448Point.stdbase() in Appendix A of :
Test Vectors
This section contains test vectors for SPAKE2+ using
the P256SHA256HKDFHMACSHA256 and P256SHA256HKDFCMACAES128 ciphersuites.
(Choice of PBKDF is omitted and values for w and w0,w1 are provided directly.)
All points are encoded using the uncompressed format, i.e., with a 0x04 octet
prefix, specified in A and B identity strings
are provided in the protocol invocation.