| Network Working Group | S. Smyshlyaev, Ed. |
| Internet-Draft | V. Popov |
| Intended status: Informational | E. Alekseev |
| Expires: December 25, 2015 | I. Oshkin |
| CRYPTO-PRO | |
| June 23, 2015 |
Guidelines on the cryptographic algorithms, accompanying the usage of standards GOST R 34.10-2012 and GOST R 34.11-2012
draft-smyshlyaev-gost-usage-00
The usage of cryptographic algorithms, that are defined by GOST R 34.10-2012 [GOST3410-2012] and GOST R 34.11-2012 [GOST3411-2012] standards, for protection of the information is carried out, as a rule, within the cryptographic protocols based on the accompanying algorithms.
This memo contains a description of the accompanying algorithms for defining the pseudorandom functions, the key derivation functions, the key agreement protocols based on the Diffie-Hellman algorithm and the keying material export algorithms.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2015.
Copyright (c) 2015 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The usage of cryptographic algorithms, that are defined by the GOST R 34.10-2012 [GOST3410-2012] and GOST R 34.11-2012 [GOST3411-2012] standards, for protection of the information is carried out, as a rule, within the cryptographic protocols based on the accompanying algorithms.
The specifications of algorithms and parameters proposed in this memo are defined on the basis of experience in the development of cryptographic protocols, as described in the [RFC4357], [RFC4490] and [RFC4491].
This memo contains a description of the accompanying algorithms for defining the pseudorandom functions, the key derivation functions, the key agreement protocols based on the Diffie-Hellman algorithm and the keying material export algorithms.
This memo does not specify the cryptographic algorithms GOST R 34.10-2012 [GOST3410-2012] and GOST R 34.11-2012 [GOST3411-2012]. These algorithms are defined by the national standards GOST R 34.10-2012 [GOST3410-2012] and GOST R 34.11-2012 [GOST3411-2012] and described in [RFC7091] and [RFC6986] (an English version of Russian national standards).
The need to ensure compatibility of the cryptographic protocol implementations based on the Russian cryptographic standards GOST R 34.10-2012 [GOST3410-2012] and GOST R 34.11-2012 [GOST3411-2012] served as the main reason for the development of this document.
This memo is recommended for use in encrypting and protecting the authenticity of the data, based on the use of digital signature algorithms GOST R 34.10-2012 [GOST3410-2012] and hash function GOST R 34.11-2012 [GOST3411-2012], in public and corporate networks to protect information that does not contain a classified information.
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 notation for the sets and operations on the elements of these sets in accordance with GOST R 34.11-2012 [GOST3411-2012]:
Note: It is proposed to interpret and edit the formulas in accordance with the above definitions.
This memo uses the following terms, abbreviations and symbols:
| Symbols | Meaning |
|---|---|
| H_256 | GOST R 34.11-2012 hash function, 256-bit |
| H_512 | GOST R 34.11-2012 hash function, 512-bit |
| HMAC | a function for calculating a message authentication code (based on some hash function) |
| HMAC_256 | a function based on the hash function H_256, intended for computing a message authentication code |
| HMAC_512 | a function based on the hash function H_512, intended for computing a message authentication code |
| PRF | a pseudorandom function, i.e., a transformation that allows to generate pseudorandom sequence of bytes |
| KDF | a key derivation function, i.e., a transformation, that allows to derive keys and keying material for the root key and random data using a pseudorandom function |
To produce a byte sequence of the size N with functions that give a longer output the input should be taken from the output sequence of the first N bytes. This remark applies to the following functions:
When n is multiple of 8, an element of V_n can be represented in the bit and byte form. The result of operation «|», applied to the elements in the bit representation is described in the bit representation. The result of the operation «|», applied to the same elements in their byte representation is described in the byte representation. Thus, the symbol «|» is used to refer to two different operations, depending on the form of their arguments. Selecting one of these operations is uniquely determined by the representation of arguments.
Hereinafter all data (the elements of V_n) unless otherwise specified, are considered given in the byte representation. Operation «|» on the arguments of functions, unless explicitly stated otherwise, is performed on their byte representation.
If the function is defined outside this document (eg, H_256) and its definition is using arguments in bit representation, it is assumed that the bit representation of the argument is formed immediately before the calculation of the function (in particular, only after the application of the operation «|» to the byte representation of the arguments).
If as the argument of the function defined below is used the output of another function that is defined outside of this document and has output value in bit representation, it is assumed that the output value will be translated into the byte representation before substitution in arguments.
For algorithms described in this paper, the possible values of the functions are limited by the permissibility of applying them as the input parameter of the transformations and are assigned by the protocols.
This section defines the HMAC transformations based on GOST R 34.11-2012 [GOST3411-2012] algorithm with different size of the output value.
This HMAC transformation is based on GOST R 34.11-2012 [GOST3411-2012] algorithm, 256-bit output. The identifier of this transformation is shown below:
The calculation of HMAC_256(K, T) for the data T of arbitrary length and the key K of n bits size is the forming of the 64-byte string K* and the transformation on K* and T using the hash function H_256.
The size n can take any value in the interval from 256 to 512.
For the formation of the key K*: if n < 512, take the string K* equal to the byte representation of the bit string K | A, where A = (0, 0, ..., 0) in V_(512-n); if n = 512, take K* equal to the byte representation of the key K.
The value of HMAC_256 (K, T) is given by:
where byte representations are:
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 given in [RFC2104]. The size of the HMAC_256 output in bytes is equal to 32, the block size of the iterative procedure for the H_256 compression function in bytes is equal to 64 (in the notation of [RFC2104], L = 32 and B = 64, respectively).
This HMAC transformation is based on GOST R 34.11-2012 [GOST3411-2012], 512-bit output. The identifier of this transformation is shown below:
The calculation of HMAC_512(K, T) for the data T of arbitrary length and the key K of n bits size is the forming of the 64-byte string K* and the transformation on K* and T using the hash function H_512.
The size n can take any value in the interval from 256 to 512. The recommended value is 512.
For the formation of the key K*: if n < 512, take the string K* equal to the byte representation of the bit string K | A, where A = (0, 0, ..., 0) in V_(512-n); if n = 512, take K* equal to the byte representation of the K key.
The value of HMAC_512 (K, T) is given by:
where byte representations are:
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 given in [RFC2104]. The size of the HMAC_512 output in bytes is equal to 64, the block size of the iterative procedure for the H_512 compression function in bytes is equal to 64 (in the notation of [RFC2104], L = 64 and B = 64, respectively).
This section defines six based on HMAC PRF transformations that are recommended for the use. Two of them are for the TLS protocol and four for IPsec.
To obtain a set of values of the total size of m bytes using any of the following PRF it should be taken equal to the corresponding sequential values from the first m bytes of the used PRF output in the byte representation.
This is the transformation to implement the pseudorandom function of the TLS protocol; the transformation uses the HMAC_256 values based on GOST R 34.11-2012 [GOST3411-2012], 256-bit output.
The A_i parameters are determined sequentially as follows:
P_GOSTR3411_2012_256 function uses HMAC_256 and corresponds to the method of method of specifying the arguments and the output value of P_hash data expansion function, given in Section 5 of [RFC2246] and kept in [RFC5246].
This is the transformation to implement the pseudorandom function of the TLS protocol; the transformation uses the HMAC_512 values based on GOST R 34.11-2012 [GOST3411-2012], 512-bit output.
The A_i parameters are determined sequentially as follows:
P_GOSTR3411_2012_512 function uses HMAC_512 and corresponds to the method of method of specifying the arguments and the output value for P_hash data expansion function, given in Section 5 of [RFC2246] and kept in [RFC5246].
This pseudorandom function for the keying material generation is defined as follows (the arguments are the byte strings K and S):
where
PRF_IPSEC_KEYMAT_GOSTR3411_2012_256 function is similar to KEYMAT function in [RFC2409] regarding the assignment scheme for the arguments in the iterations.
This pseudorandom function for the keying material generation is defined as follows (the arguments are the byte strings K and S)
where
PRF_IPSEC_PRFPLUS_GOSTR3411_2012_256 output size is not more than 255*256 bits, which corresponds to the output sequence T1| T2| T3| T4| ... | T255.
PRF_IPSEC_PRFPLUS_GOSTR3411_2012_256 is similar to the prf+ function in [RFC5996] regarding the assignment scheme for the arguments in iterations.
This pseudorandom function for the keying material generation is defined as follows (the arguments are the byte strings K and S):
where
PRF_IPSEC_KEYMAT_GOSTR3411_2012_512 is similar to KEYMAT function in [RFC2409] regarding the assignment scheme for the arguments in iterations.
This pseudorandom function for the keying material generation is defined as follows (the arguments are the byte strings K and S):
where
PRF_IPSEC_PRFPLUS_GOSTR3411_2012_512 output size is not more than 255*512 bits, which corresponds to the output sequence T1| T2| T3| T4|...| T255.
The function PRF_IPSEC_PRFPLUS_GOSTR3411_2012_512 is similar to the prf+ function in [RFC5996] regarding the assignment scheme for the arguments in iterations.
This section identifies the key agreement algorithms using GOST R 34.10-2012 [GOST3410-2012].
The 256-bit VKO GOST R 34.10-2012 algorithm is used for an agreement of the VKO 256-bit keys and based on GOST R 34.11-2012 [GOST3411-2012], 256-bit. The algorithm can be used for an agreement of the GOST R 34.10-2012 [GOST3410-2012] keys with the size of 256 bits or 512 bits.
The algorithm is designed to produce an encryption key or a keying material of size 256 bits to be used in the cryptographic protocols. Key or keying material KEK_VKO (x, y, UKM) is produced by the exchange participant from his private key x, the public key y*P of the opposite side and UKM value, considered as a number.
The algorithm can be used for both static and ephemeral key with the public key size n ≥ 512 bits including the case where one side uses a static key and the other - ephemeral.
UKM parameter is optional (the default UKM = 1) and can take any value from 1 to 2^(n/2)-1. It is allowed to use a nonzero UKM of arbitrary size not exceeding n/2 bits. UKM size of 64 bit or more is recommended for cases where the keys at least one of the parties are static.
where m and q - the parameters of the elliptic curve according GOST R 34.10-2012 [GOST3410-2012] notation.
This algorithm is defined by analogy with Section 5.2 of [RFC4357], but instead of the hash function GOST R 34.11-94 [GOST3411-94] (referred as gostR3411) applies the hash function H_256 and K(x, y, UKM) is calculated at the public key size n ≥ 512 bits and UKM size up to n/2 bits.
The 512-bit VKO GOST R 34.10-2012 algorithm is used for an agreement of the VKO 512-bit keys and based on GOST R 34.11-2012 [GOST3411-2012], 512-bit. The algorithm can be used for an agreement of the GOST R 34.10-2012 [GOST3410-2012] keys with the size of 512 bits.
The algorithm is designed to produce an encryption key or keying material of size 512 bits to be used in cryptographic protocols. Key or keying material KEK_VKO (x, y, UKM) is produced by the exchange participant from his private key x, the public key y*P of the opposite side and the UKM value, considered as a number.
The algorithm can be used for both static and ephemeral key with the public key size n ≥ 1024 bits including the case where one side uses a static key and the other - ephemeral.
UKM parameter is optional (the default UKM = 1) and can take any value from 1 to 2^(n/2)-1. It is allowed to use a nonzero UKM of arbitrary size not exceeding n/2 bits. UKM size of 128 bit or more is recommended for cases where the keys at least one of the parties are static.
where m and q - the parameters of the elliptic curve according GOST R 34.10-2012 [GOST3410-2012] notation.
This algorithm is defined by analogy with Section 5.2 of [RFC4357], but instead of the hash function GOST R 34.11-94 [GOST3411-94] (referred as gostR3411) applies the hash function H_256, and K(x, y, UKM) is calculated at the public key size n ≥ 1024 bits and UKM size up to n/2 bits.
The key derivation function KDF_GOSTR3411_2012_256 based on HMAC_256 function is designed to generate a 256-bit keying material and is given by:
where
The key derivation function KDF_GOSTR3411_2012_256 is a special case of KDF_TREE_GOSTR3411_2012 function, described in the next section.
The key derivation function KDF_TREE_GOSTR3411_2012_256 based on HMAC_256 and is given by:
where
The key derivation function KDF_TREE_GOSTR3411_2012_256 is intended for generating a keying material in size of L, not exceeding 256*(2^(8*R)-1) bits, and utilizes general principles of the input and output for the key derivation function that are outlined in Section 5.1 of NIST SP 800-108 [NISTSP800-108]. HMAC_256 algorithm with 256-bit output described in Section 4.1 is selected as a pseudorandom function.
When R = 1 and L = 256 the function KDF_TREE_GOSTR3411_2012_256 is equivalent to KDF_GOSTR3411_2012_256 from the previous section.
Each key derived from the keying material, which was formed with the derivation key K_in (0-level key) may be a 1-level diversification key and may used to generate a new keying material. The keying material derived from the 1-level derivation key, can be broken down into the 2nd level derivation keys. The application of this procedure leads to the construction of the key tree with the root key and the formation of the key 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 the protocols.
Wrapped representation of the secret key K (GOST R 34.10-2012 [GOST3410-2012] key or GOST 28147-89 [GOST28147-89] key) is formed as follows by using a given export key K_e (GOST 28147-89 [GOST28147-89] key) and the random UKM vector from 8 to 16 bytes in size:
Where as a key derivation function is used KDF function (see previous section) for the fixed value
and the seed value that is equal to UKM.
During key import the value of key K is restored as follows from the wrapped representation of the key (GOST R 34.10-2012 [GOST3410-2012] key or GOST 28147-89 key [GOST28147-89] key) and the export key K_e:
The algorithms for wrapping and unwrapping of the GOST R 34.10-2012 [GOST3410-2012] keys are modifications of CryptoPro Key Wrap and CryptoPro Key Unwrap algorithms, described in Sections 6.3 and 6.4 of [RFC4357].
1) HMAC_GOSTR3411_2012_256
Key K:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
T:
01 26 bd b8 78 00 af 21 43 41 45 65 63 78 01 00
HMAC_256(K, T) value:
a1 aa 5f 7d e4 02 d7 b3 d3 23 f2 99 1c 8d 45 34
01 31 37 01 0a 83 75 4f d0 af 6d 7c d4 92 2e d9
2) HMAC_GOSTR3411_2012_512
Key K:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
T:
01 26 bd b8 78 00 af 21 43 41 45 65 63 78 01 00
HMAC_256(K, T) value:
a5 9b ab 22 ec ae 19 c6 5f bd e6 e5 f4 e9 f5 d8
54 9d 31 f0 37 f9 df 9b 90 55 00 e1 71 92 3a 77
3d 5f 15 30 f2 ed 7e 96 4c b2 ee dc 29 e9 ad 2f
3a fe 93 b2 81 4f 79 f5 00 0f fc 03 66 c2 51 e6
3) PRF_TLS_GOSTR3411_2012_256
Key K:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Seed:
18 47 1d 62 2d c6 55 c4 d2 d2 26 96 91 ca 4a 56
0b 50 ab a6 63 55 3a f2 41 f1 ad a8 82 c9 f2 9a
Label:
11 22 33 44 55
Output T1:
ff 09 66 4a 44 74 58 65 94 4f 83 9e bb 48 96 5f
15 44 ff 1c c8 e8 f1 6f 24 7e e5 f8 a9 eb e9 7f
Output T2:
c4 e3 c7 90 0e 46 ca d3 db 6a 01 64 30 63 04 0e
c6 7f c0 fd 5c d9 f9 04 65 23 52 37 bd ff 2c 02
4) PRF_TLS_GOSTR3411_2012_512
Key K:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Seed:
18 47 1d 62 2d c6 55 c4 d2 d2 26 96 91 ca 4a 56
0b 50 ab a6 63 55 3a f2 41 f1 ad a8 82 c9 f2 9a
Label:
11 22 33 44 55
Output T1:
f3 51 87 a3 dc 96 55 11 3a 0e 84 d0 6f d7 52 6c
5f c1 fb de c1 a0 e4 67 3d d6 d7 9d 0b 92 0e 65
ad 1b c4 7b b0 83 b3 85 1c b7 cd 8e 7e 6a 91 1a
62 6c f0 2b 29 e9 e4 a5 8e d7 66 a4 49 a7 29 6d
Output T2:
e6 1a 7a 26 c4 d1 ca ee cf d8 0c ca 65 c7 1f 0f
88 c1 f8 22 c0 e8 c0 ad 94 9d 03 fe e1 39 57 9f
72 ba 0c 3d 32 c5 f9 54 f1 cc cd 54 08 1f c7 44
02 78 cb a1 fe 7b 7a 17 a9 86 fd ff 5b d1 5d 1f
5) PRF_IPSEC_KEYMAT_GOSTR3411_2012_256
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 of S:
01 26 bd b8 78 00 1d 80 60 3c 85 44 c7 27 01 00
Output T1:
21 01 d8 0c 47 db 54 bc 3c 82 9b 8c 30 7c 47 55
50 88 83 a6 d6 9e 60 1b f7 aa fb 0a bc a4 ed 95
Output T2:
33 b8 4e d0 8f 93 56 f8 1d f8 d2 79 f0 79 c9 02
87 cb 45 2c 81 d4 1e 80 38 43 08 86 c1 92 12 aa
6) PRF_IPSEC_PRFPLUS_GOSTR3411_2012_256
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 of S:
01 26 bd b8 78 00 1d 80 60 3c 85 44 c7 27 01 00
Output T1:
2d e5 ee 84 e1 3d 7b e5 36 16 67 39 13 37 0a b0
54 c0 74 b7 9b 69 a8 a8 46 82 a9 f0 4f ec d5 87
Output T2:
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
7) PRF_IPSEC_KEYMAT_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 of S:
01 26 bd b8 78 00 1d 80 60 3c 85 44 c7 27 01 00
Output T1:
b9 55 5b 29 91 75 4b 37 9d a6 8e 60 98 f5 b6 0e
df 91 8a 56 20 4b ff f3 a8 37 6d 1f 57 ed b2 34
a5 12 32 81 23 cd 6c 03 0b 54 14 2e 1e c7 78 2b
03 00 be a5 7c c2 a1 4c a3 b4 f0 85 a4 5c d6 ca
Output T2:
37 b1 e0 86 52 43 a4 fb 29 14 8d 27 4d 30 63 fc
bf b0 f2 f4 68 d5 27 e4 3b ca 41 fa 6b b5 3e c8
df 21 bf c4 62 3a 2e 76 8b 64 54 03 3e 09 52 32
d1 8c 86 a6 8f 00 98 d3 31 81 75 f6 59 05 ae db
8) 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 of 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
9) VKO_GOSTR3410_2012_256 with 256-bit output on the GOST R 34.10-2012 keys (512-bit output) 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
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
10) VKO_GOSTR3410_2012_512 with 512-bit output on the GOST R 34.10-2012 keys (512-bit output) 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
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:
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
11) Key derivation function KDF_GOSTR3411_2012_256:
K_in key:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Label:
26 bd b8 78
Seed:
af 21 43 41 45 65 63 78
KDF(K_in, label, seed) value:
a1 aa 5f 7d e4 02 d7 b3 d3 23 f2 99 1c 8d 45 34
01 31 37 01 0a 83 75 4f d0 af 6d 7c d4 92 2e d9
12) Key derivation function KDF_TREE_GOSTR3411_2012_256
Output size of L:
512
K_in key:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Label:
26 bd b8 78
Seed:
af 21 43 41 45 65 63 78
Value of K1:
22 b6 83 78 45 c6 be f6 5e a7 16 72 b2 65 83 10
86 d3 c7 6a eb e6 da e9 1c ad 51 d8 3f 79 d1 6b
Value of K2:
07 4c 93 30 59 9d 7f 8d 71 2f ca 54 39 2f 4d dd
e9 37 51 20 6b 35 84 c8 f4 3f 9e 6d c5 15 31 f9
13) Key wrap and unwrap with the szOID_Gost28147_89_TC26_Z_ParamSet parameters
Key K:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
UKM value:
af 21 43 41 45 65 63 78
Label:
26 bd b8 78
KEK_e(UKM) = KDF(K_e, label, UKM):
a1 aa 5f 7d e4 02 d7 b3 d3 23 f2 99 1c 8d 45 34
01 31 37 01 0a 83 75 4f d0 af 6d 7c d4 92 2e d9
CEK_MAC:
38 d5 8a a3
CEK_ENC:
b9 fb 92 42 95 0f 84 3f 0f bd 5b 9a 5e cf 9f 17
f7 9e 6d 21 58 16 56 de 6d c5 85 dd 62 7a 44 0a