The Security Evaluated Standardized Password Authenticated Key Exchange (SESPAKE) Protocol
CRYPTO-PRO18, Suschevsky val Moscow127018Russian Federation+7 (495) 995-48-20svs@cryptopro.ruCRYPTO-PRO18, Suschevsky val Moscow127018Russian Federation+7 (495) 995-48-20alekseev@cryptopro.ruCRYPTO-PRO18, Suschevsky val Moscow127018Russian Federation+7 (495) 995-48-20oshkin@cryptopro.ruCRYPTO-PRO18, Suschevsky val Moscow127018Russian Federation+7 (495) 995-48-20vpopov@cryptopro.ru
General
Network Working GroupTODO
This document specifies the Security Evaluated Standardized Password
Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol provides password authenticated
key exchange for usage in the systems for protection of sensitive information.
The security proofs of the protocol were made for the case of an active adversary in the channel,
including MitM attacks and attacks based on the impersonation of one of the subjects.
The current document contains the description of the password authenticated
key exchange protocol SESPAKE (security evaluated standardized password
authenticated key exchange) for usage in the systems for protection of sensitive information.
The protocol is intended to use for establishment of keys that are then used for organization of secure
channel for protection of sensitive information. The security proofs of the
protocol were made for the case of an active adversary in the channel,
including MitM attacks and attacks based on the impersonation of one of the subjects.
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
.
This document uses the following parameters of elliptic curves in accordance with :
an elliptic curve defined over a finite prime field GF(p), where p > 3;
the characteristic of the underlying prime field;
the coefficients of the equation of the elliptic curve in the canonical form;
the elliptic curve group order;
the elliptic curve subgroup order;
a generator of the subgroup of order q;
the coordinates of the elliptic curve point in the canonical form;
zero point (point of infinity) of the elliptic curve.
This memo uses the following functions:
the underlying hash function;
the function for calculating a message authentication code,
based on a HASH function in accordance with ;
the value of the function PBKDF2(PW,salt,n,len), where PBKDF2(PW,salt,n,len) is
calculated according to
The parameter len is considered equal to minimal integer that is
a multiple of 8 and satisfies the following condition:
len >= floor(log_2(q)).
This document uses the following terms and definitions for the sets
and operations on the elements of these sets
the set of byte strings of size n, n >= 0, for n = 0 the B_n set consists
of a single empty string of size 0;
if b is an element of B_n, then b = (b_1,...,b_n), where b_1,...,b_n are elements of {0,…,255};
concatenation of byte strings A and C, i.e.,
if A in B_n1, C in B_n2, A = (a_1,a_2,...,a_n1) and C = (c_1,c_2,...,c_n2),
then A||C = (a_1,a_2,…,a_n1,c_1,c_2,…,c_n2) is an element of B_(n1+n2);
for the byte string A= (a_1,...,a_n) in B_n an integer int(A) = 256^(n-1)a_n +...+ 256^(0)a_1;
the byte string A in B_n such that int(A) = X, where X is integer, 0 <= X < 256^n;
for Q in E, the byte string bytes_n(X) || bytes_n(Y), where X, Y are standard Weierstrass coordinates of point Q and n = ceil(log_{256}(p)).
The main point of the SESPAKE protocol is that parties sharing a weak key (a password) generate a strong common key.
The active adversary who has an access to a channel is not able to obtain any information that can be used to find a key in offline mode, i.e. without
interaction with legitimate participants.
The protocol is used by the subjects A (client) and B (server) that share some
secret parameter that was established in an out-of-band mechanism: a client is a participant who stores a password as a secret
parameter and a server is a participant who stores a password-based computed point of the
elliptic curve.
The SESPAKE protocol consists of two steps: the key agreement step and the key confirmation step.
During the first step (the key agreement step) the parties exchange keys using Diffie-Hellman with public components masked by
an element that depends on the password - one of the predefined elliptic curve points multiplied by the password-based coefficient.
This approach provides an implicit key authentication, which means that after this step one party is assured that
no other party aside from a specifically identified second party may gain access to the generated secret key.
During the second step (the key confirmation step) the parties exchange strings that strongly depend on the generated key.
After this step the parties are assured that a legitimate party and no one else actually has possession of the secret key.
To protect against online guessing attacks the failed connections counters were introduced in the SESPAKE protocol. There is also a
special way of a small order point processing and a mechanism that provides a reflection attack protection by
using different operations for different sides.
Various elliptic curves can be used in the protocol. For each elliptic
curve supported by clients the following values MUST be defined:
the protocol parameters identifier ID_ALG (which can also define a HASH function, PRF used in PBKDF2 function, etc.), that is a byte string of an arbitrary length;
the point P, that is a generator point of the subgroup of order q of the curve;
the set of distinct curve points {Q_1,Q_2,...,Q_N} of order q, where the total
number of points N is defined for protocol instance.
The method of generation of the points {P,Q_1,Q_2,...,Q_N} is described
in .
The protocol parameters that are used by subject A are the following:
The secret password value PW, which is a byte string that is uniformly
randomly chosen from a subset of cardinality 10^10 or greater of
the set B_k, where k >= 6 is password length.
The list of curve identifiers supported by A.
Sets of points {Q_1,Q_2,…,Q_N}, corresponding to curves supported by A.
The C_1^A counter, that tracks the total number of unsuccessful authentication
trials in a row, and a value of CLim_1 that stores the maximum possible
number of such events.
The C_2^A counter, that tracks the total number of unsuccessful authentication
events during the period of usage of the specific PW, and a value of CLim_2
that stores the maximum possible number of such events.
The C_3^A counter, that tracks the total number of authentication events
(successful and unsuccessful) during the period of usage of the specific PW,
and a value of CLim_3 that stores the maximum possible number of such events.
The unique identifier ID_A of the subject A (OPTIONAL), which is a byte string of an arbitrary length.
The protocol parameters that are used by subject B are the following:
The values ind and salt, where ind is in {1,…,N}, salt is in {1,…,2^128-1}.
The point Q_PW, satisfying the following equation:
Q_PW = int (F (PW, salt, 2000))*Q_ind.
It is possible that the point Q_PW is not stored and is calculated using PW
in the beginning of the protocol. In that case B has to store PW and points Q_1,Q_2,…,Q_N.
The ID_ALG identifier.
The C_1^B counter, that tracks the total number of unsuccessful authentication
trials in a row, and a value of CLim_1 that stores the maximum possible
number of such events.
The C_2^B counter, that tracks the total number of unsuccessful authentication
events during the period of usage of the specific PW, and a value of CLim_2
that stores the maximum possible number of such events.
The C_3^B counter, that tracks the total number of authentication events
(successful and unsuccessful) during the period of usage of the specific PW,
and a value of CLim_3 that stores the maximum possible number of such events.
The unique identifier ID_B of the subject B (OPTIONAL), which is a byte string of an arbitrary length.
After the setup of a new password value PW the values of the counters MUST be assigned as follows:
C_1^A = C_1^B = CLim_1, where CLim_1 is in {3,…,5};
C_2^A = C_2^B = CLim_2, where CLim_2 is in {7,…,20};
C_3^A = C_3^B = CLim_3, where CLim_3 is in {10^3,10^3+1,…,10^5}.
The basic SESPAKE steps are shown in the scheme below:
A [A_ID, PW]B [B_ID, Q_PW , ind, salt]if C_1^A or C_2^A or C_3^A = 0 ==> quitdecrement C_1^A, C_2^A, C_3^A by 1A_ID --->if C_1^B or C_2^B or C_3^B = 0 ==> quitz_A = 0<--- ID_ALG, B_ID (OPTIONAL), ind, saltdecrement C_1^B, C_2^B, C_3^B by 1Q_PW^A = int(F(PW, salt, 2000)) * Q_indchoose alpha randomly from {1,...,q&nbhy;1}u_1 = alpha*P - Q_PW^Au_1 --->if u_1 not in E ==> quitz_B = 0Q_B = u_1 + Q_PWchoose betta randomly from {1,...,q&nbhy;1}if m/q*Q_B = O ==> Q_B = betta*P, z_B = 1K_B = HASH(BYTES((m/q*betta*(mod q))*Q_B))if u_2 not in E ==> quit<--- u_2u_2 = betta*P + Q_PWQ_A = u_2 - Q_PW^Aif m/q*Q_A = O ==> Q_A = alpha*P, z_A = 1K_A = HASH(BYTES((m/q*alpha(mod q))*Q_A))U_1 = BYTES(u_1), U_2 = BYTES(u_2)MAC_A = HMAC(K_A, 0x01 || ID_A || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A)DATA_A, MAC_A &nbhy;&nbhy;&nbhy;>U_1 = BYTES(u_1), U_2 = BYTES(u_2)if MAC_A != HMAC(K_B, 0x01 || ID_A || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A) ==> quitif z_B = 1 ==> quitC_1^B = CLim_1, increment C_2^B by 1if MAC_B != HMAC(K_A, 0x02 || ID_B || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A || DATA_B) ==> quit<--- DATA_B, MAC_BMAC_B = HMAC(K_B, 0x02 || ID_B || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A || DATA_B)if z_A = 1 ==> quitC_1^A = CLim_1, increment C_2^A by 1
The full description of the protocol consists of the following steps:
If any of the counters C_1^A, C_2^A, C_3^A is equal to 0, A finishes
the protocol with an error that informs of exceeding the number of
trials that is controlled by the corresponding counter.
A decrements each of the counters C_1^A, C_2^A, C_3^A by 1, requests
open authentication information from B and sends the ID_A identifier.
If any of the counters C_1^B, C_2^B, C_3^B is equal to 0, B finishes
the protocol with an error that informs of exceeding the number of
trials that is controlled by the corresponding counter.
B decrements each of the counters C_1^B, C_2^B, C_3^B by 1.
B sends the values of ind, salt and the ID_ALG identifier to A.
B also can OPTIONALLY send the ID_B identifier to A.
All following calculations are done by B in the elliptic curve group
defined by the ID_ALG identifier.
A sets the curve defined by the received ID_ALG identifier as the
used elliptic curve. All following calculations are done by A in this elliptic curve group.
A calculates the point Q_PW^A = int (F (PW, salt, 2000))*Q_ind.
A chooses randomly (according to the uniform distribution) the value
alpha, alpha is in {1,…,q-1}, and assigns z_A = 0.
A sends the value u_1 = alpha*P - Q_PW^A to B.
After receiving u_1, B checks that u_1 is in E. If it is not, B finishes
with an error, considering the authentication process unsuccessful.
B calculates Q_B = u_1 + Q_PW, assigns z_B = 0 and chooses randomly
(according to the uniform distribution) the value betta, betta is in {1,…,q-1}.
If m/q*Q_B = O, B assigns Q_B = betta*P and z_B = 1.
B calculates K_B = HASH (BYTES(( m/q*betta*(mod q))*Q_B )).
B sends the value u_2 = betta*P + Q_PW to A.
After receiving u_2, A checks that u_2 is in E. If it is not, A finishes
with an error, considering the authentication process unsuccessful.
A calculates Q_A = u_2 - Q_PW^A.
If m/q*Q_A = O, then A assigns Q_A = alpha*P and z_A = 1.
A calculates K_A = HASH (BYTES(( m/q*alpha(mod q))*Q_A )).
A calculates U_1 = BYTES(u_1), U_2 = BYTES(u_2).
A calculates MAC_A = HMAC (K_A, 0x01 || ID_A || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A),
where DATA_A is an OPTIONAL string that is authenticated with MAC_A
(if it is not used, then DATA_A is considered to be of zero length).
A sends DATA_A, MAC_A to B.
B calculates U_1 = BYTES(u_1), U_2 = BYTES(u_2).
B checks that the values MAC_A and HMAC (K_B, 0x01 || ID_A || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A)
are equal. If they are not, it finishes with an error, considering the authentication process unsuccessful.
If z_B = 1, B finishes, considering the authentication process unsuccessful.
B sets the value of C_1^B to CLim_1 and increments C_2^B by 1.
B calculates MAC_B = HMAC(K_B, 0x02 || ID_B || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A || DATA_B),
where DATA_B is an OPTIONAL string that is authenticated with MAC_B
(if it is not used, then DATA_B is considered to be of zero length).
B sends DATA_B, MAC_B to A.
A checks that the values MAC_B and HMAC (K_A, 0x02 || ID_B || ind || salt || U_1 || U_2 || ID_ALG (OPTIONAL) || DATA_A || DATA_B)
are equal. If they are not, it finishes with an error, considering the authentication process unsuccessful.
If z_A = 1, A finishes, considering the authentication process unsuccessful.
A sets the value of C_1^A to CLim_1 and increments C_2^A by 1.
After the successful finish of the procedure the subjects A and B
are mutually authenticated and each subject has an explicitly authenticated value of K = K_A = K_B.
N o t e s :
In the case when the interaction process can be initiated by any subject (client or server) the ID_A and ID_B options MUST be used
and the receiver MUST check that the identifier he had received is not equal to his own, otherwise, it finishes the protocol.
If an OPTIONAL parameter ID_A (or ID_B) is not used in the protocol, it SHOULD
be considered equal to a fixed byte string (zero-length string is allowed) defined by a specific implementation.
The ind, ID_A, ID_B and salt parameters can be agreed in advance.
If some parameter is agreed in advance, it is possible not to send it during
a corresponding step. Nevertheless, all parameters MUST be used as corresponding
inputs to HMAC function during stages 20, 23, 26 and 28.
The ID_ALG parameter can be fixed or agreed in advance.
The ID_ALG parameter is RECOMMENDED to be used in HMAC during stages 20, 23, 26 and 28.
Continuation of protocol interaction in case of any of the counters
C_1^A, C_1^B being equal to zero MAY be done without changing password.
In this case these counters can be used for protection against denial-of-service attacks.
For example, continuation of interaction can be allowed after a certain delay.
Continuation of protocol interaction in case of any of the counters
C_2^A, C_3^A, C_2^B, C_3^B being equal to zero MUST be done only after changing password.
It is RECOMMENDED that during the stages 9 and 14 the points u_1 and u_2 are sent in a non-compressed format (BYTES(u_1) and BYTES(u_2)).
However, the point compression MAY be used.
The use of several Q points can reinforce the independence of the data streams
in case of working with several applications, when, for example, two high-level protocols can use two
different points. However, the use of more than one point is OPTIONAL.
This section provides an example of possible algorithm for generation
of each point Q_i in the set {Q_1,...,Q_N} that corresponds to the given elliptic curve E.
The algorithm is based on choosing points with coordinates with known preimages of a
cryptographic hash function H, which is the GOST R 34.11-2012 hash function (see ) with 256-bit output, if
2^254 < q < 2^256, and the GOST R 34.11-2012 hash function (see ) with 512-bit output , if 2^508 < q < 2^512.
The algorithm consists of the following steps:
Set i = 1, SEED = 0, s = 4.
Calculate X = int(HASH(BYTES(P)||bytes_s(SEED))) mod p.
Check that the value of X^3 + aX + b is a quadratic residue in the field F_p.
If it is not, set SEED = SEED + 1 and return to Step 2.
Choose the value of Y = min{r1, r2}, where r1, r2 from {0,1,...,p-1} are such that r1 != r2 and r1^2 = r2^2 = R mod p for R = X^3 + aX + b.
Check that for the point Q = (X,Y) the following relations hold: Q != O and q*Q = O.
If they do, go to Step 6; if not, set SEED = SEED + 1 and return to Step 2.
Set Q_i = Q. If i < N, then set i = i+1 and go to Step 2, else finish.
With the defined algorithm for any elliptic curve E point sets {Q_1,...,Q_N}
are constructed. Constructed points in one set MUST have distinct X-coordinates.
N o t e : The knowledge of a hash function preimage prevents knowledge of the
multiplicity of any point related to generator point P. It is of primary
importance, because such a knowledge could be used to implement an attack
against protocol with exhaustive search of password.
We thank Lolita Sonina, Georgiy Borodin, Sergey Agafin and Ekaterina
Smyshlyaeva for their careful readings and useful comments.
Any cryptographic algorithms, particularly HASH function and HMAC function,
that are used in the SESPAKE protocol MUST be carefully designed and MUST be able to withstand all known types of cryptanalytic attack.
It is RECOMMENDED that the HASH function satisfies the following condition:
hashlen <= log_2(q) + 4, where hashlen is the lengths of the HASH function output.
The output length of hash functions that are used in the SESPAKE protocol is RECOMMENDED to be greater or equal to 256 bits.
The points Q_1, Q_2,...,Q_N and P MUST be chosen in such a way that they are provable pseudorandom. As a practical matter,
this means that the algorithm for generation of each point Q_i in the set {Q_1,...,Q_N} (see )
ensures that multiplicity of any point under any other point is unknown.
For a certain ID_ALG using N = 1 is RECOMMENDED.
N o t e: The exact adversary models, which have been considered during the
security evaluation, can be found in the paper , containing the security proofs.
Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012
The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.
These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.
PKCS #5: Password-Based Cryptography Specification Version 2.0
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.
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.
HMAC: Keyed-Hashing 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, SHA-1, 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
GOST R 34.10-2012: Digital Signature Algorithm
This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832.
GOST R 34.11-2012: Hash Function
This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.
Fundamental Elliptic Curve Cryptography Algorithms
This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.
Information technology. Cryptographic data security. Signature and verification
processes of [electronic] digital signature
Federal Agency on Technical Regulating and Metrology (In Russian)
Information technology. Cryptographic Data Security. Hashing function
Federal Agency on Technical Regulating and Metrology (In Russian)
On the Security of One Password Authenticated Key Exchange Protocol
The following test examples are made for the protocol implementation that is
based on the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 .
The English versions of these standards can be found in and .
There is one point Q_1 for each of the elliptic curves below.
These points were constructed using the method described in , in case when N = 1,
where the GOST R 34.11-2012 hash function (see ) with 256-bit output is used if 2^254 < q < 2^256,
the GOST R 34.11-2012 hash function (see ) with 512-bit output is used if 2^508 < q < 2^512.
Each of the points complies with the GOST R 34.10-2012 standard and
is represented by a pair of (X, Y) coordinates in the canonical form and
by a pair of (U, V) coordinates in the twisted Edwards form in accordance with the document
for the curves that have the equivalent representations in this form.
There is a SEED value for each point, by which it was generated.
This protocol implementation uses
the GOST R 34.11-2012 hash function (see ) with 256-bit output as the H function
and the HMAC_GOSTR3411_2012_512 function defined in as a PRF function for the F function.
The parameter len is considered equal to 256, if 2^254 < q < 2^256, and equal to 512, if 2^508 < q < 2^512.
The test examples for the point of each curve in are given below.
The points from the were generated with the following point verification script in Python: