idnits 2.17.1 draft-smyslov-esp-gost-05.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 (April 27, 2021) is 1095 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 491, but not defined -- Looks like a reference, but probably isn't: '12' on line 812 -- Looks like a reference, but probably isn't: '16' on line 800 -- Looks like a reference, but probably isn't: '8' on line 880 -- Looks like a reference, but probably isn't: '64' on line 739 -- Looks like a reference, but probably isn't: '112' on line 814 -- Looks like a reference, but probably isn't: '4' on line 866 -- Looks like a reference, but probably isn't: '108' on line 882 -- Looks like a reference, but probably isn't: '80' on line 872 -- Looks like a reference, but probably isn't: '0' on line 879 == Outdated reference: A later version (-20) exists of draft-smyshlyaev-mgm-19 Summary: 0 errors (**), 0 flaws (~~), 3 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 April 27, 2021 5 Expires: October 29, 2021 7 Using GOST ciphers in ESP and IKEv2 8 draft-smyslov-esp-gost-05 10 Abstract 12 This document defines a set of encryption transforms for use in the 13 Encapsulating Security Payload (ESP) and in the 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 October 29, 2021. 35 Copyright Notice 37 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . 9 67 4.8. Using Transforms . . . . . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 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 transforms for the Encapsulating Security 79 Payload protocol (ESP) [RFC4303] and for the Internet Key Exchange 80 protocol version 2 (IKEv2) [RFC7296]. These document is based on 81 Russian Standard [GOST-ESP], which describes how Russian 82 cryptographic standard algorithms are used in ESP and IKEv2. 83 Transforms defined in this document are based on two block ciphers 84 from Russian cryptographic standard algorithms (often called "GOST" 85 algorithms) - "Kuznyechik" [GOST3412-2015][RFC7801] and "Magma" 86 [GOST3412-2015][RFC8891] in Multilinear Galois Mode (MGM) 87 [GOST-MGM][I-D.smyshlyaev-mgm]. These transforms provide 88 Authenticated Encryption with Associated Data (AEAD). An external 89 re-keying mechanism, described in [RFC8645] is also used in these 90 transforms to limit load on session keys. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. Overview 102 Russian cryptographic standard algorithms, often referred as "GOST" 103 algorithms, constitute a set of cryptographic algorithms of different 104 types - ciphers, hash functions, digital signatures etc. In 105 particular, Russian cryptographic standard [GOST3412-2015] defines 106 two block ciphers - "Kuznyechik" (also defined in [RFC7801]) and 107 "Magma" (also defined in [RFC8891]). Both ciphers use 256-bit key. 108 "Kuznyechik" has a block size of 128 bits, while "Magma" has a 64-bit 109 block. 111 Multilinear Galois Mode (MGM) is an AEAD mode defined in 112 [GOST-MGM][I-D.smyshlyaev-mgm]. It is claimed to provide defense 113 against some attacks on well-known AEAD modes, like Galois Counter 114 Mode (GCM). 116 [RFC8645] defines mechanisms that can be used to limit the number of 117 times any particular session key is used. One of these mechanisms, 118 called external re-keying with tree-based construction (defined in 119 Section 5.2.3 of [RFC8645]), is used in the defined transforms. For 120 the purpose of deriving subordinate keys a Key Derivation Function 121 (KDF) KDF_GOSTR3411_2012_256 defined in Section 4.5 of [RFC7836], is 122 used. This KDF is based on an HMAC [RFC2104] in a combination with a 123 Russian GOST hash function defined in Russian cryptographic standard 124 [GOST3411-2012] (also defined in [RFC6986]). 126 4. Transforms Description 128 This document defines four transforms for use in ESP and IKEv2. All 129 of them use MGM mode of operation with tree-based external re-keying. 130 The transforms differ in underlying ciphers and in cryptographic 131 services they provide. 133 o ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transform 134 based on "Kuznyechik" algorithm; it provides confidentiality and 135 message authentication and thus can be used both in ESP and IKEv2 137 o ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform based 138 on "Magma" algorithm; it provides confidentiality and message 139 authentication and thus can be used both in ESP and IKEv2 141 o ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only 142 transform based on "Kuznyechik" algorithm; it provides no 143 confidentiality and thus can only be used in ESP, but not in IKEv2 145 o ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only transform 146 based on "Magma" algorithm; it provides no confidentiality and 147 thus can only be used in ESP, but not in IKEv2 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 messages 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 details. This construction allows to protect a large amount of 160 data, 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. The size of the ICN is n-1 bits, where n is the block 241 size of the underlying cipher. The two ciphers used in the 242 transforms defined in this document have different block sizes, so 243 two different formats for the ICN are defined. 245 MGM specification requires that the nonce be n-1 bits in size, where 246 n is a block size of underlying cipher. This document defines MGM 247 nonces that are n bits in size, because that makes them having a 248 whole number of bytes. When used inside MGM the most significant bit 249 of the first octet of the nonce (represented as an octet string) is 250 dropped, making an effective size of the nonce equal to n-1 bits. 251 Note, that the dropped bit is a part of zero field (see Figure 2 and 252 Figure 3) which is always set to 0, so no information is lost when it 253 is dropped. 255 4.3.1. MGM Nonce Format for "Kuznyechik" based Transforms 257 For transforms based on "Kuznyechik" cipher 258 (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the ICN 259 consists of a zero octet, a 24-bit message counter and a 96-bit 260 secret salt, that is fixed for SA and is not transmitted. 262 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | zero | pnum | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 | salt | 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2: Nonce format for "Kuznyechik" based transforms 274 where: 276 o zero (1 octet) - set to 0 278 o pnum (3 octets) - the counter for the messages protected by the 279 given leaf key; this field MUST be equal to the pnum field in the 280 IV 282 o salt (12 octets) - secret salt 284 4.3.2. MGM Nonce Format for "Magma" based Transforms 286 For transforms based on "Magma" cipher (ENCR_MAGMA_MGM_KTREE and 287 ENCR_MAGMA_MGM_MAC_KTREE) the ICN consists of a zero octet, a 24-bit 288 message counter and a 32-bit secret salt, that is fixed for SA and is 289 not transmitted. 291 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | zero | pnum | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | salt | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 3: Nonce format for "Magma" based transforms 301 where: 303 o zero (1 octet) - set to 0 305 o pnum (3 octets) - the counter for the messages protected by the 306 given leaf key; this field MUST be equal to the pnum field in the 307 IV 309 o salt (4 octets) - secret salt 311 4.4. Keying Material 313 The key for ENCR_KUZNYECHIK_MGM_KTREE and 314 ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits, of 315 which the first 256 bits is a root key for the tree (denoted as K in 316 Section 4.1) and the remaining 96 bits is a secret salt (see 317 Section 4.3.1). 319 The key for ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE 320 transforms consists of 288 bits, of which the first 256 bits is a 321 root key for the tree (denoted as K in Section 4.1) and the remaining 322 32 bits is a secret salt (see Section 4.3.2). 324 The keys in case ESP are extracted from the KEYMAT, and in case IKEv2 325 they are SK_ei/SK_er keys. Note, that since these transforms provide 326 authenticated encryption, no additional keys are needed for 327 authentication. It means that in case of IKEv2 the keys SK_ai/SK_ar 328 are not used. 330 4.5. Integrity Check Value 332 The MGM computes authentication tag equal to the block size of the 333 underlying cipher. For "Kuznyechik" based transforms 334 (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the 335 resulting Integrity Check Value (ICV) is truncated to 96 bits by 336 dropping the last 4 octets of the produced authentication tag. For 337 "Magma" based transforms (ENCR_MAGMA_MGM_KTREE and 338 ENCR_MAGMA_MGM_MAC_KTREE) 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 similarly 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 similarly 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 376 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | SPI | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | 64-bit Extended Sequence Number | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 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 407 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | SPI | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | 64-bit Extended Sequence Number | 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | IV | 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 ~ Payload Data (variable) ~ 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Padding (0-255 bytes) | 423 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | Pad Length | Next Header | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 7: AAD for authentication only transforms with 64-bit ESN 429 4.7.2. IKEv2 AAD 431 For IKEv2 the AAD consists of the IKEv2 Header, any unencrypted 432 payloads followed it (if they are present) and the Encrypted (or the 433 Encrypted Fragment) payload header. The AAD is constructed similar 434 to one in [RFC5282]. 436 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 ~ IKEv2 Header ~ 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 ~ Unencrypted IKE Payloads ~ 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Next Payload |C| RESERVED | Payload Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 8: AAD for IKEv2 448 4.8. Using Transforms 450 When SA is established the i1, i2 and i3 parameters are set to 0 by 451 the sender and a leaf key is calculated. The pnum parameter starts 452 from 0 and is incremented with each message protected by the same 453 leaf key. When sender decides that the leaf should be changed, it 454 increments i3 parameter and generates a new leaf key. The pnum 455 parameter for the new leaf key is reset to 0 and the process 456 continues. If the sender decides, that 3-rd level key corresponding 457 to i3 is used enough times, it increments i2, resets i3 to 0 and 458 calculates a new leaf key. The pnum is reset to 0 (as with every new 459 leaf key) and the process continues. Similar procedure is used when 460 2-nd level key needs to be changed. 462 The receiver always uses i1, i2 and i3 from the received message. If 463 they differ from the values in previously received packets, a new 464 leaf key is calculated. The pnum parameter is always used from the 465 received packet. To improve performance implementations may cache 466 recently used leaf key. When new leaf key is calculated (based on 467 the values from received message) the old key may be kept for some 468 time to improve performance in case of possible packet reordering 469 (when packets protected by the old leaf key are delayed and arrive 470 later). 472 5. Security Considerations 474 The most important security consideration for MGM is that the nonce 475 MUST NOT repeat for a given key. For this reason the transforms 476 defined in this document MUST NOT be used with manual keying. 478 Security properties of MGM are discussed in [MGM-SECURITY]. 480 6. IANA Considerations 482 IANA has assigned four Transform IDs in the "Transform Type 1 - 483 Encryption Algorithm Transform IDs" registry (where RFCXXXX is this 484 document): 486 Number Name ESP Reference IKEv2 Reference 487 --------------------------------------------------------------------- 488 32 ENCR_KUZNYECHIK_MGM_KTREE [RFCXXXX] [RFCXXXX] 489 33 ENCR_MAGMA_MGM_KTREE [RFCXXXX] [RFCXXXX] 490 34 ENCR_KUZNYECHIK_MGM_MAC_KTREE [RFCXXXX] Not allowed 491 35 ENCR_MAGMA_MGM_MAC_KTREE [RFCXXXX] Not allowed 493 7. References 495 7.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 504 May 2017, . 506 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 507 RFC 4303, DOI 10.17487/RFC4303, December 2005, 508 . 510 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 511 Kivinen, "Internet Key Exchange Protocol Version 2 512 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 513 2014, . 515 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 516 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 517 2013, . 519 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 520 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 521 . 523 [RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: 524 Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891, 525 September 2020, . 527 [I-D.smyshlyaev-mgm] 528 Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and E. 529 Griboedova, "Multilinear Galois Mode (MGM)", draft- 530 smyshlyaev-mgm-19 (work in progress), January 2021. 532 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 533 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 534 on the Cryptographic Algorithms to Accompany the Usage of 535 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 536 RFC 7836, DOI 10.17487/RFC7836, March 2016, 537 . 539 7.2. Informative References 541 [GOST3411-2012] 542 Federal Agency on Technical Regulating and Metrology, 543 "Information technology. Cryptographic Data Security. 544 Hashing function", GOST R 34.11-2012, 2012. 546 (In Russian) 548 [GOST3412-2015] 549 Federal Agency on Technical Regulating and Metrology, 550 "Information technology. Cryptographic data security. 551 Block ciphers", GOST R 34.12-2015, 2015. 553 (In Russian) 555 [GOST-MGM] 556 Federal Agency on Technical Regulating and Metrology, 557 "Information technology. Cryptographic data security. 558 Authenticated encryption block cipher operation modes", 559 R 1323565.1.026-2019, 2019. 561 (In Russian) 563 [GOST-ESP] 564 Federal Agency on Technical Regulating and Metrology, 565 "Information technology. Cryptographic data security. 566 Using Russian cryptographic algorithms in data security 567 protocol ESP", R 1323565.1.035-2021, 2021. 569 (In Russian) 571 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 572 Hashing for Message Authentication", RFC 2104, 573 DOI 10.17487/RFC2104, February 1997, 574 . 576 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 577 (GCM) in IPsec Encapsulating Security Payload (ESP)", 578 RFC 4106, DOI 10.17487/RFC4106, June 2005, 579 . 581 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 582 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 583 DOI 10.17487/RFC4543, May 2006, 584 . 586 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 587 Algorithms with the Encrypted Payload of the Internet Key 588 Exchange version 2 (IKEv2) Protocol", RFC 5282, 589 DOI 10.17487/RFC5282, August 2008, 590 . 592 [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric 593 Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, 594 . 596 [MGM-SECURITY] 597 Akhmetzyanova, L., Alekseev, E., Karpunin, G., and V. 598 Nozdrunov, "Security of Multilinear Galois Mode (MGM)", 599 2019, . 601 Appendix A. Test Vectors 603 1. ENCR_KUZNYECHIK_MGM_KTREE, example 1: 605 K: 606 b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c 607 e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 608 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 609 K_msg: 610 2f f1 c9 0e de 78 6e 06 1e 17 b3 74 d7 82 af 7b 611 d8 80 bd 52 7c 66 a2 ba dc 3e 56 9a ab 27 1d a4 612 salt [12]: 613 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 614 nonce [16]: 615 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 616 IV [8]: 617 00 00 00 00 00 00 00 00 618 AAD [8]: 619 51 46 53 6b 00 00 00 01 620 plaintext [64]: 621 45 00 00 3c 23 35 00 00 7f 01 ee cc 0a 6f 0a c5 622 0a 6f 0a 1d 08 00 f3 5b 02 00 58 00 61 62 63 64 623 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 624 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 625 ciphertext [64]: 626 18 9d 12 88 b7 18 f9 ea be 55 4b 23 9b ee 65 96 627 c6 d4 ea fd 31 64 96 ef 90 1c ac 31 60 05 aa 07 628 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e 7b 9d eb 31 629 85 ff e9 17 9c a9 bf 0b db af c2 3e ae 4d a5 6f 630 ESP ICV [12]: 631 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed 632 ESP packet [112]: 633 45 00 00 70 00 4d 00 00 ff 32 91 4f 0a 6f 0a c5 634 0a 6f 0a 1d 51 46 53 6b 00 00 00 01 00 00 00 00 635 00 00 00 00 18 9d 12 88 b7 18 f9 ea be 55 4b 23 636 9b ee 65 96 c6 d4 ea fd 31 64 96 ef 90 1c ac 31 637 60 05 aa 07 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e 638 7b 9d eb 31 85 ff e9 17 9c a9 bf 0b db af c2 3e 639 ae 4d a5 6f 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed 641 2. ENCR_KUZNYECHIK_MGM_KTREE, example 2: 643 K: 644 b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c 645 e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 646 i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 647 K_msg: 648 9a ba c6 57 78 18 0e 6f 2a f6 1f b8 d5 71 62 36 649 66 c2 f5 13 0d 54 e2 11 6c 7d 53 0e 6e 7d 48 bc 650 salt [12]: 651 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 652 nonce [16]: 653 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 654 IV [8]: 655 00 00 01 00 01 00 00 00 656 AAD [8]: 657 51 46 53 6b 00 00 00 10 658 plaintext [64]: 659 45 00 00 3c 23 48 00 00 7f 01 ee b9 0a 6f 0a c5 660 0a 6f 0a 1d 08 00 e4 5b 02 00 67 00 61 62 63 64 661 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 662 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 663 ciphertext [64]: 664 78 0a 2c 62 62 32 15 7b fe 01 76 32 f3 2d b4 d0 665 a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b ac 1d fc 4b 666 15 4b 69 03 4d c2 1d ef 20 90 6d 59 62 81 12 7c 667 ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 a4 d4 9a 4d 668 ESP ICV [12]: 669 c2 2f 87 40 83 8e 3d fa ce 91 cc b8 670 ESP packet [112]: 671 45 00 00 70 00 5c 00 00 ff 32 91 40 0a 6f 0a c5 672 0a 6f 0a 1d 51 46 53 6b 00 00 00 10 00 00 01 00 673 01 00 00 00 78 0a 2c 62 62 32 15 7b fe 01 76 32 674 f3 2d b4 d0 a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b 675 ac 1d fc 4b 15 4b 69 03 4d c2 1d ef 20 90 6d 59 676 62 81 12 7c ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 677 a4 d4 9a 4d c2 2f 87 40 83 8e 3d fa ce 91 cc b8 679 3. ENCR_MAGMA_MGM_KTREE, example 1: 681 K: 682 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 683 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 684 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 685 K_msg: 686 25 65 21 e2 70 b7 4a 16 4d fc 26 e6 bf 0c ca 76 687 5e 9d 41 02 7d 4b 7b 19 76 2b 1c c9 01 dc de 7f 688 salt [4]: 689 cf 36 63 12 690 nonce [8]: 691 00 00 00 00 cf 36 63 12 692 IV [8]: 693 00 00 00 00 00 00 00 00 694 AAD [8]: 695 c8 c2 b2 8d 00 00 00 01 696 plaintext [64]: 697 45 00 00 3c 24 2d 00 00 7f 01 ed d4 0a 6f 0a c5 698 0a 6f 0a 1d 08 00 de 5b 02 00 6d 00 61 62 63 64 699 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 700 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 701 ciphertext [64]: 702 fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c 4a 91 7e 0c 703 d8 6f 8e 61 04 03 87 64 6b b9 df bd 91 50 3f 4a 704 f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc 99 ac ee 9e 705 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 15 52 cc e8 706 ESP ICV [8]: 707 5f 4a fa 8b 02 94 0f 5c 708 ESP packet [108]: 709 45 00 00 6c 00 62 00 00 ff 32 91 3e 0a 6f 0a c5 710 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 01 00 00 00 00 711 00 00 00 00 fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c 712 4a 91 7e 0c d8 6f 8e 61 04 03 87 64 6b b9 df bd 713 91 50 3f 4a f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc 714 99 ac ee 9e 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 715 15 52 cc e8 5f 4a fa 8b 02 94 0f 5c 717 4. ENCR_MAGMA_MGM_KTREE, example 2: 719 K: 720 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 721 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 722 i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 723 K_msg: 724 20 e0 46 d4 09 83 9b 23 f0 66 a5 0a 7a 06 5b 4a 725 39 24 4f 0e 29 ef 1e 6f 2e 5d 2e 13 55 f5 da 08 726 salt [4]: 727 cf 36 63 12 728 nonce [8]: 729 00 00 00 00 cf 36 63 12 730 IV [8]: 731 00 00 01 00 01 00 00 00 732 AAD [8]: 733 c8 c2 b2 8d 00 00 00 10 734 plaintext [64]: 735 45 00 00 3c 24 40 00 00 7f 01 ed c1 0a 6f 0a c5 736 0a 6f 0a 1d 08 00 cf 5b 02 00 7c 00 61 62 63 64 737 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 738 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 739 ciphertext [64]: 740 7a 71 48 41 a5 34 b7 58 93 6a 8e ab 26 91 40 a8 741 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c 9b 88 db 72 742 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b d7 7a 07 1d 743 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 bf fe a1 dd 744 ESP ICV [8]: 745 dd 5d 50 9a fd b8 09 98 746 ESP packet [108]: 747 45 00 00 6c 00 71 00 00 ff 32 91 2f 0a 6f 0a c5 748 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 10 00 00 01 00 749 01 00 00 00 7a 71 48 41 a5 34 b7 58 93 6a 8e ab 750 26 91 40 a8 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c 751 9b 88 db 72 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b 752 d7 7a 07 1d 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 753 bf fe a1 dd dd 5d 50 9a fd b8 09 98 755 5. ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 1: 757 K: 758 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 759 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be 760 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 761 K_msg: 762 98 f1 03 01 81 0a 04 1c da dd e1 bd 85 a0 8f 21 763 8b ac b5 7e 00 35 e2 22 c8 31 e3 e4 f0 a2 0c 8f 764 salt [12]: 765 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 766 nonce [16]: 767 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 768 IV [8]: 769 00 00 00 00 00 00 00 00 770 AAD [80]: 771 3d ac 92 6a 00 00 00 01 00 00 00 00 00 00 00 00 772 45 00 00 3c 0c f1 00 00 7f 01 05 11 0a 6f 0a c5 773 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 61 62 63 64 774 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 775 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 776 plaintext [0]: 777 ciphertext [0]: 778 ESP ICV [12]: 779 ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d 780 ESP packet [112]: 781 45 00 00 70 00 01 00 00 ff 32 91 9b 0a 6f 0a c5 782 0a 6f 0a 1d 3d ac 92 6a 00 00 00 01 00 00 00 00 783 00 00 00 00 45 00 00 3c 0c f1 00 00 7f 01 05 11 784 0a 6f 0a c5 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 785 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 786 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 787 01 02 02 04 ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d 789 6. ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 2: 791 K: 792 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 793 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be 794 i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 795 K_msg: 796 02 c5 41 87 7c c6 23 f3 f1 35 91 9a 75 13 b6 f8 797 a8 a1 8c b2 63 99 86 2f 50 81 4f 52 91 01 67 84 798 salt [12]: 799 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 800 nonce [16]: 801 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d 802 IV [8]: 803 00 00 00 00 01 00 00 00 804 AAD [80]: 805 3d ac 92 6a 00 00 00 06 00 00 00 00 01 00 00 00 806 45 00 00 3c 0c fb 00 00 7f 01 05 07 0a 6f 0a c5 807 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 61 62 63 64 808 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 809 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 810 plaintext [0]: 811 ciphertext [0]: 812 ESP ICV [12]: 813 ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91 814 ESP packet [112]: 815 45 00 00 70 00 06 00 00 ff 32 91 96 0a 6f 0a c5 816 0a 6f 0a 1d 3d ac 92 6a 00 00 00 06 00 00 00 00 817 01 00 00 00 45 00 00 3c 0c fb 00 00 7f 01 05 07 818 0a 6f 0a c5 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 819 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 820 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 821 01 02 02 04 ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91 823 7. ENCR_MAGMA_MGM_MAC_KTREE, example 1: 825 K: 826 d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 827 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 828 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 829 K_msg: 830 4c 61 45 99 a0 a0 67 f1 94 87 24 0a e1 00 e1 b7 831 ea f2 3e da f8 7e 38 73 50 86 1c 68 3b a4 04 46 832 salt [4]: 833 88 79 8f 29 834 nonce [8]: 835 00 00 00 00 88 79 8f 29 836 IV [8]: 837 00 00 00 00 00 00 00 00 838 AAD [80]: 839 3e 40 69 9c 00 00 00 01 00 00 00 00 00 00 00 00 840 45 00 00 3c 0e 08 00 00 7f 01 03 fa 0a 6f 0a c5 841 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 61 62 63 64 842 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 843 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 844 plaintext [0]: 845 ciphertext [0]: 846 ESP ICV [8]: 847 4d d4 25 8a 25 35 95 df 848 ESP packet [108]: 849 45 00 00 6c 00 13 00 00 ff 32 91 8d 0a 6f 0a c5 850 0a 6f 0a 1d 3e 40 69 9c 00 00 00 01 00 00 00 00 851 00 00 00 00 45 00 00 3c 0e 08 00 00 7f 01 03 fa 852 0a 6f 0a c5 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 853 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 854 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 855 01 02 02 04 4d d4 25 8a 25 35 95 df 857 8. ENCR_MAGMA_MGM_MAC_KTREE, example 2: 859 K: 860 d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 861 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 862 i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 863 K_msg: 864 b4 f3 f9 0d c4 87 fa b8 c4 af d0 eb 45 49 f2 f0 865 e4 36 32 b6 79 19 37 2e 1e 96 09 ea f0 b8 e2 28 866 salt [4]: 867 88 79 8f 29 868 nonce [8]: 869 00 00 00 00 88 79 8f 29 870 IV [8]: 871 00 00 00 00 01 00 00 00 872 AAD [80]: 873 3e 40 69 9c 00 00 00 06 00 00 00 00 01 00 00 00 874 45 00 00 3c 0e 13 00 00 7f 01 03 ef 0a 6f 0a c5 875 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 61 62 63 64 876 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 877 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 878 plaintext [0]: 879 ciphertext [0]: 880 ESP ICV [8]: 881 84 84 a9 23 30 a0 b1 96 882 ESP packet [108]: 883 45 00 00 6c 00 18 00 00 ff 32 91 88 0a 6f 0a c5 884 0a 6f 0a 1d 3e 40 69 9c 00 00 00 06 00 00 00 00 885 01 00 00 00 45 00 00 3c 0e 13 00 00 7f 01 03 ef 886 0a 6f 0a c5 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 887 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 888 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 889 01 02 02 04 84 84 a9 23 30 a0 b1 96 891 Author's Address 893 Valery Smyslov 894 ELVIS-PLUS 895 PO Box 81 896 Moscow (Zelenograd) 124460 897 RU 899 Phone: +7 495 276 0211 900 Email: svan@elvis.ru