idnits 2.17.1 draft-popov-cryptopro-cpalgs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2543. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2535), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 736 has weird spacing: '...modules gostR...' == Line 742 has weird spacing: '...modules gostR...' == Line 746 has weird spacing: '...modules gostR...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 5, 2005) is 6961 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 855 -- Looks like a reference, but probably isn't: '1' on line 413 -- Looks like a reference, but probably isn't: '7' on line 409 -- Looks like a reference, but probably isn't: '8' on line 424 == Missing Reference: 'GOST341194' is mentioned on line 540, but not defined ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Vladimir Popov, CRYPTO-PRO 3 Igor Kurepkin, CRYPTO-PRO 4 Expires October 5, 2005 Serguei Leontiev, CRYPTO-PRO 5 Intended Category: Informational April 5, 2005 7 Additional cryptographic algorithms for use with GOST 28147-89, 8 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 algorithms. 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 This document is an Internet Draft and is subject to all provisions 20 of Section 10 of RFC2026. Internet Drafts are working documents of 21 the Internet Engineering Task Force (IETF), its areas, and its 22 working groups. Note that other groups may also distribute working 23 documents as Internet Drafts. Internet Drafts are draft documents 24 valid for a maximum of 6 months and may be updated, replaced, or 25 obsoleted by other documents at any time. It is inappropriate to use 26 Internet Drafts as reference material or to cite them other than as a 27 "work in progress". 29 The list of current Internet Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document describes the cryptographic algorithms and parameters 40 supplementary to the original GOST specifications GOST 28147-89, GOST 41 R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 for use in internet 42 applications. 44 Table of Contents 45 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 46 1.2 Terminology. . . . . . . . . . . . . . . . . . . . . . . 2 47 2 Cipher modes and parameters. . . . . . . . . . . . . . . 3 48 2.1 GOST 28147-89 CBC mode . . . . . . . . . . . . . . . . . 3 49 2.2 GOST 28147-89 padding modes. . . . . . . . . . . . . . . 4 50 2.3 Key Meshing Algorithms . . . . . . . . . . . . . . . . . 4 51 2.3.1 Null Key Meshing . . . . . . . . . . . . . . . . . . . . 4 52 2.3.2 CryptoPro Key Meshing. . . . . . . . . . . . . . . . . . 4 53 3 HMAC_GOSTR3411 . . . . . . . . . . . . . . . . . . . . . 5 54 4 PRF_GOSTR3411. . . . . . . . . . . . . . . . . . . . . . 5 55 5 Key Derivation Algorithms. . . . . . . . . . . . . . . . 5 56 5.1 VKO GOST R 34.10-94. . . . . . . . . . . . . . . . . . . 5 57 5.2 VKO GOST R 34.10-2001. . . . . . . . . . . . . . . . . . 6 58 6 Key Wrap algorithms. . . . . . . . . . . . . . . . . . . 6 59 6.1 GOST 28147-89 Key Wrap . . . . . . . . . . . . . . . . . 6 60 6.2 GOST 28147-89 Key Unrap. . . . . . . . . . . . . . . . . 7 61 6.3 CryptoPro Key Wrap . . . . . . . . . . . . . . . . . . . 7 62 6.4 CryptoPro Key Unwrap . . . . . . . . . . . . . . . . . . 8 63 6.5 CryptoPro KEK Diversification Algorithm. . . . . . . . . 8 64 7 Secret Key Diversification . . . . . . . . . . . . . . . 9 65 8 Algorithm parameters . . . . . . . . . . . . . . . . . . 9 66 8.1 Encryption algorithm parameters . . . . . . . . . . . . 9 67 8.2 Digest algorithm parameters. . . . . . . . . . . . . . . 11 68 8.3 GOST R 34.10-94 public key algorithm parameters . . . . 11 69 8.4 GOST R 34.10-2001 public key algorithm parameters. . . . 12 70 9 Security Considerations. . . . . . . . . . . . . . . . . 13 71 10 Appendix ASN.1 Modules . . . . . . . . . . . . . . . . . 14 72 11 References . . . . . . . . . . . . . . . . . . . . . . . 49 73 12 Acknowledgments. . . . . . . . . . . . . . . . . . . . . 51 74 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 51 75 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 53 77 1 Introduction 79 Russian cryptographic standards that define the algorithms GOST 80 28147-89 [GOST28147], GOST R 34.10-94 [GOSTR341094], GOST R 81 34.10-2001 [GOSTR34102001] and GOST R34.11-94 [GOSTR341194] provide 82 basic information about how the algorithms work, but need 83 supplemental specifications to effectively use the algorithms (a 84 brief english technical description of these algorithms can be found 85 in [Schneier95]). 87 This document is a proposal put forward by the CRYPT-PRO Company to 88 provide supplemental information and specifications needed by the 89 "Russian Cryptographic Software Compatibility Agreement" community. 91 1.2 Terminology 93 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 94 SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described 95 in [RFC 2119]. 97 The following functions and operators are also used in this document: 99 '|' stands for concatenation 101 encryptECB (K, D) - is D, encrypted with key K using GOST 28147-89 in 102 "prostaya zamena" (ECB) mode 104 decryptECB (K, D) - is D, decrypted with key K using GOST 28147-89 in 105 ECB mode 107 encryptCFB (IV, K, D) - is D, encrypted with key K using GOST 108 28147-89 in "gammirovanie s obratnoj svyaziyu" (64-bit CFB) mode, and 109 IV as initialization vector. 111 encryptCNT (IV, K, D) - is D, encrypted with key K using GOST 112 28147-89 in "gammirovanie" (counter) mode, and IV as initialization 113 vector. 115 gostR3411 (D) - is the 256-bit result of GOST R 34.11-94 hash 116 function, used with zero intitialization vector, and S-Box parameter, 117 defined by gostR3411CryptoProParamSetAI (see Appendix, 118 GostR3411-94-ParamSetSyntax module). 120 gost28147IMIT (IV, K, D) - is the 32-bit result of GOST 28147-89 in 121 "imitovstavka" (MAC) mode, used with D as plaintext, K as key and IV 122 as initialization vector. Note, that standard specifies it's use in 123 this mode only with zero initialization vector. 125 When keys and initialization vectors are converted to/from byte 126 arrays, little-endian byte order is assumed. 128 2 Cipher modes and parameters 130 This document defines four cipher properties that allow an 131 implementer to vary cipher operations. The four parameters are the 132 cipher mode, the key meshing algorithm, the padding mode, and the S- 133 box. 135 [GOST28147] defines only three cipher modes for GOST 28147-89: ECB, 136 CFB and counter mode. This document defines an additional cipher 137 mode, CBC. 139 When GOST 28147-89 is used to process large amounts of data, a 140 symmetric key should be protected by key meshing algorithm. Key 141 meshing transforms a symmetric key after some amount of data has been 142 processed. This document defines CryptoPro key meshing algorithm. 144 The cipher mode, key meshing algorithm, padding mode, and S-box are 145 specified by algorithm parameters. 147 2.1 GOST 28147-89 CBC mode 149 This section provides the supplemental information to GOST 28147-89 150 (a block to block primitive) needed to operate in CBC mode. 152 Before each plaintext block is encrypted, it is combined with the 153 cipher text of the previous block via a bitwise XOR operation. This 154 ensures that even if the plaintext contains many identical blocks, 155 each block will encrypt to a different cipher text block. The 156 initialization vector is combined with the first plaintext block by a 157 bitwise XOR operation before the block is encrypted. 159 2.2 GOST 28147-89 padding modes 161 This section provides the supplemental information to GOST 28147-89, 162 needed to operate on plaintext where the length is not divisible by 163 GOST 28147-89 block size (8 bytes). 165 Let x (0 < x < 8) be the number of bytes in the last, possibly 166 incomplete, block of data. 168 There are three padding modes: 169 * Zero padding: 8-x remaining bytes are filled with zero 170 * PKCS#5 padding: 8-x remaining bytes are filled with value of 8-x. 171 If there's no incomplete block, one extra block filled with 172 value 8 is added. 173 * Random padding: 8-x remaining bytes of the last block are 174 set to random. 176 2.3 Key Meshing Algorithms 178 When there is a need to limit the amount of data enciphered with the 179 same key, several key meshing algorithms can be used. Key meshing 180 algorithms transform the key after processing a certain amount of 181 data. 183 All encryption parameter sets defined in this document specify the 184 use of CryptoPro key meshing algorithm, except for id- 185 Gost28147-89-TestParamSet, which specifies use of null key meshing 186 algorithm. 188 2.3.1 Null Key Meshing 190 The null key meshing algorithm never changes a key. 192 The identifier for this algorithm is: 194 id-Gost28147-89-None-KeyMeshing OBJECT IDENTIFIER ::= 195 { id-CryptoPro-algorithms keyMeshing(14) none(0) } 197 There are no meaningful parameters to this algorithm. If present, 198 AlgorithmIdentifier.parameters MUST contain NULL. 200 2.3.2 CryptoPro Key Meshing 202 The CryptoPro key meshing algorithm transforms the key and 203 initialization vector every 1KB of plaintext data. 205 The identifier for this algorithm is: 207 id-Gost28147-89-CryptoPro-KeyMeshing OBJECT IDENTIFIER ::= 208 { id-CryptoPro-algorithms keyMeshing(14) cryptoPro(1) } 210 There are no meaningful parameters to this algorithm. If present, 211 AlgorithmIdentifier.parameters MUST contain NULL. 213 Encryption or decryption starts with key K[0] = K, IV0[0] = IV, i = 214 0. Let IV[0] be the value of the initialization vector after 215 processing the first 1K block of data. Encryption or decryption of 216 the next 1K data block will start with K[1] and IV0[1], which are 217 calculated using the formula: 219 K[i+1] = decryptECB (K[i], C); 220 IV0[i+1] = encryptECB (K[i+1],IV[i]) 222 Where C = {0x69, 0x00, 0x72, 0x22, 0x64, 0xC9, 0x04, 0x23, 223 0x8D, 0x3A, 0xDB, 0x96, 0x46, 0xE9, 0x2A, 0xC4, 224 0x18, 0xFE, 0xAC, 0x94, 0x00, 0xED, 0x07, 0x12, 225 0xC0, 0x86, 0xDC, 0xC2, 0xEF, 0x4C, 0xA9, 0x2B}; 227 After processing each 1K block of data: 228 * the resulting initialization vector is stored as IV[i]. 229 * K[i+1] and IV0[i+1] are calculated 230 * i is incremented. 231 * Next block is encrypted or decrypted using the new key and IV. 232 The process is repeated until all the data has been processed. 234 3 HMAC_GOSTR3411 236 HMAC_GOSTR3411 (K,text) function is based on hash function GOST R 237 34.11-94, as defined in [HMAC], with the following parameter values: 238 B = 32, L = 32. 240 4 PRF_GOSTR3411 242 PRF_GOSTR3411 is a pseudorandom function, based on HMAC_GOSTR3411. 243 It is calculated as P_hash, defined in section 5 of [TLS]. 244 PRF_GOSTR3411(secret,label,seed) = P_GOSTR3411 (secret,label|seed) 246 5 Key Derivation Algorithms 248 Standards [GOSTR341094] and [GOSTR34102001] do not define any key 249 derivation algorithms. 251 Section 5.1 specifies algorithm VKO GOST R 34.10-94, which generates 252 GOST KEK using two GOST R 34.10-94 keypairs. 254 Section 5.2 specifies algorithm VKO GOST R 34.10-2001, which 255 generates GOST KEK using two GOST R 34.10-2001 keypairs and UKM. 257 Keypairs MUST have identical parameters. 259 5.1 VKO GOST R 34.10-94 261 This algorithm creates a a key encryption key (KEK) using the 262 sender's private key and the recipient's public key (or vice versa). 264 Exchange key EK is a 256-bit hash of 1024-bit Diffie-Hellman key 265 K(x,y); 267 1. Let K(x,y) = a^(x*y) (mod p), where 268 x - sender's private key, a^x - sender's public key 269 y - recipient's private key, a^y - recipient's public key 270 a, p - parameters 2. Calculate a 256-bit hash of K(x,y): 271 KEK(x,y) = gostR3411 (K(x,y)) 273 Keypairs x and y MUST comply with [GOSTR341094]. 275 This algorithm MUST NOT be used when a^x = a (mod p) or a^y = a (mod 276 p). 278 5.2 VKO GOST R 34.10-2001 280 This algorithm creates a key encryption key (KEK) using 64 bit UKM, 281 the sender's private key and the recipient's public key (or the 282 reverse of the latter pair). 284 1. Let K(x,y,UKM) = ((UKM*x)(mod q)) . (y.P) (512 bit), where 285 x - sender's private key (256 bit) 286 x.P - sender's public key (512 bit) 287 y - recipient's private key (256 bit) 288 y.P - recipient's public key (512 bit) 289 UKM - User Keying Material (64 bit) 290 P - base point on the elliptic curve (two 256-bit coordinates) 291 UKM*x - x multiplied by UKM as integers 292 x.P - a multiple point 294 2. Calculate a 256-bit hash of K(x,y,UKM): 295 KEK(x,y,UKM) = gostR3411 (K(x,y,UKM)) 297 Keypairs x and y MUST comply with [GOSTR34102001]. 299 This algorithm MUST NOT be used when x.P = P, y.P = P 301 6 Key Wrap algorithms 303 This document defines two key wrap algorithms: GOST 28147-89 Key Wrap 304 and CryptoPro Key Wrap. These are used to encrypt a Content Encryption 305 Key (CEK) with a Key Encryption Key (KEK). 307 6.1 GOST 28147-89 Key Wrap 309 This algorithm encrypts GOST 28147-89 CEK with a GOST 28147-89 KEK. 311 Note: This algorithm MUST NOT be used with a KEK produced by VKO GOST 312 R 34.10-94, because such a KEK is constant for every sender-recipient 313 pair. Encrypting many different content encryption keys on the same 314 constant KEK may reveal that KEK. 316 The identifier for this algorithm is: 318 id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::= 319 { id-CryptoPro-algorithms keyWrap(13) none(0) } 321 The GOST 28147-89 key wrap algorithm is: 323 1. For a unique symmetric KEK, generate 8 octets at random, 324 call the result UKM. 325 For a KEK, produced by VKO GOST R 34.10-2001, use the UKM 326 that was used for key derivation. 327 2. Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK, CEK). 328 Call the result CEK_MAC. 329 3. Encrypt the CEK in ECB mode using the KEK. 330 Call the ciphertext CEK_ENC. 331 4. Let RES = UKM | CEK_ENC | CEK_MAC. 333 6.2 GOST 28147-89 Key Unwrap 335 This algorithm decrypts GOST 28147-89 CEK with a GOST 28147-89 KEK. 337 The GOST 28147-89 key unwrap algorithm is: 339 1. If the wrapped content-encryption key is not 44 octets, then 340 error. 341 2. Decompose the the wrapped content-encryption key into UKM, 342 CEK_ENC 343 and CEK_MAC. UKM is the most significant (first) 8 octets. 344 CEK_ENC 345 is next 32 octets, and CEK_MAC is the least significant (last) 4 346 octets. 347 3. Decrypt CEK_ENC in ECB mode using the KEK. 348 Call the output CEK. 349 4. Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK, CEK), 350 compare the result with CEK_MAC. If not equal, then error. 352 6.3 CryptoPro Key Wrap 354 This algorithm encrypts GOST 28147-89 CEK with a GOST 28147-89 KEK. 355 It can be used with any KEK (e.g. produced by VKO GOST R 34.10-94 or 356 VKO GOST R 34.10-2001) because unique UKM is used to diversify the 357 KEK. 359 Identifier for this algorithm: 361 id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::= 362 { id-CryptoPro-algorithms keyWrap(13) cryptoPro(1) } 364 The CryptoPro key wrap algorithm is: 366 1. For a unique symmetric KEK or a KEK produced by VKO GOST R 367 34.10-94, 368 generate 8 octets at random. Call the result UKM. 369 For a KEK, produced by VKO GOST R 34.10-2001, use the UKM 370 that was used for key derivation. 371 2. Diversify KEK, using the CryptoPro KEK Diversification Algorithm, 372 described in section 6.5. Call the result KEK(UKM). 373 3. Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK(UKM), 374 CEK). 375 Call the result CEK_MAC. 376 4. Encrypt CEK in ECB mode using KEK(UKM). Call the ciphertext 377 CEK_ENC. 378 5. Let RES = UKM | CEK_ENC | CEK_MAC. 380 6.4 CryptoPro Key Unrap 382 This algorithm encrypts GOST 28147-89 CEK with a GOST 28147-89 KEK. 383 The CryptoPro key unwrap algorithm is: 385 1. If the wrapped content-encryption key is not 44 octets, then 386 error. 387 2. Decompose the the wrapped content-encryption key into UKM, 388 CEK_ENC 389 and CEK_MAC. UKM is the most significant (first) 8 octets. 390 CEK_ENC 391 is next 32 octets, and CEK_MAC is the least significant (last) 392 4 octets. 393 3. Diversify KEK using the CryptoPro KEK Diversification Algorithm, 394 described in section 6.5. Call the result KEK(UKM). 395 4. Decrypt CEK_ENC in ECB mode using KEK(UKM). 396 Call the output CEK. 397 5. Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK(UKM), 398 CEK), 399 compare the result with CEK_MAC. If not equal, then error. 401 6.5 CryptoPro KEK Diversification Algorithm 403 Given a random 64-bit UKM, and a GOST 28147-89 key K, this algorithm 404 creates a new GOST 28147-89 key K(UKM). 406 1. Let K[0] = K; 408 2. UKM is split into components a[i,j]: 409 UKM = a[0]|..|a[7] (a[i] - byte, a[i,0]..a[i,7] - it's bits) 411 3. Let i be 0. 413 4. K[1]..K[8] are calculated by repeating the 414 following algorithm eight times: 416 A) K[i] is split into components k[i,j]: 417 K[i] = k[i,0]|k[i,1]|..|k[i,7] (k[i,j] - 32-bit integer) 418 B) Vector S[i] is calculated: 419 S[i] = ((a[i,0]*k[i,0] + ... + a[i,7]*k[i,7]) mod 2^32) 420 | ((~a[i,0]*k[i,0] + ... + ~a[i,7]*k[i,7]) mod 2^32); 421 C) K[i+1] = encryptCFB (S[i], K[i], K[i]) 422 D) i = i + 1 424 5. Let K(UKM) be K[8]. 426 7 Secret Key Diversification 428 This algorithm creates a GOST 28147-89 key Kd, given GOST R 34.10-94 429 or GOST R 34.10-2001 secret key K and diversification data D of size 430 4..40 bytes. 432 1) 40-byte blob B is created from D by cloning it enough times to 433 fill all 40 bytes. For example, if D is 40-bytes long, B = D; If D is 434 4-bytes long, B = D|D|D|D|D|D|D|D|D|D. 436 2) B is split into 8-byte UKM and 32-byte SRCKEY (B = UKM|SRCKEY). 438 3) The algorithm from section 6.5 is used to create K(UKM) from key K 439 and UKM with two differences: 440 * Instead of S[i], vector (0,0,0,UKM[i],ff,ff,ff,ff XOR UKM[i]) is 441 used. 442 * During each encryption step, only 8 out of 32 GOST 28147-89 steps 443 are done. 445 4) Kd is calculated: 446 Kd = encryptCFB (UKM, K(UKM), SRCKEY). 448 8 Algorithm parameters 450 Standards [GOST28147], [GOST341194], [GOSTR341094] and 451 [GOSTR34102001] do not define specific values for algorithm 452 parameters. 454 This document introduces the use of OIDs to specify algorithm 455 parameters. 457 Identifiers and corresponding parameter values for all of the 458 proposed parameter sets can be found in the Appendix in the form of 459 ASN.1 modules [X.660]. 461 8.1 Encryption algorithm parameters 463 GOST 28147-89 can be used in several modes, additional CBC mode is 464 defined in section 2.1 this document. It also has an S-Box parameter 465 (see Algorithm Parameters part in [GOST28147] in Russian, description 466 in English see in [Schneier95] ch. 14.1, p. 331). 468 This table contains the list of proposed parameter sets for GOST 469 28147-89: 471 Gost28147-89-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= { 472 { Gost28147-89-ParamSetParameters IDENTIFIED BY 473 id-Gost28147-89-TestParamSet } | 474 { Gost28147-89-ParamSetParameters IDENTIFIED BY 475 id-Gost28147-89-CryptoPro-A-ParamSet } | 476 { Gost28147-89-ParamSetParameters IDENTIFIED BY 477 id-Gost28147-89-CryptoPro-B-ParamSet } | 478 { Gost28147-89-ParamSetParameters IDENTIFIED BY 479 id-Gost28147-89-CryptoPro-C-ParamSet } | 480 { Gost28147-89-ParamSetParameters IDENTIFIED BY 481 id-Gost28147-89-CryptoPro-D-ParamSet } | 482 { Gost28147-89-ParamSetParameters IDENTIFIED BY 483 id-Gost28147-89-CryptoPro-Simple-A-ParamSet } | 484 { Gost28147-89-ParamSetParameters IDENTIFIED BY 485 id-Gost28147-89-CryptoPro-Simple-B-ParamSet } | 486 { Gost28147-89-ParamSetParameters IDENTIFIED BY 487 id-Gost28147-89-CryptoPro-Simple-C-ParamSet } | 488 { Gost28147-89-ParamSetParameters IDENTIFIED BY 489 id-Gost28147-89-CryptoPro-Simple-D-ParamSet } 490 } 492 Identifier values are in the Appendix. 494 Parameters for GOST 28147-89 are presented in the following form: 496 Gost28147-89-ParamSetParameters ::= SEQUENCE { 497 eUZ Gost28147-89-UZ, 498 mode INTEGER { 499 gost28147-89-CNT(0), 500 gost28147-89-CFB(1), 501 cryptoPro-CBC(2) 502 }, 503 shiftBits INTEGER { gost28147-89-block(64) }, 504 keyWrap AlgorithmIdentifier, 505 keyMeshing AlgorithmIdentifier 506 } 507 Gost28147-89-UZ ::= OCTET STRING (SIZE (64)) 508 Gost28147-89-KeyMeshingAlgorithms ALGORITHM-IDENTIFIER ::= { 509 { NULL IDENTIFIED BY id-Gost28147-89-CryptoPro-KeyMeshing } | 510 { NULL IDENTIFIED BY id-Gost28147-89-None-KeyMeshing } 511 } 512 Gost28147-89-KeyWrapAlgorithms ALGORITHM-IDENTIFIER ::= { 513 { NULL IDENTIFIED BY id-Gost28147-89-CryptoPro-KeyWrap } | 514 { NULL IDENTIFIED BY id-Gost28147-89-None-KeyWrap } 515 } 517 where 518 eUZ - S-box value; 519 mode - cipher mode; 520 shiftBits - cipher parameter; 521 keyWrap - key export algorithm identifier; 522 keyMeshing - key meshing algorithm identifier. 524 8.2 Digest algorithm parameters 526 This table contains the list of proposed parameter sets for 527 [GOST341194]: 529 GostR3411-94-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= { 530 { GostR3411-94-ParamSetParameters IDENTIFIED BY 531 id-GostR3411-94-TestParamSet 532 } | 533 { GostR3411-94-ParamSetParameters IDENTIFIED BY 534 id-GostR3411-94-CryptoProParamSet 535 } 536 } 538 Identifier values are in the Appendix. 540 Parameters for [GOST341194] are presented in the following form: 542 GostR3411-94-ParamSetParameters ::= 543 SEQUENCE { 544 hUZ Gost28147-89-UZ, -- S-Box for digest 545 h0 GostR3411-94-Digest -- start digest value 546 } 547 GostR3411-94-Digest ::= OCTET STRING (SIZE (32)) 549 6.3 GOST R 34.10-94 public key algorithm parameters 551 This table contains the list of proposed parameter sets for GOST R 552 34.10-94: 554 GostR3410-94-ParamSetAlgorithm ALGORITHM-IDENTIFIER ::= { 555 { GostR3410-94-ParamSetParameters IDENTIFIED BY 556 id-GostR3410-94-TestParamSet } | 557 { GostR3410-94-ParamSetParameters IDENTIFIED BY 558 id-GostR3410-94-CryptoPro-A-ParamSet } | 559 { GostR3410-94-ParamSetParameters IDENTIFIED BY 560 id-GostR3410-94-CryptoPro-B-ParamSet } | 561 { GostR3410-94-ParamSetParameters IDENTIFIED BY 562 id-GostR3410-94-CryptoPro-C-ParamSet } | 563 { GostR3410-94-ParamSetParameters IDENTIFIED BY 564 id-GostR3410-94-CryptoPro-D-ParamSet } | 565 { GostR3410-94-ParamSetParameters IDENTIFIED BY 566 id-GostR3410-94-CryptoPro-XchA-ParamSet } | 567 { GostR3410-94-ParamSetParameters IDENTIFIED BY 568 id-GostR3410-94-CryptoPro-XchB-ParamSet } | 569 { GostR3410-94-ParamSetParameters IDENTIFIED BY 570 id-GostR3410-94-CryptoPro-XchC-ParamSet } 571 } 573 Identifier values are in the Appendix. 575 Parameters for GOST R 34.10-94 are presented in the following form: 577 GostR3410-94-ParamSetParameters ::= 578 SEQUENCE { 579 t INTEGER, 580 p INTEGER, 581 q INTEGER, 582 a INTEGER, 583 validationAlgorithm AlgorithmIdentifier {{ 584 GostR3410-94-ValidationAlgorithms 585 }} OPTIONAL 586 } 588 GostR3410-94-ValidationParameters ::= 589 SEQUENCE { 590 x0 INTEGER, 591 c INTEGER, 592 d INTEGER OPTIONAL 593 } 595 Where 596 t - bit length of p (512 or 1024 bits); 597 p - modulus, prime number, 2^(t-1)