idnits 2.17.1 draft-smyslov-esp-gost-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2019) is 1659 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 487, but not defined -- Looks like a reference, but probably isn't: '12' on line 789 -- Looks like a reference, but probably isn't: '16' on line 777 -- Looks like a reference, but probably isn't: '8' on line 857 -- Looks like a reference, but probably isn't: '64' on line 716 -- Looks like a reference, but probably isn't: '112' on line 791 -- Looks like a reference, but probably isn't: '4' on line 843 -- Looks like a reference, but probably isn't: '108' on line 859 -- Looks like a reference, but probably isn't: '80' on line 849 -- Looks like a reference, but probably isn't: '0' on line 856 == Outdated reference: A later version (-06) exists of draft-dolmatov-magma-03 == Outdated reference: A later version (-20) exists of draft-smyshlyaev-mgm-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Informational October 11, 2019 5 Expires: April 13, 2020 7 Using GOST ciphers in ESP and IKEv2 8 draft-smyslov-esp-gost-01 10 Abstract 12 This document defines a set of encryption transforms for use in 13 Encapsulating Security Payload (ESP) and Internet Key Exchange 14 version 2 (IKEv2) protocols. The transforms are based on Russian 15 cryptographic standard algorithms (GOST) in a Multilinear Galois Mode 16 (MGM). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 13, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Transforms Description . . . . . . . . . . . . . . . . . . . 3 56 4.1. Tree-based External Re-Keying . . . . . . . . . . . . . . 4 57 4.2. Initialization Vector Format . . . . . . . . . . . . . . 5 58 4.3. Nonce Format for MGM . . . . . . . . . . . . . . . . . . 5 59 4.3.1. MGM Nonce Format for "Kuznyechik" based Transforms . 6 60 4.3.2. MGM Nonce Format for "Magma" based Transforms . . . . 6 61 4.4. Keying Material . . . . . . . . . . . . . . . . . . . . . 7 62 4.5. Integrity Check Value . . . . . . . . . . . . . . . . . . 7 63 4.6. Plaintext Padding . . . . . . . . . . . . . . . . . . . . 8 64 4.7. AAD Construction . . . . . . . . . . . . . . . . . . . . 8 65 4.7.1. ESP AAD . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.7.2. IKEv2 AAD . . . . . . . . . . . . . . . . . . . . . . 10 67 4.8. Using Transforms . . . . . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 7.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 76 1. Introduction 78 This document defines four encryption transforms for the 79 Encapsulating Security Payload (ESP) [RFC4303] and the Internet Key 80 Exchange version 2 (IKEv2) [RFC7296]. These transforms are based on 81 two block ciphers from Russian cryptographic standard algorithms 82 (often called "GOST" algorithms) - "Kuznyechik" [RFC7801] and "Magma" 83 [I-D.dolmatov-magma]. These ciphers are used in Multilinear Galois 84 Mode (MGM) [I-D.smyshlyaev-mgm] which provides Authenticated 85 Encryption with Associated Data (AEAD). In addition these transforms 86 use external re-keying mechanism, described in [RFC8645] to limit a 87 load on a session key. 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. Overview 99 Russian cryptographic standard algorithms, often referred as "GOST" 100 algorithms, are a set of cryptographic algorithms of different types 101 - ciphers, hash functions, digital signatures etc. In particular, 102 Russian cryptographic standard [GOST3412-2015] defines two block 103 ciphers - "Kuznyechik" (also defined in [RFC7801]) and "Magma" (also 104 defined in [I-D.dolmatov-magma]). Both these ciphers use 256-bit 105 key. "Kuznyechik" has a block size of 128 bits, while "Magma" has a 106 64-bit block. 108 Multilinear Galois Mode (MGM) is an AEAD mode defined in 109 [I-D.smyshlyaev-mgm]. It is claimed to provide defense against some 110 attacks on well-known AEAD modes, like Galois Counter Mode (GCM). 112 In addition, [RFC8645] defines some mechanisms that can be used to 113 limit the number of times any particular session key is used. One of 114 these mechanisms, called External Re-Keying with Tree-based 115 Construction (defined in Section 5.2.3 of [RFC8645]), is used in the 116 defined transforms. For the purpose of deriving subordinate keys a 117 Key Derivation Function (KDF) KDF_GOSTR3411_2012_256 defined in 118 Section 4.5 of [RFC7836], is used. This KDF is based on an HMAC 119 [RFC2104] in a combination with a Russian GOST hash function defined 120 in Russian cryptographic standard [GOST3411-2012] (also defined in 121 [RFC6986]). 123 4. Transforms Description 125 This document defines four transforms for use in ESP and IKEv2. All 126 of them use MGM mode of operation with Tree-based External Re-Keying. 127 The transforms differ in used underlying algorithms and in 128 cryptographic services they provide. 130 o ENCR_KUZNYECHIK_MGM_KTREE is an AEAD transform based on 131 "Kuznyechik" algorithm; it provides confidentiality and message 132 authentication and thus can be used both in ESP and IKEv2; the 133 Transform ID is ; 135 o ENCR_MAGMA_MGM_KTREE is an AEAD transform based on "Magma" 136 algorithm; it provides confidentiality and message authentication 137 and thus can be used both in ESP and IKEv2; the Transform ID is 138 140 o ENCR_KUZNYECHIK_MGM_MAC_KTREE is a MAC-only transform based on 141 "Kuznyechik" algorithm; it provides no confidentiality and thus 142 can only be used in ESP, but not in IKEv2; the Transform ID is 143 145 o ENCR_MAGMA_MGM_MAC_KTREE is a MAC-only transform based on "Magma" 146 algorithm; it provides no confidentiality and thus can only be 147 used in ESP, but not in IKEv2; the Transform ID is 149 4.1. Tree-based External Re-Keying 151 All four transforms use the same Tree-based External Re-Keying 152 mechanism. The idea is that the key that is provided for the 153 transform (Child SA key derived from KEYMAT in case of ESP or SK_ei/ 154 SK_er in case of IKEv2) is not directly used to protect messages. 155 Instead a tree of keys is derived using this key as a root. This 156 tree may have several levels. The leaf keys are used for message 157 protection, while intermediate nodes keys are used to derive lower 158 level keys (including leaf keys). See Section 5.2.3 of [RFC8645] for 159 more detail. This construction allows to protect a large amount of 160 data, but at the same time providing a bound on a number of times any 161 particular key in the tree is used, thus defending from some side 162 channel attacks. 164 The transforms defined in this document use three-level tree. The 165 leaf key that protects a message is computed as follows: 167 K_msg = KDF (KDF (KDF (K, l1, i1), l2, i2), l3, i3) 169 where: 171 KDF (k, l, s) Key Derivation Function KDF_GOSTR3411_2012_256 172 defined in Section 4.5 of [RFC7836], which accepts 173 three input parameters - a key (k), a label (l) and a 174 seed (s) and provides a new key as an output; 176 K the key for the transform (ESP SA key derived from 177 KEYMAT or SK_ei/SK_er in case of IKEv2); 179 l1, l2, l3 labels defined as 6 octet ASCII strings without null 180 termination: 182 l1 = "level1" 184 l2 = "level2" 186 l3 = "level3" 188 i1, i2, i3 parameters that determine which keys out of the tree 189 are used on each level, altogether they determine a 190 leaf key that is used for message protection; these 191 parameters are two octet integers in network byte 192 order; 194 This construction allows to generate up to 2^16 keys on each level, 195 but due to IV construction (see Section 4.2) the number of possible 196 keys on the level 1 is limited to 2^8. So, the total number of 197 possible leaf keys generated from one SA key is 2^40. 199 This specifications doesn't impose any requirements on the frequency 200 the external re-keying takes place. It is expected that sending 201 application will follow its own policy dictating how many times the 202 keys on each level must be used. 204 4.2. Initialization Vector Format 206 Each message protected by the defined transforms must contain 207 Initialization Vector (IV). The IV has a size of 64 bits and 208 consists of the four fields, three of which are i1, i2 and i3 209 parameters that determine the particular leaf key this message was 210 protected with (see Section 4.1), and the fourh is a counter, 211 representing the message number for this key. 213 1 2 3 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | i1 | i2 | i3 | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | i3 (cont) | pnum | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 1: IV Format 223 where: 225 o i1 (1 octet), i2 (2 octets), i3 (2 octets) - parameters, 226 determining the particular key used to protect this message; 227 2-octets parameters are integers in network byte order 229 o pnum (3 octets) - message counter in network byte order for the 230 leaf key protecting this message; up to 2^24 messages may be 231 protected using a single leaf key 233 For any given SA the IV MUST NOT repeat, but there is no requirement 234 that IV is unpredictable. 236 4.3. Nonce Format for MGM 238 MGM requires a per-message nonce (called Initial Counter Nonce, ICN, 239 in the [I-D.smyshlyaev-mgm]) that must be unique in the context of 240 any leaf key (that are used to actually protect messages). The size 241 of the ICN is n-1 bits, where n is the size of the block of the 242 underlying cipher. The two ciphers used in the defined transforms 243 have different block sizes, so two different formats for the ICN are 244 defined. 246 MGM specification requires that the nonce be n-1 bits in size, where 247 n is a block size of underlying cipher. This document defines MGM 248 nonces that are n bits in size, because that makes them having a 249 whole number of bytes. When used inside MGM the most significant bit 250 of the first octet of the nonce (represented as an octet string) is 251 dropped, making an effective size of the nonce equal to n-1 bits. 252 Note, that the dropped bit is a part of zero field (see Figure 2 and 253 Figure 3) which is always set to 0, so no information is lost when it 254 is dropped. 256 4.3.1. MGM Nonce Format for "Kuznyechik" based Transforms 258 For transforms based on "Kuznyechik" cipher 259 (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the ICN 260 consists of a zero octet, a 24-bit message counter and a 96-bit 261 secret salt, that is fixed for SA and is not transmitted. 263 1 2 3 264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | zero | pnum | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 | salt | 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2: Nonce format for "Kuznyechik" based transforms 275 where: 277 o zero (1 octet) - set to 0 279 o pnum (3 octets) - the counter for the messages protected by the 280 given leaf key; this field MUST be equal to the pnum field in the 281 IV 283 o salt (12 octets) - secret salt 285 4.3.2. MGM Nonce Format for "Magma" based Transforms 287 For transforms based on "Magma" cipher (ENCR_MAGMA_MGM_KTREE and 288 ENCR_MAGMA_MGM_MAC_KTREE) the ICN consists of a zero octet, a 24-bit 289 message counter and a 32-bit secret salt, that is fixed for SA and is 290 not transmitted. 292 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | zero | pnum | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | salt | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 3: Nonce format for "Magma" based transforms 302 where: 304 o zero (1 octet) - set to 0 306 o pnum (3 octets) - the counter for the messages protected by the 307 given leaf key; this field MUST be equal to the pnum field in the 308 IV 310 o salt (4 octets) - secret salt 312 4.4. Keying Material 314 The key for ENCR_KUZNYECHIK_MGM_KTREE and 315 ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits, of 316 which the first 256 bits is a root key for the tree (denoted as K in 317 Section 4.1) and the remaining 96 bits is a secret salt (see 318 Section 4.3.1). 320 The key for ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE 321 transforms consists of 288 bits, of which the first 256 bits is a 322 root key for the tree (denoted as K in Section 4.1) and the remaining 323 32 bits is a secret salt (see Section 4.3.2). 325 The keys in case ESP are extracted from the KEYMAT, and in case IKEv2 326 they are SK_ei/SK_er keys. Note, that since these transforms provide 327 authenticated encryption, no additional keys are needed for 328 authentication. It means that in case of IKEv2 the keys SK_ai/SK_ar 329 are not used. 331 4.5. Integrity Check Value 333 The MGM computes authentication tag equal to the size of the block of 334 the underlying cipher. For "Kuznyechik" based transforms 335 (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the 336 resulting Integrity Check Value (ICV) is truncated to 96 bits by 337 dropping the last 4 octets of the produced authentication tag. For 338 "Magma" based transforms the full 64-bit authentication tag is used 339 as ICV. 341 4.6. Plaintext Padding 343 Transforms defined in this document don't require any plaintext 344 padding, as specified in [I-D.smyshlyaev-mgm]. It means, that only 345 those padding requirements that are imposed by the protocol are 346 applied (4 bytes for ESP, no padding for IKEv2). 348 4.7. AAD Construction 350 4.7.1. ESP AAD 352 Additional Authenticated Data (AAD) in ESP is constructed differently 353 depending on the transform being used and whether Extended Sequence 354 Number (ESN) is in use or not. The ENCR_KUZNYECHIK_MGM_KTREE and 355 ENCR_MAGMA_MGM_KTREE provide confidentiality, so the content of the 356 ESP body is encrypted and AAD consists of the ESP SPI and (E)SN. The 357 AAD is constructed similar to the one in [RFC4106]. 359 On the other hand the ENCR_KUZNYECHIK_MGM_MAC_KTREE and 360 ENCR_MAGMA_MGM_MAC_KTREE don't provide confidentiality, they provide 361 only message authentication. For this purpose the IV and the part of 362 ESP packet that is normally encrypted are included in the AAD. For 363 these transforms encryption capability provided by MGM is not used. 364 The AAD is constructed similar to the one in [RFC4543]. 366 1 2 3 367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | SPI | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | 32-bit Sequence Number | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 4: AAD for AEAD transforms with 32-bit SN 375 1 2 3 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | SPI | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | 64-bit Extended Sequence Number | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 5: AAD for AEAD transforms with 64-bit ESN 386 1 2 3 387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | SPI | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | 32-bit Sequence Number | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | IV | 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 ~ Payload Data (variable) ~ 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Padding (0-255 bytes) | 401 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | Pad Length | Next Header | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 6: AAD for authentication only transforms with 32-bit SN 406 1 2 3 407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | SPI | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | 64-bit Extended Sequence Number | 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | IV | 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 ~ Payload Data (variable) ~ 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Padding (0-255 bytes) | 422 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | Pad Length | Next Header | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 7: AAD for authentication only transforms with 64-bit ESN 428 4.7.2. IKEv2 AAD 430 For IKEv2 the AAD consists of the IKEv2 Header, the unencrypted 431 payload followed it and an Encrypted (or Encrypted Fragment) payload 432 header. The AAD is constructed similar to one in [RFC5282]. 434 1 2 3 435 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 ~ IKEv2 Header ~ 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 ~ Unencrypted IKE Payloads ~ 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Next Payload |C| RESERVED | Payload Length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 8: AAD for IKEv2 446 4.8. Using Transforms 448 When SA is established the i1, i2 and i3 parameters are set to 0 by 449 the sender and a leaf key is calculated. The pnum parameter starts 450 from 0 and is incremented with each message protected by the same 451 leaf key. When sender decides that the leaf should be changed, it 452 increments i3 parameter and generates a new leaf key. The pnum 453 parameter for the new leaf key is reset to 0 and the process 454 continues. If the sender decides, that 3-rd level key corresponding 455 to i3 is used enough times, it increments i2, resets i3 to 0 and 456 calculates a new leaf key. The pnum is reset to 0 (as with every new 457 leaf key) and the process continues. 459 The receiver always uses i1, i2 and i3 from the incoming message. If 460 they differ from the values in previous packets, a new leaf key is 461 calculated . The pnum parameter is always used from the incoming 462 packet. To improve performance implementations may cache recently 463 used leaf key. When new leaf key is calculated (based on the values 464 from incoming message) the old key may be kept for some time to 465 improve performance in case of possible packet reordering (when 466 packets protected by the old leaf key are delayed and arrive later). 468 5. Security Considerations 470 The most important security consideration for MGM is that the nonce 471 never repeat for a given key. For this reason the transforms defined 472 in this document MUST NOT be used with manual keying. 474 Security properties of MGM are discussed in [MGM-SECURITY]. 476 6. IANA Considerations 478 IANA has assigned four Transform IDs in the "Transform Type 1 - 479 Encryption Algorithm Transform IDs" registry (where RFCXXXX is this 480 document): 482 Number Name ESP Reference IKEv2 Reference 483 --------------------------------------------------------------------- 484 TBA1 ENCR_KUZNYECHIK_MGM_KTREE [RFCXXXX] [RFCXXXX] 485 TBA2 ENCR_MAGMA_MGM_KTREE [RFCXXXX] [RFCXXXX] 486 TBA3 ENCR_KUZNYECHIK_MGM_MAC_KTREE [RFCXXXX] Not allowed 487 TBA4 ENCR_MAGMA_MGM_MAC_KTREE [RFCXXXX] Not allowed 489 7. References 491 7.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 499 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 500 May 2017, . 502 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 503 RFC 4303, DOI 10.17487/RFC4303, December 2005, 504 . 506 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 507 Kivinen, "Internet Key Exchange Protocol Version 2 508 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 509 2014, . 511 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 512 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 513 2013, . 515 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 516 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 517 . 519 [I-D.dolmatov-magma] 520 Dolmatov, V. and D. Eremin-Solenikov, "GOST R 34.12-2015: 521 Block Cipher "Magma"", draft-dolmatov-magma-03 (work in 522 progress), September 2019. 524 [I-D.smyshlyaev-mgm] 525 Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and S. 526 Ekaterina, "Multilinear Galois Mode (MGM)", draft- 527 smyshlyaev-mgm-11 (work in progress), June 2019. 529 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 530 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 531 on the Cryptographic Algorithms to Accompany the Usage of 532 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 533 RFC 7836, DOI 10.17487/RFC7836, March 2016, 534 . 536 7.2. Informative References 538 [GOST3411-2012] 539 Federal Agency on Technical Regulating and Metrology, 540 "Information technology. Cryptographic Data Security. 541 Hashing function", GOST R 34.11-2012 (in Russian), 2012. 543 [GOST3412-2015] 544 Federal Agency on Technical Regulating and Metrology, 545 "Information technology. Cryptographic data security. 546 Block ciphers", GOST R 34.12-2015 (in Russian), 2015. 548 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 549 Hashing for Message Authentication", RFC 2104, 550 DOI 10.17487/RFC2104, February 1997, 551 . 553 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 554 (GCM) in IPsec Encapsulating Security Payload (ESP)", 555 RFC 4106, DOI 10.17487/RFC4106, June 2005, 556 . 558 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 559 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 560 DOI 10.17487/RFC4543, May 2006, 561 . 563 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 564 Algorithms with the Encrypted Payload of the Internet Key 565 Exchange version 2 (IKEv2) Protocol", RFC 5282, 566 DOI 10.17487/RFC5282, August 2008, 567 . 569 [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric 570 Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, 571 . 573 [MGM-SECURITY] 574 Akhmetzyanova, L., Alekseev, E., Karpunin, G., and V. 575 Nozdrunov, "Security of Multilinear Galois Mode (MGM)", 576 2019, . 578 Appendix A. Test Vectors 580 1. ENCR_KUZNYECHIK_MGM_KTREE, example 1: 582 K: 583 b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c 584 e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 585 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 586 K_msg: 587 2f f1 c9 0e de 78 6e 06 1e 17 b3 74 d7 82 af 7b 588 d8 80 bd 52 7c 66 a2 ba dc 3e 56 9a ab 27 1d a4 589 salt [12]: 590 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 591 nonce [16]: 592 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 593 IV [8]: 594 00 00 00 00 00 00 00 00 595 AAD [8]: 596 51 46 53 6b 00 00 00 01 597 plaintext [64]: 598 45 00 00 3c 23 35 00 00 7f 01 ee cc 0a 6f 0a c5 599 0a 6f 0a 1d 08 00 f3 5b 02 00 58 00 61 62 63 64 600 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 601 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 602 ciphertext [64]: 603 18 9d 12 88 b7 18 f9 ea be 55 4b 23 9b ee 65 96 604 c6 d4 ea fd 31 64 96 ef 90 1c ac 31 60 05 aa 07 605 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e 7b 9d eb 31 606 85 ff e9 17 9c a9 bf 0b db af c2 3e ae 4d a5 6f 607 ESP ICV [12]: 608 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed 609 ESP packet [112]: 610 45 00 00 70 00 4d 00 00 ff 32 91 4f 0a 6f 0a c5 611 0a 6f 0a 1d 51 46 53 6b 00 00 00 01 00 00 00 00 612 00 00 00 00 18 9d 12 88 b7 18 f9 ea be 55 4b 23 613 9b ee 65 96 c6 d4 ea fd 31 64 96 ef 90 1c ac 31 614 60 05 aa 07 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e 615 7b 9d eb 31 85 ff e9 17 9c a9 bf 0b db af c2 3e 616 ae 4d a5 6f 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed 618 2. ENCR_KUZNYECHIK_MGM_KTREE, example 2: 620 K: 621 b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c 622 e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 623 i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 624 K_msg: 625 9a ba c6 57 78 18 0e 6f 2a f6 1f b8 d5 71 62 36 626 66 c2 f5 13 0d 54 e2 11 6c 7d 53 0e 6e 7d 48 bc 627 salt [12]: 628 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 629 nonce [16]: 630 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 631 IV [8]: 632 00 00 01 00 01 00 00 00 633 AAD [8]: 634 51 46 53 6b 00 00 00 10 635 plaintext [64]: 636 45 00 00 3c 23 48 00 00 7f 01 ee b9 0a 6f 0a c5 637 0a 6f 0a 1d 08 00 e4 5b 02 00 67 00 61 62 63 64 638 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 639 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 640 ciphertext [64]: 641 78 0a 2c 62 62 32 15 7b fe 01 76 32 f3 2d b4 d0 642 a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b ac 1d fc 4b 643 15 4b 69 03 4d c2 1d ef 20 90 6d 59 62 81 12 7c 644 ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 a4 d4 9a 4d 645 ESP ICV [12]: 646 c2 2f 87 40 83 8e 3d fa ce 91 cc b8 647 ESP packet [112]: 648 45 00 00 70 00 5c 00 00 ff 32 91 40 0a 6f 0a c5 649 0a 6f 0a 1d 51 46 53 6b 00 00 00 10 00 00 01 00 650 01 00 00 00 78 0a 2c 62 62 32 15 7b fe 01 76 32 651 f3 2d b4 d0 a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b 652 ac 1d fc 4b 15 4b 69 03 4d c2 1d ef 20 90 6d 59 653 62 81 12 7c ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 654 a4 d4 9a 4d c2 2f 87 40 83 8e 3d fa ce 91 cc b8 656 3. ENCR_MAGMA_MGM_KTREE, example 1: 658 K: 659 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 660 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 661 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 662 K_msg: 663 25 65 21 e2 70 b7 4a 16 4d fc 26 e6 bf 0c ca 76 664 5e 9d 41 02 7d 4b 7b 19 76 2b 1c c9 01 dc de 7f 665 salt [4]: 666 cf 36 63 12 667 nonce [8]: 668 00 00 00 00 cf 36 63 12 669 IV [8]: 670 00 00 00 00 00 00 00 00 671 AAD [8]: 672 c8 c2 b2 8d 00 00 00 01 673 plaintext [64]: 674 45 00 00 3c 24 2d 00 00 7f 01 ed d4 0a 6f 0a c5 675 0a 6f 0a 1d 08 00 de 5b 02 00 6d 00 61 62 63 64 676 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 677 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 678 ciphertext [64]: 679 fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c 4a 91 7e 0c 680 d8 6f 8e 61 04 03 87 64 6b b9 df bd 91 50 3f 4a 681 f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc 99 ac ee 9e 682 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 15 52 cc e8 683 ESP ICV [8]: 684 5f 4a fa 8b 02 94 0f 5c 685 ESP packet [108]: 686 45 00 00 6c 00 62 00 00 ff 32 91 3e 0a 6f 0a c5 687 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 01 00 00 00 00 688 00 00 00 00 fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c 689 4a 91 7e 0c d8 6f 8e 61 04 03 87 64 6b b9 df bd 690 91 50 3f 4a f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc 691 99 ac ee 9e 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 692 15 52 cc e8 5f 4a fa 8b 02 94 0f 5c 694 4. ENCR_MAGMA_MGM_KTREE, example 2: 696 K: 697 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 698 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 699 i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 700 K_msg: 701 20 e0 46 d4 09 83 9b 23 f0 66 a5 0a 7a 06 5b 4a 702 39 24 4f 0e 29 ef 1e 6f 2e 5d 2e 13 55 f5 da 08 703 salt [4]: 704 cf 36 63 12 705 nonce [8]: 706 00 00 00 00 cf 36 63 12 707 IV [8]: 708 00 00 01 00 01 00 00 00 709 AAD [8]: 710 c8 c2 b2 8d 00 00 00 10 711 plaintext [64]: 712 45 00 00 3c 24 40 00 00 7f 01 ed c1 0a 6f 0a c5 713 0a 6f 0a 1d 08 00 cf 5b 02 00 7c 00 61 62 63 64 714 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 715 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 716 ciphertext [64]: 717 7a 71 48 41 a5 34 b7 58 93 6a 8e ab 26 91 40 a8 718 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c 9b 88 db 72 719 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b d7 7a 07 1d 720 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 bf fe a1 dd 721 ESP ICV [8]: 722 dd 5d 50 9a fd b8 09 98 723 ESP packet [108]: 724 45 00 00 6c 00 71 00 00 ff 32 91 2f 0a 6f 0a c5 725 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 10 00 00 01 00 726 01 00 00 00 7a 71 48 41 a5 34 b7 58 93 6a 8e ab 727 26 91 40 a8 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c 728 9b 88 db 72 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b 729 d7 7a 07 1d 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 730 bf fe a1 dd dd 5d 50 9a fd b8 09 98 732 5. ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 1: 734 K: 735 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 736 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be 737 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 738 K_msg: 739 98 f1 03 01 81 0a 04 1c da dd e1 bd 85 a0 8f 21 740 8b ac b5 7e 00 35 e2 22 c8 31 e3 e4 f0 a2 0c 8f 741 salt [12]: 742 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 743 nonce [16]: 744 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 745 IV [8]: 746 00 00 00 00 00 00 00 00 747 AAD [80]: 748 3d ac 92 6a 00 00 00 01 00 00 00 00 00 00 00 00 749 45 00 00 3c 0c f1 00 00 7f 01 05 11 0a 6f 0a c5 750 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 61 62 63 64 751 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 752 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 753 plaintext [0]: 754 ciphertext [0]: 755 ESP ICV [12]: 756 ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d 757 ESP packet [112]: 758 45 00 00 70 00 01 00 00 ff 32 91 9b 0a 6f 0a c5 759 0a 6f 0a 1d 3d ac 92 6a 00 00 00 01 00 00 00 00 760 00 00 00 00 45 00 00 3c 0c f1 00 00 7f 01 05 11 761 0a 6f 0a c5 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 762 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 763 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 764 01 02 02 04 ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d 766 6. ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 2: 768 K: 769 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 770 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be 771 i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 772 K_msg: 773 02 c5 41 87 7c c6 23 f3 f1 35 91 9a 75 13 b6 f8 774 a8 a1 8c b2 63 99 86 2f 50 81 4f 52 91 01 67 84 775 salt [12]: 776 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 777 nonce [16]: 778 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 779 IV [8]: 780 00 00 00 00 01 00 00 00 781 AAD [80]: 782 3d ac 92 6a 00 00 00 06 00 00 00 00 01 00 00 00 783 45 00 00 3c 0c fb 00 00 7f 01 05 07 0a 6f 0a c5 784 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 61 62 63 64 785 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 786 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 787 plaintext [0]: 788 ciphertext [0]: 789 ESP ICV [12]: 790 ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91 791 ESP packet [112]: 792 45 00 00 70 00 06 00 00 ff 32 91 96 0a 6f 0a c5 793 0a 6f 0a 1d 3d ac 92 6a 00 00 00 06 00 00 00 00 794 01 00 00 00 45 00 00 3c 0c fb 00 00 7f 01 05 07 795 0a 6f 0a c5 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 796 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 797 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 798 01 02 02 04 ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91 800 7. ENCR_MAGMA_MGM_MAC_KTREE, example 1: 802 K: 803 d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 804 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 805 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 806 K_msg: 807 4c 61 45 99 a0 a0 67 f1 94 87 24 0a e1 00 e1 b7 808 ea f2 3e da f8 7e 38 73 50 86 1c 68 3b a4 04 46 809 salt [4]: 810 88 79 8f 29 811 nonce [8]: 812 00 00 00 00 88 79 8f 29 813 IV [8]: 814 00 00 00 00 00 00 00 00 815 AAD [80]: 816 3e 40 69 9c 00 00 00 01 00 00 00 00 00 00 00 00 817 45 00 00 3c 0e 08 00 00 7f 01 03 fa 0a 6f 0a c5 818 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 61 62 63 64 819 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 820 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 821 plaintext [0]: 822 ciphertext [0]: 823 ESP ICV [8]: 824 4d d4 25 8a 25 35 95 df 825 ESP packet [108]: 826 45 00 00 6c 00 13 00 00 ff 32 91 8d 0a 6f 0a c5 827 0a 6f 0a 1d 3e 40 69 9c 00 00 00 01 00 00 00 00 828 00 00 00 00 45 00 00 3c 0e 08 00 00 7f 01 03 fa 829 0a 6f 0a c5 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 830 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 831 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 832 01 02 02 04 4d d4 25 8a 25 35 95 df 834 8. ENCR_MAGMA_MGM_MAC_KTREE, example 2: 836 K: 837 d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 838 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 839 i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 840 K_msg: 841 b4 f3 f9 0d c4 87 fa b8 c4 af d0 eb 45 49 f2 f0 842 e4 36 32 b6 79 19 37 2e 1e 96 09 ea f0 b8 e2 28 843 salt [4]: 844 88 79 8f 29 845 nonce [8]: 846 00 00 00 00 88 79 8f 29 847 IV [8]: 848 00 00 00 00 01 00 00 00 849 AAD [80]: 850 3e 40 69 9c 00 00 00 06 00 00 00 00 01 00 00 00 851 45 00 00 3c 0e 13 00 00 7f 01 03 ef 0a 6f 0a c5 852 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 61 62 63 64 853 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 854 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 855 plaintext [0]: 856 ciphertext [0]: 857 ESP ICV [8]: 858 84 84 a9 23 30 a0 b1 96 859 ESP packet [108]: 860 45 00 00 6c 00 18 00 00 ff 32 91 88 0a 6f 0a c5 861 0a 6f 0a 1d 3e 40 69 9c 00 00 00 06 00 00 00 00 862 01 00 00 00 45 00 00 3c 0e 13 00 00 7f 01 03 ef 863 0a 6f 0a c5 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 864 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 865 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 866 01 02 02 04 84 84 a9 23 30 a0 b1 96 868 Author's Address 870 Valery Smyslov 871 ELVIS-PLUS 872 PO Box 81 873 Moscow (Zelenograd) 124460 874 RU 876 Phone: +7 495 276 0211 877 Email: svan@elvis.ru