RFC 9189: GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2
- S. Smyshlyaev, Ed.,
- D. Belyavsky,
- E. Alekseev
Abstract
This document specifies three new cipher suites, two new signature algorithms, seven new supported groups, and two new certificate types for the Transport
Layer Security (TLS) protocol version 1.2 to support the Russian cryptographic standard algorithms (called "GOST" algorithms).
This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations
This specification facilitates implementations that aim to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types.¶
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
This document specifies three new cipher suites, two new signature algorithms, seven new supported groups, and two new certificate types for the Transport Layer Security (TLS)
protocol version 1.2 [RFC5246] (note that [RFC5246] has been obsoleted by [RFC8446] ) to support the set of Russian cryptographic standard algorithms (called "GOST" algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations
The CTR_OMAC cipher suites use the GOST R 34.12-2015 (see [RFC7801] and [RFC8891]) block ciphers.¶
The CNT_IMIT cipher suite uses the GOST 28147-89 [RFC5830] block cipher.¶
This document specifies the profile of the TLS protocol version 1.2 with GOST algorithms. The profile of the TLS protocol version 1.3 [RFC8446] with GOST algorithms is specified in a separate document [DraftGostTLS13].¶
This specification facilitates implementations that aim to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types.¶
2. Conventions Used in This Document
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
3. Basic Terms and Definitions
This document follows the terminology from [RFC8446bis] for "preliminary secret" and "extended
This document uses the following terms and definitions for the sets and operations on the elements of these sets:¶
- B_t
- 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}.¶
- B*
- the set of all byte strings of a finite length (hereinafter referred to as "strings"), including the empty string.¶
- A[i..j]
- 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.¶
- L(A)
- the length of the byte string A in bytes.¶
- A | C
- 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.¶
- A XOR C
- bitwise exclusive-or of byte strings A and C both belonging to B_t (both are of length t bytes), i.e., a string in B_t such that if A = (a_1, a_2, ... , a_t) and 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.¶
- i & j
- bitwise AND of unsigned integers i and j.¶
- STR_t
- the transformation that maps an integer i = 256t-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).¶
- str_t
- the transformation that maps an integer i = 256t-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).¶
- INT
- the transformation that maps a string a = (a_1, ... , a_t) in B_t into the integer INT(a) = 256t-1 * a_1 + ... + 256 * a_{t-1} + a_t (the interpretation of the byte string in big-endian format as an integer).¶
- int
- the transformation that maps a string a = (a_1, ... , a_t) in B_t into the integer int(a) = 256t-1 * a_t + ... + 256 * a_2 + a_1 (the interpretation of the byte string in little-endian format as an integer).¶
- k
- the length of the block cipher key in bytes.¶
- n
- the length of the block cipher block in bytes.¶
- Q_c
- the public key stored in the client's certificate.¶
- d_c
- the private key that corresponds to the Q_c key.¶
- Q_s
- the public key stored in the server's certificate.¶
- d_s
- the private key that corresponds to the Q_s key.¶
- q_s
- an order of a cyclic subgroup of the elliptic curve points group containing point Q_s.¶
- P_s
- the distinguished generator of the subgroup of order q_s that belongs to the same curve as Q_s.¶
- r_c
-
the random string contained in the Client
Hello .random field (see [RFC5246]).¶ - r_s
-
the random string contained in the Server
Hello .random field (see [RFC5246]).¶
4. Cipher Suite Definitions
This document specifies the CTR_OMAC cipher suites and the CNT_IMIT cipher suite.¶
The CTR_OMAC cipher suites have the following values:¶
The CNT_IMIT cipher suite has the following value:¶
4.1. Record Payload Protection
The profile of TLS 1.2 with GOST algorithms requires that the compression not be used.¶
All of the cipher suites described in this document use such modes of operation (see Section 4.3.3) that protect the records in the same way as if they were protected by a stream cipher. 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 [RFC5246]):¶
where TLSCiphertext
The connection key material is a key material that
consists of the sender
The record key material is a key material that is generated from the connection key material and is used to protect a record with a certain sequence number. Note that with some cipher suites defined in this document, the record key material can be equal to the connection key material.¶
In this section, the TLSCiphertext
4.1.1. CTR_OMAC
In the CTR_OMAC cipher suites, the record key material differs from the connection key material, and for the seqnum sequence number consists of:¶
The K_ENC_seqnum and K_MAC_seqnum values are calculated using the TLSTREE function defined in Section 8.1, the connection key material, and the seqnum sequence number . IV_seqnum is calculated by adding the seqnum value to sender_write_IV modulo 2(n/2)*8:¶
The TLSCiphertext
Note that the CTR_OMAC cipher suites use the authenticate
4.1.2. CNT_IMIT
In the CNT_IMIT cipher suite, the record key material is equal to the connection key material and consists of:¶
The TLSCiphertext
Note that the CNT_IMIT cipher suite uses the authenticate
4.2. Key Exchange and Authentication
The cipher suites defined in this document use a key encapsulation mechanism based on Diffie-Hellman to share the TLS preliminary secret.¶
Figure 1 shows all messages involved in the TLS key establishment protocol (full handshake).
A Server
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 preliminary 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 the CTR_OMAC and CNT_IMIT cipher suites consists of the following steps:¶
This section specifies the data structures and computations used by the profile of TLS 1.2 with GOST algorithms.
The specifications for the ClientHello, ServerHello, Server Certificate, Certificate
4.2.1. Hello Messages
The ClientHello message is generated in accordance with Section 7.4.1.2 of [RFC5246] and must meet the following requirements:¶
The ServerHello message is generated in accordance with Section 7.4.1.3 of [RFC5246] and must meet the following requirements:¶
4.2.2. Server Certificate
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 [RFC5246].¶
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).¶
4.2.3. CertificateRequest
This message is sent by the server when requesting client authentication and is generated in accordance with Section 7.4.4 of [RFC5246].¶
If the CTR_OMAC or CNT_IMIT cipher suite is negotiated, the Certificate
4.2.4. ClientKeyExchange
The Client
The body of the Client
The Gost
The DER encoding rules are used to encode the Gost
4.2.4.1. CTR_OMAC
In the CTR_OMAC cipher suites, the body of the Client
The client generates the Client
Upon receiving the Client
4.2.4.2. CNT_IMIT
In the CNT_IMIT cipher suite, the body of the Client
The client generates the Client
In the context of this document, the Gost
The Gost28147
The key
Upon receiving the Client
4.2.5. CertificateVerify
The client generates the value sgn as follows:¶
where SIGN_{d_c} is the GOST R 34.10-2012 [RFC7091] 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 the gostr34102012
Here, "handshake
The TLS Certificate
where the Signature
4.2.6. Finished
The TLS Finished message is generated in accordance with Section 7.4.9 of [RFC5246].¶
The verify
4.3. Cryptographic Algorithms
4.3.1. Block Cipher
The cipher suite TLS
The cipher suite TLS
The cipher suite TLS
4.3.2. MAC Algorithm
The CTR_OMAC cipher suites use the One-Key MAC (OMAC) construction defined in [GOST3413-2015], which is the same as the Cipher-Based MAC (CMAC) mode defined in [CMAC] where the Kuznyechik or Magma block cipher (see Section 4.3.1) is used instead of the AES block cipher (see [IK2003] 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 MAC function gostIMIT28147 defined in Section 8.4 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 [RFC4357]. The resulting MAC length is 4 bytes, and the MAC key length is 32 bytes.¶
4.3.3. Encryption Algorithm
The CTR_OMAC cipher suites use the block cipher in the CTR-ACPKM encryption mode defined in [RFC8645] as the ENC function.
The section size N is 4 KB for the TLS
The CNT_IMIT cipher suite uses the block cipher in counter encryption mode (CNT) defined in Section 6 of [RFC5830], with the CryptoPro key meshing algorithm defined in [RFC4357] as the ENC function.¶
Note that the counter modes used in cipher suites described in this document act as stream ciphers.¶
4.3.4. PRF and HASH Algorithms
The PRF for all the cipher suites defined in this document is the PRF
The hash function HASH for all the cipher suites defined in this document is the GOST R 34.11-2012 [RFC6986] hash algorithm with a 32-byte (256-bit) hash code.¶
4.3.5. SNMAX Parameter
The SNMAX parameter defines the maximal value of the seqnum sequence number during one TLS 1.2 connection and is defined as follows:¶
5. New Values for the TLS SignatureAlgorithm Registry
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 Signature
This document defines new values for the "TLS Signature
where the gostr34102012
According to [RFC7091], the GOST R 34.10-2012 signature algorithm with a 32-byte (256-bit) or 64-byte (512-bit) key length
uses the GOST R 34.11-2012 [RFC6986] hash algorithm with a 32-byte (256-bit) or 64-byte (512-bit) hash code, respectively
(the hash algorithm is intrinsic to the signature algorithm).
Therefore, if the Signature
So, to represent gostr34102012
6. New Values for the TLS Supported Groups Registry
The Supported Groups Extension indicates the set of elliptic curves supported by the client and is defined in [RFC8422] and [RFC7919].¶
This document defines new values for the "TLS Supported Groups" registry:¶
where the values correspond to the following curves:¶
7. New Values for the TLS ClientCertificateType Identifiers Registry
The Client
This document defines new values for the "TLS Client
To use the gost_sign256 or gost_sign512 authentication mechanism, the client MUST possess a
certificate containing a GOST R 34
The client proves possession of the private key corresponding to the
certified key by including a signature in the Certificate
8. Additional Algorithms
The cipher suites specified in this document rely on some additional algorithms, specified below; the use of these algorithms is not confined to the use in TLS specified in this document.¶
8.1. TLSTREE
The TLSTREE function is defined as follows:¶
where¶
8.1.1. Key Tree Parameters
The CTR_OMAC cipher suites use the TLSTREE function for the rekeying approach. The constants for it are defined as in the table below.¶
8.2. Key Export and Key Import Algorithms
8.2.1. KExp15 and KImp15 Algorithms
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 [MODES] and 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 [MODES]).¶
The KImp15 key import algorithm is defined as follows:¶
where the OMAC function is defined in [MODES] and the CTR-Decrypt(K, IV, S) function denotes the decryption of message S on key K and nonce IV in the CTR mode (see [MODES]).¶
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 a key with the KImp15 algorithm, the IV value may be sent with the export key representation.¶
8.2.2. KExp28147 and KImp28147 Algorithms
The KExp28147 key export algorithm is defined as follows:¶
where the gost28147IMIT function is defined in Section 8.4 and the ECB-Encrypt(K, S) function denotes the encryption of message S on key K with the block cipher GOST 28147-89 in the electronic codebook (ECB) mode (see [RFC5830]).¶
The KImp28147 key import algorithm is defined as follows:¶
where the gost28147IMIT function is defined in Section 8.4 and
the ECB
8.3. Key Exchange Generation Algorithms
8.3.1. KEG Algorithm
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
The KEG_512 algorithm is defined as follows:¶
where VKO_512 is the VKO
8.3.2. KEG_28147 Algorithm
The KEG_28147 algorithm is defined as follows:¶
where the VKO_256 function is equal to the VKO
8.4. gostIMIT28147
gost28147IMIT
where the PAD function is the padding function that adds m zero bytes to the end of the message, m is the smallest, non-negative solution to the equation (L(M) + m) mod 8 = 0, and the MAC28147 function corresponds to the MAC generation mode defined in [RFC5830] with a 4-byte length output.¶
9. IANA Considerations
IANA has added the following values to the "TLS Cipher Suites" registry:¶
IANA has added the following values to the "TLS Signature
IANA has added the following values to the "TLS Signature
IANA has also added the following footnote to values 64 and 65 in the "TLS Signature
These values were allocated from the Reserved state due to a misunderstanding of the difference between Reserved and Unallocated that went undetected for a long time. Additional allocations from the Reserved state are not expected, and the TLS SignatureScheme registry is suitable for use for new allocations instead of this registry.¶
IANA has added the following values to the "TLS Supported Groups" registry:¶
IANA has added the following values to the "TLS Client
10. Historical Considerations
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 {0xFF, 0x85} instead of the {0xC1, 0x02} value to indicate the TLS
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 (see [RFC4357] and [R
The client should be prepared to handle any of these correctly if the corresponding group is included in the supported
11. Security Considerations
The cipher suites defined in this document do not provide Perfect Forward Secrecy.¶
The authenticate
12. References
12.1. Normative References
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC4357]
-
Popov, V., Kurepkin, I., and S. Leontiev, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", RFC 4357, DOI 10
.17487 , , <https:///RFC4357 www >..rfc -editor .org /info /rfc4357 - [RFC4490]
-
Leontiev, S., Ed. and G. Chudov, Ed., "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", RFC 4490, DOI 10
.17487 , , <https:///RFC4490 www >..rfc -editor .org /info /rfc4490 - [RFC5246]
-
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10
.17487 , , <https:///RFC5246 www >..rfc -editor .org /info /rfc5246 - [RFC5746]
-
Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10
.17487 , , <https:///RFC5746 www >..rfc -editor .org /info /rfc5746 - [RFC5830]
-
Dolmatov, V., Ed., "GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms", RFC 5830, DOI 10
.17487 , , <https:///RFC5830 www >..rfc -editor .org /info /rfc5830 - [RFC6986]
-
Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10
.17487 , , <https:///RFC6986 www >..rfc -editor .org /info /rfc6986 - [RFC7091]
-
Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10
.17487 , , <https:///RFC7091 www >..rfc -editor .org /info /rfc7091 - [RFC7366]
-
Gutmann, P., "Encrypt
-then , RFC 7366, DOI 10-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" .17487 , , <https:///RFC7366 www >..rfc -editor .org /info /rfc7366 - [RFC7627]
-
Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10
.17487 , , <https:///RFC7627 www >..rfc -editor .org /info /rfc7627 - [RFC7801]
-
Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher "Kuznyechik"", RFC 7801, DOI 10
.17487 , , <https:///RFC7801 www >..rfc -editor .org /info /rfc7801 - [RFC7836]
-
Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012", RFC 7836, DOI 10
.17487 , , <https:///RFC7836 www >..rfc -editor .org /info /rfc7836 - [RFC7919]
-
Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10
.17487 , , <https:///RFC7919 www >..rfc -editor .org /info /rfc7919 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8422]
-
Nir, Y., Josefsson, S., and M. Pegourie
-Gonnard , "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487 , , <https:///RFC8422 www >..rfc -editor .org /info /rfc8422 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8645]
-
Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric Keys", RFC 8645, DOI 10
.17487 , , <https:///RFC8645 www >..rfc -editor .org /info /rfc8645 - [RFC8891]
-
Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: Block Cipher "Magma"", RFC 8891, DOI 10
.17487 , , <https:///RFC8891 www >..rfc -editor .org /info /rfc8891
12.2. Informative References
- [CMAC]
-
Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", NIST Special Publication 800-38B, DOI 10
.6028 , , <https:///NIST .SP .800 -38B www >..nist .gov /publications /recommendation -block -cipher -modes -operation -cmac -mode -authentication -0 - [DraftGostTLS13]
-
Smyshlyaev, S., Alekseev, E., Griboedova, E., Babueva, A., and L. Nikiforova, "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft
-smyshlyaev , , <https://-tls13 -gost -suites -05 datatracker >..ietf .org /doc /html /draft -smyshlyaev -tls13 -gost -suites -05 - [GOST3413-2015]
- Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Modes of operation for block ciphers", GOST R 34.13-2015, .
- [IK2003]
-
Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 2003, Lecture Notes in Computer Science, Vol. 2887, DOI 10
.1007 , , <https:///978 -3 -540 -39887 -5 _11 doi >..org /10 .1007 /978 -3 -540 -39887 -5 _11 - [MODES]
-
Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", NIST Special Publication 800-38A, DOI 10
.6028 , , <https:///NIST .SP .800 -38A csrc >..nist .gov /publications /detail /sp /800 -38a /final - [R
-1323565 .1 .024 -2019] -
Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Elliptic curve parameters for the cryptographic algorithms and protocols", R 1323565
.1 , ..024 -2019 - [RFC8446bis]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft
-ietf , , <https://-tls -rfc8446bis -04 datatracker >..ietf .org /doc /html /draft -ietf -tls -rfc8446bis -04
Appendix A. Test Examples
A.1. Test Examples for CTR_OMAC Cipher Suites
A.1.1. TLSTREE Examples
A.1.1.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher Suite
A.1.1.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite
A.1.2. Record Examples
A.1.2.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher Suite
A.1.2.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite
A.1.3. Handshake Examples
The Client
A.1.3.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher Suite
A.1.3.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite
A.2. Test Examples for CNT_IMIT Cipher Suites
A.2.1. Record Examples
A.2.2. Handshake Examples
The Client