rfc9189.original   rfc9189.txt 
Network Working Group S.V. Smyshlyaev, Ed. Independent Submission S. Smyshlyaev, Ed.
Internet-Draft CryptoPro Request for Comments: 9189 CryptoPro
Intended status: Informational D. Belyavskiy Category: Informational D. Belyavskiy
Expires: 11 May 2022 Cryptocom ISSN: 2070-1721 Cryptocom
M-J. Saarinen E. Alekseev
Independent Consultant
E.K. Alekseev
CryptoPro CryptoPro
7 November 2021 February 2022
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version
1.2 1.2
draft-smyshlyaev-tls12-gost-suites-18
Abstract Abstract
This document specifies three new cipher suites, two new signature This document specifies three new cipher suites, two new signature
algorithms, seven new supported groups and two new certificate types algorithms, seven new supported groups, and two new certificate types
for the Transport Layer Security (TLS) protocol Version 1.2 to for the Transport Layer Security (TLS) protocol version 1.2 to
support the Russian cryptographic standard algorithms (called GOST support the Russian cryptographic standard algorithms (called "GOST"
algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms). This document specifies a profile of TLS 1.2 with GOST
algorithms so that implementers can produce interoperable algorithms so that implementers can produce interoperable
implementations. implementations.
This specification is developed to facilitate implementations that This specification facilitates implementations that aim to support
wish to support the GOST algorithms. This document does not imply the GOST algorithms. This document does not imply IETF endorsement
IETF endorsement of the cipher suites, signature algorithms, of the cipher suites, signature algorithms, supported groups, and
supported groups and certificate types. certificate types.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 11 May 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9189.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document.
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document
3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 4 3. Basic Terms and Definitions
4. Cipher Suite Definitions . . . . . . . . . . . . . . . . . . 6 4. Cipher Suite Definitions
4.1. Record Payload Protection . . . . . . . . . . . . . . . . 6 4.1. Record Payload Protection
4.1.1. CTR_OMAC . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. CTR_OMAC
4.1.2. CNT_IMIT . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. CNT_IMIT
4.2. Key Exchange and Authentication . . . . . . . . . . . . . 10 4.2. Key Exchange and Authentication
4.2.1. Hello Messages . . . . . . . . . . . . . . . . . . . 11 4.2.1. Hello Messages
4.2.2. Server Certificate . . . . . . . . . . . . . . . . . 12 4.2.2. Server Certificate
4.2.3. CertificateRequest . . . . . . . . . . . . . . . . . 12 4.2.3. CertificateRequest
4.2.4. ClientKeyExchange . . . . . . . . . . . . . . . . . . 13 4.2.4. ClientKeyExchange
4.2.4.1. CTR_OMAC . . . . . . . . . . . . . . . . . . . . 13 4.2.4.1. CTR_OMAC
4.2.4.2. CNT_IMIT . . . . . . . . . . . . . . . . . . . . 15 4.2.4.2. CNT_IMIT
4.2.5. CertificateVerify . . . . . . . . . . . . . . . . . . 17 4.2.5. CertificateVerify
4.2.6. Finished . . . . . . . . . . . . . . . . . . . . . . 18 4.2.6. Finished
4.3. Cryptographic Algorithms . . . . . . . . . . . . . . . . 18 4.3. Cryptographic Algorithms
4.3.1. Block Cipher . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Block Cipher
4.3.2. MAC algorithm . . . . . . . . . . . . . . . . . . . . 18 4.3.2. MAC Algorithm
4.3.3. Encryption algorithm . . . . . . . . . . . . . . . . 19 4.3.3. Encryption Algorithm
4.3.4. PRF and HASH algorithms . . . . . . . . . . . . . . . 19 4.3.4. PRF and HASH Algorithms
4.3.5. SNMAX parameter . . . . . . . . . . . . . . . . . . . 19 4.3.5. SNMAX Parameter
5. New Values for the SignatureAlgorithm Registry . . . . . . . 19 5. New Values for the TLS SignatureAlgorithm Registry
6. New Values for the Supported Groups Registry . . . . . . . . 20 6. New Values for the TLS Supported Groups Registry
7. New Values for the ClientCertificateType Identifiers 7. New Values for the TLS ClientCertificateType Identifiers
Registry . . . . . . . . . . . . . . . . . . . . . . . . 21 Registry
8. Additional Algorithms . . . . . . . . . . . . . . . . . . . . 22 8. Additional Algorithms
8.1. TLSTREE . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. TLSTREE
8.1.1. Key Tree Parameters . . . . . . . . . . . . . . . . . 22 8.1.1. Key Tree Parameters
8.2. Key export and key import algorithms . . . . . . . . . . 23 8.2. Key Export and Key Import Algorithms
8.2.1. KExp15 and KImp15 Algorithms . . . . . . . . . . . . 23 8.2.1. KExp15 and KImp15 Algorithms
8.2.2. KExp28147 and KImp28147 Algorithms . . . . . . . . . 24 8.2.2. KExp28147 and KImp28147 Algorithms
8.3. Key Exchange Generation Algorithms
8.3. Key Exchange Generation Algorithms . . . . . . . . . . . 25 8.3.1. KEG Algorithm
8.3.1. KEG Algorithm . . . . . . . . . . . . . . . . . . . . 25 8.3.2. KEG_28147 Algorithm
8.3.2. KEG_28147 Algorithm . . . . . . . . . . . . . . . . . 27 8.4. gostIMIT28147
8.4. gostIMIT28147 . . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. Historical Considerations
10. Historical Considerations . . . . . . . . . . . . . . . . . . 31 11. Security Considerations
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. Test Examples
Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 34 A.1. Test Examples for CTR_OMAC Cipher Suites
A.1. Test Examples for CTR_OMAC cipher suites . . . . . . . . 34 A.1.1. TLSTREE Examples
A.1.1. TLSTREE Examples . . . . . . . . . . . . . . . . . . 34 A.1.1.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher
A.1.1.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Suite
ciphersuite . . . . . . . . . . . . . . . . . . . . 34 A.1.1.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher
A.1.1.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Suite
ciphersuite . . . . . . . . . . . . . . . . . . . . 36 A.1.2. Record Examples
A.1.2. Record Examples . . . . . . . . . . . . . . . . . . . 39 A.1.2.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher
A.1.2.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Suite
ciphersuite . . . . . . . . . . . . . . . . . . . . 39 A.1.2.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher
A.1.2.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Suite
ciphersuite . . . . . . . . . . . . . . . . . . . . 41 A.1.3. Handshake Examples
A.1.3. Handshake Examples . . . . . . . . . . . . . . . . . 44 A.1.3.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher
A.1.3.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Suite
ciphersuite . . . . . . . . . . . . . . . . . . . . 45 A.1.3.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher
A.1.3.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Suite
ciphersuite . . . . . . . . . . . . . . . . . . . . 58 A.2. Test Examples for CNT_IMIT Cipher Suites
A.2. Test Examples for CNT_IMIT cipher suites . . . . . . . . 77 A.2.1. Record Examples
A.2.1. Record Examples . . . . . . . . . . . . . . . . . . . 77 A.2.2. Handshake Examples
A.2.2. Handshake Examples . . . . . . . . . . . . . . . . . 78 Contributors
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 92 Authors' Addresses
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
1. Introduction 1. Introduction
This document specifies three new cipher suites, two new signature This document specifies three new cipher suites, two new signature
algorithms, seven new supported groups and two new certificate types algorithms, seven new supported groups, and two new certificate types
for the Transport Layer Security (TLS) Protocol Version 1.2 [RFC5246] for the Transport Layer Security (TLS) protocol version 1.2 [RFC5246]
to support the set of Russian cryptographic standard algorithms (note that [RFC5246] has been obsoleted by [RFC8446] ) to support the
(called GOST algorithms). This document specifies a profile of TLS set of Russian cryptographic standard algorithms (called "GOST"
1.2 with GOST algorithms so that implementers can produce algorithms). This document specifies a profile of TLS 1.2 with GOST
interoperable implementations. The profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable
algorithms uses the hash algorithm GOST R 34.11-2012 [RFC6986] and implementations. The profile of TLS 1.2 with GOST algorithms uses
the signature algorithm GOST R 34.10-2012 [RFC7091] and use two types the hash algorithm GOST R 34.11-2012 [RFC6986], the signature
of cipher suites: the CTR_OMAC cipher suites and the CNT_IMIT cipher algorithm GOST R 34.10-2012 [RFC7091], and two types of cipher
suite. suites: the CTR_OMAC and the CNT_IMIT.
The CTR_OMAC cipher suites use the GOST R 34.12-2015 (see [RFC7801], The CTR_OMAC cipher suites use the GOST R 34.12-2015 (see [RFC7801]
[RFC8891]) block ciphers. and [RFC8891]) block ciphers.
The CNT_IMIT cipher suite uses the GOST 28147-89 [RFC5830] block The CNT_IMIT cipher suite uses the GOST 28147-89 [RFC5830] block
cipher. cipher.
This document specifies the profile of the TLS protocol version 1.2 This document specifies the profile of the TLS protocol version 1.2
with GOST algorithms. The profile of the TLS protocol version 1.3 with GOST algorithms. The profile of the TLS protocol version 1.3
[RFC8446] with GOST algorithms is specified in a separate document [RFC8446] with GOST algorithms is specified in a separate document
[DraftGostTLS13]. [DraftGostTLS13].
This specification is developed to facilitate implementations that This specification facilitates implementations that aim to support
wish to support the GOST algorithms. This document does not imply the GOST algorithms. This document does not imply IETF endorsement
IETF endorsement of the cipher suites, signature algorithms, of the cipher suites, signature algorithms, supported groups, and
supported groups and certificate types. certificate types.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Basic Terms and Definitions 3. Basic Terms and Definitions
This document follows the terminology from [RFC8446bis] for
"preliminary secret" and "extended_main_secret".
This document uses the following terms and definitions for the sets This document uses the following terms and definitions for the sets
and operations on the elements of these 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 the set of byte strings of length t, t >= 0. For t = 0,
B_t set consists of a single empty string of zero length. If the B_t set consists of a single empty string of zero
A is an element of B_t, then A = (a_1, a_2, ... , a_t), where length. If A is an element of B_t, then A = (a_1, a_2,
a_1, a_2, ... , a_t are in {0, ... , 255}; ... , 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 B* the set of all byte strings of a finite length (hereinafter
referred to as strings), including the empty string; 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} A[i..j] the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in
where A = (a_1, ... , a_t) in B_t and 1<=i<=j<=t; 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; 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 | C concatenation of strings A and C both belonging to B*,
a string in B_{L(A)+L(C)}, where the left substring in B_L(A) i.e., a string in B_{L(A)+L(C)}, where the left substring
is equal to A, and the right substring in B_L(C) is equal to in B_L(A) is equal to A and the right substring in B_L(C)
C; is equal to C.
A XOR C bitwise exclusive-or of byte strings A and C both belonging A XOR 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 to B_t (both are of length t bytes), i.e., a string in B_t
B_t such that if A = (a_1, a_2, ... , a_t), C = (c_1, c_2, 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, ... ... , 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 ... , a_t (xor) c_t), where (xor) is bitwise exclusive-or
bytes; of bytes.
i & j bitwise AND of unsigned integers i and j; i & j bitwise AND of unsigned integers i and j.
STR_t the transformation that maps an integer i = 256^{t-1} * i_1 + STR_t 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) = + ... + 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 (i_1, ... , i_t) in B_t (the interpretation of the integer
a byte string in big-endian format); as a byte string in big-endian format).
str_t the transformation that maps an integer i = 256^{t-1} * i_t + str_t 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, + ... + 256 * i_2 + i_1 into the byte string str_t(i) =
... , i_t) in B_t (the interpretation of the integer as a (i_1, ... , i_t) in B_t (the interpretation of the integer
byte string in little-endian format); as a byte string in little-endian format).
INT the transformation that maps a string a = (a_1, ... , a_t) in INT the transformation that maps a string a = (a_1, ... , a_t)
B_t into the integer INT(a) = 256^{t-1} * a_1 + ... + 256 * in B_t into the integer INT(a) = 256^(t-1) * a_1 + ... +
a_{t-1} + a_t (the interpretation of the byte string in big- 256 * a_{t-1} + a_t (the interpretation of the byte string
endian format as an integer); in big-endian format as an integer).
int the transformation that maps a string a = (a_1, ... , a_t) in int the transformation that maps a string a = (a_1, ... , a_t)
B_t into the integer int(a) = 256^{t-1} * a_t + ... + 256 * in B_t into the integer int(a) = 256^(t-1) * a_t + ... +
a_2 + a_1 (the interpretation of the byte string in little- 256 * a_2 + a_1 (the interpretation of the byte string in
endian format as an integer); little-endian format as an integer).
k the length of the block cipher key in bytes; k the length of the block cipher key in bytes.
n the length of the block cipher block in bytes; n the length of the block cipher block in bytes.
Q_c the public key stored in the client's certificate; Q_c the public key stored in the client's certificate.
d_c the private key that corresponds to the Q_c key; d_c the private key that corresponds to the Q_c key.
Q_s the public key stored in the server's certificate; Q_s the public key stored in the server's certificate.
d_s the private key that corresponds to the Q_s key; d_s the private key that corresponds to the Q_s key.
q_s an order of a cyclic subgroup of elliptic curve points group q_s an order of a cyclic subgroup of the elliptic curve points
containing point Q_s; group containing point Q_s.
P_s the distinguished generator of the subgroup of order q_s that P_s the distinguished generator of the subgroup of order q_s
belongs to the same curve as Q_s; that belongs to the same curve as Q_s.
r_c the random string contained in ClientHello.random field (see r_c the random string contained in the ClientHello.random field
[RFC5246]); (see [RFC5246]).
r_s the random string contained in ServerHello.random field (see r_s the random string contained in the ServerHello.random field
[RFC5246]). (see [RFC5246]).
4. Cipher Suite Definitions 4. Cipher Suite Definitions
This document specifies the CTR_OMAC cipher suites and the CNT_IMIT This document specifies the CTR_OMAC cipher suites and the CNT_IMIT
cipher suite. cipher suite.
The CTR_OMAC cipher suites have the following values: The CTR_OMAC cipher suites have the following values:
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xC1, 0x00}; TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xC1, 0x00};
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xC1, 0x01}. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xC1, 0x01}.
The CNT_IMIT cipher suite has the following value: The CNT_IMIT cipher suite has the following value:
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xC1, 0x02}. TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xC1, 0x02}.
4.1. Record Payload Protection 4.1. Record Payload Protection
The profile of TLS 1.2 with GOST algorithms requires that the The profile of TLS 1.2 with GOST algorithms requires that the
compression is not used. compression not be used.
All of the cipher suites described in this document use such modes of 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 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 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 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 accordance with the standard stream cipher case (see Section 6.2.3.1
of [RFC5246]): of [RFC5246]):
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 length; uint16 length;
GenericStreamCipher fragment; GenericStreamCipher fragment;
} TLSCiphertext; } TLSCiphertext;
where TLSCiphertext.fragment is generated in accordance with where TLSCiphertext.fragment is generated in accordance with
Section 4.1.1 when the CTR_OMAC cipher suite is used and Section 4.1.1 when the CTR_OMAC cipher suites are used and
Section 4.1.2 when the CNT_IMIT cipher suite is used. Section 4.1.2 when the CNT_IMIT cipher suite is used.
The connection key material is a key material that consists of the The connection key material is a key material that consists of the
sender_write_key (either the client_write_key or the sender_write_key (either the client_write_key or the
server_write_key), the sender_write_MAC_key (either the server_write_key), the sender_write_MAC_key (either the
client_write_MAC_key or the server_write_MAC_key) and 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) sender_write_IV (either the client_write_IV or the server_write_IV)
parameters that are generated in accordance with Section 6.3 of parameters that are generated in accordance with Section 6.3 of
[RFC5246]. [RFC5246].
The record key material is a key material that is generated from the 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 connection key material and is used to protect a record with a
certain sequence number. Note that with some cipher suites defined certain sequence number. Note that with some cipher suites defined
in this document the record key material can be equal to the in this document, the record key material can be equal to the
connection key material. connection key material.
In this section the TLSCiphertext.fragment generation is described In this section, the TLSCiphertext.fragment generation is described
for one particular endpoint (server or client) with the corresponding for one particular endpoint (server or client) with the corresponding
connection key material and record key material. connection key material and record key material.
4.1.1. CTR_OMAC 4.1.1. CTR_OMAC
In case of the CTR_OMAC cipher suites the record key material differs In the CTR_OMAC cipher suites, the record key material differs from
from the connection key material, and for the sequence number seqnum the connection key material, and for the seqnum sequence number
consists of: consists of:
* K_ENC_seqnum in B_k; K_ENC_seqnum in B_k;
* K_MAC_seqnum in B_k; K_MAC_seqnum in B_k; and
* IV_seqnum in B_{n/2}. IV_seqnum in B_{n/2}.
The K_ENC_seqnum and K_MAC_seqnum values are calculated using the The K_ENC_seqnum and K_MAC_seqnum values are calculated using the
TLSTREE function defined in Section 8.1, the connection key material TLSTREE function defined in Section 8.1, the connection key material,
and the sequence number seqnum. IV_seqnum is calculated by adding and the seqnum sequence number . IV_seqnum is calculated by adding
seqnum value to sender_write_IV modulo 2^{(n/2)*8}: the seqnum value to sender_write_IV modulo 2^((n/2)*8):
* K_ENC_seqnum = TLSTREE(sender_write_key, seqnum); K_ENC_seqnum = TLSTREE(sender_write_key, seqnum);
* K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seqnum); K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seqnum); and
* IV_seqnum = STR_{n/2}((INT(sender_write_IV) + seqnum) mod IV_seqnum = STR_{n/2}((INT(sender_write_IV) + seqnum)
2^{(n/2)*8}). mod 2^({(n/2)*8}).
The TLSCiphertext.fragment that corresponds to the seqnum sequence The TLSCiphertext.fragment that corresponds to the seqnum sequence
number is calculated as follows: number is calculated as follows:
1. The MACValue_seqnum value is generated using the MAC algorithm 1. The MACValue_seqnum value is generated using the Message
(see Section 4.3.2) similar to Section 6.2.3.1 of [RFC5246] except Authentication Code (MAC) algorithm (see Section 4.3.2) similar
the sender_write_MAC_key is replaced by the K_MAC_seqnum key: to Section 6.2.3.1 of [RFC5246], 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 | MACValue_seqnum = MAC(K_MAC_seqnum, STR_8(seqnum) | type_seqnum |
version_seqnum | length_seqnum | fragment_seqnum), version_seqnum | length_seqnum | fragment_seqnum),
where type_seqnum, version_seqnum, length_seqnum, fragment_seqnum are where type_seqnum, version_seqnum, length_seqnum, and
the TLSCompressed.type, TLSCompressed.version, TLSCompressed.length fragment_seqnum are the TLSCompressed.type,
and TLSCompressed.fragment values of the record with the seqnum TLSCompressed.version, TLSCompressed.length, and
sequence number. TLSCompressed.fragment values of the record with the seqnum
sequence number.
2. The entire data with the MACValue is encrypted with the ENC 2. The entire data with the MACValue is encrypted with the ENC
stream cipher (see Section 4.3.3): stream cipher (see Section 4.3.3):
ENCValue_seqnum = ENC(K_ENC_seqnum, IV_seqnum, fragment_seqnum | ENCValue_seqnum = ENC(K_ENC_seqnum, IV_seqnum, fragment_seqnum |
MACValue_seqnum), MACValue_seqnum),
where fragment_seqnum is the TLSCompressed.fragment value of the where fragment_seqnum is the TLSCompressed.fragment value of the
record with the seqnum sequence number. record with the seqnum sequence number.
3. The fields of the GenericStreamCipher structure (see section 3. The fields of the GenericStreamCipher structure (see
6.2.3.1 of [RFC5246]) for the TLSCiphertext.fragment value are Section 6.2.3.1 of [RFC5246]) for the TLSCiphertext.fragment
defined by the ENCValue_seqnum value: value are defined by the ENCValue_seqnum value:
TLSCiphertext.fragment.content = TLSCiphertext.fragment.content =
ENCValue_seqnum[1..length_seqnum], ENCValue_seqnum[1..length_seqnum],
TLSCiphertext.fragment.MAC = ENCValue_seqnum[length_seqnum + TLSCiphertext.fragment.MAC = ENCValue_seqnum[length_seqnum +
1..length_seqnum + mac_length], 1..length_seqnum + mac_length],
where length_seqnum is the TLSCompressed.length value of the record where length_seqnum is the TLSCompressed.length value of the
with the seqnum sequence number, mac_length is equal to 16 for the record with the seqnum sequence number and mac_length is equal to
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and 8 for 16 for the TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher
the TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher suite. suite and 8 for the TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
cipher suite.
Note that the CTR_OMAC cipher suites use the authenticate-then- Note that the CTR_OMAC cipher suites use the authenticate-then-
encrypt method (see Appendix F.4 of [RFC5246]). Since these ciphers encrypt method (see Appendix F.4 of [RFC5246]). Since these ciphers
are functioning as stream ciphers, the authenticate-then-encrypt are functioning as stream ciphers, the authenticate-then-encrypt
method is secure, and, as specified by [RFC7366], the server that method is secure, and as specified by [RFC7366], the server that
selects the CTR_OMAC ciphers MUST NOT send an encrypt_then_mac selects the CTR_OMAC ciphers MUST NOT send an encrypt_then_mac
extension to the client. extension to the client.
4.1.2. CNT_IMIT 4.1.2. CNT_IMIT
In case of the CNT_IMIT cipher suite the record key material is equal In the CNT_IMIT cipher suite, the record key material is equal to the
to the connection key material and consists of: connection key material and consists of:
* sender_write_key in B_k; sender_write_key in B_k;
* sender_write_MAC_key in B_k; sender_write_MAC_key in B_k; and
* sender_write_IV in B_n.
sender_write_IV in B_n.
The TLSCiphertext.fragment that corresponds to the seqnum sequence The TLSCiphertext.fragment that corresponds to the seqnum sequence
number is calculated as follows: number is calculated as follows:
1. The MACValue_seqnum value is generated by the MAC algorithm (see 1. The MACValue_seqnum value is generated by the MAC algorithm (see
Section 4.3.2) as follows: Section 4.3.2) as follows:
MACValue_seqnum = MAC(sender_write_MAC_key, STR_8(0) | type_0 | MACValue_seqnum = MAC(sender_write_MAC_key, STR_8(0) | type_0 |
version_0 | length_0 | fragment_0 | ... | STR_8(seqnum) | version_0 | length_0 | fragment_0 | ... | STR_8(seqnum) |
type_seqnum | version_seqnum | length_seqnum | fragment_seqnum), type_seqnum | version_seqnum | length_seqnum | fragment_seqnum),
where type_i, version_i, length_i, fragment_i, i in {0, ... , where type_i, version_i, length_i, fragment_i, and i in {0, ... ,
seqnum}, are the TLSCompressed.type, TLSCompressed.version, seqnum} are the TLSCompressed.type, TLSCompressed.version,
TLSCompressed.length and TLSCompressed.fragment values of the record TLSCompressed.length, and TLSCompressed.fragment values of the
with the i sequence number. record with the i sequence number.
Due to the use of the CBC-MAC based mode (see Section 4.3.2) Due to the use of the mode based on Cipher Block Chaining MAC
producing the MACValue_seqnum value does not mean processing all (CBC-MAC) (see Section 4.3.2), producing the MACValue_seqnum
previous records. It is enough to store only an intermediate value does not mean processing all previous records. It is
internal state of the MAC algorithm. enough to store only an intermediate internal state of the MAC
algorithm.
2. The entire data with the MACValue is encrypted with the ENC 2. The entire data with the MACValue is encrypted with the ENC
stream cipher (see Section 4.3.3): stream cipher (see Section 4.3.3):
ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_write_key, ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_write_key,
sender_write_IV, fragment_0 | MACValue_0 | ... | fragment_seqnum | sender_write_IV, fragment_0 | MACValue_0 | ... | fragment_seqnum |
MACValue_seqnum), MACValue_seqnum),
where the length of the byte string ENCValue_i in bytes is equal to where the length of the byte string ENCValue_i in bytes is equal
the length of the byte string (fragment_i | MACValue_i) in bytes, i to the length of the byte string (fragment_i | MACValue_i) in
in {0, ... , seqnum}. bytes and i in {0, ... , seqnum}.
Due to the use of the stream cipher (see Section 4.3.3) producing the Due to the use of the stream cipher (see Section 4.3.3),
ENCValue_seqnum value does not mean processing all previous records. producing the ENCValue_seqnum value does not mean processing all
It is enough to store only an intermediate internal state of the ENC previous records. It is enough to store only an intermediate
stream cipher. internal state of the ENC stream cipher.
3. The fields of the GenericStreamCipher structure (see section 3. The fields of the GenericStreamCipher structure (see
6.2.3.1 of [RFC5246]) for the TLSCiphertext.fragment value are Section 6.2.3.1 of [RFC5246]) for the TLSCiphertext.fragment
defined by the ENCValue_seqnum value: value are defined by the ENCValue_seqnum value:
TLSCiphertext.fragment.content = TLSCiphertext.fragment.content =
ENCValue_seqnum[1..length_seqnum], ENCValue_seqnum[1..length_seqnum],
TLSCiphertext.fragment.MAC = ENCValue_seqnum[length_seqnum + TLSCiphertext.fragment.MAC = ENCValue_seqnum[length_seqnum +
1..length_seqnum + mac_length], 1..length_seqnum + mac_length],
where length_seqnum is the TLSCompressed.length value of the record where length_seqnum is the TLSCompressed.length value of the
with the seqnum sequence number, mac_length is equal to 4. record with the seqnum sequence number, and mac_length is equal
to 4.
Note that the CNT_IMIT cipher suite uses the authenticate-then- Note that the CNT_IMIT cipher suite uses the authenticate-then-
encrypt method (see Appendix F.4 of [RFC5246]). Since this cipher is encrypt method (see Appendix F.4 of [RFC5246]). Since this cipher is
functioning as a stream cipher, the authenticate-then-encrypt method functioning as a stream cipher, the authenticate-then-encrypt method
is secure, and, as specified by [RFC7366], the server that selects is secure, and as specified by [RFC7366], the server that selects the
the CNT_IMIT cipher MUST NOT send an encrypt_then_mac extension to CNT_IMIT cipher MUST NOT send an encrypt_then_mac extension to the
the client. client.
4.2. Key Exchange and Authentication 4.2. Key Exchange and Authentication
The cipher suites defined in this document use a key encapsulation The cipher suites defined in this document use a key encapsulation
mechanism based on Diffie-Hellman to share the TLS premaster secret. mechanism based on Diffie-Hellman to share the TLS preliminary
secret.
Client Server Client Server
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate Certificate
CertificateRequest* CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 1: Message flow for a full handshake. Figure 1: Message Flow for a Full Handshake
* Indicates optional messages that are sent for Notes for Figure 1:
the client authentication.
Note: To help avoid pipeline stalls, ChangeCipherSpec is an 1. "*" indicates optional messages that are sent for the client
independent TLS protocol content type, and is not actually authentication.
a TLS handshake message.
2. To help avoid pipeline stalls, ChangeCipherSpec is an independent
TLS protocol content type and is not actually a TLS handshake
message.
Figure 1 shows all messages involved in the TLS key establishment Figure 1 shows all messages involved in the TLS key establishment
protocol (full handshake). A ServerKeyExchange MUST NOT be sent (the protocol (full handshake). A ServerKeyExchange MUST NOT be sent (the
server's certificate contains enough data to allow client to exchange server's certificate contains enough data to allow the client to
the premaster secret). exchange the preliminary secret).
The server side of the channel is always authenticated; the client The server side of the channel is always authenticated; the client
side is optionally authenticated. The server is authenticated by side is optionally authenticated. The server is authenticated by
proving that it knows the premaster secret that is encrypted with the proving that it knows the preliminary secret that is encrypted with
public key Q_s from the server's certificate. The client is the public key Q_s from the server's certificate. The client is
authenticated via its signature over the handshake transcript. authenticated via its signature over the handshake transcript.
In general the key exchange process for both CTR_OMAC and CNT_IMIT In general, the key exchange process for both the CTR_OMAC and
cipher suites consists of the following steps: CNT_IMIT cipher suites consists of the following steps:
1. The client generates the ephemeral key pair (d_eph, Q_eph) that 1. The client generates the ephemeral key pair (d_eph, Q_eph) that
corresponds to the server's public key Q_s stored in its corresponds to the server's public key Q_s stored in its
certificate. certificate.
2. The client generates the premaster secret PS. The PS value is 2. The client generates the preliminary secret PS. The PS value is
chosen from B_32 at random. chosen from B_32 at random.
3. Using d_eph and Q_s the client generates the export key material 3. Using d_eph and Q_s, the client generates the export key material
(see Section 4.2.4.1 and Section 4.2.4.2) for the particular key (see Sections 4.2.4.1 and 4.2.4.2) for the particular key export
export algorithm (see Section 8.2.1 and Section 8.2.2) to algorithm (see Sections 8.2.1 and 8.2.2) to generate the export
generate the export representation PSExp of the PS value. representation PSExp of the PS value.
4. The client sends its ephemeral public key Q_eph and PSExp value 4. The client sends its ephemeral public key Q_eph and PSExp value
in the ClientKeyExchange message. in the ClientKeyExchange message.
5. Using its private key d_s the server generates the import key 5. Using its private key d_s, the server generates the import key
material (see Section 4.2.4.1 and Section 4.2.4.2) for the material (see Sections 4.2.4.1 and 4.2.4.2) for the particular
particular key import algorithm (see Section 8.2.1 and key import algorithm (see Sections 8.2.1 and 8.2.2) to extract
Section 8.2.2) to extract the premaster secret PS from the export the preliminary secret PS from the export representation PSExp.
representation PSExp.
This section specifies the data structures and computations used by This section specifies the data structures and computations used by
the profile of TLS 1.2 with GOST algorithms. The specifications for the profile of TLS 1.2 with GOST algorithms. The specifications for
the ClientHello, ServerHello, server Certificate, CertificateRequest, the ClientHello, ServerHello, Server Certificate, CertificateRequest,
ClientKeyExchange, CertificateVerify and Finished handshake messages ClientKeyExchange, CertificateVerify, and Finished handshake messages
are described in further detail below. are described in further detail below.
4.2.1. Hello Messages 4.2.1. Hello Messages
The ClientHello message is generated in accordance with The ClientHello message is generated in accordance with
Section 7.4.1.2 of [RFC5246] and must meet the following Section 7.4.1.2 of [RFC5246] and must meet the following
requirements: requirements:
* The ClientHello.compression_methods field MUST contain exactly one * The ClientHello.compression_methods field MUST contain exactly one
byte, set to zero, which corresponds to the "null" compression byte, set to zero, which corresponds to the "null" compression
skipping to change at page 12, line 29 skipping to change at line 549
* The ServerHello.extensions field MUST NOT contain the * The ServerHello.extensions field MUST NOT contain the
encrypt_then_mac extension (see [RFC7366]). encrypt_then_mac extension (see [RFC7366]).
4.2.2. Server Certificate 4.2.2. Server Certificate
This message is used to authentically convey the server's public key 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 Q_s to the client and is generated in accordance with Section 7.4.2
of [RFC5246]. of [RFC5246].
Upon receiving this message the client validates the certificate Upon receiving this message, the client validates the certificate
chain, extracts the server's public key, and checks that the key type chain, extracts the server's public key, and checks that the key type
is appropriate for the negotiated key exchange algorithm. (A is appropriate for the negotiated key exchange algorithm. (A
possible reason for a fatal handshake failure is that the client's possible reason for a fatal handshake failure is that the client's
capabilities for handling elliptic curves and point formats are capabilities for handling elliptic curves and point formats are
exceeded). exceeded).
4.2.3. CertificateRequest 4.2.3. CertificateRequest
This message is sent by the server when requesting client This message is sent by the server when requesting client
authentication and is generated in accordance with Section 7.4.4 of authentication and is generated in accordance with Section 7.4.4 of
skipping to change at page 13, line 7 skipping to change at line 575
* the CertificateRequest.supported_signature_algorithm field MUST * the CertificateRequest.supported_signature_algorithm field MUST
contain only signature/hash algorithm pairs with the values {8, contain only signature/hash algorithm pairs with the values {8,
64} or {8, 65} defined in Section 5; 64} or {8, 65} defined in Section 5;
* the CertificateRequest.certificate_types field MUST contain only * the CertificateRequest.certificate_types field MUST contain only
the gost_sign256 (67) or gost_sign512 (68) values defined in the gost_sign256 (67) or gost_sign512 (68) values defined in
Section 7. Section 7.
4.2.4. ClientKeyExchange 4.2.4. ClientKeyExchange
The ClientKeyExchange message is defined as follows. The ClientKeyExchange message is defined as follows:
enum { vko_kdf_gost, vko_gost } KeyExchangeAlgorithm; enum { vko_kdf_gost, vko_gost } KeyExchangeAlgorithm;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case vko_kdf_gost: GostKeyTransport; case vko_kdf_gost: GostKeyTransport;
case vko_gost: TLSGostKeyTransportBlob; case vko_gost: TLSGostKeyTransportBlob;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
The body of the ClientKeyExchange message consists of a The body of the ClientKeyExchange message consists of a
GostKeyTransport/TLSGostKeyTransportBlob structure that contains an GostKeyTransport/TLSGostKeyTransportBlob structure that contains an
export representation of the premaster secret PS. export representation of the preliminary secret PS.
The GostKeyTransport structure corresponds to the CTR_OMAC cipher The GostKeyTransport structure corresponds to the CTR_OMAC cipher
suites and is described in Section 4.2.4.1 and the suites and is described in Section 4.2.4.1, and the
TLSGostKeyTransportBlob structure corresponds to CNT_IMIT cipher TLSGostKeyTransportBlob structure corresponds to the CNT_IMIT cipher
suite and is described in Section 4.2.4.2. suite and is described in Section 4.2.4.2.
The DER encoding rules are used to encode the GostKeyTransport and The DER encoding rules are used to encode the GostKeyTransport and
the TLSGostKeyTransportBlob structures. the TLSGostKeyTransportBlob structures.
4.2.4.1. CTR_OMAC 4.2.4.1. CTR_OMAC
In case of the CTR_OMAC cipher suites the body of the In the CTR_OMAC cipher suites, the body of the ClientKeyExchange
ClientKeyExchange message consists of the GostKeyTransport structure message consists of the GostKeyTransport structure that is defined
that is defined bellow. below.
The client generates the ClientKeyExchange message in accordance with The client generates the ClientKeyExchange message in accordance with
the following steps: the following steps:
1. Generates the ephemeral key pair (Q_eph, d_eph), where: 1. Generates the ephemeral key pair (Q_eph, d_eph), where:
d_eph is chosen from {1, ... , q_s - 1} at random; d_eph is chosen from {1, ... , q_s - 1} at random;
Q_eph = d_eph * P_s. Q_eph = d_eph * P_s.
2. Generates the premaster secret PS, where PS is chosen from B_32 2. Generates the preliminary secret PS, where PS is chosen from B_32
at random. at random.
3. Generates export keys (K_EXP_MAC and K_EXP_ENC) using the KEG 3. Generates export keys (K_EXP_MAC and K_EXP_ENC) using the KEG
algorithm defined in Section 8.3.1: algorithm defined in Section 8.3.1:
H = HASH(r_c | r_s); H = HASH(r_c | r_s);
K_EXP_MAC | K_EXP_ENC = KEG(d_eph, Q_s, H). K_EXP_MAC | K_EXP_ENC = KEG(d_eph, Q_s, H).
4. Generates an export representation PSExp of the premaster secret 4. Generates an export representation PSExp of the preliminary
PS using the KExp15 algorithm defined in Section 8.2.1: secret PS using the KExp15 algorithm defined in Section 8.2.1:
IV = H[25..24 + n / 2]; IV = H[25..24 + n / 2];
PSExp = KExp15(PS, K_EXP_MAC, K_EXP_ENC, IV). PSExp = KExp15(PS, K_EXP_MAC, K_EXP_ENC, IV).
5. Generates the ClientKeyExchange message using the 5. Generates the ClientKeyExchange message using the
GostKeyTransport structure that is defined as follows: GostKeyTransport structure that is defined as follows:
GostKeyTransport ::= SEQUENCE { GostKeyTransport ::= SEQUENCE {
keyExp OCTET STRING, keyExp OCTET STRING,
ephemeralPublicKey SubjectPublicKeyInfo, ephemeralPublicKey SubjectPublicKeyInfo,
ukm OCTET STRING OPTIONAL ukm OCTET STRING OPTIONAL
} }
SubjectPublicKeyInfo ::= SEQUENCE { SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING subjectPublicKey BIT STRING
} }
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
parameters ANY OPTIONAL parameters ANY OPTIONAL
} }
where the keyExp field contains the PSExp value, the where the keyExp field contains the PSExp value, the
ephemeralPublicKey field contains the Q_eph value and the ukm field ephemeralPublicKey field contains the Q_eph value, and the ukm
MUST be ignored by the server. field MUST be ignored by the server.
Upon receiving the ClientKeyExchange message, the server process it Upon receiving the ClientKeyExchange message, the server process is
as follows. as follows.
1. Checks the following three conditions. If either of these checks 1. The following three conditions are checked. If any of these
fails, then the server MUST abort the handshake with an alert. checks fail, 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 belongs to the same curve as server public key Q_s;
* Q_eph is not equal to zero point; * Q_eph is not equal to zero point;
* q_s * Q_eph is 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 2. The export keys (K_EXP_MAC and K_EXP_ENC) are generated using the
algorithm defined in Section 8.3.1: KEG algorithm defined in Section 8.3.1:
H = HASH(r_c | r_s); H = HASH(r_c | r_s);
K_EXP_MAC | K_EXP_ENC = KEG(d_s, Q_eph, H). K_EXP_MAC | K_EXP_ENC = KEG(d_s, Q_eph, H).
3. Extracts the premaster secret PS from the export representation 3. The preliminary secret PS is extracted from the export
PSExp using the KImp15 algorithm defined in Section 8.2.1: representation PSExp using the KImp15 algorithm defined in
Section 8.2.1:
IV = H[25..24 + n / 2]; IV = H[25..24 + n / 2];
PS = KImp15(PSExp, K_EXP_MAC, K_EXP_ENC, IV). PS = KImp15(PSExp, K_EXP_MAC, K_EXP_ENC, IV).
4.2.4.2. CNT_IMIT 4.2.4.2. CNT_IMIT
In case of the CNT_IMIT cipher suite the body of the In the CNT_IMIT cipher suite, the body of the ClientKeyExchange
ClientKeyExchange message consists of a TLSGostKeyTransportBlob message consists of a TLSGostKeyTransportBlob structure that is
structure that is defined bellow. defined below.
The client generates the ClientKeyExchange message in accordance with The client generates the ClientKeyExchange message in accordance with
the following steps: the following steps:
1. Generates the ephemeral key pair (Q_eph, d_eph), where: 1. The ephemeral key pair (Q_eph, d_eph) is generated, where:
d_eph is chosen from {1, ... , q_s - 1} at random; d_eph is chosen from {1, ... , q_s - 1} at random;
Q_eph = d_eph * P_s. Q_eph = d_eph * P_s.
2. Generates the premaster secret PS, where PS is chosen from B_32 2. The preliminary secret PS is generated, where PS is chosen from
at random. B_32 at random.
3. Generates export key (K_EXP) using the KEG_28147 algorithm 3. The export key (K_EXP) is generated using the KEG_28147 algorithm
defined in Section 8.3.2: defined in Section 8.3.2:
* H = HASH(r_c | r_s); H = HASH(r_c | r_s);
* K_EXP = KEG_28147(d_eph, Q_s, H). K_EXP = KEG_28147(d_eph, Q_s, H).
4. Generates an export representation PSExp of the premaster secret 4. An export representation PSExp of the preliminary secret PS using
PS using the KExp28147 algorithm defined in Section 8.2.2: the KExp28147 algorithm defined in Section 8.2.2 is generated:
PSExp = IV | CEK_ENC | CEK_MAC = KExp28147(PS, K_EXP, H[1..8]). PSExp = IV | CEK_ENC | CEK_MAC = KExp28147(PS, K_EXP, H[1..8]).
5. Generates the ClientKeyExchange message using the 5. The ClientKeyExchange message is generated using the
TLSGostKeyTransportBlob structure that is defined as follows: TLSGostKeyTransportBlob structure that is defined as follows:
TLSGostKeyTransportBlob ::= SEQUENCE { TLSGostKeyTransportBlob ::= SEQUENCE {
keyBlob GostR3410-KeyTransport, keyBlob GostR3410-KeyTransport
} }
GostR3410-KeyTransport ::= SEQUENCE { GostR3410-KeyTransport ::= SEQUENCE {
sessionEncryptedKey Gost28147-89-EncryptedKey, sessionEncryptedKey Gost28147-89-EncryptedKey,
transportParameters [0] IMPLICIT GostR3410-TransportParameters transportParameters [0] IMPLICIT GostR3410-
OPTIONAL TransportParameters OPTIONAL
} }
Gost28147-89-EncryptedKey ::= SEQUENCE { Gost28147-89-EncryptedKey ::= SEQUENCE {
encryptedKey Gost28147-89-Key, encryptedKey Gost28147-89-Key,
maskKey [0] IMPLICIT Gost28147-89-Key OPTIONAL, maskKey [0] IMPLICIT Gost28147-89-Key OPTIONAL,
macKey Gost28147-89-MAC macKey Gost28147-89-MAC
} }
GostR3410-TransportParameters ::= SEQUENCE { GostR3410-TransportParameters ::= SEQUENCE {
encryptionParamSet OBJECT IDENTIFIER, encryptionParamSet OBJECT IDENTIFIER,
ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo
ukm OCTET STRING OPTIONAL,
} ukm OCTET STRING
}
where GostR3410-KeyTransport, Gost28147-89-EncryptedKey and where GostR3410-KeyTransport, Gost28147-89-EncryptedKey, and
GostR3410-TransportParameters are defined according to Section 4.2.1 GostR3410-TransportParameters are defined according to
of [RFC4490]. Section 4.2.1 of [RFC4490].
In the context of this document the In the context of this document, the
GostR3410-KeyTransport.transportParameters field is always used, the GostR3410-KeyTransport.transportParameters field is always used, the
Gost28147-89-EncryptedKey.maskKey field is omitted, the Gost28147-89-EncryptedKey.maskKey field is omitted, and the
GostR3410-KeyTransport.transportParameters.ephemeralPublicKey field GostR3410-KeyTransport.transportParameters.ephemeralPublicKey field
is always used. is always used.
The Gost28147-89-EncryptedKey.encryptedKey field contains the CEK_ENC The Gost28147-89-EncryptedKey.encryptedKey field contains the CEK_ENC
value, the Gost28147-89-EncryptedKey.macKey field contains the value, the Gost28147-89-EncryptedKey.macKey field contains the
CEK_MAC value, and GostR3410-TransportParameters.ukm field contains CEK_MAC value, and the GostR3410-TransportParameters.ukm field
the IV value. contains the initialization vector (IV) value.
The keyBlob.transportParameters.ephemeralPublicKey field contains the The keyBlob.transportParameters.ephemeralPublicKey field contains the
client ephemeral public key Q_eph. The encryptionParamSet contains 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- the value 1.2.643.7.1.2.5.1.1, which corresponds to the id-tc26-gost-
28147-param-Z parameters set defined in [RFC7836]. 28147-param-Z parameters set defined in [RFC7836].
Upon receiving the ClientKeyExchange message, the server process it Upon receiving the ClientKeyExchange message, the server process is
as follows. as follows.
1. Checks the following three conditions. If either of these checks 1. The following three conditions are checked. If either of these
fails, then the server MUST abort the handshake with an alert. 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 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; * Q_eph is not equal to zero point;
2. Generates export key (K_EXP) using the KEG_28147 algorithm * q_s * Q_eph is equal to zero point.
defined in Section 8.3.2:
* H = HASH(r_c | r_s); 2. The export key (K_EXP) is generated using the KEG_28147 algorithm
defined in Section 8.3.2:
* K_EXP = KEG_28147(d_s, Q_eph, H). H = HASH(r_c | r_s);
3. Extracts the premaster secret PS from the export representation K_EXP = KEG_28147(d_s, Q_eph, H).
PSExp using the KImp28147 algorithm defined in Section 8.2.2:
3. The preliminary secret PS is extracted from the export
representation PSExp using the KImp28147 algorithm defined in
Section 8.2.2:
PS = KImp28147(PSExp, K_EXP, H[1..8]). PS = KImp28147(PSExp, K_EXP, H[1..8]).
4.2.5. CertificateVerify 4.2.5. CertificateVerify
Client generates the value sgn as follows: The client generates the value sgn as follows:
sgn = SIGN_{d_c}(handshake_messages) = str_l(r) | str_l(s) sgn = SIGN_{d_c}(handshake_messages) = str_l(r) | str_l(s)
where SIGN_{d_c} is the GOST R 34.10-2012 [RFC7091] signature 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 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 the client long-term public key Q_c from the client's certificate, l
= 32 for gostr34102012_256 value of the SignatureAndHashAlgorithm = 32 for the gostr34102012_256 value of the SignatureAndHashAlgorithm
field and l = 64 for gostr34102012_512 value of the field, and l = 64 for the gostr34102012_512 value of the
SignatureAndHashAlgorithm field. SignatureAndHashAlgorithm field.
Here handshake_messages refers to all handshake messages sent or Here, "handshake_messages" refers to all handshake messages sent or
received, starting at ClientHello and up to CertificateVerify, but received, starting at ClientHello and up to CertificateVerify without
not including the last message, including the type and length fields the last message; it includes the type and length fields of the
of the handshake messages. handshake messages.
The TLS CertificateVerify message is specified as follows. The TLS CertificateVerify message is specified as follows:
struct { struct {
SignatureAndHashAlgorithm algorithm; SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} CertificateVerify; } CertificateVerify;
where SignatureAndHashAlgorithm structure is specified in Section 5 where the SignatureAndHashAlgorithm structure is specified in
and CertificateVerify.signature field contains sgn value. Section 5, and the CertificateVerify.signature field contains the sgn
value.
4.2.6. Finished 4.2.6. Finished
The TLS Finished message is generated in accordance with The TLS Finished message is generated in accordance with
Section 7.4.9 of [RFC5246]. Section 7.4.9 of [RFC5246].
The verify_data_length value is equal to 32 for the CTR_OMAC cipher 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 suites and is equal to 12 for the CNT_IMIT cipher suite. The
function is defined in Section 4.3.4. pseudorandom function (PRF) is defined in Section 4.3.4.
4.3. Cryptographic Algorithms 4.3. Cryptographic Algorithms
4.3.1. Block Cipher 4.3.1. Block Cipher
The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC MUST The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC MUST
use Kuznyechik [RFC7801] as a base block cipher for the encryption use Kuznyechik [RFC7801] as a base block cipher for the encryption
and MAC algorithm. The block length n is 16 bytes and the key length and MAC algorithm. The block length n is 16 bytes, and the key
k is 32 bytes. length k is 32 bytes.
The cipher suite TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC MUST use The cipher suite TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC MUST use
Magma [RFC8891] as a base block cipher for the encryption and MAC Magma [RFC8891] 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 algorithm. The block length n is 8 bytes, and the key length k is 32
bytes. bytes.
The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT MUST use The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT MUST use
GOST 28147-89 as a base block cipher [RFC5830] with the set of GOST 28147-89 as a base block cipher [RFC5830] with the set of
parameters id-tc26-gost-28147-param-Z defined in [RFC7836]. The parameters id-tc26-gost-28147-param-Z defined in [RFC7836]. The
block length n is 8 bytes and the key length k is 32 bytes. block length n is 8 bytes, and the key length k is 32 bytes.
4.3.2. MAC algorithm 4.3.2. MAC Algorithm
The CTR_OMAC cipher suites use the OMAC message authentication code The CTR_OMAC cipher suites use the One-Key MAC (OMAC) construction
construction defined in [GOST3413-2015], which can be considered as defined in [GOST3413-2015], which is the same as the Cipher-Based MAC
the CMAC mode defined in [CMAC] where Kuznyechik or Magma block (CMAC) mode defined in [CMAC] where the Kuznyechik or Magma block
cipher (see Section 4.3.1) are used instead of AES block cipher (see cipher (see Section 4.3.1) is used instead of the AES block cipher
[IK2003] for more detail) as the MAC function. The resulting MAC (see [IK2003] for more detail) as the MAC function. The resulting
length is equal to the block length and the MAC key length is 32 MAC length is equal to the block length, and the MAC key length is 32
bytes. bytes.
The CNT_IMIT cipher suite uses the message authentication code The CNT_IMIT cipher suite uses the MAC function gostIMIT28147 defined
function gostIMIT28147 defined in Section 8.4 with the initialization in Section 8.4 with the initialization vector IV = IV0, where IV0 in
vector IV = IV0, where IV0 in B_8 is a string of all zeros, with the B_8 is a string of all zeros, with the CryptoPro Key Meshing
CryptoPro Key Meshing algorithm defined in [RFC4357]. The resulting algorithm defined in [RFC4357]. The resulting MAC length is 4 bytes,
MAC length is 4 bytes and the MAC key length is 32 bytes. and the MAC key length is 32 bytes.
4.3.3. Encryption algorithm 4.3.3. Encryption Algorithm
The CTR_OMAC cipher suites use the block cipher in CTR-ACPKM The CTR_OMAC cipher suites use the block cipher in the CTR-ACPKM
encryption mode defined in [RFC8645] as the ENC function. The encryption mode defined in [RFC8645] as the ENC function. The
section size N is 4 KB for section size N is 4 KB for the
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and 1 KB TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and 1 KB
for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher suite. for the TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher suite.
The CNT_IMIT cipher suite uses the block cipher in counter encryption The CNT_IMIT cipher suite uses the block cipher in counter encryption
mode (CNT) defined in Section 6 of [RFC5830] with the CryptoPro Key mode (CNT) defined in Section 6 of [RFC5830], with the CryptoPro key
Meshing algorithm defined in [RFC4357] as the ENC function. meshing algorithm defined in [RFC4357] as the ENC function.
Note that the counter modes used in cipher suites described in this Note that the counter modes used in cipher suites described in this
document act as stream ciphers. document act as stream ciphers.
4.3.4. PRF and HASH algorithms 4.3.4. PRF and HASH Algorithms
The pseudorandom function (PRF) for all the cipher suites defined in The PRF for all the cipher suites defined in this document is the
this document is the PRF_TLS_GOSTR3411_2012_256 function defined in PRF_TLS_GOSTR3411_2012_256 function defined in [RFC7836].
[RFC7836].
The hash function HASH for all the cipher suites defined in this The hash function HASH for all the cipher suites defined in this
document is the GOST R 34.11-2012 [RFC6986] hash algorithm with document is the GOST R 34.11-2012 [RFC6986] hash algorithm with a
32-byte (256-bit) hash code. 32-byte (256-bit) hash code.
4.3.5. SNMAX parameter 4.3.5. SNMAX Parameter
The SNMAX parameter defines the maximal value of the sequence number The SNMAX parameter defines the maximal value of the seqnum sequence
seqnum during one TLS 1.2 connection and is defined as follows: number during one TLS 1.2 connection and is defined as follows:
+=================================================+==========+
| Cipher Suites | SNMAX |
+=================================================+==========+
| TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC | SNMAX = |
| TLS_GOSTR341112_256_WITH_28147_CNT_IMIT | 2^64 - 1 |
+-------------------------------------------------+----------+
| TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC | SNMAX = |
| | 2^32 - 1 |
+-------------------------------------------------+----------+
+---------------------------------------------+--------------------+
| CipherSuites | SNMAX |
+---------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC | SNMAX = 2^64 - 1 |
|TLS_GOSTR341112_256_WITH_28147_CNT_IMIT | |
+---------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC | SNMAX = 2^32 - 1 |
+---------------------------------------------+--------------------+
Table 1 Table 1
5. New Values for the SignatureAlgorithm Registry 5. New Values for the TLS SignatureAlgorithm Registry
The signature/hash algorithm pairs are used to indicate to the The signature/hash algorithm pairs are used to indicate to the
server/client which algorithms can be used in digital signatures and server/client which algorithms can be used in digital signatures and
are defined by the SignatureAndHashAlgorithm structure (see are defined by the SignatureAndHashAlgorithm structure (see
Section 7.4.1.4.1 of [RFC5246]). Section 7.4.1.4.1 of [RFC5246]).
This document defines new values for the "SignatureAlgorithm This document defines new values for the "TLS SignatureAlgorithm"
Registry" that can be used in the SignatureAndHashAlgorithm.signature registry that can be used in the SignatureAndHashAlgorithm.signature
field for the particular signature/hash algorithm pair: field for the particular signature/hash algorithm pair:
enum { enum {
gostr34102012_256(64), gostr34102012_256(64),
gostr34102012_512(65), gostr34102012_512(65),
} SignatureAlgorithm; } SignatureAlgorithm;
where the gostr34102012_256 and gostr34102012_512 values correspond where the gostr34102012_256 and gostr34102012_512 values correspond
to the GOST R 34.10-2012 [RFC7091] signature algorithm with 32-byte to the GOST R 34.10-2012 [RFC7091] signature algorithm with a 32-byte
(256-bit) and 64-byte (512-bit) key length respectively. (256-bit) and 64-byte (512-bit) key length, respectively.
According to [RFC7091] the GOST R 34.10-2012 signature algorithm with According to [RFC7091], the GOST R 34.10-2012 signature algorithm
32-byte (256-bit) or 64-byte (512-bit) key length use the GOST R with a 32-byte (256-bit) or 64-byte (512-bit) key length uses the
34.11-2012 [RFC6986] hash algorithm with 32-byte (256-bit) or 64-byte GOST R 34.11-2012 [RFC6986] hash algorithm with a 32-byte (256-bit)
(512-bit) hash code respectively (the hash algorithm is intrinsic to or 64-byte (512-bit) hash code, respectively (the hash algorithm is
the signature algorithm). Therefore, if the intrinsic to the signature algorithm). Therefore, if the
SignatureAndHashAlgorithm.signature field of a particular hash/ SignatureAndHashAlgorithm.signature field of a particular hash/
signature pair listed in the Signature Algorithms Extension is equal signature pair listed in the Signature Algorithms Extension is equal
to the 64 (gostr34102012_256) or 65 (gostr34102012_512) value, the to the 64 (gostr34102012_256) or 65 (gostr34102012_512) value, the
SignatureAndHashAlgorithm.hash field of this pair MUST contain the SignatureAndHashAlgorithm.hash field of this pair MUST contain the
"Intrinsic" value 8 (see [RFC8422]). "Intrinsic" value 8 (see [RFC8422]).
So, to represent gostr34102012_256 and gostr34102012_512 in the So, to represent gostr34102012_256 and gostr34102012_512 in the
signature_algorithms extension, the value shall be (8,64) and (8,65), signature_algorithms extension, the value shall be (8,64) and (8,65),
respectively. respectively.
6. New Values for the Supported Groups Registry 6. New Values for the TLS Supported Groups Registry
The Supported Groups Extension indicates the set of elliptic curves The Supported Groups Extension indicates the set of elliptic curves
supported by the client and is defined in [RFC8422] and [RFC7919]. supported by the client and is defined in [RFC8422] and [RFC7919].
This document defines new values for the "Supported Groups" registry: This document defines new values for the "TLS Supported Groups"
registry:
enum { enum {
GC256A(34), GC256B(35), GC256C(36), GC256D(37), GC256A(34), GC256B(35), GC256C(36), GC256D(37),
GC512A(38), GC512B(39), GC512C(40), GC512A(38), GC512B(39), GC512C(40),
} NamedGroup; } NamedGroup;
Where the values corresponds to the following curves: where the values correspond to the following curves:
+=============+========================================+===========+
| Description | Curve Identifier Value | Reference |
+=============+========================================+===========+
| GC256A | id-tc26-gost-3410-2012-256-paramSetA | [RFC7836] |
+-------------+----------------------------------------+-----------+
| GC256B | id-GostR3410-2001-CryptoPro-A-ParamSet | [RFC4357] |
+-------------+----------------------------------------+-----------+
| GC256C | id-GostR3410-2001-CryptoPro-B-ParamSet | [RFC4357] |
+-------------+----------------------------------------+-----------+
| GC256D | id-GostR3410-2001-CryptoPro-C-ParamSet | [RFC4357] |
+-------------+----------------------------------------+-----------+
| GC512A | id-tc26-gost-3410-12-512-paramSetA | [RFC7836] |
+-------------+----------------------------------------+-----------+
| GC512B | id-tc26-gost-3410-12-512-paramSetB | [RFC7836] |
+-------------+----------------------------------------+-----------+
| GC512C | id-tc26-gost-3410-2012-512-paramSetC | [RFC7836] |
+-------------+----------------------------------------+-----------+
+-------------+--------------------------------------+-----------+
| Description | Curve Identifier Value | Reference |
+-------------+--------------------------------------+-----------+
| GC256A | id-tc26-gost-3410-2012-256-paramSetA | RFC 7836 |
+-------------+--------------------------------------+-----------+
| GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| RFC 4357 |
+-------------+--------------------------------------+-----------+
| GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| RFC 4357 |
+-------------+--------------------------------------+-----------+
| GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| RFC 4357 |
+-------------+--------------------------------------+-----------+
| GC512A | id-tc26-gost-3410-12-512-paramSetA | RFC 7836 |
+-------------+--------------------------------------+-----------+
| GC512B | id-tc26-gost-3410-12-512-paramSetB | RFC 7836 |
+-------------+--------------------------------------+-----------+
| GC512C | id-tc26-gost-3410-2012-512-paramSetC | RFC 7836 |
+-------------+--------------------------------------+-----------+
Table 2 Table 2
7. New Values for the ClientCertificateType Identifiers Registry 7. New Values for the TLS ClientCertificateType Identifiers Registry
The ClientCertificateType field of the CertificateRequest message The ClientCertificateType field of the CertificateRequest message
contains a list of the types of certificate types that the client may contains a list of certificate types that the client may offer and is
offer and is defined in Section 7.4.4 of [RFC5246]. defined in Section 7.4.4 of [RFC5246].
This document defines new values for the "ClientCertificateType This document defines new values for the "TLS ClientCertificateType
Identifiers" registry: Identifiers" registry:
enum { enum {
gost_sign256(67), gost_sign256(67),
gost_sign512(68), gost_sign512(68),
} ClientCertificateType; } ClientCertificateType;
To use the gost_sign256 or gost_sign512 authentication mechanism, the To use the gost_sign256 or gost_sign512 authentication mechanism, the
client MUST possess a certificate containing a GOST R client MUST possess a certificate containing a GOST R
34.10-2012-capable public key that corresponds to the 32-byte 34.10-2012-capable public key that corresponds to the 32-byte
(256-bit) or 64-byte (512-bit) signature key respectively. (256-bit) or 64-byte (512-bit) signature key, respectively.
The client proves possession of the private key corresponding to the The client proves possession of the private key corresponding to the
certified key by including a signature in the CertificateVerify certified key by including a signature in the CertificateVerify
message as described in Section 4.2.5. message as described in Section 4.2.5.
8. Additional Algorithms 8. Additional Algorithms
The cipher suites specified in this document rely on some additional The cipher suites specified in this document rely on some additional
algorithms, specified below; the use of these algorithms is not algorithms, specified below; the use of these algorithms is not
confined to the use in TLS specified in this document. confined to the use in TLS specified in this document.
8.1. TLSTREE 8.1. TLSTREE
The TLSTREE function is defined as follows: The TLSTREE function is defined as follows:
TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), 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)), STR_8(i & C_2)), STR_8(i & C_3)),
where where
* K_root in B_32; * K_root in B_32;
* i in {0, 1, ... , 2^64 - 1}; * i in {0, 1, ... , 2^64 - 1};
* C_1, C_2, C_3 are constants defined by the particular cipher suite * C_1, C_2, C_3 are constants defined by the particular cipher suite
(see Section 8.1.1); (see Section 8.1.1);
* KDF_j(K, D), j = 1, 2, 3, K in B_32, D in B_8, is the key * 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 derivation function based on the KDF_GOSTR3411_2012_256 function
defined in [RFC7836]: defined in [RFC7836]:
KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D); KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D);
KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D); KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D); and
KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D). KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D).
8.1.1. Key Tree Parameters 8.1.1. Key Tree Parameters
The CTR_OMAC cipher suites use the TLSTREE function for the re-keying The CTR_OMAC cipher suites use the TLSTREE function for the rekeying
approach. The constants for it are defined as in the table below. approach. The constants for it are defined as in the table below.
+--------------------------------------------+----------------------+ +============================================+======================+
| CipherSuites | C_1, C_2, C_3 | |Cipher Suites |C_1, C_2, C_3 |
+--------------------------------------------+----------------------+ +============================================+======================+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC|C_1=0xFFFFFFFF00000000| |TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC|C_1=0xFFFFFFFF00000000|
| |C_2=0xFFFFFFFFFFF80000| | |C_2=0xFFFFFFFFFFF80000|
| |C_3=0xFFFFFFFFFFFFFFC0| | |C_3=0xFFFFFFFFFFFFFFC0|
+--------------------------------------------+----------------------+ +--------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC |C_1=0xFFFFFFC000000000| |TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC |C_1=0xFFFFFFC000000000|
| |C_2=0xFFFFFFFFFE000000| | |C_2=0xFFFFFFFFFE000000|
| |C_3=0xFFFFFFFFFFFFF000| | |C_3=0xFFFFFFFFFFFFF000|
+--------------------------------------------+----------------------+ +--------------------------------------------+----------------------+
Table 3
8.2. Key export and key import algorithms Table 3
8.2. Key Export and Key Import Algorithms
8.2.1. KExp15 and KImp15 Algorithms 8.2.1. KExp15 and KImp15 Algorithms
Algorithms KExp15 and KImp15 use the block cipher determined by the Algorithms KExp15 and KImp15 use the block cipher determined by the
particular cipher suite. particular cipher suite.
The KExp15 key export algorithm is defined as follows. The KExp15 key export algorithm is defined as follows:
+------------------------------------------------------------+ +------------------------------------------------------------+
| KExp15(S, K_Exp_MAC, K_Exp_ENC, IV) | | KExp15(S, K_Exp_MAC, K_Exp_ENC, IV) |
|------------------------------------------------------------| |------------------------------------------------------------|
| Input: | | Input: |
| - secret S to be exported, S in B*, | | - secret S to be exported, S in B*, |
| - key K_Exp_MAC in B_k, | | - key K_Exp_MAC in B_k, |
| - key K_Exp_ENC in B_k, | | - key K_Exp_ENC in B_k, |
| - IV in B_{n/2} | | - IV in B_{n/2} |
| Output: | | Output: |
| - export representation SExp in B_{L(S)+n} | | - export representation SExp in B_{L(S)+n} |
|------------------------------------------------------------| |------------------------------------------------------------|
| 1. CEK_MAC = OMAC(K_Exp_MAC, IV | S), CEK_MAC in B_n | | 1. CEK_MAC = OMAC(K_Exp_MAC, IV | S), CEK_MAC in B_n |
| 2. SExp = CTR-Encrypt(K_Exp_ENC, IV, S | CEK_MAC) | | 2. SExp = CTR-Encrypt(K_Exp_ENC, IV, S | CEK_MAC) |
| 3. return SExp | | 3. return SExp |
+------------------------------------------------------------+ +------------------------------------------------------------+
where the OMAC function is defined in [MODES], the CTR-Encrypt(K, IV, where the OMAC function is defined in [MODES] and the CTR-Encrypt(K,
S) function denotes the encryption of message S on key K and nonce IV IV, S) function denotes the encryption of message S on key K and
in the CTR mode with s = n (see [MODES]). nonce IV in the CTR mode with s = n (see [MODES]).
The KImp15 key import algorithm is defined as follows. The KImp15 key import algorithm is defined as follows:
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| KImp15(SExp, K_Exp_MAC, K_Exp_ENC, IV) | | KImp15(SExp, K_Exp_MAC, K_Exp_ENC, IV) |
|-------------------------------------------------------------------| |-------------------------------------------------------------------|
| Input: | | Input: |
| - export representation SExp in B* | | - export representation SExp in B* |
| - key K_Exp_MAC in B_k, | | - key K_Exp_MAC in B_k, |
| - key K_Exp_ENC in B_k, | | - key K_Exp_ENC in B_k, |
| - IV in B_{n/2} | | - IV in B_{n/2} |
| Output: | | Output: |
| - secret S in B_{L(SExp)-n} or FAIL | | - secret S in B_{L(SExp)-n} or FAIL |
|-------------------------------------------------------------------| |-------------------------------------------------------------------|
| 1. S | CEK_MAC = CTR-Decrypt(K_Exp_ENC, IV, SExp), CEK_MAC in B_n| | 1. S | CEK_MAC = CTR-Decrypt(K_Exp_ENC, IV, SExp), CEK_MAC in B_n|
| 2. If CEK_MAC = OMAC(K_Exp_MAC, IV | S) | | 2. If CEK_MAC = OMAC(K_Exp_MAC, IV | S) |
| then return S; else return FAIL | | then return S; else return FAIL |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
where the OMAC function is defined in [MODES], the CTR-Decrypt(K, IV, where the OMAC function is defined in [MODES] and the CTR-Decrypt(K,
S) function denotes the decryption of message S on key K and nonce IV IV, S) function denotes the decryption of message S on key K and
in the CTR mode (see [MODES]). nonce IV in the CTR mode (see [MODES]).
The keys K_Exp_MAC and K_Exp_ENC MUST be independent. For every pair 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 of keys (K_Exp_ENC, K_Exp_MAC), the IV values MUST be unique. For
import of key with the KImp15 algorithm, the IV value may be sent the import of a key with the KImp15 algorithm, the IV value may be
with the export key representation. sent with the export key representation.
8.2.2. KExp28147 and KImp28147 Algorithms 8.2.2. KExp28147 and KImp28147 Algorithms
The KExp28147 key export algorithm is defined as follows. The KExp28147 key export algorithm is defined as follows:
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KExp28147(S, K, IV) | | KExp28147(S, K, IV) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - secret S to be exported, S in B_32, | | - secret S to be exported, S in B_32, |
| - key K in B_32, | | - key K in B_32, |
| - IV in B_8. | | - IV in B_8. |
| Output: | | Output: |
| - export representation SExp in B_44 | | - export representation SExp in B_44 |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. CEK_MAC = gost28147IMIT(IV, K, S), CEK_MAC in B_4 | | 1. CEK_MAC = gost28147IMIT(IV, K, S), CEK_MAC in B_4 |
| 2. CEK_ENC = ECB-Encrypt(K, S), CEK_ENC in B_32 | | 2. CEK_ENC = ECB-Encrypt(K, S), CEK_ENC in B_32 |
| 3. return SExp = IV | CEK_ENC | CEK_MAC | | 3. return SExp = IV | CEK_ENC | CEK_MAC |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
where the gost28147IMIT function is defined in Section 8.4, 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 [RFC5830]).
The KImp28147 key import 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:
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KImp28147(SExp, K, IV) | | KImp28147(SExp, K, IV) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - export representation SExp in B_44, | | - export representation SExp in B_44, |
| - key K in B_32, | | - key K in B_32, |
| - IV in B_8. | | - IV in B_8. |
| Output: | | Output: |
| - imported secret S in B_32 or FAIL | | - imported secret S in B_32 or FAIL |
skipping to change at page 25, line 30 skipping to change at line 1139
| 1. extract from SExp | | 1. extract from SExp |
| IV' = SExp[1..8], | | IV' = SExp[1..8], |
| CEK_ENC = SExp[9..40], | | CEK_ENC = SExp[9..40], |
| CEK_MAC = SExp[41..44] | | CEK_MAC = SExp[41..44] |
| 2. if IV' != IV then return FAIL; else | | 2. if IV' != IV then return FAIL; else |
| 3. S = ECB-Decrypt(K, CEK_ENC), S in B_32 | | 3. S = ECB-Decrypt(K, CEK_ENC), S in B_32 |
| 4. If CEK_MAC = gost28147IMIT(IV, K, S) | | 4. If CEK_MAC = gost28147IMIT(IV, K, S) |
| then return S; else return FAIL | | then return S; else return FAIL |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
where the gost28147IMIT function is defined in Section 8.4, the ECB- where the gost28147IMIT function is defined in Section 8.4 and the
Decrypt(CEK_ENC, M) function denotes the decryption of ciphertext 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 CEK_ENC on key K with a block cipher GOST 28147-89 in the ECB mode
(see [RFC5830]). (see [RFC5830]).
8.3. Key Exchange Generation Algorithms 8.3. Key Exchange Generation Algorithms
8.3.1. KEG Algorithm 8.3.1. KEG Algorithm
The KEG algorithm is defined as follows: The KEG algorithm is defined as follows:
+----------------------------------------------------------------+ +----------------------------------------------------------------+
skipping to change at page 26, line 17 skipping to change at line 1162
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - private key d, | | - private key d, |
| - public key Q, | | - public key Q, |
| - H in B_32. | | - H in B_32. |
| Output: | | Output: |
| - key material K in B_64. | | - key material K in B_64. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. If q * Q is not equal to zero point | | 1. If q * Q is not equal to zero point |
| return FAIL | | return FAIL |
| 2. If 2^{254} < q < 2^{256} | | 2. If 2^254 < q < 2^256 |
| return KEG_256(d, Q, H) | | return KEG_256(d, Q, H) |
| 3. If 2^{508} < q < 2^{512} | | 3. If 2^508 < q < 2^512 |
| return KEG_512(d, Q, H) | | return KEG_512(d, Q, H) |
| 4. return FAIL | | 4. return FAIL |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
where q is an order of a cyclic subgroup of elliptic curve points where q is an order of a cyclic subgroup of elliptic curve points
group containing point Q, d in {1, ... , q - 1}. group containing point Q, d in {1, ... , q - 1}.
The KEG_256 algorithm is defined as follows: The KEG_256 algorithm is defined as follows:
+----------------------------------------------------------------+ +----------------------------------------------------------------+
skipping to change at page 27, line 46 skipping to change at line 1239
| - key material K in B_32. | | - key material K in B_32. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. If q * Q is not equal to zero point | | 1. If q * Q is not equal to zero point |
| return FAIL | | return FAIL |
| 2. UKM = H[1..8] | | 2. UKM = H[1..8] |
| 3. R = VKO_256(d, Q, int(UKM)) | | 3. R = VKO_256(d, Q, int(UKM)) |
| 4. return K = CPDivers(UKM, R) | | 4. return K = CPDivers(UKM, R) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
where the VKO_256 function is equal to the VKO_GOSTR3410_2012_256 where the VKO_256 function is equal to the VKO_GOSTR3410_2012_256
function defined in [RFC7836], the CPDivers function corresponds to function defined in [RFC7836] and the CPDivers function corresponds
the CryptoPro KEK Diversification Algorithm defined in [RFC4357], to the CryptoPro KEK Diversification Algorithm defined in [RFC4357],
which takes as input the UKM value and the key value. which takes as input the User Keying Material (UKM) value and the key
value.
8.4. gostIMIT28147 8.4. gostIMIT28147
gost28147IMIT(IV, K, M) is a MAC algorithm with 4 bytes output and is gost28147IMIT(IV, K, M) is a MAC algorithm with a 4-byte output and
defined as follows: is defined as follows:
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| gost28147IMIT(IV, K, M) | | gost28147IMIT(IV, K, M) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - initial value IV in B_8, | | - initial value IV in B_8, |
| - key K in B_32, | | - key K in B_32, |
| - message M in B*. | | - message M in B*. |
| Output: | | Output: |
| - MAC value T in B_4. | | - MAC value T in B_4. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. M' = PAD(M) | | 1. M' = PAD(M) |
| 2. M' = M'_0 | ... | M'_r, L(M'_i) = 8, i in {0, ... , r} | | 2. M' = M'_0 | ... | M'_r, L(M'_i) = 8, i in {0, ... , r} |
| 3. M'' = (M'_0 XOR IV) | M'_1 | ... | M'_r | | 3. M'' = (M'_0 XOR IV) | M'_1 | ... | M'_r |
| 4. return T = MAC28147(K, M'') | | 4. return T = MAC28147(K, M'') |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
where the PAD function is the padding function that adds m zero bytes 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 to the end of the message, m is the smallest, non-negative solution
solution to the equation (L(M) + m) mod 8 = 0, the MAC28147 function to the equation (L(M) + m) mod 8 = 0, and the MAC28147 function
corresponds to Message Authentication Code Generation Mode defined in corresponds to the MAC generation mode defined in [RFC5830] with a
[RFC5830] with 4 byte length output. 4-byte length output.
9. IANA Considerations 9. IANA Considerations
IANA is asked to update the registry entries to reference this IANA has added the following values to the "TLS Cipher Suites"
document when it is published as an RFC. registry:
IANA has added numbers {0xC1, 0x00}, {0xC1, 0x01} and {0xC1, 0x02} +=========+==========================+=======+============+=========+
with the names TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC, |Value | Description |DTLS-OK|Recommended |Reference|
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC, +=========+==========================+=======+============+=========+
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT to the "TLS Cipher Suite" |0xC1,0x00| TLS_GOSTR341112_256_ |N |N |RFC 9189 |
registry with this document as reference, as shown below. | | WITH_KUZNYECHIK_CTR_OMAC | | | |
+---------+--------------------------+-------+------------+---------+
|0xC1,0x01| TLS_GOSTR341112_256_ |N |N |RFC 9189 |
| | WITH_MAGMA_CTR_OMAC | | | |
+---------+--------------------------+-------+------------+---------+
|0xC1,0x02| TLS_GOSTR341112_256_ |N |N |RFC 9189 |
| | WITH_28147_CNT_IMIT | | | |
+---------+--------------------------+-------+------------+---------+
+-------------+-----------------------------+---------+----------+ Table 4
| Value | Description | DTLS-OK | Reference|
+-------------+-----------------------------+---------+----------+
| 0xC1, 0x00 | TLS_GOSTR341112_256_ | N | this RFC |
| | _WITH_KUZNYECHIK_CTR_OMAC | | |
+-------------+-----------------------------+---------+----------+
| 0xC1, 0x01 | TLS_GOSTR341112_256_ | N | this RFC |
| | _WITH_MAGMA_CTR_OMAC | | |
+-------------+-----------------------------+---------+----------+
| 0xC1, 0x02 | TLS_GOSTR341112_256_ | N | this RFC |
| | _WITH_28147_CNT_IMIT | | |
+-------------+-----------------------------+---------+----------+
Table 4
IANA has added numbers 64, 65 with the names gostr34102012_256, IANA has added the following values to the "TLS SignatureAlgorithm"
gostr34102012_512, to the "TLS SignatureAlgorithm" registry, as shown registry:
below.
+-----------+---------------------+---------+----------+ +=======+===================+=========+===========+
| Value | Description | DTLS-OK | Reference| | Value | Description | DTLS-OK | Reference |
+-----------+---------------------+---------+----------+ +=======+===================+=========+===========+
| 64 | gostr34102012_256 | Y | this RFC | | 64 | gostr34102012_256 | Y | RFC 9189 |
+-----------+---------------------+---------+----------+ +-------+-------------------+---------+-----------+
| 65 | gostr34102012_512 | Y | this RFC | | 65 | gostr34102012_512 | Y | RFC 9189 |
+-----------+---------------------+---------+----------+ +-------+-------------------+---------+-----------+
Table 5
IANA is asked to reserve the numbers 0x0840, 0x0841 for backward Table 5
compatibility to the "TLS SignatureScheme" registry with this
document as reference, as shown below.
+--------+-------------------------------------+----------+---------+ IANA has added the following values to the "TLS SignatureScheme"
| Value | Description |Recomended|Reference| registry:
+--------+-------------------------------------+----------+---------+
| 0x0840 | Reserved for backward compatibility | N |this RFC |
+--------+-------------------------------------+----------+---------+
| 0x0841 | Reserved for backward compatibility | N |this RFC |
+--------+-------------------------------------+----------+---------+
Table 6
IANA is requested to add a note to the allocated TLS +========+=======================+=============+===========+
SignatureAlgorithm values 64 and 65, reading "These values were | Value | Description | Recommended | Reference |
allocated from the Reserved state due to a misunderstanding of the +========+=======================+=============+===========+
difference between Reserved and Unallocated that went undetected for | 0x0840 | Reserved for backward | N | RFC 9189 |
a long time. Additional allocations from the Reserved state are not | | compatibility | | |
expected, and the TLS SignatureScheme registry is suitable for use +--------+-----------------------+-------------+-----------+
for new allocations instead of this registry". | 0x0841 | Reserved for backward | N | RFC 9189 |
| | compatibility | | |
+--------+-----------------------+-------------+-----------+
IANA has added numbers 34, 35, 36, 37, 38, 39, 40 with the names Table 6
GC256A, GC256B, GC256C, GC256D, GC512A, GC512B, GC512C to the "TLS
Supported Groups" registry, as shown below.
+-----------+----------------+---------+------------+-----------+ IANA has also added the following footnote to values 64 and 65 in the
| Value | Description | DTLS-OK | Recomended | Reference | "TLS SignatureAlgorithm" registry:
+-----------+----------------+---------+------------+-----------+
| 34 | GC256A | Y | N | this RFC |
+-----------+----------------+---------+------------+-----------+
| 35 | GC256B | Y | N | this RFC |
+-----------+----------------+---------+------------+-----------+
| 36 | GC256C | Y | N | this RFC |
+-----------+----------------+---------+------------+-----------+
| 37 | GC256D | Y | N | this RFC |
+-----------+----------------+---------+------------+-----------+
| 38 | GC512A | Y | N | this RFC |
+-----------+----------------+---------+------------+-----------+
| 39 | GC512B | Y | N | this RFC |
+-----------+----------------+---------+------------+-----------+
| 40 | GC512C | Y | N | this RFC |
+-----------+----------------+---------+------------+-----------+
Table 7
IANA has added numbers 67, 68 with the names gost_sign256, | These values were allocated from the Reserved state due to a
gost_sign512 to the "ClientCertificateType Identifiers" registry, as | misunderstanding of the difference between Reserved and
shown below. | 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"
| Value | Description | DTLS-OK | Reference| registry:
+-----------+---------------------+---------+----------+
| 67 | gost_sign256 | Y | this RFC | +=======+=============+=========+=============+===========+
+-----------+---------------------+---------+----------+ | Value | Description | DTLS-OK | Recommended | Reference |
| 68 | gost_sign512 | Y | this RFC | +=======+=============+=========+=============+===========+
+-----------+---------------------+---------+----------+ | 34 | GC256A | Y | N | RFC 9189 |
Table 8 +-------+-------------+---------+-------------+-----------+
| 35 | GC256B | Y | N | RFC 9189 |
+-------+-------------+---------+-------------+-----------+
| 36 | GC256C | Y | N | RFC 9189 |
+-------+-------------+---------+-------------+-----------+
| 37 | GC256D | Y | N | RFC 9189 |
+-------+-------------+---------+-------------+-----------+
| 38 | GC512A | Y | N | RFC 9189 |
+-------+-------------+---------+-------------+-----------+
| 39 | GC512B | Y | N | RFC 9189 |
+-------+-------------+---------+-------------+-----------+
| 40 | GC512C | Y | N | RFC 9189 |
+-------+-------------+---------+-------------+-----------+
Table 7
IANA has added the following values to the "TLS ClientCertificateType
Identifiers" registry:
+-------+--------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-------+--------------+---------+-----------+
| 67 | gost_sign256 | Y | RFC 9189 |
+-------+--------------+---------+-----------+
| 68 | gost_sign512 | Y | RFC 9189 |
+-------+--------------+---------+-----------+
Table 8
10. Historical Considerations 10. Historical Considerations
Note that prior to the existence of this document implementations Note that prior to the existence of this document, implementations
could use only the values from the Private Use space in order to use could use only the values from the "Private Use" space in order to
the GOST-based algorithms. So some old implementations can still use use the GOST-based algorithms. So some old implementations can still
the old value {0xFF, 0x85} instead of the {0xC1, 0x02} value to use the old value {0xFF, 0x85} instead of the {0xC1, 0x02} value to
indicate the TLS_GOSTR341112_256_WITH_28147_CNT_IMIT cipher suite; 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 old value 0xEE instead of the values 64, 8, and 67 (to indicate
the gostr34102012_256 signature algorithm, the Intrinsic hash the gostr34102012_256 signature algorithm, the Intrinsic hash
algorithm and the gost_sign256 certificate type respectively); one algorithm, and the gost_sign256 certificate type, respectively); the
old value 0xEF instead of the values 65, 8 and 68 (to indicate the old value 0xEF instead of the values 65, 8, and 68 (to indicate the
gostr34102012_512 signature algorithm, the Intrinsic hash algorithm gostr34102012_512 signature algorithm, the Intrinsic hash algorithm,
and the gost_sign512 certificate type respectively). and the gost_sign512 certificate type, respectively).
Due to historical reasons in addition to the curve identifier values Due to historical reasons, in addition to the curve identifier values
listed in Table 2 there exist some extra identifier values that listed in Table 2, there exist some extra identifier values that
correspond to the curves GC256B, GC256C and GC256D as follows (see correspond to the curves GC256B, GC256C, and GC256D as follows (see
[RFC4357], [R-1323565.1.024-2019]). [RFC4357] and [R-1323565.1.024-2019]).
+-------------+-----------------------------------------+ +=============+==============================================+
| Description | Curve Identifier Values | | Description | Curve Identifier Values |
+-------------+-----------------------------------------+ +=============+==============================================+
| GC256B |id-GostR3410_2001-CryptoPro-XchA-ParamSet| | GC256B | id-GostR3410_2001-CryptoPro-XchA-ParamSet |
| |id-tc26-gost-3410-2012-256-paramSetB | | | id-tc26-gost-3410-2012-256-paramSetB |
+-------------+-----------------------------------------+ +-------------+----------------------------------------------+
| GC256C |id-tc26-gost-3410-2012-256-paramSetC | | GC256C | id-tc26-gost-3410-2012-256-paramSetC |
+-------------+-----------------------------------------+ +-------------+----------------------------------------------+
| GC256D |id-GostR3410-2001-CryptoPro-XchB-ParamSet| | GC256D | id-GostR3410-2001-CryptoPro-XchB-ParamSet |
| |id-tc26-gost-3410-2012-256-paramSetD | | | id-tc26-gost-3410-2012-256-paramSetD |
+-------------+-----------------------------------------+ +-------------+----------------------------------------------+
Table 9
Client should be prepared to handle any of them correctly if Table 9
The client should be prepared to handle any of these correctly if the
corresponding group is included in the supported_groups extension corresponding group is included in the supported_groups extension
(see [RFC8422] and [RFC7919]). (see [RFC8422] and [RFC7919]).
11. Security Considerations 11. Security Considerations
The cipher suites defined in this document do not provide Perfect The cipher suites defined in this document do not provide Perfect
Forward Secrecy. Forward Secrecy.
The authenticate-then-encrypt method is crucial for the CNT_IMIT The authenticate-then-encrypt method is crucial for the CNT_IMIT
cipher suite. Encryption of the MAC value is conducted to reduce the cipher suite. Encryption of the MAC value is conducted to reduce the
possibility of forgery to guessing. Here the probability of guess is possibility of forgery to guessing. Here, the probability of a guess
approximately equal to 2^{-32}, which is acceptable in some practical is approximately equal to 2^-32, which is acceptable in some
cases. practical cases.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 34, line 8 skipping to change at line 1510
Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019,
<https://www.rfc-editor.org/info/rfc8645>. <https://www.rfc-editor.org/info/rfc8645>.
[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: [RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:
Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891, Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,
September 2020, <https://www.rfc-editor.org/info/rfc8891>. September 2020, <https://www.rfc-editor.org/info/rfc8891>.
12.2. Informative References 12.2. Informative References
[CMAC] Dworkin, M., "Recommendation for Block Cipher Modes of [CMAC] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: the CMAC Mode for Authentication", NIST Special Operation: The CMAC Mode for Authentication", NIST Special
Publication 800-38B, 2005. Publication 800-38B, DOI 10.6028/NIST.SP.800-38B, October
2016, <https://www.nist.gov/publications/recommendation-
block-cipher-modes-operation-cmac-mode-authentication-0>.
[DraftGostTLS13] [DraftGostTLS13]
Smyshlyaev, S., Alekseev, E., Griboedova, E., and A. Smyshlyaev, S., Alekseev, E., Griboedova, E., Babueva, A.,
Babueva, "GOST Cipher Suites for Transport Layer Security and L. Nikiforova, "GOST Cipher Suites for Transport Layer
(TLS) Protocol Version 1.3", 2021, Security (TLS) Protocol Version 1.3", Work in Progress,
<https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost- Internet-Draft, draft-smyshlyaev-tls13-gost-suites-05, 10
suites-04>. December 2021, <https://datatracker.ietf.org/doc/html/
draft-smyshlyaev-tls13-gost-suites-05>.
[GOST3413-2015] [GOST3413-2015]
Federal Agency on Technical Regulating and Metrology, Federal Agency on Technical Regulating and Metrology,
"Information technology. Cryptographic data security. "Information technology. Cryptographic data security.
Modes of operation for block ciphers", GOST R 34.13-2015, Modes of operation for block ciphers", GOST R 34.13-2015,
2015. 2015.
[IK2003] Iwata T., Kurosawa K. (2003), "OMAC: One-Key CBC MAC.", [IK2003] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE
FSE 2003. Lecture Notes in Computer Science, vol 2887. 2003, Lecture Notes in Computer Science, Vol. 2887,
Springer, Berlin, Heidelberg, 2003. DOI 10.1007/978-3-540-39887-5_11, 2003,
<https://doi.org/10.1007/978-3-540-39887-5_11>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques", NIST Special Operation: Methods and Techniques", NIST Special
Publication 800-38A, December 2001. Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December
2001, <https://csrc.nist.gov/publications/detail/sp/800-
38a/final>.
[R-1323565.1.024-2019] [R-1323565.1.024-2019]
Federal Agency on Technical Regulating and Metrology, Federal Agency on Technical Regulating and Metrology,
"Information technology. Cryptographic data security. "Information technology. Cryptographic data security.
Elliptic curve parameters for the cryptographic algorithms Elliptic curve parameters for the cryptographic algorithms
and protocols", R 1323565.1.024-2019, 2019. and protocols", R 1323565.1.024-2019, January 2019.
[RFC8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-03, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-03>.
Appendix A. Test Examples Appendix A. Test Examples
A.1. Test Examples for CTR_OMAC cipher suites A.1. Test Examples for CTR_OMAC Cipher Suites
A.1.1. TLSTREE Examples A.1.1. TLSTREE Examples
A.1.1.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC ciphersuite A.1.1.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher Suite
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
*********************************************** ***********************************************
Root Key K_root: Root Key K_root:
00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
seqnum = 0 seqnum = 0
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 4095 seqnum = 4095
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 4096 seqnum = 4096
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
FB 30 EE 53 CF CF 89 D7 48 FC 0C 72 EF 16 0B 8B FB 30 EE 53 CF CF 89 D7 48 FC 0C 72 EF 16 0B 8B
53 CB BB FD 03 12 82 B0 26 21 4A B2 E0 77 58 FF 53 CB BB FD 03 12 82 B0 26 21 4A B2 E0 77 58 FF
seqnum = 33554431 seqnum = 33554431
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3:
The resulting key from Divers_3:
B8 5B 36 DC 22 82 32 6B C0 35 C5 72 DC 93 F1 8D B8 5B 36 DC 22 82 32 6B C0 35 C5 72 DC 93 F1 8D
83 AA 01 74 F3 94 20 9A 51 3B B3 74 DC 09 35 AE 83 AA 01 74 F3 94 20 9A 51 3B B3 74 DC 09 35 AE
seqnum = 33554432 seqnum = 33554432
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
3F EA 59 38 DA 2B F8 DD C4 7E C1 DC 55 61 89 66 3F EA 59 38 DA 2B F8 DD C4 7E C1 DC 55 61 89 66
79 02 BE 42 0D F4 C3 7D AF 21 75 3B CB 1D C7 F3 79 02 BE 42 0D F4 C3 7D AF 21 75 3B CB 1D C7 F3
The resulting key from Divers 3: The resulting key from Divers_3:
0F D7 C0 9E FD F8 E8 15 73 EE CC F8 6E 4B 95 E3 0F D7 C0 9E FD F8 E8 15 73 EE CC F8 6E 4B 95 E3
AF 7F 34 DA B1 17 7C FD 7D B9 7B 6D A9 06 40 8A AF 7F 34 DA B1 17 7C FD 7D B9 7B 6D A9 06 40 8A
seqnum = 274877906943 seqnum = 274877906943
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
AB F3 A5 37 98 3A 1B 98 40 06 6D E6 8A 49 BF 25 AB F3 A5 37 98 3A 1B 98 40 06 6D E6 8A 49 BF 25
97 7E E5 C3 F5 2D 33 3E 3C 22 0F 1D 15 C5 08 93 97 7E E5 C3 F5 2D 33 3E 3C 22 0F 1D 15 C5 08 93
The resulting key from Divers 3: The resulting key from Divers_3:
48 0F 99 72 BA F2 5D 4C 36 9A 96 AF 91 BC A4 55 48 0F 99 72 BA F2 5D 4C 36 9A 96 AF 91 BC A4 55
3F 79 D8 F0 C5 61 8B 19 FD 44 CF DC 57 FA 37 33 3F 79 D8 F0 C5 61 8B 19 FD 44 CF DC 57 FA 37 33
seqnum = 274877906944 seqnum = 274877906944
First level key from Divers_1: First-level key from Divers_1:
15 60 0D 9E 8F A6 85 54 CF 15 2D C7 4F BC 42 51 15 60 0D 9E 8F A6 85 54 CF 15 2D C7 4F BC 42 51
17 B0 3E 09 76 BB 28 EA 98 24 C3 B7 0F 28 CB D8 17 B0 3E 09 76 BB 28 EA 98 24 C3 B7 0F 28 CB D8
Second level key from Divers_2: Second-level key from Divers_2:
6C C2 8E B0 93 24 72 12 5C 7A D3 F8 09 73 B3 C8 6C C2 8E B0 93 24 72 12 5C 7A D3 F8 09 73 B3 C8
C4 13 7D A5 73 BC 17 1A 24 ED D4 A3 71 F1 F8 73 C4 13 7D A5 73 BC 17 1A 24 ED D4 A3 71 F1 F8 73
The resulting key from Divers 3: The resulting key from Divers_3:
25 28 C1 C6 A8 F0 92 7B F2 BE 27 BB 78 D2 7F 21 25 28 C1 C6 A8 F0 92 7B F2 BE 27 BB 78 D2 7F 21
46 D6 55 93 B0 C7 17 3A 06 CB 9D 88 DF 92 32 65 46 D6 55 93 B0 C7 17 3A 06 CB 9D 88 DF 92 32 65
A.1.1.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC ciphersuite A.1.1.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC
*********************************************** ***********************************************
Root Key K_root: Root Key K_root:
00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
seqnum = 0 seqnum = 0
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 63 seqnum = 63
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 64 seqnum = 64
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37 AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37
FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B
seqnum = 524287 seqnum = 524287
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
6F 18 D4 00 3E A2 CB 30 F5 FE C1 93 A2 34 F0 7D 6F 18 D4 00 3E A2 CB 30 F5 FE C1 93 A2 34 F0 7D
7C 43 94 98 7F 50 75 8D E2 2B 22 0D 8A 10 51 06 7C 43 94 98 7F 50 75 8D E2 2B 22 0D 8A 10 51 06
seqnum = 524288 seqnum = 524288
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
F6 59 EB 85 EE BD 2A 8D CC 1B B3 F7 C6 00 57 FF F6 59 EB 85 EE BD 2A 8D CC 1B B3 F7 C6 00 57 FF
6D 33 B6 0F 74 65 DD 42 B5 11 2C F3 A6 B1 AB 66 6D 33 B6 0F 74 65 DD 42 B5 11 2C F3 A6 B1 AB 66
The resulting key from Divers 3: The resulting key from Divers_3:
E5 4B 16 41 5B 3B 66 3E 78 0B 06 2D 24 F7 36 C4 E5 4B 16 41 5B 3B 66 3E 78 0B 06 2D 24 F7 36 C4
49 54 63 C3 A8 91 E1 FA 46 F7 AE 99 FF F9 F3 78 49 54 63 C3 A8 91 E1 FA 46 F7 AE 99 FF F9 F3 78
seqnum = 4294967295 seqnum = 4294967295
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
F4 BC 10 1A BB 68 86 2A 8C E3 1E A0 0D DF A7 FE F4 BC 10 1A BB 68 86 2A 8C E3 1E A0 0D DF A7 FE
B8 29 10 F1 24 F4 B1 E2 9E A8 3B E0 06 C2 26 8D B8 29 10 F1 24 F4 B1 E2 9E A8 3B E0 06 C2 26 8D
The resulting key from Divers 3: The resulting key from Divers_3:
CF 60 09 04 C7 1E 7B 88 A4 9A C8 E2 45 77 4B 3D CF 60 09 04 C7 1E 7B 88 A4 9A C8 E2 45 77 4B 3D
BE ED FB 81 DE 9A 0E 2F 4E 46 C3 56 07 BC 2F 04 BE ED FB 81 DE 9A 0E 2F 4E 46 C3 56 07 BC 2F 04
seqnum = 4294967296 seqnum = 4294967296
First level key from Divers_1: First-level key from Divers_1:
55 CC 95 E0 D1 FB 54 85 AF 8E F6 9A CD 72 B2 32 55 CC 95 E0 D1 FB 54 85 AF 8E F6 9A CD 72 B2 32
79 7C D2 E8 5D 86 CD FD 1D E5 5B D1 FA 14 37 78 79 7C D2 E8 5D 86 CD FD 1D E5 5B D1 FA 14 37 78
Second level key from Divers_2: Second-level key from Divers_2:
72 16 91 E1 01 C4 28 96 A6 40 AE 18 3F BB 44 5B 72 16 91 E1 01 C4 28 96 A6 40 AE 18 3F BB 44 5B
76 37 9C 57 E1 FD 8A 7D 49 A6 23 E4 23 8C 0E 1D 76 37 9C 57 E1 FD 8A 7D 49 A6 23 E4 23 8C 0E 1D
The resulting key from Divers 3: The resulting key from Divers_3:
16 18 0B 24 64 54 00 B8 36 14 38 37 D8 6A AC 93 16 18 0B 24 64 54 00 B8 36 14 38 37 D8 6A AC 93
95 2A E3 EB 82 44 D5 EC 2A B0 2C FF 30 78 11 38 95 2A E3 EB 82 44 D5 EC 2A B0 2C FF 30 78 11 38
A.1.2. Record Examples A.1.2. Record Examples
A.1.2.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC ciphersuite A.1.2.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher Suite
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
******************************************************** ********************************************************
It is assumed that during Handshake following keys were established: It is assumed that the following keys were established
during handshake:
- MAC key: - MAC key:
00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
- Encryption key: - Encryption key:
00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11
00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22
- IV: - IV:
00000: 00 00 00 00 00000: 00 00 00 00
--------------------------------------------------------- ---------------------------------------------------------
skipping to change at page 41, line 43 skipping to change at line 1892
TLSCiphertext: TLSCiphertext:
00000: 17 03 03 08 08 99 95 26 07 03 47 1D ED A2 E6 55 00000: 17 03 03 08 08 99 95 26 07 03 47 1D ED A2 E6 55
00010: B6 B3 93 83 5E 33 8B 1E D0 0E DD 22 47 A2 FB 88 00010: B6 B3 93 83 5E 33 8B 1E D0 0E DD 22 47 A2 FB 88
00020: FB B7 A8 94 80 62 08 8A F3 2C AE B6 AA 2C 4F 2A 00020: FB B7 A8 94 80 62 08 8A F3 2C AE B6 AA 2C 4F 2A
. . . . . .
007D0: 7F 0B 24 61 E7 5F E1 06 34 B8 4D C5 70 35 72 5A 007D0: 7F 0B 24 61 E7 5F E1 06 34 B8 4D C5 70 35 72 5A
007E0: CA 4F 0C BC A9 B0 6C B9 F7 6F BD 2F 80 46 2B 8D 007E0: CA 4F 0C BC A9 B0 6C B9 F7 6F BD 2F 80 46 2B 8D
007F0: 77 5E BD 41 6F 63 41 39 AC 89 C2 ED 3D F1 9F E2 007F0: 77 5E BD 41 6F 63 41 39 AC 89 C2 ED 3D F1 9F E2
00800: 4E F8 C0 5A A8 90 93 1B 01 86 FD 7D DF 00800: 4E F8 C0 5A A8 90 93 1B 01 86 FD 7D DF
A.1.2.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC ciphersuite A.1.2.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC
*********************************************** ***********************************************
It is assumed that during Handshake following keys were established: It is assumed that the following keys were established
during handshake:
- MAC key: - MAC key:
00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
- Encryption key: - Encryption key:
00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11
00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22
- IV: - IV:
00000: 00 00 00 00 00 00 00 00 00000: 00 00 00 00 00 00 00 00
skipping to change at page 43, line 24 skipping to change at line 1963
. . . . . .
00FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01000: 00 00 00 00 00 01000: 00 00 00 00 00
K_MAC_63: K_MAC_63:
00000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 00000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
00010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 00010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
Mac value: MAC value:
00000: 98 46 27 61 D0 26 24 4A 2C 0B 7D 1B CC CB E7 B0 00000: 98 46 27 61 D0 26 24 4A 2C 0B 7D 1B CC CB E7 B0
K_ENC_63: K_ENC_63:
00000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79 00000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79
00010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56 00010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56
IV_63: IV_63:
00000: 00 00 00 00 00 00 00 3F 00000: 00 00 00 00 00 00 00 3F
TLSCiphertext: TLSCiphertext:
skipping to change at page 44, line 4 skipping to change at line 1991
01010: 24 78 F4 D1 96 01010: 24 78 F4 D1 96
--------------------------------------------------------- ---------------------------------------------------------
seqnum = 64 seqnum = 64
Application data: Application data:
00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . .
01FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
TLSPlaintext: TLSPlaintext:
00000: 17 03 03 20 00 00 00 00 00 00 00 00 00 00 00 00 00000: 17 03 03 20 00 00 00 00 00 00 00 00 00 00 00 00
00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . .
01FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02000: 00 00 00 00 00 02000: 00 00 00 00 00
K_MAC_64: K_MAC_64:
00000: AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37 00000: AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37
00010: FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B 00010: FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B
Mac value: MAC value:
00000: EA C3 97 87 84 2B 1D BD 60 80 CC 3F BF AE 5C 2F 00000: EA C3 97 87 84 2B 1D BD 60 80 CC 3F BF AE 5C 2F
K_ENC_64: K_ENC_64:
00000: 64 F5 5A FC 37 A1 74 D9 53 3E 70 8B CD 14 FA 4A 00000: 64 F5 5A FC 37 A1 74 D9 53 3E 70 8B CD 14 FA 4A
00010: EE C3 7B C0 E3 2B A4 99 01 B4 66 9E 96 A6 3D 96 00010: EE C3 7B C0 E3 2B A4 99 01 B4 66 9E 96 A6 3D 96
IV_64: IV_64:
00000: 00 00 00 00 00 00 00 40 00000: 00 00 00 00 00 00 00 40
TLSCiphertext: TLSCiphertext:
skipping to change at page 44, line 46 skipping to change at line 2032
00020: 80 C8 30 D7 5A B7 D4 6C 25 06 DC 8B 83 E1 F2 D3 00020: 80 C8 30 D7 5A B7 D4 6C 25 06 DC 8B 83 E1 F2 D3
. . . . . .
01FE0: B3 02 67 2C CB 02 86 CD 40 48 FB D5 38 1A 65 55 01FE0: B3 02 67 2C CB 02 86 CD 40 48 FB D5 38 1A 65 55
01FF0: 26 11 25 51 01 4F A8 ED F5 C2 1B 7D 1D B3 9D 6B 01FF0: 26 11 25 51 01 4F A8 ED F5 C2 1B 7D 1D B3 9D 6B
02000: AD EC 0D 7C 07 05 34 8B 5C 55 6C 4D 50 81 69 1A 02000: AD EC 0D 7C 07 05 34 8B 5C 55 6C 4D 50 81 69 1A
02010: A9 EC 36 F8 B5 02010: A9 EC 36 F8 B5
A.1.3. Handshake Examples A.1.3. Handshake Examples
The ClientHello.extensions and the ServerHello.extensions fields The ClientHello.extensions and the ServerHello.extensions fields
contain the extended_master_secret extension (see [RFC7627]) and the contain the extended_main_secret extension (see [RFC7627]) and the
renegotiation_info extension (see [RFC5746]) in the following renegotiation_info extension (see [RFC5746]) in the following
examples. examples.
A.1.3.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC ciphersuite A.1.3.1. TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC Cipher Suite
Server certificate curve OID: Server certificate curve OID:
id-GostR3410-2001-CryptoPro-A-ParamSet, "1.2.643.2.2.35.1" id-GostR3410-2001-CryptoPro-A-ParamSet, "1.2.643.2.2.35.1"
Server public key Q_s: Server public key Q_s:
x = 0x6531D4A72E655BFC9DFB94293B260702 x = 0x6531D4A72E655BFC9DFB94293B260702
82FABF10D5C49B7366148C60E0BF8167 82FABF10D5C49B7366148C60E0BF8167
y = 0x37F8CC71DC5D917FC4A66F7826E72750 y = 0x37F8CC71DC5D917FC4A66F7826E72750
8270B4FFC266C26CD4363E77B553A5B8 8270B4FFC266C26CD4363E77B553A5B8
skipping to change at page 46, line 26 skipping to change at line 2102
signature: signature:
41 41
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_master_secret */ Extension: /* extended_main_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50 00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50
00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45 00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45
00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00 00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00
00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00 00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00
00040: 00 17 00 00 00040: 00 17 00 00
skipping to change at page 47, line 36 skipping to change at line 2161
length: 0009 length: 0009
vector: vector:
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_master_secret */ Extension: /* extended_main_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45 00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45
00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13 00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13
00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6 00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6
00030: ED 51 AC 24 39 D7 E7 C1 01 00 00 09 FF 01 00 01 00030: ED 51 AC 24 39 D7 E7 C1 01 00 00 09 FF 01 00 01
00040: 00 00 17 00 00 00040: 00 00 17 00 00
skipping to change at page 58, line 40 skipping to change at line 2679
Record layer message: Record layer message:
type: 15 type: 15
version: version:
major: 03 major: 03
minor: 03 minor: 03
length: 000A length: 000A
fragment: 999468B49AC5B0DE512C fragment: 999468B49AC5B0DE512C
00000: 15 03 03 00 0A 99 94 68 B4 9A C5 B0 DE 51 2C 00000: 15 03 03 00 0A 99 94 68 B4 9A C5 B0 DE 51 2C
A.1.3.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC ciphersuite A.1.3.2. TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite
Server certificate curve OID: Server certificate curve OID:
id-tc26-gost-3410-2012-512-paramSetC, "1.2.643.7.1.2.1.2.3" id-tc26-gost-3410-2012-512-paramSetC, "1.2.643.7.1.2.1.2.3"
Server public key Q_s: Server public key Q_s:
x = 0xF14589DA479AD972C66563669B3FF580 x = 0xF14589DA479AD972C66563669B3FF580
92E6A30A288BF447CD9FF6C3133E9724 92E6A30A288BF447CD9FF6C3133E9724
7A9706B267703C9B4E239F0D7C7E3310 7A9706B267703C9B4E239F0D7C7E3310
C22D2752B35BD2E4FD39B8F11DEB833A C22D2752B35BD2E4FD39B8F11DEB833A
y = 0xF305E95B36502D4E60A1059FB20AB30B y = 0xF305E95B36502D4E60A1059FB20AB30B
skipping to change at page 60, line 41 skipping to change at line 2765
signature: signature:
41 41
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_master_secret */ Extension: /* extended_main_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50 00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50
00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45 00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45
00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00 00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00
00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00 00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00
00040: 00 17 00 00 00040: 00 17 00 00
skipping to change at page 62, line 4 skipping to change at line 2824
length: 0009 length: 0009
vector: vector:
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_main_secret */
Extension: /* extended_master_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45 00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45
00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13 00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13
00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6 00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6
00030: ED 51 AC 24 39 D7 E7 C1 00 00 00 09 FF 01 00 01 00030: ED 51 AC 24 39 D7 E7 C1 00 00 00 09 FF 01 00 01
00040: 00 00 17 00 00 00040: 00 00 17 00 00
skipping to change at page 77, line 33 skipping to change at line 3556
version: version:
major: 03 major: 03
minor: 03 minor: 03
length: 0012 length: 0012
fragment: EB62E5AB78BF2A4B678920A11027EC43 fragment: EB62E5AB78BF2A4B678920A11027EC43
0C3F 0C3F
00000: 15 03 03 00 12 EB 62 E5 AB 78 BF 2A 4B 67 89 20 00000: 15 03 03 00 12 EB 62 E5 AB 78 BF 2A 4B 67 89 20
00010: A1 10 27 EC 43 0C 3F 00010: A1 10 27 EC 43 0C 3F
A.2. Test Examples for CNT_IMIT cipher suites A.2. Test Examples for CNT_IMIT Cipher Suites
A.2.1. Record Examples A.2.1. Record Examples
It is assumed that during Handshake following keys were established: It is assumed that the following keys were established
during handshake:
- MAC key: - MAC key:
00000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
- Encryption key: - Encryption key:
00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- IV: - IV:
00000: 00 00 00 00 00 00 00 00 00000: 00 00 00 00 00 00 00 00
skipping to change at page 92, line 5 skipping to change at line 4228
Record layer message: Record layer message:
type: 15 type: 15
version: version:
major: 03 major: 03
minor: 03 minor: 03
length: 0006 length: 0006
fragment: 117B57AD5FED fragment: 117B57AD5FED
00000: 15 03 03 00 06 11 7B 57 AD 5F ED 00000: 15 03 03 00 06 11 7B 57 AD 5F ED
Appendix B. Contributors Contributors
* Ekaterina Griboedova
CryptoPro
griboedova.e.s@gmail.com
* Grigory Sedov
CryptoPro
sedovgk@cryptopro.ru
* Dmitry Eremin-Solenikov
Auriga
dbaryshkov@gmail.com
* Lidiia Nikiforova Ekaterina Griboedova
CryptoPro
Email: griboedova.e.s@gmail.com
CryptoPro Grigory Sedov
CryptoPro
Email: sedovgk@cryptopro.ru
nikiforova@cryptopro.ru Dmitry Eremin-Solenikov
Auriga
Email: dbaryshkov@gmail.com
Appendix C. Acknowledgments Lidiia Nikiforova
CryptoPro
Email: nikiforova@cryptopro.ru
Authors' Addresses Authors' Addresses
Stanislav Smyshlyaev (editor) Stanislav Smyshlyaev (editor)
CryptoPro CryptoPro
18, Suschevsky val 18, Suschevsky val
Moscow Moscow
127018 127018
Russian Federation Russian Federation
Phone: +7 (495) 995-48-20 Phone: +7 (495) 995-48-20
Email: svs@cryptopro.ru Email: svs@cryptopro.ru
Dmitry Belyavskiy Dmitry Belyavskiy
Cryptocom Cryptocom
14/2 Kedrova st 14/2, Kedrova St.
Moscow Moscow
117218 117218
Russian Federation Russian Federation
Email: beldmit@gmail.com Email: beldmit@gmail.com
Markku-Juhani O. Saarinen
Independent Consultant
Email: mjos@iki.fi
Evgeny Alekseev Evgeny Alekseev
CryptoPro CryptoPro
18, Suschevsky val 18, Suschevsky val
Moscow Moscow
127018 127018
Russian Federation Russian Federation
Email: alekseev@cryptopro.ru Email: alekseev@cryptopro.ru
 End of changes. 276 change blocks. 
707 lines changed or deleted 728 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/