Independent Submission S. Smyshlyaev, Ed. Request for Comments: 7836 E. Alekseev Category: Informational I. Oshkin ISSN: 2070-1721 V. Popov S. Leontiev CRYPTO-PRO V. Podobaev FACTOR-TS D. Belyavsky TCI March 2016
Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012
Abstract
The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.
These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7836.
Smyshlyaev, et al. Informational [Page 1]
RFC 7836 Cryptographic Algorithms for GOST March 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
The accompanying algorithms are intended for the implementation of cryptographic protocols. This memo contains a description of the accompanying algorithms based on the Russian national standards GOST R 34.10-2012 [GOST3410-2012] and GOST R 34.11-2012 [GOST3411-2012]. The English versions of these standards can be found in [RFC7091] and [RFC6986]; the English version of the encryption standard GOST 28147-89 [GOST28147-89] (which is used in the key export functions) can be found in [RFC5830].
The specifications of algorithms and parameters proposed in this memo are provided on the basis of experience in the development of the cryptographic protocols, as described in [RFC4357], [RFC4490], and [RFC4491].
This memo describes the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions necessary to ensure interoperability of security protocols that make use of the Russian cryptographic standards GOST R 34.10-2012 [GOST3410-2012] digital signature algorithm and GOST R 34.11-2012 [GOST3411-2012] cryptographic hash function.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document uses the following terms and definitions for the sets and operations on the elements of these sets:
(xor) Exclusive-or of two binary vectors of the same length.
V_n The finite vector space over GF(2) of dimension n, n >= 0, with the (xor) operation. For n = 0, the V_0 space consists of a single empty element of size 0. If U is an element of V_n, then U = (u_(n-1), u_(n-2), ..., u_1, u_0), where u_i in {0, 1}.
Smyshlyaev, et al. Informational [Page 3]
RFC 7836 Cryptographic Algorithms for GOST March 2016
V_(8, r) The set of byte vectors of size r, r >= 0, for r = 0 the V_(8, r) set consists of a single empty element of size 0. If W is an element of V_(8, r), r > 0, then W = (w^0, w^1, ..., w^(r-1)), where w^0, w^1, ..., w^(r-1) are elements of V_8.
Bit representation The bit representation of the element W = (w^0, w^1, ..., w^(r-1)) of V_(8, r) is an element (w_(8r-1), w_(8r-2), ..., w_1, w_0) of V_(8*r), where w^0 = (w_7, w_6, ..., w_0), w^1 = (w_15, w_14, ..., w_8), ..., w^(r-1) = (w_(8r-1), w_(8r-2), ..., w_(8r-8)) are elements of V_8.
Byte representation If n is a multiple of 8, r = n/8, then the byte representation of the element W = (w_(n-1), w_(n-2), ..., w_0) of V_n is a byte vector (w^0, w^1, ..., w^(r-1)) of V_(8, r), where w^0 = (w_7, w_6, ..., w_0), w^1 = (w_15, w_14, ..., w_8), ..., w^(r-1) = (w_(8r-1), w_(8r-2), ..., w_(8r-8)) are elements of V_8.
A|B Concatenation of byte vectors A and B, i.e., if A in V_(8, r1), B in V_(8, r2), A = (a^0, a^1, ..., a^(r1-1)) and B = (b^0, b^1, ..., b^(r2-1)), then A|B = (a^0, a^1, ..., a^(r1-1), b^0, b^1, ..., b^(r2-1)) is an element of V_(8, r1+r2).
K (key) An arbitrary element of V_n. If K in V_n, then its size (in bits) is equal to n, where n can be an arbitrary natural number.
Smyshlyaev, et al. Informational [Page 4]
RFC 7836 Cryptographic Algorithms for GOST March 2016
This memo uses the following abbreviations and symbols:
+---------+---------------------------------------------------------+ | Symbols | Meaning | +---------+---------------------------------------------------------+ | H_256 | GOST R 34.11-2012 hash function with 256-bit output | | | | | H_512 | GOST R 34.11-2012 hash function with 512-bit output | | | | | HMAC | Hashed-based Message Authentication Code. A function | | | for calculating a message authentication code, based on | | | a hash function in accordance with [RFC2104] | | | | | PRF | A pseudorandom function, i.e., a transformation that | | | allows generation of a pseudorandom sequence of bytes | | | | | KDF | A key derivation function, i.e., a transformation that | | | allows keys and keying material to be derived from the | | | root key and additional input using a pseudorandom | | | function | | | | | VKO | A key agreement algorithm based on the Diffie-Hellman | | | algorithm and a hash function | +---------+---------------------------------------------------------+
To generate a byte sequence of the size r with functions that give a longer output, the output is truncated to the first r bytes. This remark applies to the following functions:
o KDF_TREE_GOSTR3411_2012_256 described in Section 4.4;
o KDF_GOSTR3411_2012_256 described in Section 4.5.
Hereinafter, all data are provided in byte representation unless otherwise specified.
If a function is defined outside this document (e.g., H_256) and its definition requires arguments in bit representation, it is assumed that the bit representations of the arguments are formed immediately before the calculation of the function (in particular, immediately after the application of the operation (|) to the byte representation of the arguments).
If the output of another function defined outside of this document is used as an argument of the functions defined below and it has the bit representation, then it is assumed that an output MUST have a length
Smyshlyaev, et al. Informational [Page 5]
RFC 7836 Cryptographic Algorithms for GOST March 2016
that is a multiple of 8 and that it will be translated into the byte representation in advance.
When a point on an elliptic curve is given to an input of a hash function, affine coordinates for short Weierstrass form are used (see Section 5): an x coordinate value is fed first, a y coordinate value is fed second, both in little-endian format.
This HMAC transformation is based on the GOST R 34.11-2012 [GOST3411-2012] hash function with 256-bit output. The object identifier of this transformation is shown below:
This algorithm uses H_256 as a hash function for HMAC, described in [RFC2104]. The method of forming the values of ipad and opad is also specified in [RFC2104]. The size of HMAC_GOSTR3411_2012_256 output is equal to 32 bytes, the block size of the iterative procedure for the H_256 compression function is equal to 64 bytes (in the notation of [RFC2104], L = 32 and B = 64, respectively).
This HMAC transformation is based on the GOST R 34.11-2012 [GOST3411-2012] hash function with 512-bit output. The object identifier of this transformation is shown below:
This algorithm uses H_512 as a hash function for HMAC, described in [RFC2104]. The method of forming the values of ipad and opad is also specified in [RFC2104]. The size of HMAC_GOSTR3411_2012_512 output is equal to 64 bytes, the block size of the iterative procedure for the H_512 compression function is equal to 64 bytes (in the notation of [RFC2104], L = 64 and B = 64, respectively).
Smyshlyaev, et al. Informational [Page 6]
RFC 7836 Cryptographic Algorithms for GOST March 2016
This section defines four HMAC-based PRF transformations recommended for usage. Two of them are designed for the Transport Layer Security (TLS) protocol and two are designed for the IPsec protocol.
This is the transformation providing the pseudorandom function for the TLS protocol (1.0 and higher versions) in accordance with GOST R 34.11-2012 [GOST3411-2012]. It uses the P_GOSTR3411_2012_256 function that is similar to the P_hash function defined in Section 5 of [RFC5246], where the HMAC_GOSTR3411_2012_256 function (defined in Section 4.1.1 of this document) is used as the HMAC_hash function.
This is the transformation providing the pseudorandom function for the TLS protocol (1.0 and higher versions) in accordance with GOST R 34.11-2012 [GOST3411-2012]. It uses the P_GOSTR3411_2012_512 function that is similar to the P_hash function defined in Section 5 of [RFC5246], where the HMAC_GOSTR3411_2012_512 function (defined in Section 4.1.2 of this document) is used as the HMAC_hash function.
Label and seed values MUST be assigned by a protocol, their lengths SHOULD be fixed by a protocol in order to avoid possible collisions.
4.2.2. PRFs for the IKEv2 Protocol Based on GOST R 34.11-2012
The specification for the Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] defines the usage of PRFs in various parts of the protocol for the purposes of generating and authenticating keying material.
IKEv2 has no default PRF. This document specifies that HMAC_GOSTR3411_2012_256 may be used as the "prf" function in the "prf+" function for the IKEv2 protocol
Smyshlyaev, et al. Informational [Page 7]
RFC 7836 Cryptographic Algorithms for GOST March 2016
(PRF_IPSEC_PRFPLUS_GOSTR3411_2012_256). Also, this document specifies that HMAC_GOSTR3411_2012_512 may be used as the "prf" function in the "prf+" function for the IKEv2 protocol (PRF_IPSEC_PRFPLUS_GOSTR3411_2012_512).
The VKO_GOSTR3410_2012_256 transformation is used for agreement of 256-bit keys and is based on the 256-bit version of GOST R 34.11-2012 [GOST3411-2012]. This algorithm can be applied for a key agreement using GOST R 34.10-2012 [GOST3410-2012] with 256-bit or 512-bit private keys.
The algorithm is designed to produce an encryption key or a keying material of size 256 bits to be used in various cryptographic protocols. A key or a keying material KEK_VKO (x, y, UKM) is produced from the private key x of one side, the public key y*P of the opposite side and the User Keying Material (UKM) value.
The algorithm can be used for static and ephemeral keys with the public key size n >= 512 bits including the case where one side uses a static key and the other uses an ephemeral one.
The UKM parameter is optional (the default UKM = 1) and can take any integer value from 1 to 2^(n/2)-1. It is allowed to use a non-zero UKM of an arbitrary size that does not exceed n/2 bits. If at least one of the parties uses static keys, the RECOMMENDED length of UKM is 64 bits or more.
KEK_VKO (x, y, UKM) is calculated using the formulas:
KEK_VKO (x, y, UKM) = H_256 (K (x, y, UKM)),
K (x, y, UKM) = (m/q*UKM*x mod q)*(y*P),
where m and q are the parameters of an elliptic curve defined in the GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve points group order, q is an order of a cyclic subgroup), P is a non- zero point of the subgroup; P is defined by a protocol.
This algorithm is defined similar to the one specified in Section 5.2 of [RFC4357], but applies the hash function H_256 instead of the hash function GOST R 34.11-94 [GOST3411-94] (referred to as "gostR3411").
Smyshlyaev, et al. Informational [Page 8]
RFC 7836 Cryptographic Algorithms for GOST March 2016
In addition, K(x, y, UKM) is calculated with public key size n >= 512 bits and UKM has a size up to n/2 bits.
The VKO_GOSTR3410_2012_512 transformation is used for agreement of 512-bit keys and is based on the 512-bit version of GOST R 34.11-2012 [GOST3411-2012]. This algorithm can be applied for a key agreement using GOST R 34.10-2012 [GOST3410-2012] with 512-bit private keys.
The algorithm is designed to produce an encryption key or a keying material of size 512 bits to be used in various cryptographic protocols. A key or a keying material KEK_VKO (x, y, UKM) is produced from the private key x of one side, the public key y*P of the opposite side and the UKM value, considered as an integer.
The algorithm can be used for static and ephemeral keys with the public key size n >= 1024 bits including the case where one side uses a static key and the other uses an ephemeral one.
The UKM parameter is optional (the default UKM = 1) and can take any integer value from 1 to 2^(n/2)-1. It is allowed to use a non-zero UKM of an arbitrary size that does not exceed n/2 bits. If at least one of the parties uses static keys, the RECOMMENDED length of UKM is 128 bits or more.
KEK_VKO (x, y, UKM) is calculated using the formulas:
KEK_VKO (x, y, UKM) = H_512 (K (x, y, UKM)),
K (x, y, UKM) = (m/q*UKM*x mod q)*(y*P),
where m and q are the parameters of an elliptic curve defined in the GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve points group order, q is an order of a cyclic subgroup), P is a non- zero point of the subgroup; P is defined by a protocol.
This algorithm is defined similar to the one specified in Section 5.2 of [RFC4357], but applies the hash function H_512 instead of the hash function GOST R 34.11-94 [GOST3411-94] (referred to as "gostR3411"). In addition, K(x, y, UKM) is calculated with public key size n >= 1024 bits and UKM has a size up to n/2 bits.
Smyshlyaev, et al. Informational [Page 9]
RFC 7836 Cryptographic Algorithms for GOST March 2016
4.4. The Key Derivation Function KDF_TREE_GOSTR3411_2012_256
The key derivation function KDF_TREE_GOSTR3411_2012_256 based on the HMAC_GOSTR3411_2012_256 function is given by:
label, seed The parameters that MUST be assigned by a protocol; their lengths SHOULD be fixed by a protocol.
R A fixed external parameter, with possible values of 1, 2, 3, or 4.
i Iteration counter.
[i]_b Byte representation of the iteration counter (in the network byte order); the number of bytes in the representation [i]_b is equal to R (no more than 4 bytes).
L The required size (in bits) of the generated keying material (an integer, not exceeding 256*(2^(8*R)-1)).
[L]_b Byte representation of L, in network byte order (variable length: no leading zero bytes added).
The key derivation function KDF_TREE_GOSTR3411_2012_256 is intended for generating a keying material of size L, not exceeding 256*(2^(8*R)-1) bits, and utilizing general principles of the input and output for the key derivation function outlined in Section 5.1 of NIST SP 800-108 [NISTSP800-108]. The HMAC_GOSTR3411_2012_256 algorithm described in Section 4.1.1 is selected as a pseudorandom function.
Each key derived from the keying material formed using the derivation key K_in (0-level key) may be a 1-level derivation key and may be used to generate a new keying material. The keying material derived from the first level derivation key can be split down into the second level derivation keys. The application of this procedure leads to the construction of the key tree with the root key and the formation
Smyshlyaev, et al. Informational [Page 10]
RFC 7836 Cryptographic Algorithms for GOST March 2016
of the keying material to the hierarchy of the levels, as described in Section 6 of NIST SP 800-108 [NISTSP800-108]. The partitioning procedure for keying material at each level is defined in accordance with a specific protocol.
4.5. The Key Derivation Function KDF_GOSTR3411_2012_256
The KDF_GOSTR3411_2012_256 function is equivalent to the function KDF_TREE_GOSTR3411_2012_256, when R = 1, L = 256, and is given by:
Wrapped representation of a secret key K (256-bit GOST 28147-89 [GOST28147-89] key, 256-bit or 512-bit GOST R 34.10-2012 [GOST3410-2012] private key) is formed as follows by using a given export key K_e (GOST 28147-89 [GOST28147-89] key) and a random seed vector:
1. Generate a random seed vector from 8 up to 16 bytes.
2. With the key derivation function, using an export key K_e as a derivation key, produce a key KEK_e (K_e, seed), where:
where the KDF_GOSTR3411_2012_256 function (see Section 4.5) is used as a key derivation function for the fixed label value
label = (0x26 | 0xBD | 0xB8 | 0x78).
3. GOST 28147-89 [GOST28147-89] Message Authentication Code (MAC) value (4-byte) for the data K and the key KEK_e (K_e, seed) is calculated; the initialization vector (IV) in this case is equal to the first 8 bytes of seed. The resulting value is denoted as CEK_MAC.
Smyshlyaev, et al. Informational [Page 11]
RFC 7836 Cryptographic Algorithms for GOST March 2016
4. The key K is encrypted with the GOST 28147-89 [GOST28147-89] algorithm in the Electronic Codebook (ECB) mode with the key KEK_e (K_e, seed). The result is denoted as CEK_ENC.
5. The wrapped representation of the key is (seed | CEK_ENC | CEK_MAC).
The value of key K is restored from the wrapped representation of the key and the export key K_e as follows:
1. Obtain the seed, CEK_ENC and CEK_MAC values from the wrapped representation of the key.
2. With the key derivation function, using the export key K_e as a derivation key, produce a key KEK_e(K_e, seed), where:
where the KDF_GOSTR3411_2012_256 function (see Section 4.5) is used as a key derivation function for the fixed label value
label = (0x26 | 0xBD | 0xB8 | 0x78).
3. The CEK_ENC field is decrypted with the GOST 28147-89 [GOST28147-89] algorithm in the Electronic Codebook (ECB) mode with the key KEK_e(K_e, seed). The unwrapped key K is assumed to be equal to the result of decryption.
4. GOST 28147-89 [GOST28147-89] MAC value (4-byte) for the data K and the key KEK_e(K_e, seed) is calculated; the initialization vector (IV) in this case is equal to the first 8 bytes of seed. If the result is not equal to CEK_MAC, an error is returned.
The GOST 28147-89 [GOST28147-89] algorithm is used with the parameter set defined in Appendix C of this document.
5. The Parameters of Elliptic Curves
This section defines the elliptic curves parameters and object identifiers that are RECOMMENDED for usage with the signature and verification algorithms of the digital signature in accordance with the GOST R 34.10-2012 [GOST3410-2012] standard and with the key agreement algorithms VKO_GOSTR3410_2012_256 and VKO_GOSTR3410_2012_512.
This document does not negate the use of other parameters of elliptic curves.
Smyshlyaev, et al. Informational [Page 12]
RFC 7836 Cryptographic Algorithms for GOST March 2016
This section defines the elliptic curves parameters of the GOST R 34.10-2012 [GOST3410-2012] standard for the case of elliptic curves with prime 512-bit moduli in canonical (short Weierstrass) form, that is given by the following equation defined in GOST R 34.10-2012 [GOST3410-2012]:
y^2 = x^3 + ax + b (mod p).
In case of elliptic curves with 256-bit prime moduli, the parameters defined in [RFC4357] are proposed for use.
This section defines the elliptic curves parameters and object identifiers of the GOST R 34.10-2012 [GOST3410-2012] standard for the case of elliptic curves that have a representation in the twisted Edwards form with prime 256-bit and 512-bit moduli.
A twisted Edwards curve E over a finite prime field F_p, p > 3, is an elliptic curve defined by the equation:
e*u^2 + v^2 = 1 + d*u^2*v^2 (mod p),
where e, d are in F_p, ed(e-d) != 0.
A twisted Edwards curve has an equivalent representation in the short Weierstrass form defined by parameters a, b. The parameters a, b, e, and d are related as follows:
a = s^2 - 3*t^2 (mod p), b = 2*t^3 - t*s^2 (mod p),
where:
s = (e - d)/4 (mod p), t = (e + d)/6 (mod p).
Coordinate transformations are defined as follows:
[GOST28147-89] "Systems of information processing. Cryptographic data security. Algorithms of cryptographic transformation", GOST 28147-89 Gosudarstvennyi Standard of USSR, Government Committee of the USSR for Standards, 1989.
[GOST3410-2012] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature", GOST R 34.10-2012 Federal Agency on Technical Regulating and Metrology (In Russian), 2012.
[GOST3411-2012] "Information technology. Cryptographic Data Security. Hashing function", GOST R 34.11-2012 Federal Agency on Technical Regulating and Metrology (In Russian), 2012.
[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", RFC 4357, DOI 10.17487/RFC4357, January 2006, <http://www.rfc-editor.org/info/rfc4357>.
[GOST3411-94] "Information technology. Cryptographic Data Security. Hashing function", GOST R 34.11-94 Federal Agency on Technical Regulating and Metrology (In Russian), 1994.
[NISTSP800-108] National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions", NIST SP 800-108, October 2009, <http://csrc.nist.gov/publications/nistpubs/800-108/ sp800-108.pdf>.
[RFC4490] Leontiev, S., Ed. and G. Chudov, Ed., "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", RFC 4490, DOI 10.17487/RFC4490, May 2006, <http://www.rfc-editor.org/info/rfc4490>.
[RFC4491] Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 4491, DOI 10.17487/RFC4491, May 2006, <http://www.rfc-editor.org/info/rfc4491>.
29 f6 0d da 45 7b f2 19 aa 2e f9 5d 7a 59 be 95 4d e0 08 f4 a5 0d 50 4d bd b6 90 be 68 06 01 53
6) PRF_IPSEC_PRFPLUS_GOSTR3411_2012_512
Key K:
c9 a9 a7 73 20 e2 cc 55 9e d7 2d ce 6f 47 e2 19 2c ce a9 5f a6 48 67 05 82 c0 54 c0 ef 36 c2 21
Data S:
01 26 bd b8 78 00 1d 80 60 3c 85 44 c7 27 01 00
Output T1:
5d a6 71 43 a5 f1 2a 6d 6e 47 42 59 6f 39 24 3f cc 61 57 45 91 5b 32 59 10 06 ff 78 a2 08 63 d5 f8 8e 4a fc 17 fb be 70 b9 50 95 73 db 00 5e 96 26 36 98 46 cb 86 19 99 71 6c 16 5d d0 6a 15 85
Output T2:
48 34 49 5a 43 74 6c b5 3f 0a ba 3b c4 6e bc f8 77 3c a6 4a d3 43 c1 22 ee 2a 57 75 57 03 81 57 ee 9c 38 8d 96 ef 71 d5 8b e5 c1 ef a1 af a9 5e be 83 e3 9d 00 e1 9a 5d 03 dc d6 0a 01 bc a8 e3
7) VKO_GOSTR3410_2012_256 with 256-bit output on the GOST R 34.10-2012 512-bit keys with id-tc26-gost-3410-12-512-paramSetA
UKM value:
1d 80 60 3c 85 44 c7 27
Private key x of A:
c9 90 ec d9 72 fc e8 4e c4 db 02 27 78 f5 0f ca c7 26 f4 67 08 38 4b 8d 45 83 04 96 2d 71 47 f8 c2 db 41 ce f2 2c 90 b1 02 f2 96 84 04 f9 b9 be 6d 47 c7 96 92 d8 18 26 b3 2b 8d ac a4 3c b6 67
Smyshlyaev, et al. Informational [Page 25]
RFC 7836 Cryptographic Algorithms for GOST March 2016
Public key x*P of A (curve point (X, Y)):
aa b0 ed a4 ab ff 21 20 8d 18 79 9f b9 a8 55 66 54 ba 78 30 70 eb a1 0c b9 ab b2 53 ec 56 dc f5 d3 cc ba 61 92 e4 64 e6 e5 bc b6 de a1 37 79 2f 24 31 f6 c8 97 eb 1b 3c 0c c1 43 27 b1 ad c0 a7 91 46 13 a3 07 4e 36 3a ed b2 04 d3 8d 35 63 97 1b d8 75 8e 87 8c 9d b1 14 03 72 1b 48 00 2d 38 46 1f 92 47 2d 40 ea 92 f9 95 8c 0f fa 4c 93 75 64 01 b9 7f 89 fd be 0b 5e 46 e4 a4 63 1c db 5a
Private key y of part B:
48 c8 59 f7 b6 f1 15 85 88 7c c0 5e c6 ef 13 90 cf ea 73 9b 1a 18 c0 d4 66 22 93 ef 63 b7 9e 3b 80 14 07 0b 44 91 85 90 b4 b9 96 ac fe a4 ed fb bb cc cc 8c 06 ed d8 bf 5b da 92 a5 13 92 d0 db
Public key y*P of B (curve point (X, Y)):
19 2f e1 83 b9 71 3a 07 72 53 c7 2c 87 35 de 2e a4 2a 3d bc 66 ea 31 78 38 b6 5f a3 25 23 cd 5e fc a9 74 ed a7 c8 63 f4 95 4d 11 47 f1 f2 b2 5c 39 5f ce 1c 12 91 75 e8 76 d1 32 e9 4e d5 a6 51 04 88 3b 41 4c 9b 59 2e c4 dc 84 82 6f 07 d0 b6 d9 00 6d da 17 6c e4 8c 39 1e 3f 97 d1 02 e0 3b b5 98 bf 13 2a 22 8a 45 f7 20 1a ba 08 fc 52 4a 2d 77 e4 3a 36 2a b0 22 ad 40 28 f7 5b de 3b 79
KEK_VKO value:
c9 a9 a7 73 20 e2 cc 55 9e d7 2d ce 6f 47 e2 19 2c ce a9 5f a6 48 67 05 82 c0 54 c0 ef 36 c2 21
8) VKO_GOSTR3410_2012_512 with 512-bit output on the GOST R 34.10-2012 512-bit keys with id-tc26-gost-3410-12-512-paramSetA
UKM value:
1d 80 60 3c 85 44 c7 27
Private key x of A:
c9 90 ec d9 72 fc e8 4e c4 db 02 27 78 f5 0f ca c7 26 f4 67 08 38 4b 8d 45 83 04 96 2d 71 47 f8 c2 db 41 ce f2 2c 90 b1 02 f2 96 84 04 f9 b9 be 6d 47 c7 96 92 d8 18 26 b3 2b 8d ac a4 3c b6 67
Smyshlyaev, et al. Informational [Page 26]
RFC 7836 Cryptographic Algorithms for GOST March 2016
Public key x*P of A (curve point (X, Y)):
aa b0 ed a4 ab ff 21 20 8d 18 79 9f b9 a8 55 66 54 ba 78 30 70 eb a1 0c b9 ab b2 53 ec 56 dc f5 d3 cc ba 61 92 e4 64 e6 e5 bc b6 de a1 37 79 2f 24 31 f6 c8 97 eb 1b 3c 0c c1 43 27 b1 ad c0 a7 91 46 13 a3 07 4e 36 3a ed b2 04 d3 8d 35 63 97 1b d8 75 8e 87 8c 9d b1 14 03 72 1b 48 00 2d 38 46 1f 92 47 2d 40 ea 92 f9 95 8c 0f fa 4c 93 75 64 01 b9 7f 89 fd be 0b 5e 46 e4 a4 63 1c db 5a
Private key y of B:
48 c8 59 f7 b6 f1 15 85 88 7c c0 5e c6 ef 13 90 cf ea 73 9b 1a 18 c0 d4 66 22 93 ef 63 b7 9e 3b 80 14 07 0b 44 91 85 90 b4 b9 96 ac fe a4 ed fb bb cc cc 8c 06 ed d8 bf 5b da 92 a5 13 92 d0 db
Public key y*P of B (curve point (X, Y)):
19 2f e1 83 b9 71 3a 07 72 53 c7 2c 87 35 de 2e a4 2a 3d bc 66 ea 31 78 38 b6 5f a3 25 23 cd 5e fc a9 74 ed a7 c8 63 f4 95 4d 11 47 f1 f2 b2 5c 39 5f ce 1c 12 91 75 e8 76 d1 32 e9 4e d5 a6 51 04 88 3b 41 4c 9b 59 2e c4 dc 84 82 6f 07 d0 b6 d9 00 6d da 17 6c e4 8c 39 1e 3f 97 d1 02 e0 3b b5 98 bf 13 2a 22 8a 45 f7 20 1a ba 08 fc 52 4a 2d 77 e4 3a 36 2a b0 22 ad 40 28 f7 5b de 3b 79
KEK_VKO value:
79 f0 02 a9 69 40 ce 7b de 32 59 a5 2e 01 52 97 ad aa d8 45 97 a0 d2 05 b5 0e 3e 17 19 f9 7b fa 7e e1 d2 66 1f a9 97 9a 5a a2 35 b5 58 a7 e6 d9 f8 8f 98 2d d6 3f c3 5a 8e c0 dd 5e 24 2d 3b df
x K1(x) K2(x) K3(x) K4(x) K5(x) K6(x) K7(x) K8(x) ------------------------------------------------------------ 0 | c 6 b c 7 5 8 1 1 | 4 8 3 8 f d e 7 2 | 6 2 5 2 5 f 2 e 3 | 2 3 8 1 a 6 5 d 4 | a 9 2 d 8 9 6 0 5 | 5 a f 4 1 2 9 5 6 | b 5 a f 6 c 1 8 7 | 9 c d 6 d a c 3 8 | e 1 e 7 0 b f 4 9 | 8 e 1 0 9 7 4 f a | d 4 7 a 3 8 b a b | 7 7 4 5 e 1 0 6 c | 0 b c 3 b 4 d 9 d | 3 d 9 e 4 3 a c e | f 0 6 9 2 e 3 b f | 1 f 0 b c 0 7 2
Acknowledgments
We thank Valery Smyslov, Igor Ustinov, Basil Dolmatov, Russ Housley, Dmitry Khovratovich, Oleksandr Kazymyrov, Ekaterina Smyshlyaeva, Vasily Nikolaev, and Lolita Sonina for their careful readings and useful comments.
Authors' Addresses
Stanislav Smyshlyaev (editor) CRYPTO-PRO 18, Suschevsky val Moscow 127018 Russian Federation
Phone: +7 (495) 995-48-20 Email: svs@cryptopro.ru
Smyshlyaev, et al. Informational [Page 30]
RFC 7836 Cryptographic Algorithms for GOST March 2016
Evgeny Alekseev CRYPTO-PRO 18, Suschevsky val Moscow 127018 Russian Federation