GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2
CryptoPro18, Suschevsky val Moscow127018Russian Federation+7 (495) 995-48-20svs@cryptopro.ruCryptocom14/2 Kedrova stMoscow117218Russian Federationbeldmit@gmail.comIndependent Consultantmjos@iki.fi
General
Network Working GroupGOST, cipher suite, TLS
This document specifies three new cipher suites for the Transport
Layer Security (TLS) protocol Version 1.2 to support the Russian cryptographic standard algorithms (called GOST algorithms).
This specification is developed to facilitate implementations
that wish to support the GOST algorithms. This document does not imply
IETF endorsement of the cipher suites.
This document specifies three new cipher suites for the Transport Layer Security (TLS)
Protocol Version 1.2 to support the set of Russian cryptographic standard algorithms (called GOST algorithms).
These cipher suites use the same hash algorithm GOST R 34.11-2012 (the English version can be found in )
and the same signature algorithm GOST R 34.10-2012
(the English version can be found in )
but use different encryption and MAC algorithms, so they are divided into two types: the CTR_OMAC cipher suites and the CNT_IMIT cipher suite.
The CTR_OMAC cipher suites use the GOST R 34.12-2015 block ciphers
(the English version can be found in ).
The CNT_IMIT cipher suite uses the GOST 28147-89 block cipher
(the English version can be found in ).
This document specifies cipher suites only for the TLS protocol version 1.2. The cipher suites for the TLS protocol version 1.3 to support the set of Russian cryptographic standard algorithms are specified in a separate document .
This specification is developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites.
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.
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 length of the byte string A in bytes;
concatenation of strings A and C both belonging to B*, i.e.,
a string in B_{L(A)+L(C)}, where the left substring in
B_L(A) is equal to A, and the right substring in B_L(C) is
equal to C;
bitwise exclusive-or of byte strings A and C both belonging to B_t (i.e. both are of length t bytes), i.e.,
a string in B_t such that if A = (a_1, a_2, ... , a_t), C = (c_1, c_2, ... , c_t) then
A XOR C = (a_1 (xor) c_1, a_2 (xor) c_2, ... , a_t (xor) c_t) where (xor) is bitwise exclusive-or of bytes;
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 transformation that maps a string a = (a_1, ... , a_t) in B_t
into the integer INT(a) = 256^{t-1} * a_1 + ... + 256 * a_{t-1} + a_t
(the interpretation of the byte string in big-endian format as an integer);
the transformation that maps a string a = (a_1, ... , a_t) in B_t
into the integer int(a) = 256^{t-1} * a_t + ... + 256 * a_2 + a_1
(the interpretation of the byte string in little-endian format as an integer);
the length of the block cipher key in bytes;
the length of the block cipher block in bytes;
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;
an order of a cyclic subgroup of elliptic curve points group containing point Q_s;
the point of order q_s that belongs to the same curve as Q_s;
the random string contained in ClientHello.random field (see );
the random string contained in ServerHello.random field (see ).
This document specifies the CTR_OMAC cipher suites and the CNT_IMIT cipher suite.
The CTR_OMAC cipher suites have the following values:
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xC1, 0x00};
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xC1, 0x01}.
The CNT_IMIT cipher suite has the following value:
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xC1, 0x02}.
The compression method (see Section 6.2.2 of ) MUST be "null" in all of the cipher suites described in this document. This compression method is negotiated according to .
Note that the CompressionMethod.null operation is an identity operation; no fields of the TLSCompressed structure are altered.
All of the cipher suites described in this document use
the stream cipher (see ) to protect records.
The TLSCiphertext structure for the CTR_OMAC and CNT_IMIT cipher suites is specified
in accordance with the Standard Stream Cipher case (see Section 6.2.3.1 of ):
where TLSCiphertext.fragment is generated in accordance with when the CTR_OMAC cipher suite is used and when the CNT_IMIT
cipher suite is used.
The connection key material is a key material that
consists of the sender_write_key (either the client_write_key or the server_write_key),
the sender_write_MAC_key (either the client_write_MAC_key or the server_write_MAC_key) and the
sender_write_IV (either the client_write_IV or the server_write_IV) parameters
that are generated in accordance with Section 6.3 of .
The record key material is a key material that is generated from the connection key material and is used to protect a record with the certain sequence number.
Note that in some cipher suites defined in this document the record key material can be equal to the connection key material.
In this section the TLSCiphertext.fragment generation is described for one particular endpoint
(server or client) with the corresponding connection key material and record key material.
In case of the CTR_OMAC cipher suites the record key material differs from the connection key material, and for the sequence number seqnum consists of:
K_ENC_seqnum in B_k;
K_MAC_seqnum in B_k;
IV_seqnum in B_{n/2}.
The K_ENC_seqnum and K_MAC_seqnum values are calculated using the TLSTREE function defined in ,
the connection key material and the sequence number seqnum. IV_seqnum is calculated by adding seqnum value to sender_write_IV modulo 2^{(n/2)*8}:
K_ENC_seqnum = TLSTREE(sender_write_key, seqnum);
K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seqnum);
IV_seqnum = STR_{n/2}((INT(sender_write_IV) + seqnum) mod 2^{(n/2)*8}).
The TLSCiphertext.fragment that corresponds to the sequence number seqnum is equal to the ENCValue_seqnum value that is calculated as follows:
1. The MACValue_seqnum value is generated using the MAC algorithm (see ) similar to Section 6.2.3.1 of
except the sender_write_MAC_key is replaced by the K_MAC_seqnum key:
MACValue_seqnum = MAC(K_MAC_seqnum, STR_8(seqnum) | type_seqnum | version_seqnum | length_seqnum | fragment_seqnum),
where type_seqnum, version_seqnum, length_seqnum, fragment_seqnum are the
TLSCompressed.type, TLSCompressed.version, TLSCompressed.length and
TLSCompressed.fragment values of the record with the seqnum sequence number.
2. The entire data with the MACValue is encrypted with the ENC stream cipher (see ):
ENCValue_seqnum = ENC(K_ENC_seqnum, IV_seqnum, fragment_seqnum | MACValue_seqnum),
where fragment_seqnum is the TLSCompressed.fragment value of the record with the seqnum sequence number.
In case of the CNT_IMIT cipher suite the record key material is equal to the connection key material and consists of:
sender_write_key in B_k;
sender_write_MAC_key in B_k;
sender_write_IV in B_n.
The TLSCiphertext.fragment that corresponds to the sequence number seqnum is equal to the ENCValue_seqnum value that is calculated as follows:
1. The MACValue_seqnum value is generated by the MAC algorithm (see ) as follows:
MACValue_seqnum = MAC(sender_write_MAC_key, STR_8(0) | type_0 | version_0 | length_0 | fragment_0 | ... | STR_8(seqnum) | type_seqnum | version_seqnum | length_seqnum | fragment_seqnum),
where type_i, version_i, length_i, fragment_i, i in {0, ... , seqnum}, are the
TLSCompressed.type, TLSCompressed.version, TLSCompressed.length and TLSCompressed.fragment values of the record with the i sequence number.
Due to the use of the CBC-MAC based mode (see ) producing the
MACValue_seqnum value does not mean processing all previous records. It is enough to store only an
intermediate internal state of the MAC algorithm.
2. The entire data with the MACValue is encrypted with the ENC stream cipher (see ):
ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_write_key, sender_write_IV, fragment_0 | MACValue_0 | ... | fragment_seqnum | MACValue_seqnum),
where the length of the byte string ENCValue_i in bytes is equal to the length of the byte string (fragment_i | MACValue_i) in bytes, i in {0, ... , seqnum}.
Due to the use of the stream cipher (see ) producing the
ENCValue_seqnum value does not mean processing all previous records. It is enough to store only an intermediate
internal state of the ENC stream cipher.
All of the cipher suites described in this document use a key encapsulation mechanism based on Diffie-Hellman to share the TLS premaster secret.
Figure 1 shows all messages involved in the TLS key establishment protocol (full handshake).
A ServerKeyExchange MUST NOT be sent (the server's certificate
contains enough data to allow client to exchange the premaster secret).
The server side of the channel is always authenticated; the client side is optionally authenticated.
The server is authenticated by proving that it knows the premaster secret that is encrypted with the public key Q_s from the server's certificate.
The client is authenticated via its signature over the handshake transcript.
In general the key exchange process for both CTR_OMAC and CNT_IMIT cipher suites consists of the following steps:
The client generates the ephemeral key pair (d_eph, Q_eph) that corresponds to the server's public key Q_s stored in its certificate.
The client generates the premaster secret PS. The PS value is chosen from B_32 at random.
Using d_eph and Q_s the client generates the export key material (see and )
for the particular key export algorithm (see and )
to generate the export representation PSExp of the PS value.
The client sends its ephemeral public key Q_eph and PSExp value in the ClientKeyExchange message.
Using its private key d_s the server generates the import key material (see and )
for the particular key import algorithm (see and )
to extract the premaster secret PS from the export representation PSExp.
The cipher suites specified in this document define
the ClientHello, ServerHello, server Certificate, CertificateRequest, ClientKeyExchange, CertificateVerify and Finished handshake messages,
that are described in further detail below.
The ClientHello message is generated in accordance with Section 7.4.1.2 of and must meet the following requirements:
The ClientHello.compression_methods field MUST contain exactly one byte, set to zero, which corresponds to the "null" compression method.
The ClientHello.extensions field MUST contain the signature_algorithms extension (see ).
If the negotiated cipher suite is one of CTR_OMAC/CTR_IMIT and the client implementation
does not support generating the signature_algorithms extension with the values defined in ,
the server MUST either abort the connection or ignore this extension and behave as if
the client had sent the signature_algorithms extension with the values {8, 64} and {8, 65}.
The ServerHello message is generated in accordance with Section 7.4.1.3 of and must meet the following requirements:
The ServerHello.compression_method field MUST contain exactly one byte, set to zero, which corresponds to the "null" compression method.
The ServerHello.extensions field MUST NOT contain the encrypt_then_mac extension (see ).
This message is used to authentically convey the server's
public key Q_s to the client and is generated in accordance with Section 7.4.2 of .
Upon receiving this message the client validates the certificate chain, extracts the server's
public key, and checks that the key type is appropriate for the
negotiated key exchange algorithm. (A possible reason for a fatal
handshake failure is that the client's capabilities for handling
elliptic curves and point formats are exceeded).
This message is sent by the server when requesting client authentication and is generated in accordance with Section 7.4.4 of .
If the CTR_OMAC or CNT_IMIT cipher suite is negotiated, the CertificateRequest message MUST meet the following requirements:
the CertificateRequest.supported_signature_algorithm field MUST contain only signature/hash algorithm pairs with the values {8, 64} or {0, 65} defined in ;
the CertificateRequest.certificate_types field MUST contain only the gost_sign256 (67) or gost_sign512 (68) values defined in .
The ClientKeyExchange message is defined as follows.
The body of the ClientKeyExchange message consists of a GostKeyTransport/TLSGostKeyTransportBlob structure that contains an export representation of the premaster secret PS.
The GostKeyTransport structure corresponds to the CTR_OMAC cipher suites and is described in and
the TLSGostKeyTransportBlob corresponds to CNT_IMIT cipher suite and is described in .
In case of the CTR_OMAC cipher suites the body of the ClientKeyExchange message consists of the GostKeyTransport structure that is defined bellow.
The client generates the ClientKeyExchange message in accordance with the following steps:
1. Generates the ephemeral key pair (Q_eph, d_eph), where:
d_eph is chosen from {1, ... , q_s - 1} at random;
Q_eph = d_eph * P_s.
2. Generates export keys (K_EXP_MAC and K_EXP_ENC) using the KEG algorithm defined in :
H = HASH(r_c | r_s);
K_EXP_MAC | K_EXP_ENC = KEG(d_eph, Q_s, H).
3. Generates an export representation PSExp of the premaster secret PS using the KExp15 algorithm defined in :
IV = H[25..24 + n / 2];
PSExp = KExp15(PS, K_EXP_MAC, K_EXP_ENC, IV).
4. Generates the ClientKeyExchange message using the GostKeyTransport structure that is defined as follows:
where the keyExp field contains the PSExp value, the ephemeralPublicKey field contains the Q_eph value and the ukm field MUST be ignored by the server.
Upon receiving the ClientKeyExchange message, the server process it as follows.
1. Checks the following three conditions. If either of these checks fails, then the server MUST abort the handshake with an alert.
Q_eph belongs to the same curve as server public key Q_s;
Q_eph is not equal to zero point;
q_s * Q_eph is equal to zero point.
2. Generates export keys (K_EXP_MAC and K_EXP_ENC) using the KEG algorithm defined in :
H = HASH(r_c | r_s);
K_EXP_MAC | K_EXP_ENC = KEG(d_s, Q_eph, H).
3. Extracts the premaster secret PS from the export representation PSExp using the KImp15 algorithm defined in :
IV = H[25..24 + n / 2];
PS = KImp15(PSExp, K_EXP_MAC, K_EXP_ENC, IV).
In case of the CNT_IMIT cipher suite the body of the ClientKeyExchange message consists of a TLSGostKeyTransportBlob structure that is defined bellow.
The client generates the ClientKeyExchange message in accordance with the following steps:
1. Generates the ephemeral key pair (Q_eph, d_eph), where:
d_eph is chosen from {1, ... , q_s - 1} at random;
Q_eph = d_eph * P_s.
2. Generates export key (K_EXP) using the KEG_28147 algorithm defined in :
H = HASH(r_c | r_s);
K_EXP = KEG_28147(d_eph, Q_s, H).
3. Generates an export representation PSExp of the premaster secret PS using the KExp28147 algorithm defined in :
PSExp = IV | CEK_ENC | CEK_MAC = KExp28147(PS, K_EXP, H[1..8]).
4. Generates the ClientKeyExchange message using the TLSGostKeyTransportBlob structure that is defined as follows:
where GostR3410-KeyTransport, Gost28147-89-EncryptedKey and GostR3410-TransportParameters are defined according to Section 4.2.1 of .
In the context of this document the GostR3410-KeyTransport.transportParameters field is always used, the Gost28147-89-EncryptedKey.maskKey field is omitted,
the GostR3410-KeyTransport.transportParameters.ephemeralPublicKey field is always used.
The Gost28147-89-EncryptedKey.encryptedKey field contains the CEK_ENC value, the Gost28147-89-EncryptedKey.macKey field contains the
CEK_MAC value, and GostR3410-TransportParameters.ukm field contains the IV value.
The keyBlob.transportParameters.ephemeralPublicKey field contains the client ephemeral public key Q_eph. The encryptionParamSet
contains value 1.2.643.7.1.2.5.1.1 that corresponds to the id-tc26-gost-28147-param-Z parameters set defined in .
Upon receiving the ClientKeyExchange message, the server process it as follows.
1. Checks the following three conditions. If either of these checks fails, then the server MUST abort the handshake with an alert.
Q_eph belongs to the same curve as server public key Q_s;
Q_eph is not equal to zero point;
q_s * Q_eph is equal to zero point;
2. Generates export key (K_EXP) using the KEG_28147 algorithm defined in :
H = HASH(r_c | r_s);
K_EXP = KEG_28147(d_s, Q_eph, H).
3. Extracts the premaster secret PS from the export representation PSExp using the KImp28147 algorithm defined in :
PS = KImp28147(PSExp, K_EXP, H[1..8]).
Client generates the value sgn as follows:
where SIGN_{d_c} is the GOST R 34.10-2012 signature algorithm, d_c is a client
long-term private key that corresponds to the client long-term public key Q_c from the client's certificate,
l = 32 for gostr34102012_256 value of the SignatureAndHashAlgorithm field and l = 64 for gostr34102012_512 value of the SignatureAndHashAlgorithm field.
Here handshake_messages refers to all handshake messages sent or
received, starting at ClientHello and up to CertificateVerify, but not including
the last message, including the type and length fields of the handshake messages.
The TLS CertificateVerify message is specified as follows.
where SignatureAndHashAlgorithm structure is specified in and CertificateVerify.signature field contains sgn value.
The TLS Finished message is generated in accordance with Section 7.4.9 of .
The verify_data_length value is equal to 32 for the CTR_OMAC cipher suites and is equal to 12 for the CNT_IMIT cipher suite.
The PRF function is defined in .
The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC MUST use Kuznyechik
as a base block cipher for the encryption and MAC algorithm.
The block length n is 16 bytes and the key length k is 32 bytes.
The cipher suite TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC MUST use Magma
as a base block cipher for the encryption and MAC algorithm.
The block length n is 8 bytes and the key length k is 32 bytes.
The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT MUST use GOST 28147-89 as a base block cipher
with the set of parameters id-tc26-gost-28147-param-Z defined in .
The block length n is 8 bytes and the key length k is 32 bytes.
The CTR_OMAC cipher suites use the OMAC message authentication code construction defined in ,
which can be considered as the CMAC mode defined in where Kuznyechik or Magma block cipher (see ) are used instead of AES block cipher
(see for more detail) as the MAC function. The resulting MAC length is equal to the block length and the MAC key length is 32 bytes.
The CNT_IMIT cipher suite uses the message authentication code function gostIMIT28147 defined in with the initialization vector IV = IV0, where IV0 in B_8 is a string of all zeros,
with the CryptoPro Key Meshing algorithm defined in . The resulting MAC length is 4 bytes and the MAC key length is 32 bytes.
The CTR_OMAC cipher suites use the block cipher in CTR-ACPKM encryption mode defined in as the ENC function.
The section size N is 4 KB for TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite
and 1 KB for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher suite.
The CNT_IMIT cipher suite uses the block cipher in counter encryption mode (CNT)
defined in Section 6 of with the CryptoPro Key Meshing
algorithm defined in as the ENC function.
The pseudorandom function (PRF) for all the cipher suites defined in this document is the PRF_TLS_GOSTR3411_2012_256 function defined in .
The hash 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 SNMAX parameter defines the maximal value of the sequence number seqnum during one TLS 1.2 connection and is defined as follows:
The signature/hash algorithm pairs are used to indicate to the server/client
which algorithms can be used in digital signatures and
are defined by the SignatureAndHashAlgorithm structure (see Section 7.4.1.4.1 of ).
This document defines new values for the "SignatureAlgorithm Registry" that can be used in the SignatureAndHashAlgorithm.signature field for the particular signature/hash algorithm pair:
where the gostr34102012_256 and gostr34102012_512 values correspond to
the GOST R 34.10-2012 signature algorithm with 32-byte (256-bit) and 64-byte (512-bit) key length respectively.
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).
Therefore, if the SignatureAndHashAlgorithm.signature field of a particular hash/signature pair listed in the Signature Algorithms Extension
is equal to the 64 (gostr34102012_256) or 65 (gostr34102012_512) value,
the SignatureAndHashAlgorithm.hash field of this pair MUST contain the "Intrinsic" value 8 (see ).
The Supported Groups Extension indicates the set of elliptic curves supported by the client and
is defined in and .
This document defines new values for the "Supported Groups" registry:
Where the values corresponds to the following curves:
The ClientCertificateType field of the CertificateRequest message contains a list of the types of certificate types that the client may
offer and is defined in Section 7.4.4 of .
This document defines new values for the "ClientCertificateType Identifiers" registry:
To use the gost_sign256 or gost_sign512 authentication mechanism, the client MUST possess a
certificate containing a GOST R 34.10-2012-capable public key that corresponds to the 32-byte (256-bit) or 64-byte (512-bit) signature key respectively.
The client proves possession of the private key corresponding to the
certified key by including a signature in the CertificateVerify
message as described in .
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};
C_1, C_2, C_3 are constants defined by the particular cipher suite (see );
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).
The CTR_OMAC cipher suites use the TLSTREE function for the re-keying approach. The constants for it
are defined as in the table below.
Algorithms KExp15 and KImp15 use the block cipher determined by the particular cipher suite.
The KExp15 key export algorithm is defined as follows.
where the OMAC function is defined in ,
the CTR-Encrypt(K, IV, S) function denotes the encryption of message S on key K and nonce IV in the CTR mode with s = n (see ).
The KImp15 key import algorithm is defined as follows.
where the OMAC function is defined in ,
the CTR-Decrypt(K, IV, S) function denotes the decryption of message S on key K and nonce IV in the CTR mode (see ).
The keys K_Exp_MAC and K_Exp_ENC MUST be independent. For every pair of keys (K_Exp_ENC, K_Exp_MAC) the IV values MUST be unique.
For the import of key K with the KImp15 algorithm every IV value MUST be sent with the export key representation
or be a preshared value.
The KExp28147 key export algorithm is defined as follows.
where the gost28147IMIT function is defined in ,
the ECB-Encrypt(K, S) function denotes the encryption of message S on key K with the block cipher GOST 28147-89 in the ECB mode (see ).
The KImp28147 key import algorithm is defined as follows.
where the gost28147IMIT function is defined in ,
the ECB-Decrypt(CEK_ENC, M) function denotes the decryption of ciphertext CEK_ENC on key K with a block cipher GOST 28147-89 in the ECB mode (see ).
The KEG algorithm is defined as follows:
where q is an order of a cyclic subgroup of elliptic curve points group containing point Q, d in {1, ... , q - 1}.
The KEG_256 algorithm is defined as follows:
where VKO_256 is the function VKO_GOSTR3410_2012_256 defined in and
KDFTREE_256 is the KDF_TREE_GOSTR3411_2012_256 function defined in with the parameter L equal to 512.
The KEG_512 algorithm is defined as follows:
where VKO_512 is the VKO_GOSTR3410_2012_512 function defined in .
The KEG_28147 algorithm is defined as follows:
where the VKO_256 function is equal to the VKO_GOSTR3410_2012_256 function defined in ,
the CPDivers function corresponds to the CryptoPro KEK Diversification Algorithm defined in , which takes as input the UKM value and the key value.
gost28147IMIT(IV, K, M) is a MAC algorithm with 4 bytes output and is defined as follows:
where the PAD function is the padding function that adds m zero bytes to the end of the message,
where m is the smallest, non-negative solution to the equation (L(M) + m) mod 8 = 0,
the MAC28147 function corresponds to Message Authentication Code Generation Mode
defined in with 4 byte length output.
IANA is asked to update the registry entries to reference this document when it is published as an RFC.
IANA has added numbers {0xC1, 0x00}, {0xC1, 0x01} and {0xC1, 0x02} with the names
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC,
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC,
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT to
the "TLS Cipher Suite" registry with this document as reference, as shown below.
IANA has added numbers 64, 65 with the names
gostr34102012_256,
gostr34102012_512,
to the "TLS SignatureAlgorithm" registry, as shown below.
IANA has added numbers 34, 35, 36, 37, 38, 39, 40 with the names
GC256A,
GC256B,
GC256C,
GC256D,
GC512A,
GC512B,
GC512C
to the "TLS Supported Groups" registry, as shown below.
IANA has added numbers 67, 68 with the names gost_sign256, gost_sign512
to the "ClientCertificateType Identifiers" registry, as shown below.
Note that prior to the existence of this document implementations could use only the values from the Private Use space in order to use the GOST-based algorithms.
So some old implementations
can still use the old value {0x00, 0x81} instead of the {0xC1, 0x02} value to indicate the TLS_GOSTR341112_256_WITH_28147_CNT_IMIT cipher suite;
one old value 0xEE instead of the values 64, 8 and 67 (to indicate the gostr34102012_256 signature algorithm, the Intrinsic hash algorithm and the gost_sign256 certificate type respectively);
one old value 0xEF instead of the values 65, 8 and 68 (to indicate the gostr34102012_512 signature algorithm, the Intrinsic hash algorithm and the gost_sign512 certificate type respectively).
Due to historical reasons in addition to the curve identifier values listed in Table 2
there exist some extra identifier values that correspond to
the curves GC256B, GC256C and GC256D as follows.
Client should be prepared to handle any of them correctly if corresponding group is included in the supported_groups extension (see and ).
This entire document is about security considerations.
OMAC: One-Key CBC MAC.
Iwata T., Kurosawa K. (2003)
Information technology. Cryptographic data security. Block ciphers
Federal Agency on Technical Regulating and Metrology
Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication
Dworkin, M.
Cryptographic Protection for Data Processing System,
Gosudarstvennyi Standard of USSR (In Russian)
Government Committee of the USSR for Standards
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
Information technology. Cryptographic data security. Modes of operation for block ciphers
Federal Agency on Technical Regulating and Metrology
Recommendation for Block Cipher Modes of Operation: Methods and Techniques
Dworkin, M.
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
CryptoPro CryptoPro CryptoPro CryptoPro
The ClientHello.extensions and the ServerHello.extensions fields contain the extended_master_secret extension (see ) and the renegotiation_info extension (see )
in the following examples.
The ClientHello.extensions and the ServerHello.extensions fields contain the renegotiation_info extension (see )
in the following examples.
Evgeny Alekseev
CryptoPro
alekseev@cryptopro.ru
Ekaterina Smyshlyaeva
CryptoPro
ess@cryptopro.ru
Grigory Sedov
CryptoPro
sedovgk@cryptopro.ru
Dmitry Eremin-Solenikov
Auriga
dbaryshkov@gmail.com