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 was 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 was 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 protocol 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 ;
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
the GOST R 34.10-2012 standard:
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;
generator of the subgroup of order q;
the coordinates of the elliptic curve point in the canonical form;
zero point of the elliptic curve.
This memo uses the following functions:
the value of the GOST R 34.11-2012 hash function (see ) with 256-bit output for a message T;
the value of the GOST R 34.11-2012 hash function (see ) with 512-bit output for a message T;
the 256-bit value of 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 using HMAC_GOSTR3411_2012_512 defined
in as PRF 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.
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};
if the byte string w'= (w_1,…,w_t) is in B_t, then int(w') is an integer w = 256^(t-1)w_t + … + 256^(0)w_1;
if the byte string w'= (w_1,…,w_t) is in B_t, then INT(w') is an integer W = 256^(t-1)w_1 + … + 256^(0)w_t;
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);
If (X, Y) is an elliptic curve point then the byte representation of (X,Y)
is a concatenation of the coordinates of this point X||Y;
the length of the byte representations of the coordinates X and Y is equal
to the minimum possible length of the byte representation of the subgroup generator p.
The protocol is used by subjects A and B that are commencing key establishment with password-based authentication.
Various elliptic curves can be used in the protocol. For each elliptic
curve supposted by clients the following values must be defined:
the curve identifier ID_ALG, that is a byte string of 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 identifier ID_A of subject A (optional), a byte string of an arbitrary length.
The unique identifier ID_A of the subject A (optional, see. Note 2), 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 of the elliptic curve used in the protocol.
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 identifier ID_B of subject B (optional), a byte string of an arbitrary length.
The unique identifier ID_B of the subject B (optional, see. Note 2), 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 described 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 = P and z_B = 1.
B calculates K_B = H_256 (( m/q*betta*(mod q))*Q_B ), where the input of
a hash function is a little-endian representation of the obtained point (x-coordinate first, then y-coordinate).
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 = P and z_A = 1.
A calculates K_A = H_256 (( m/q*alpha(mod q))*Q_A ), where the input of
a hash function is a little-endian representation of the obtained point (x-coordinate first, then y-coordinate).
A calculates MAC_A = HMAC (K_A, 0x01 || ID_A || ind || salt || u_1 || u_2 || 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 checks that the values MAC_A and HMAC (K_B, 0x01 || ID_A || ind || salt || u_1 || u_2 || 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 increases C_2^B by 1.
B calculates MAC_B = HMAC(K_B, 0x02 || ID_B || ind || salt || u_1 || u_2 || 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 || 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 increases 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:
Keys K_A, K_B in steps 13 and 18 are produced according to VKO_GOSTR3410_2012_256, algorithm defined in .
In the case where the interaction process can be initiated by any subject (client or server) the ID_A and ID_B options MUST be used
and the resiver 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 19, 21, 24 and 26.
The ID_ALG parameter can be fixed or agreed in advance.
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.
For a given elliptic curve E the algorithm of construction
of each point Q_i in the set {Q_1,…,Q_N} that corresponds to this curve is
based on choosing points with coordinates with known preimages of a
cryptographic hash function H, which is H_256, if
2^254 < q < 2^256, and H_512 , if 2^508 < q < 2^512. The algorithm consists of the following steps:
Choose an arbitrary SEED value with length of 32 bytes or more.
Calculate X = INT (H (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, return to Step 1.
Choose the value of Y arbitrarily from the set {+sqrt(A),-sqrt(A)},
where A = X^3 + aX + b. Here sqrt(A) is an element of F_p, for which (sqrt(A))^2 = A mod p.
Check that for point Q = (X,Y) the following relations hold: Q != O and q*Q = O.
If they do not, return to Step 1.
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 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, Georgy Borodin, Sergei Agafin and Ekaterina
Smyshlyaeva for their careful readings and useful comments.
This entire document is about security considerations.
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)
There are three points (Q_1, Q_2, Q_3) for each of the elliptic curves below.
This points were constructed using the method described in .
The same method should be used for constructing, if necessary, additional points.
Each of the points is represented by a pair of (X, Y) coordinates in the canonical form and
by a pair of (U, V) coordinates in the twisted Edward form in accordance with the document
for the curves that have the equivalent representation in this form.
There is a SEED value for each point, by which it was generated.
The test examples for one of the three points of each curve
in of this document are given below.