GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
CryptoPro18, Suschevsky val Moscow127018Russian Federation+7 (495) 995-48-20svs@cryptopro.ruCryptoPro18, Suschevsky val Moscow127018Russian Federationalekseev@cryptopro.ruCryptoPro18, Suschevsky val Moscow127018Russian Federationess@cryptopro.ruCryptoPro18, Suschevsky val Moscow127018Russian Federationbabueva@cryptopro.ru
General
Network Working GroupGOST, cipher suite, TLS
This document specifies a set of cipher suites for the Transport
Layer Security (TLS) protocol Version 1.3 to support the Russian cryptographic standard algorithms.
This document specifies four new cipher suites for the Transport Layer Security (TLS)
Protocol Version 1.3 to support the set of Russian cryptographic standard algorithms called GOST algorithms (see ).
These cipher suites use the hash algorithm GOST R 34.11-2012 (the English version can be found in ),
the AEAD algorithm MGM and the block ciphers GOST R 34.12-2015
(the English version can be found in ).
The GOST cipher suites have the following values:
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {TBD1};
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {TBD2};
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {TBD3};
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {TBD4}.
These cipher suites have different key lifetime value (see ), so
they are divided into two types: the _S (strong) cipher suites and the _L (light) cipher suites (see , ).
This document specifies seven new signature schemes (see ) to be used with GOST cipher suites.
These signature schemes use the signature algorithm GOST R 34.10-2012
(the English version can be found in ) and have the following values:
gostr34102012_256a = {TBD5};
gostr34102012_256b = {TBD6};
gostr34102012_256c = {TBD7};
gostr34102012_256d = {TBD8};
gostr34102012_512a = {TBD9};
gostr34102012_512b = {TBD10};
gostr34102012_512c = {TBD11}.
Additionally this document specifies the key exchange and authentication process in case of negotiating
GOST cipher suites (see ).
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 terms and definitions for the sets and operations
on the elements of these sets:
the set of byte strings of length t, t >= 0, for t = 0 the
B_t set consists of a single empty string of zero length.
If A is an element of B_t, then A = (a_1, a_2,
... , a_t), where a_1, a_2, ... , a_t are in {0, ... , 255};
the set of all byte strings of a finite length
(hereinafter referred to as strings), including the empty
string;
the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{j-i+1} where A = (a_1, ... , a_t) in B_t and 1<=i<=j<=t;
the byte length of the byte string A;
concatenation of strings A and C both belonging to B*, i.e.,
a string in B_{|A|+|C|}, where the left substring in
B_|A| is equal to A, and the right substring in B_|C| is
equal to C;
bitwise AND of integers i and j;
the transformation that maps an integer i = 256^{t-1} * i_1 + ... + 256 * i_{t-1} + i_t
into the byte string STR_t(i) = (i_1, ... , i_t) in B_t
(the interpretation of the integer as a byte string in big-endian format);
the transformation that maps an integer i = 256^{t-1} * i_t + ... + 256 * i_2 + i_1
into the byte string str_t(i) = (i_1, ... , i_t) in B_t
(the interpretation of the integer as a byte string in little-endian format);
the byte-length of the block cipher key;
the byte-length of the block cipher block;
elliptic curve indicated by client in "supported_group" extension;
the public key stored in the client's certificate;
the private key that corresponds to the Q_c key;
the public key stored in the server's certificate;
the private key that corresponds to the Q_s key;
subgroup order of group of points of the elliptic curve that corresponds to Q_s;
the point of order q_s that belongs to the same curve as Q_s;
This document defines the following new values for the "Cipher Suites" registry, that can be used in the ClientHello.cipher_suites
and ServerHello.cipher_suites fields for the particular cipher suite:
Each cipher suite defines the pair of the AEAD algorithm and
the hash algorithm. AEAD algorithm is used for the payload protection
(see for more details)
and hash algorithm is used for key derivation and handshake
message authentication.
All of the cipher suites described in this document use
the block cipher in Authenticated Encryption with Associated
Data (AEAD) mode (see ) to protect records.
The TLSCiphertext structure is specified in accordance with as follows.
The encrypted_record field of TLSCiphertext is set to AEADEncrypted, where AEADEncrypted is computed as follows:
AEADEncrypted = AEAD-Encrypt(sender_write_key, nonce, additional_data, plaintext),
where
AEAD-Encrypt function is defined in ;
the traffic key material that
consists of the sender_write_key (either the client_write_key or the server_write_key)
and the sender_write_IV (either the client_write_IV or the server_write_IV) parameters
is generated in accordance with Section 7.3 of ;
the nonce is derived from the sequence number and the sender_write_iv
(see Section 5.3 of );
the plaintext input to the AEAD algorithm is the encoded
TLSInnerPlaintext structure;
the additional data input is the record header:
In order to decrypt and verify, the cipher takes as input the key,
nonce, additional data and the AEADEncrypted value. The output is
either the plaintext or an error indicating that the decryption
failed.
plaintext of encrypted_record =
AEAD-Decrypt(sender_write_key, nonce,
additional_data, AEADEncrypted)
where AEAD-Decrypt function is defined in .
The GOST cipher suites use the block cipher in MGM authenticated encryption with associated data mode
defined in . The base block cipher is defined in .
The size S of the authentication field is n bytes. The IVlen parameter is n bytes.
The record key material is a key material that is generated from the traffic key material
and is used to protect a record with the certain sequence number. All of the cipher suites described
in this document use TLSTREE algorithm to derive record key material ().
For each record with sequence number seqnum AEAD-Encrypt and AEAD-Decrypt functions are defined as follows.
MGM-Encrypt and MGM-Decrypt functions are defined in ,
TLSTREE function is defined in .
The maximum value of the sequence number seqnum during one TLS 1.3 connection is defined in .
The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik
as a base block cipher for the AEAD algorithm.
The block length n is 16 bytes and the key length k is 32 bytes.
The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST uses Magma
as a base block cipher for the AEAD algorithm.
The block length n is 8 bytes and the key length k is 32 bytes.
The GOST cipher suites use the TLSTREE function for the external re-keying approach (see ). The TLSTREE function is defined as follows:
TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), STR_8(i & C_2)), STR_8(i & C_3)),
where
K_root in B_32;
i in {0, 1, ... , 2^64 - 1};
KDF_j(K, D), j = 1, 2, 3, K in B_32,
D in B_8, is the key derivation function based on the KDF_GOSTR3411_2012_256
function defined in :
KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D);
KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D);
KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D).
C_1, C_2, C_3 are constants defined by the particular cipher suite:
The SNMAX parameter defines the maximal value of the sequence number seqnum during one TLS 1.3 connection and is defined as follows:
The function HASH for all the cipher suites defined in this document is the GOST R 34.11-2012 hash algorithm with 32-byte (256-bit) hash code.
The function HASH is used for key derivation process (see Section 7.1 of ),
Finished message calculation, Transcript-Hash function, PSK binder value calculation,
derivation of record key material (see ) and other purposes during key exchange process.
The signature scheme values are used to indicate to the server/client
which signature algorithms and curves can be used in digital signatures and
are defined by the SignatureSchemeList structure (see Section 4.2.3 of ) as follows:
This document defines new values for the "SignatureAlgorithm" registry that can be used in the
SignatureSchemeList.supported_signature_algorithms field for the particular signature scheme:
where the values correspond to the following signature algorithms and curves:
This document defines the SIGN function which is used for computing signature value
in CertificateVerify message (see ) as follows.
where
q is the subgroup order of group
of points of the elliptic curve;
l is defined as follows:
l = 32 for gostr34102012_256a, gostr34102012_256b, gostr34102012_256c
and gostr34102012_256d values of the SignatureScheme field;
l = 64 for gostr34102012_512a, gostr34102012_512b and gostr34102012_512c
values of the SignatureScheme field;
SIGNGOST(M, d_sign) is the GOST R 34.10-2012 signature
algorithm.
The signature value sgn is the concatenation of two strings that are byte representations of r and s
values in the little-endian format.
According to the GOST R 34.10-2012 signature algorithm with
32-byte (256-bit) or 64-byte (512-bit) key length use the GOST R
34.11-2012 hash algorithm with 32-byte (256-bit) or 64-byte
(512-bit) hash code respectively (the hash algorithm is intrinsic to
the signature algorithm).
Key exchange and authentication process in case of using GOST cipher suites
is defined in and , .
Additionally the proposed cipher suites specify some Handshake messages (see ).
TLS 1.3 supports three basic key exchange modes in accordance with :
1. (EC)DHE
2. PSK-only
3. PSK with (EC)DHE
All of the cipher suites described in this document use Diffie-Hellman over elliptic curves in (EC)DHE and PSK with (EC)DHE key exchange modes.
Diffie-Hellman over finite fields SHOULD NOT be used. This document defines the process of ECDHE shared secret calculation
(see ) and specifies the elliptic curves that can be used during this process
(see ).
In accordance with PSKs can be divided into two types:
internal PSKs which can be established during the previous connection;
external PSKs which can be established out of band.
This document defines that PSK-only key exchange mode SHOULD be used only
with the internal PSKs. External PSKs SHOULD be used together with certificates
in PSK with (EC)DHE mode only.
ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
For GOST cipher suites the contents are the
serialized value of the following struct:
X and Y, respectively, contain the binary representations of the x and y
values of point Q (Q = (x, y)) in the little-endian format and are specified as follows:
X = str_{coordinate_length}(x);
Y = str_{coordinate_length}(y).
The coordinate_length value is defined in Table 5.
The client calculates ECDHE shared secret value in accordance with the following steps:
1. Chooses from all supported curves E_1, ..., E_R the set of curves E_{i_1}, ..., E_{i_r}, 1 ≤ i_1 ≤ i_r ≤ R, where
r ≥ 1 in the case of first message;
r = 1 in the case of responding to HelloRetryRequest message, E_{i_1} SHOULD correspond to the curve
indicated in the key_share extension in the HelloRetryRequest message.
2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., (d_C^{i_r}, Q_C^{i_r}) corresponding to
E_{i_1}, ..., E_{i_r} curves, where for each i in {i_1, ..., i_r}:
d_C^i is chosen from {1, ..., q_i - 1} at random;
Q_C^i = d_C^i * P_i.
3. Sends ClientHello message specified in accordance with Section 4.1.2 of
and , which contains:
key_share extension with public ephemeral keys Q_C^{i_1}, ..., Q_C^{i_r} specified in accordance with
Section 4.2.8 of ;
supported_group extension with supported curves E_1, ..., E_R specified in accordance with
Section 4.2.7 of .
4. In case of receiving HelloRetryRequest message client should return to step 1 and correct parameters according to
Section 4.1.2 of .
In case of receiving ServerHello message client proceeds to the next step. In other cases client MUST terminate the
connection with "unexpected_message" alert.
5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., R}, from ServerHello message and checks whether
the Q_res belongs to E_res. If this check fails, the client MUST
abort the handshake with "handshake_failure" alert.
6. Generates Q^ECDHE:
Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res.
7. Client MUST check whether the computed shared
secret Q^ECDHE is not equal to zero point. If this check fails, the client MUST
abort the handshake with "handshake_failure" alert.
8. Shared secret value ECDHE is the byte representation of the coordinate X^ECDHE
of point Q^ECDHE in the little-endian format:
ECDHE = str_{coordinate_length}(X^ECDHE),
where coordinate_length is defined in Table 5.
Upon receiving the ClientHello message, the server calculates ECDHE shared secret
value in accordance with the following steps:
1. Chooses the curve E_res, res in {1, ..., R} from the list of curves E_1, ..., E_R indicated in supported_group
extension in ClientHello message and the corresponding public ephemeral key value Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r},
1 ≤ i_1 ≤ i_r ≤ R, indicated in key_share extension. If no corresponding public ephemeral key value is found
(res in {1, ..., R}\{i_1, ..., i_r}), server MAY send HelloRetryRequest message with key_share extension indicated E_res and
wait for the next ClientHello message.
2. Checks whether Q_res belongs to E_res. If this check fails, the server MUST
abort the handshake with "handshake_failure" alert.
3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to E_res:
d_S^res is chosen from {1, ..., q_res - 1} at random;
Q_S^res = d_S^res * P_res.
4. Sends ServerHello message specified in accordance with Section 4.1.3 of
and with key_share extension indicated public ephemeral key
value Q_S^res corresponding to E_res.
5. Generates Q^ECDHE:
Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res.
6. Server MUST check whether the computed shared
secret Q^ECDHE is not equal to zero point. If this check fails, the server MUST
abort the handshake with "handshake_failure" alert.
7. Shared secret value ECDHE is the byte representation of the coordinate X^ECDHE
of point Q^ECDHE in the little-endian format:
ECDHE = str_{coordinate_length}(X^ECDHE),
where coordinate_length is defined in Table 5.
The supported_groups extension indicates the set of elliptic curves supported by the client and
is defined in .
This document defines the following values for the "Supported Groups" registry:
Where the values correspond to the following curves and the following values of
coordinate_length parameter ("cl" column).
These values are the same as in .
In accordance with authentication can happen
via signature with certificate or via symmetric pre-shared key (PSK).
The server side of the channel is always
authenticated; the client side is optionally authenticated.
PSK-based authentication happens as a side effect of key exchange.
This document defines that external PSKs SHOULD be combined only
with the mutual autentication.
Certificate-based authentication happens via authentication messages.
This document defines the signature schemes that are used for
certificate-based authentication (see ) and specifies some autehtication messages
(see , ).
The proposed cipher suites specify the ClientHello, ServerHello, CertificateRequest and CertificateVerify handshake messages,
that are described in further detail below.
The ClientHello message is generated in accordance with the following
requirements.
The ClientHello.cipher_suites field SHOULD contain cipher suites with the values defined in .
The ClientHello.extensions field MAY contain the signature_algorithms and signature_algorithms_cert extensions.
The extension_data field of these extensions contains a SignatureSchemeList value, where SignatureSchemeList.supported_signature_algorithms
field SHOULD contain only the values defined in .
The ClientHello.extensions field MAY contain the supported_group extension. The extension_data field
of this extension contains a NamedGroupList value, where NamedGroupList.named_group_list field
SHOULD contain only the values defined in .
The ClientHello.extensions field SHOULD NOT contain early_data extension.
The ServerHello message is generated in accordance with the following
requirements.
The ServerHello.cipher_suites field SHOULD contain cipher suites with the values defined in .
This message is sent when requesting client authentication and is specified in accordance with as follows.
If the GOST cipher suite is negotiated, the CertificateRequest message MUST meet the following requirements.
The CertificateRequest.extensions field MUST contain the signature_algorithms extension. The "extension_data" field
of this extension contains a SignatureSchemeList value, where SignatureSchemeList.supported_signature_algorithms field
SHOULD contain only the values defined in .
The CertificateRequest.extensions field MAY contain the signature_algorithms_cert extension. The "extension_data" field
of this extension contains a SignatureSchemeList value, where SignatureSchemeList.supported_signature_algorithms field
SHOULD contain only the values defined in .
This CertificateVerify message is used to provide explicit proof that an endpoint
possesses the private key corresponding to its certificate and is specified
in accordance with as follows.
If the GOST cipher suite is negotiated, the CertificateVerify message MUST meet the following requirements.
The CertificateVerify.algorithm field SHOULD contain only the signature schemes with the values defined in .
The CertificateVerify.signature field contains sgn value, which is computed as follows:
sgn = SIGN(M, d_sign),
where
function SIGN is defined in ,
structure of M is defined in Section 4.4.3 of ,
d_sign is the sender long-term private key that corresponds to
the sender long-term public key Q_sign from the sender's certificate.
IANA is asked to assign numbers TBD1, TBD2, TBD3 and TBD4 with the names
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L,
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L,
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S,
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S to
the "TLS Cipher Suites" registry with this document as reference, as shown below.
IANA is asked to assign numbers TBD5, TBD6, TBD7, TBD8, TBD9, TBD10 and TBD11 with the names
gostr34102012_256a,
gostr34102012_256b,
gostr34102012_256c,
gostr34102012_256d,
gostr34102012_512a,
gostr34102012_512b,
gostr34102012_512c
to the "TLS SignatureAlgorithm" registry, as shown below.
Due to historical reasons in addition to the curve identifier values listed in Table 5
there exist some extra identifier values that correspond to
the signature schemes as follows.
Client should be prepared to handle any of them correctly if corresponding signature scheme is included in the signature_algorithms
or signature_algorithms_cert extensions.
In order to create an effective implementation and to resist attacks client and server SHOULD stick to the following rules.
1. While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD be invoked only if sequence number seqnum reaches such value that
seqnum & C_j != (seqnum - 1) & C_j.
Otherwise the previous value should be used.
2. For each pre-shared key value PSK the binder_key value should be computed only once
within all connections where ClientHello message contains a
pre_shared_key extension indicating this PSK value.
3. Server SHOULD NOT send Application Data prior to receiving first client's Finished message in a mutually
authenticated connection.
Multilinear Galois Mode (MGM) CryptoPro TC 26TC 26CryptoPro
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2
CryptoPro Cryptocom Independent Consultant
Information technology. Cryptographic data security. Block ciphers
Federal Agency on Technical Regulating and Metrology
Information technology. Cryptographic data security. Signature and verification
processes of [electronic] digital signature
Federal Agency on Technical Regulating and Metrology
Information technology. Cryptographic Data Security. Hashing function
Federal Agency on Technical Regulating and Metrology
TODO
Lilia Akhmetzyanova
CryptoPro
lah@cryptopro.ru
Alexandr Sokolov
CryptoPro
sokolov@cryptopro.ru
Vasily Nikolaev
CryptoPro
nikolaev@cryptopro.ru