]>
SPAKE2, a PAKEUC Berkeleywatsonbladd@gmail.comAkamai Technologieskaduk@mit.eduThis 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 method is compatible with any group, is
computationally efficient, and has a strong 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 strong 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 Diffie-Hellman (DH) problem is hard of
order p*h, with p a big prime and h a cofactor. We denote the
operations in the group additively. Let H be a hash function from
arbitrary strings to bit strings of a fixed length. Common choices
for H are SHA256 or SHA512 .
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.|| 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.We fix two elements M and N as defined in the table in this document
for common groups, as well as a generator G of the group. G is
specified in the document defining the group, and so we do not repeat
it here.Let A and B be two parties. We will assume that A and B also have digital
representations of the parties' identities such as MAC addresses or other names
(hostnames, usernames, etc). We assume they share an integer w;
typically w will be the hash of a user-supplied password, truncated
and taken mod p. 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 designed 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+.A picks x randomly and uniformly from the integers in [0,ph)
divisible by h, and calculates X=x*G and T=w*M+X, then transmits T to
B.B selects y randomly and uniformly from the integers in [0,p*h),
divisible by h and calculates Y=y*G, S=w*N+Y, then transmits S to A.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.This K is a shared value, but the scheme as described is not secure.
K MUST be combined with the values transmitted and received via a
hash function to prevent man-in-the-middle attackers from being able
to insert themselves into the exchange. Higher-level protocols
SHOULD prescribe a method for incorporating a "transcript" of the exchanged
values and endpoint identity information into the shared secret. One
such approach would be to
compute a K' as H(len(A) || A || len(B) || B || len(S) || S ||
len(T) || T || len(K) || K || len(w) || w) and use K' as the key.This protocol and security proof appear in . We
use the same setup as for SPAKE2, except that we have two secrets, w0
and w1. B stores L=w1*g and w0.When executing SPAKE2+, A selects x uniformly at random from the
numbers in the range [0, p*h) divisible by h, and lets X=x*G+w0*M, then
transmits X to B. B selects y uniformly at random from the numbers in
[0, p*h) divisible by h, then computes Y=y*G+w0*N, and transmits it to
Alice.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. For higher-level protocols without
sufficient transcript hashing, let K' be
H(len(A) || A || len(B) || B || len(X) || X || len(Y) || Y || len(Z) || Z || len(V) || V || len(w0) || w0)
and use K' as the established key.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.These bytestrings are compressed points as in
for curves from .For P256:For P384:For P521:For edwards25519:For edwards448: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: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 security proof
(though the corresponding model excludes precomputation attacks).There is no key-confirmation as this is a one-round protocol. It is
expected that a protocol using this key exchange mechanism will provide key
confirmation separately if desired.Elements received from a peer MUST be checked for group membership:
failure to properly
validate group elements can lead to attacks. In particular it is
essential to verify that received points are valid compressions of
points on an elliptic curve when using elliptic curves. It is not
necessary to validate membership in the prime order subgroup: the
multiplication by cofactors eliminates the potential for mebership
in a small-order subgroup.The choices of random numbers MUST BE uniform. Note that to pick a
random multiple of h in [0, p*h) one can pick a random integer in [0, p)
and multiply by h. Ephemeral values MUST NOT be reused; such reuse
permits 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.As specified, the shared secret K is not suitable for direct use as a shared
key. It MUST be passed to a hash function along with the public values
used to derive it and the identities of the participating parties
in order to avoid attacks. In
protocols which do not perform this separately, the value denoted K'
MUST be used instead of K.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. Trevor Perrin informed me of SPAKE2+.STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: Elliptic Curve
Cryptography", version 2.0SEC
&RFC2119;
&RFC5480;
&RFC6234;
&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;