]>
SPAKE2, a PAKEUC Berkeleywatsonbladd@gmail.comAkamai Technologieskaduk@mit.eduThis document describes SPAKE2 and its augmented variant SPAKE2+, which are protocols for
two parties that share a password to derive a strong shared key with no risk of disclosing
the password. This method is compatible with any prime order group, is computationally
efficient, and SPAKE2 (but not SPAKE2+) has a security proof.This document describes SPAKE2, a means for two parties that share a password
to derive a strong shared key with no risk of disclosing the password.
This password-based key exchange protocol is compatible with any group
(requiring only a scheme to map a random input of fixed length per group
to a random group element), is
computationally efficient, and has a security proof.
Predetermined parameters for a selection of commonly used groups are
also provided for use by other protocols.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.Let G be a group in which the computational Diffie-Hellman (CDH)
problem is hard. Suppose G has order p*h where p is a large prime;
h will be called the cofactor. Let I be the unit element in
G, e.g., the point at infinity if G is an elliptic curve group. We denote the
operations in the group additively. We assume there is a representation of
elements of G as byte strings: common choices would be SEC1
compressed for elliptic curve groups or big
endian integers of a fixed (per-group) length for prime field DH.
We fix two elements M and N in the prime-order subgroup of G as defined
in the table in this document for common groups, as well as a generator P
of the (large) prime-order subgroup of G. P is specified in the document defining
the group, and so we do not repeat it here.|| denotes concatenation of strings. We also let len(S) denote the
length of a string in bytes, represented as an eight-byte little-
endian number. Finally, let nil represent an empty string, i.e.,
len(nil) = 0.KDF is a key-derivation function that takes as input a salt, 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 H are SHA256 or SHA512 . Let MHF be a memory-hard
hash function designed to slow down brute-force attackers. Scrypt
is a common example of this function. The output length of MHF matches that
of Hash. Parameter selection for MHF is out of scope for this document.
specifies variants of KDF, MAC, Hash, and MHF
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
Authenticated Data (AAD) of length at most 2^16 - 1 bits that is separate
from their identities which they may want to include in the protocol execution.
One example of AAD is a list of supported protocol versions if SPAKE2(+) were
used in a higher-level protocol which negotiates use of a particular PAKE. Including
this list would ensure that both parties agree upon the same set of supported protocols
and therefore prevent downgrade attacks. We also assume A and B share an integer w;
typically w = MHF(pw) mod p, for a user-supplied password pw.
Standards such NIST.SP.800-56Ar3 suggest taking mod p of a
hash value that is 64 bits longer than that needed to represent p to remove
statistical bias introduced by the modulation. Protocols using this specification must define
the method used to compute w: it may be necessary to carry out various
forms of normalization of the password before hashing .
The hashing algorithm SHOULD be a MHF so as to slow down brute-force
attackers. We present two protocols below. Note that it is insecure to use the
same password with both protocols; passwords MUST NOT be used for
both SPAKE2 and SPAKE2+.To begin, A picks x randomly and uniformly from the integers in [0,p),
and calculates X=x*P and T=w*M+X, then transmits T to B. Upon receipt
of T, B computes T*h and aborts if the result is equal to I. (This ensures
T is in the prime order subgroup of G.)B selects y randomly and uniformly from the integers in [0,p), and calculates
Y=y*P, S=w*N+Y, then transmits S to A. Upon receipt of S, A computes S*h and
aborts if the result is equal to I.Both A and B calculate a group element K. A calculates it as
x*(S-wN), while B calculates it as y*(T-w*M). A knows S because it has
received it, and likewise B knows T. A and B multiply protocol messages from
each peer by h so as to avoid small subgroup attacks, but the result of
the multiplication is not used for operations other than the comparison
against I and the non-multiplied value is used in subsequent calculations.K is a shared value, though it MUST NOT be used as a shared secret.
Both A and B must derive two shared secrets from K and the protocol transcript.
This prevents man-in-the-middle attackers from inserting themselves into
the exchange. The transcript TT is encoded as follows:If an identity is absent, it is omitted from the transcript entirely. For example,
if both A and B are absent, then TT = len(S) || S || len(T) || T || len(K) || K || len(w) || w.
Likewise, if only A is absent, TT = len(B) || B || len(S) || S || len(T) || T || len(K) || K || len(w) || w.
This must only be done for applications in which identities are implicit. Otherwise,
the protocol risks Unknown Key Share attacks (discussion of Unknown Key Share attacks
in a specific protocl is given in .Upon completion of this protocol, A and B compute shared secrets Ke, KcA, and KcB as
specified in . A MUST send B a key confirmation message
so both parties agree upon these shared secrets. This confirmation message F
is computed as a MAC over the protocol transcript TT using KcA, as follows:
F = MAC(KcA, TT). Similarly, B MUST send A a confirmation message using a MAC
computed equivalently except with the use of KcB. Key confirmation verification
requires computing F and checking for equality against that which was received.This protocol appears in . We
use the same setup as for SPAKE2, except that we have two secrets, w0
and w1, derived by hashing the password pw with the identities of the two
participants, A and B. Specifically,
w0s || w1s = MHF(len(pw) || pw || len(A) || A || len(B) || B),
and then computing w0 = w0s mod p and w1 = w1s mod p.
The length of each of w0s and w1s is equal to half of the MHF output, e.g.,
|w0s| = |w1s| = 128 bits for scrypt.
w0 and w1 MUST NOT equal I. If they are,
they MUST be iteratively regenerated by computing
w0s || w1s = MHF(len(pw) || pw || len(A) || A || len(B) || B || 0x0000),
where 0x0000 is 16-bit increasing counter. This process must repeat until
valid w0 and w1 are produced. B stores L=w1*P and w0.When executing SPAKE2+, A selects x uniformly at random from the
numbers in the range [0, p), and lets X=x*P+w0*M, then transmits X to
B. Upon receipt of X, A computes h*X and aborts if the result is equal
to I. B then selects y uniformly at random from the numbers in [0, p),
then computes Y=y*P+w0*N, and transmits Y to A. Upon receipt of Y, A computes
Y*h and aborts if the result is equal to I.A computes Z as x*(Y-w0*N), and V as w1*(Y-w0*N). B computes Z as y*(X-
w0*M) and V as y*L. Both share Z and V as common keys. 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.As in , inclusion of A and B in the transcript is optional depending
on whether or not the identities are implicit.Upon completion of this protocol, A and B follow the same key derivation and confirmation
steps as outlined in .The protocol transcript TT, as defined in Sections and
, is unique and secret to A and B. Both parties use TT to
derive shared symmetric secrets Ke and Ka as Ke || Ka = Hash(TT). The length of each
key is equal to half of the digest output, e.g., |Ke| = |Ka| = 128 bits for SHA-256.Both endpoints use Ka to derive subsequent MAC keys for key confirmation messages.
Specifically, let KcA and KcB be the MAC keys used by A and B, respectively.
A and B compute them as KcA || KcB = KDF(nil, Ka, "ConfirmationKeys" || AAD), where AAD
is the associated data each given to each endpoint, or nil if none was provided.
The length of each of KcA and KcB is equal to half of the KDF output, e.g.,
|KcA| = |KcB| = 128 bits for HKDF(SHA256).The resulting key schedule for this protocol, given transcript TT and additional associated
data AAD, is as follows.A and B output Ke as the shared secret from the protocol. Ka and its derived keys are not
used for anything except key confirmation.
This section documents SPAKE2 and SPAKE2+ ciphersuite configurations. A ciphersuite
indicates a group, cryptographic hash algorithm, and pair of KDF and MAC functions, e.g.,
SPAKE2-P256-SHA256-HKDF-HMAC. This ciphersuite indicates a SPAKE2 protocol instance over
P-256 that uses SHA256 along with HKDF and HMAC
for G, Hash, KDF, and MAC functions, respectively.GHashKDFMACMHFP-256SHA256 HKDF HMAC scrypt P-256SHA512 HKDF HMAC scrypt P-384SHA256 HKDF HMAC scrypt P-384SHA512 HKDF HMAC scrypt P-512SHA512 HKDF HMAC scrypt edwards25519 SHA256 HKDF HMAC scrypt edwards448 SHA512 HKDF HMAC scrypt P-256SHA256 HKDF CMAC-AES-128 scrypt P-256SHA512 HKDF CMAC-AES-128 scrypt The following points represent permissible point generation seeds
for the groups listed in the Table ,
using the algorithm presented in .
These bytestrings are compressed points as in
for curves from .For P256:For P384:For P521:For edwards25519:For edwards448:A security proof of SPAKE2 for prime order groups is found in . Note that the choice of M and N is critical for the
security proof. The generation method specified in this document is
designed to eliminate concerns related to knowing discrete logs of M
and N.SPAKE2+ appears in along with a path to a proof that
server compromise does not lead to password compromise under the DH assumption
(though the corresponding model excludes precomputation attacks).Elements received from a peer MUST be checked for group membership:
failure to properly validate group elements can lead to attacks. Beyond the cofactor
multiplication checks to ensure that these elements are in the prime order subgroup
of G, it is essential that endpoints verify received points are members of G.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.SPAKE2 does not support augmentation. As a result, the server has to
store a password equivalent. This is considered a significant drawback,
and so SPAKE2+ also appears in this document.No IANA action is required.Special thanks to Nathaniel McCallum and Greg Hudson
for generation of test vectors.
Thanks to Mike Hamburg for advice on how to deal with cofactors. Greg
Hudson also suggested the addition of warnings on the reuse of x and y. Thanks
to Fedor Brunner, Adam Langley, and the members of the CFRG for
comments and advice. Chris Wood contributed substantial text and reformatting
to address the excellent review comments from Kenny Paterson.
Trevor Perrin informed me of SPAKE2+.STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: Elliptic Curve
Cryptography", version 2.0SEC
&RFC2104;
&RFC2119;
&RFC4493;
&RFC5480;
&RFC5869;
&RFC6234;
&RFC7748;
&RFC7914;
&RFC8032;
&RFC8174;
Simple Password-Based Encrypted Key Exchange Protocols.Appears in A. Menezes, editor. Topics in
Cryptography-CT-RSA 2005, Volume 3376 of Lecture Notes in Computer
Science, pages 191-208, San Francisco, CA, US. Springer-Verlag,
Berlin, Germany.
The Twin-Diffie Hellman Problem and ApplicationsEUROCRYPT 2008. Volume 4965 of Lecture notes in Computer
Science, pages 127-145. Springer-Verlag, Berlin, Germany.
&RFC8265;
&uks;
This section describes the algorithm that was used to generate
the points (M) and (N) in the table in .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 P-512. 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 low-order bit of the first byte as the sign bit.
In order to obtain the correct format, the value of the first
byte is set to 0x02 or 0x03 (clearing the first six bits
and setting the seventh bit), leaving the sign bit as it was
in the byte string constructed by concatenating hash blocks.
For the curves a different procedure is used.
For edwards448 the 57-byte input has the least-significant 7 bits of the
last byte set to zero, and for edwards25519 the 32-byte input is
not modified. For both 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 :