GOST Cipher Suites for TLS 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 a set of cipher suites for the Transport
Layer Security (TLS) protocol Version 1.2 to support the Russian cryptographic standard algorithms.
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).
All of them use the GOST R 34.11-2012 hash algorithm
(the English version can be found in )
and the GOST R 34.10-2012 signature algorithm
(the English version can be found in )
but use different encryption 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 ):
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xXX, 0xXX};
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xXX, 0xXX}.
The CNT_IMIT cipher suites use the GOST 28147-89 block cipher
(the English version can be found in ):
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xXX, 0xXX}.
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 all byte strings of a finite length
(hereinafter referred to as strings), including the empty
string;
The set of byte vectors of size s, s >= 0, for s = 0 the
B_s set consists of a single empty element of size 0.
If W is an element of B_s, then W = (w^1, w^2,
..., w^s), where w^1, w^2, ..., w^s are in {0, ... , 255};
the string b[i..j] = (b_i, b_{i+1}, ... , b_j) in B_{j-i+1} where 1<=i<=j<=s and b = (b_1, ... , b_s) in B_s
the byte length of the byte string X;
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;
the transformation that maps a string a = (a_s, ... , a_1) in B_s
into the integer Int_s(a) = 256^{s-1} * a_s + ... + 256 * a_2 + a_1
(the interpretation of the binary string as an integer);
the transformation inverse to the mapping Int_s (the interpretation of an integer as a binary string);
the transformation that maps an integer i = 256^{s-1} * i_s + ... + 2 * i_2 + i_1
into the string Str_s(i) = (i_1, ... , i_s) in B_s;
the byte-length of the block cipher key;
the block size of the block cipher (in bytes);
the public key stored in the client's certificate;
the private key that corresponds to Q_C key;
the server's public key;
the server's private key;
the random string that corresponds to ClientHello.random field from ;
the random string that corresponds to ServerHello.random field from .
All of the cipher suites described in this document MUST use
the stream cipher (see ) to protect records.
The TLSCiphertext structure for the CTR_OMAC and CNT_IMIT cipher suits is specified
in accordance with the GenericStreamCipher case (see Section 6.2.3.1 of ):
Here TLSCiphertext.fragment is generated as described in and .
The connection key material 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 according to section 6.3 of .
In case of the CTR_OMAC cipher_suites there is a certain key material which is used by the peer to
protect a record that corresponds to the seqnum sequence number (in the following simply record key material) and consist of
K_ENC_seqnum, K_MAC_seqnum and IV_seqnum values that are calculated
using the TLSTREE function defined in
and the connection key material:
K_ENC_seqnum = TLSTREE(sender_write_key, seqnum);
K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seqnum);
IV_seqnum = Vec_{n/2}((Int_{n/2}(sender_write_IV) + seqnum) mod 2^{n*8/2}).
The TLSCiphertext.fragment that corresponds to the seqnum sequence number is equal to the ENCValue_seqnum value that is calculated as follows:
1. The MAC value (MACValue_seqnum) is generated by the MAC algorithm (see ) similar to Section 6.2.3.1 of
except the used MAC key: the sender_write_MAC_key is replaced by the K^seqnum_MAC key:
MACData_seqnum = Str_8(seqnum) | type_seqnum | version_seqnum | length_seqnum | fragment_seqnum;
MACValue_seqnum = MAC(K_MAC_seqnum, MACData_seqnum),
where type_seqnum, version_seqnum, length_seqnum, fragment_seqnum are the
TLSCompressed.type, the TLSCompressed.version, the TLSCompressed.length and the TLSCompressed.fragment values of the record with the seqnum sequence number.
2. The stream cipher ENC (see ) encrypts the entire data with the MACValue as follows:
ENCData_seqnum = fragment_seqnum | MACValue_seqnum;
ENCValue_seqnum = ENC( K_ENC_seqnum, IV_seqnum, ENCData_seqnum).
In case of the CNT_IMIT cipher_suites the TLSCiphertext.fragment that corresponds to the seqnum sequence number is equal to the ENCValue_seqnum value that is calculated as follows:
1. The MAC value (MACValue_seqnum) is generated by the MAC algorithm (see ) as follows:
MACData_i = Str_8(i) | type_i | version_i | length_i | fragment_i, i in {0, ... , seqnum};
MACValue_seqnum = MAC(sender_write_MAC_key, MACData_0 | ... | MACData_seqnum),
where type_i, version_i, length_i, fragment_i are the
TLSCompressed.type, the TLSCompressed.version, the TLSCompressed.length and the TLSCompressed.fragment values of the record with the i sequence number.
2. The stream cipher ENC (see ) encrypts the entire data ENCData_i with the MACValue_i that correspond to the record sequence number i with the MACValue as follows:
ENCData_i = fragment_i | MACValue_i, i in {0, ... , seqnum};
ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_write_key, sender_write_IV, ENCData_0 | ... |ENCData_seqnum).
All of the cipher suites described in this document use ECDH to compute the TLS premaster secret.
Figure 1 shows all messages involved in the TLS key establishment protocol (aka full handshake).
A ServerKeyExchange MUST NOT be sent (the server's certificate
contains all the necessary keying information required by the client
to arrive at the premaster secret).
The key exchange process consists of the following steps:
The client generates ECDHE key pair (Q_eph, k_eph), Q_eph is on the same curve as the
server's long-term public key Q_S.
The client generates the premaster secret value PS. The PS value is chosen by random from B_32.
Using k_eph, server long-term public key and some generated nonce value the client generates the encryption key for key-wrap algorithm
and then sends the PS value wrapped with particular key-wrap algorithm.
The client sends its ephemeral public key Q_eph and the wrapped PS value in the ClientKeyExchange message.
The server extract the premaster secret value PS using its long-term secret key k_S
in accordance with the key wrap algorithm.
The server side of the channel is always authenticated; the client side is optionally authenticated.
The server is authenticated using it's long term private key from the certificate and proving that it knows a shared secret.
The client is authenticated when the server is checking its signature.
The proposed cipher suites has direct impact
only on the ClientHello, the ServerHello, the CertificateRequest, the ClientKeyExchange and the CertificateVerify handshake messages,
that are described bellow in greater detail in terms of the content and processing of these messages.
The ClientHello message 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.
While using cipher CTR_OMAC cipher suites the ClientHello.extensions field MUST contain the following three extensions:
signature_algorithms (see ), extended_master_secret (see ), renegotiation_info (see ).
While using the CNT_IMIT cipher suite the ClientHello.extensions field MUST contain the signature_algorithms (see ) extension.
And it is RECOMMENDED to contain the following two extensions:
extended_master_secret (see ), renegotiation_info (see ).
The ServerHello message 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.
While using the CTR_OMAC cipher suites the ServerHello.extensions field MUST contain the following two extensions:
extended_master_secret (see ), renegotiation_info (see ).
While using the CNT_IMIT cipher suite it is RECOMMENDED for the ServerHello.extensions field to contain the following two extensions:
extended_master_secret (see ), renegotiation_info (see ).
Note: If the extended_master_secret extension is agreed, then the master secret value MUST be
calculated in accordance with .
The signature_algorithms extension is described in Section 7.4.1.4.1 of (see ) and is specified as follows.
The set of supported hash algorithms is specified as follows:
where gostr34112012_256 and gostr34112012_512 values correspond to
the GOST R 34.11-2012 hash algorithm with 32-byte (256-bit) and 64-byte (512-bit) hash code respectively.
The set of supported signature algorithms is specified as follows:
where 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.
When this message is sent: this message is sent when requesting client authentication.
Meaning of this message: the server uses this message to suggest acceptable certificates.
The TLS CertificateRequest message is extended as follows.
where the SignatureAndHashAlgorithm structure is specified in , the ClientCertificateType and the DistinguishedName structures are specified as follows.
The ClientKeyExchange structure is defined as follows.
The PSKeyTransport 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 .
The CTR_OMAC cipher suites use the KExp15 and the KImp15 algorithms defined in for key wrapping.
The export representation of the PS value is calculated as follows.
1. The client generates the keys K^EXP_MAC and K^EXP_ENC using the KEG function described in :
H = HASH(r_C | r_S);
K^EXP_MAC | K^EXP_ENC = KEG(k_eph, Q_S, H).
2. The client generates export representation of the premaster secret value PS:
IV = H[25..24 + n / 2];
PSExp = KExp15(PS, K^EXP_MAC, K^EXP_ENC, IV).
3. The client creates the PSKeyTransport structure that is defined as follows:
Here the PSEXP field contains the PSExp value and the ephemeralPublicKey field contains the Q_eph value.
After receiving the ClientKeyExchange message the server process it as follows.
1. Checks the next three conditions fulfilling and terminates the connection with fatal error if not.
Q_eph is on the same curve as server public key;
Q_eph is not equal to zero point;
q * Q_eph is not equal to zero point.
2. Generates the keys K^EXP_MAC and K^EXP_ENC using the KEG function described in :
H = HASH(r_C | r_S);
K^EXP_MAC | K^EXP_ENC = KEG(k_S, Q_eph, H).
3. Extracts the common secret PS from the export representation PSExp:
IV = H[25..24+n/2];
PS = KImp15(PSExp, K^EXP_MAC, K^EXP_ENC, IV).
The client generates the key KEK using the VKO function. VKO is one of the functions
VKO_GOSTR3410_2012_256 or VKO_GOSTR3410_2012_512 described in .
The particular function depends on the elliptic curve used in the server certificate.
The KEK calculation is made as follow
UKM = HASH(r_C | r_S)
KEK = VKO(k_eph, Q_S, UKM)
Generates the diversified key KEK(UKM) using the function
CryptoPro KEK Diversification Algorithm defined in
Generates export representation of the common secret PS:
Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK) as described in . Call the result CEK_MAC.
Encrypt CEK in ECB mode using KEK(UKM). Call the ciphertext CEK_ENC.
The wrapped key is the string UKM | CEK_ENC | CEK_MAC in B_44.
The TLSGostKeyTransportBlob is defined as
The Gost28147-89-EncryptedKey.encryptedKey value contais CEK_ENC value, the Gost28147-89-EncryptedKey.macKey contains
CEK_MAC, and GostR3410-TransportParameters.ukm contains the UKM value.
There MUST be a keyBlob.transportParameters.ephemeralPublicKey field containing the client ephemeral public key Q_eph.
After receiving ClientKeyExchange message server process it as follows
Checks the next four conditions fulfilling and terminates the connection with fatal error if not.
Q_eph is on the same curve as server public key;
Q_eph is not equal to zero point;
q * Q_eph is not equal to zero point;
Checks if UKM = HASH(r_C | r_S).
Generates the key KEK using the VKO function.
KEK = VKO(k_S, Q_eph, UKM).
Generates the diversified key KEK(UKM) using the function
CryptoPro KEK Diversification Algorithm defined in
Extracts the common secret PS from the export representation:
Decrypt CEK_ENC in ECB mode using KEK(UKM). Call the result CEK.
Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK). If the
result is not equal to CEK_MAC return a fault value.
The TLS CertificateVerify message is extended as follows.
where SignatureAndHashAlgorithm structure is specified in .
The CertificateVerify.signature field is specified as follows.
where SIGN_{k_C} is the GOST R 34.10-2012 signature algorithm, k_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 signature algorithm and l = 64 for gostr34102012_512 signature algorithm.
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 for this suite is 16 bytes and the key length 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 for this suite is 8 bytes and the key length 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 for this suite is 8 bytes and the key length 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 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 CTR_OMAC cipher suites use the block cipher in CTR-ACPKM encryption mode defined in as the ENC encryption algorithm.
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 initial counter nonce is defined as in .
The CNT_IMIT cipher suite uses use the block cipher in counter encryption mode (CNT)
defined in Section 6 of with the CryptoPro Key Meshing
algorithm defined in as the ENC encryption algorithm.
The SNMAX parameter defines the maximal amount of messages that can be send during one TLS 1.2 connection.
For TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite this amount is
2^64 - 1 messages and for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC is 2^32 - 1 messages.
The pseudorandom function (PRF) for all the cipher suites defined in this document is the PRF_TLS_GOSTR3411_2012_256 function described 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 TLSTREE function is defined as follows:
TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, Vec(i & C_1)), Vec(i & C_2)), Vec(i & C_2)),
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 functions 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.
Key tree constantsCipherSuitesC_1, C_2, C_3TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC
C_1=0xFFFFFFFF00000000,
C_2=0xFFFFFFFFFFF80000,
C_3=0xFFFFFFFFFFFFFFC0
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
C_1=0xFFFFFFC000000000,
C_2=0xFFFFFFFFFE000000,
C_3=0xFFFFFFFFFFFFF000
Algorithms KExp15 and KImp15 are keywrap algorithms those provide confidentiality and integrity of keys.
These algorithms use the block cipher defined by the particular cipher suite.
The inputs of Kexp15 key export algorithm are
key K in V*;
MAC key K^Exp_MAC in B_k;
encryption key K^Exp_ENC in B_k;
IV value in B_{n/2}.
The keys K^Exp_MAC and K^Exp_ENC MUST be independent. The export representation of the key K is computed as follows
Compute the MAC value of n byte length:
KEYMAC = OMAC(K^Exp_MAC, IV | K),
where OMAC(K, M) is a MAC function defined in .
Compute the KEXP value:
KEXP = encKey | encKeyMac = CTR(K^Exp_ENC, IV, KEYMAC),
where |encKey| = |K|, |encKeyMAC| = |KEYMAC|, CTR(K, IV, M) is the counter encryption mode CTR defined in
where s = n which can be considered as the CTR mode defined in .
The export representation of key K is the result of the Kexp15 algorithm and is defined as
KExp15(K, K^Exp_MAC, K^Exp_ENC, IV) = KEXP.
The import of key K via KImp15 algorithm is restoring the key K from export representation KEXP with keys
K^Exp_MAC and K^Exp_ENC from B_k and value IV from B_{n/2}. This is performed as follows
The string KEXP is decrypted on the key K^Exp_ENC with counter encryption mode CTR.
The result of this operation is the string K|KEYMAC.
Compute the MAC value of n byte length:
KEYMAC' = OMAC(K^Exp_MAC, IV | K).
If KEYMAC is not equal to KEYMAC' return a fault value.
Otherwise the result of the KImp15 algorithm is defined as
KImp15(KEXP, K^KExp_MAC, K^KExp_ENC, IV) and is equal to string K.
During the use of one keypair (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 KEG algorithm of export key elaboration takes on input private key d, public key Q and string h from B_32.
Then it returns the string from B_64.
The KEG algorithm is defined by two distinct ways depending on the private key length.
If the length of private key d is 64 bytes the KEG algorithm is defined as follows:
KEG(d, Q, h) = VKO_512(d, Q, UKM),
where VKO_512 is the VKO_GOSTR3410_2012_512 function defined in and the UKM parameter is
equal to r = Int_32(h[1..16]) if r is not equal to 0 and is equal to 1 otherwise.
If the length of private key d is 32 bytes the KEG algorithm is defined as follows:
KEG(d, Q, h) = KDFTREE_256(K_EXP, "kdf tree", seed, 1),
where KDFTREE_256 is the KDF_TREE_GOSTR3411_2012_256 function defined in
and the parameters K_EXP and seed are defined as
K_EXP = VKO_256(d, Q, UKM);
UKM is equal to r if r is not equal to 0 and is equal to 1 otherwise;
r = Int_32(h[1..16]);
seed = h[17..24],
where VKO_256 is the function VKO_GOSTR3410_2012_256 defined in .
gost28147IMIT (IV, K, M) IV in B_8, K in B_32, M in B* is a MAC computation algorithm with 4 bytes output that proceed as follow
Divide M into 8 byte blocks: M = M_0 | M_1 | ... | M_r.
Let M' = M_0 (xor) IV | M_1 | M_2 | ... | M_r.
Compute MAC value with 4 byte length with algorithm described in using K as key and M' as input.
The result of MAC computation is the result of gost28147IMIT (IV, K, M) algorithm.
IANA has added the following entries in the TLS Cipher Suite Registry: TODO
Re-keying Mechanisms for Symmetric Keys CryptoPro
OMAC: One-Key CBC MAC.
Iwata T., Kurosawa K. (2003)
Information technology. Cryptographic data security. Block ciphers
Federal Agency on Technical Regulating and Metrology
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.
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