RFC 9227 | GOST Ciphers in ESP and IKEv2 | March 2022 |
Smyslov | Informational | [Page] |
This document defines a set of encryption transforms for use in the Encapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of the IP Security (IPsec) protocol suite. The transforms are based on the GOST R 34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and the external rekeying approach.¶
This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9227.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The IP Security (IPsec) protocol suite consists of several protocols, of which the Encapsulating Security Payload (ESP) [RFC4303] and the Internet Key Exchange version 2 (IKEv2) [RFC7296] are most widely used. This document defines four transforms for ESP and IKEv2 based on Russian cryptographic standard algorithms (often referred to as "GOST" algorithms). These definitions are based on the recommendations [GOST-ESP] established by the Federal Agency on Technical Regulating and Metrology (Rosstandart), which describe how Russian cryptographic standard algorithms are used in ESP and IKEv2. The transforms defined in this document are based on two block ciphers from Russian cryptographic standard algorithms -- "Kuznyechik" [GOST3412-2015] [RFC7801] and "Magma" [GOST3412-2015] [RFC8891] in Multilinear Galois Mode (MGM) [GOST-MGM] [RFC9058]. These transforms provide Authenticated Encryption with Associated Data (AEAD). An external rekeying mechanism, described in [RFC8645], is also used in these transforms to limit the load on session keys.¶
Because the GOST specification includes the definition of both 128-bit ("Kuznyechik") and 64-bit ("Magma") block ciphers, both are included in this document. Implementers should make themselves aware of the relative security and other cost-benefit implications of the two ciphers. See Section 5 for more details.¶
This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Russian cryptographic standard algorithms, often referred to as "GOST" algorithms, constitute a set of cryptographic algorithms of different types -- ciphers, hash functions, digital signatures, etc. In particular, Russian cryptographic standard [GOST3412-2015] defines two block ciphers -- "Kuznyechik" (also defined in [RFC7801]) and "Magma" (also defined in [RFC8891]). Both ciphers use a 256-bit key. "Kuznyechik" has a block size of 128 bits, while "Magma" has a 64-bit block.¶
Multilinear Galois Mode (MGM) is an AEAD mode defined in [GOST-MGM] and [RFC9058]. It is claimed to provide defense against some attacks on well-known AEAD modes, like Galois/Counter Mode (GCM).¶
[RFC8645] defines mechanisms that can be used to limit the number of times any particular session key is used. One of these mechanisms, called external rekeying with tree-based construction (defined in Section 5.2.3 of [RFC8645]), is used in the defined transforms. For the purpose of deriving subordinate keys, the Key Derivation Function (KDF) KDF_GOSTR3411_2012_256, defined in Section 4.5 of [RFC7836], is used. This KDF is based on a Hashed Message Authentication Code (HMAC) construction [RFC2104] with a Russian GOST hash function defined in Russian cryptographic standard [GOST3411-2012] (also defined in [RFC6986]).¶
This document defines four transforms of Type 1 (Encryption Algorithm) for use in ESP and IKEv2. All of them use MGM as the mode of operation with tree-based external rekeying. The transforms differ in underlying ciphers and in cryptographic services they provide.¶
Note that transforms ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MGM_MAC_KTREE don't provide any confidentiality, but they are defined as Type 1 (Encryption Algorithm) transforms because of the need to include an Initialization Vector (IV), which is impossible for Type 3 (Integrity Algorithm) transforms.¶
All four transforms use the same tree-based external rekeying mechanism. The idea is that the key that is provided for the transform is not directly used to protect messages. Instead, a tree of keys is derived using this key as a root. This tree may have several levels. The leaf keys are used for message protection, while intermediate-node keys are used to derive lower-level keys, including leaf keys. See Section 5.2.3 of [RFC8645] for more details. This construction allows us to protect a large amount of data, at the same time providing a bound on a number of times any particular key in the tree is used, thus defending against some side-channel attacks and also increasing the key lifetime limitations based on combinatorial properties.¶
The transforms defined in this document use a three-level tree. The leaf key that protects a message is computed as follows:¶
K_msg = KDF (KDF (KDF (K, l1, 0x00 | i1), l2, i2), l3, i3)¶
where:¶
labels defined as 6-octet ASCII strings without null termination:¶
This construction allows us to generate up to 28 keys on level 1 and up to 216 keys on levels 2 and 3. So, the total number of possible leaf keys generated from a single Security Association (SA) key is 240.¶
This specification doesn't impose any requirements on how frequently external rekeying takes place. It is expected that the sending application will follow its own policy dictating how many times the keys on each level must be used.¶
Each message protected by the defined transforms MUST contain an IV. The IV has a size of 64 bits and consists of four fields. The fields i1, i2, and i3 are parameters that determine the particular leaf key this message was protected with (see Section 4.1). The fourth field is a counter, representing the message number for this key.¶
where:¶
For any given SA, the IV MUST NOT be used more than once, but there is no requirement that IV be unpredictable.¶
MGM requires a per-message nonce (called the Initial Counter Nonce, or ICN in [RFC9058]) that MUST be unique in the context of any leaf key. The size of the ICN is n-1 bits, where n is the block size of the underlying cipher. The two ciphers used in the transforms defined in this document have different block sizes, so two different formats for the ICN are defined.¶
MGM specification requires that the nonce be n-1 bits in size, where n is the block size of the underlying cipher. This document defines MGM nonces having n bits (the block size of the underlying cipher) in size. Since n is always a multiple of 8 bits, this makes MGM nonces having a whole number of octets. When used inside MGM, the most significant bit of the first octet of the nonce (represented as an octet string) is dropped, making the effective size of the nonce equal to n-1 bits. Note that the dropped bit is a part of the "zero" field (see Figures 2 and 3), which is always set to 0, so no information is lost when it is dropped.¶
For transforms based on the "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the ICN consists of a "zero" octet; a 24-bit message counter; and a 96-bit secret salt, which is fixed for the SA and is not transmitted.¶
where:¶
For transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE), the ICN consists of a "zero" octet; a 24-bit message counter; and a 32-bit secret salt, which is fixed for the SA and is not transmitted.¶
where:¶
We'll call a string of bits that is used to initialize the transforms defined in this specification a "transform key". The transform key is a composite entity consisting of the root key for the tree and the secret salt.¶
The transform key for the ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits (44 octets), of which the first 256 bits is a root key for the tree (denoted as K in Section 4.1) and the remaining 96 bits is a secret salt (see Section 4.3.1).¶
The transform key for the ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE transforms consists of 288 bits (36 octets), of which the first 256 bits is a root key for the tree (denoted as K in Section 4.1) and the remaining 32 bits is a secret salt (see Section 4.3.2).¶
In the case of ESP, the transform keys are extracted from the KEYMAT as defined in Section 2.17 of [RFC7296]. In the case of IKEv2, the transform keys are either SK_ei or SK_er, which are generated as defined in Section 2.14 of [RFC7296]. Note that since these transforms provide authenticated encryption, no additional keys are needed for authentication. This means that, in the case of IKEv2, the keys SK_ai/SK_ar are not used and MUST be treated as having zero length.¶
The length of the authentication tag that MGM can compute is in the range from 32 bits to the block size of the underlying cipher. Section 4 of [RFC9058] states that the authentication tag length MUST be fixed for a particular protocol. For transforms based on the "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the resulting Integrity Check Value (ICV) length is set to 96 bits. For transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE), the full ICV length is set to the block size (64 bits).¶
The transforms defined in this document don't require any plaintext padding, as specified in [RFC9058]. This means that only those padding requirements that are imposed by the protocol are applied (4 bytes for ESP, no padding for IKEv2).¶
Additional Authenticated Data (AAD) in ESP is constructed differently, depending on the transform being used and whether the Extended Sequence Number (ESN) is in use or not. The ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE transforms provide confidentiality, so the content of the ESP body is encrypted and the AAD consists of the ESP Security Parameter Index (SPI) and (E)SN. The AAD is constructed similarly to the AAD in [RFC4106].¶
On the other hand, the ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MGM_MAC_KTREE transforms don't provide confidentiality; they provide only message authentication. For this purpose, the IV and the part of the ESP packet that is normally encrypted are included in the AAD. For these transforms, the encryption capability provided by MGM is not used. The AAD is constructed similarly to the AAD in [RFC4543].¶
For IKEv2, the AAD consists of the IKEv2 Header, any unencrypted payloads following it (if present), and either the Encrypted payload header (Section 3.14 of [RFC7296]) or the Encrypted Fragment payload (Section 2.5 of [RFC7383]), depending on whether IKE fragmentation is used. The AAD is constructed similarly to the AAD in [RFC5282].¶
When the SA is established, the i1, i2, and i3 parameters are set to 0 by the sender and a leaf key is calculated. The pnum parameter starts from 0 and is incremented with each message protected by the same leaf key. When the sender decides that the leaf should be changed, it increments the i3 parameter and generates a new leaf key. The pnum parameter for the new leaf key is reset to 0, and the process continues. If the sender decides that a third-level key corresponding to i3 is used enough times, it increments i2, resets i3 to 0, and calculates a new leaf key. The pnum is reset to 0 (as with every new leaf key), and the process continues. A similar procedure is used when a second-level key needs to be changed.¶
A combination of i1, i2, i3, and pnum MUST NOT repeat for any particular SA. This means that the wrapping of these counters is not allowed: when i2, i3, or pnum reaches its respective maximum value, a procedure for changing a leaf key, described above, is executed, and if all four parameters reach their maximum values, the IPsec SA becomes unusable.¶
There may be other reasons to recalculate leaf keys besides reaching maximum values for the counters. For example, as described in Section 5, it is RECOMMENDED that the sender count the number of octets protected by a particular leaf key and generate a new key when some threshold is reached, and at the latest when reaching the octet limits stated in Section 5 for each of the ciphers.¶
The receiver always uses i1, i2, and i3 from the received message. If they differ from the values in previously received packets, a new leaf key is calculated. The pnum parameter is always used from the received packet. To improve performance, implementations may cache recently used leaf keys. When a new leaf key is calculated (based on the values from the received message), the old key may be kept for some time to improve performance in the case of possible packet reordering (when packets protected by the old leaf key are delayed and arrive later).¶
The most important security consideration for MGM is that the nonce MUST NOT repeat for a given key. For this reason, the transforms defined in this document MUST NOT be used with manual keying.¶
Excessive use of the same key can give an attacker advantages in breaking security properties of the transforms defined in this document. For this reason, the amount of data that any particular key is used to protect should be limited. This is especially important for algorithms with a 64-bit block size (like "Magma"), which currently are generally considered insecure after protecting a relatively small amount of data. For example, Section 3.4 of [SP800-67] limits the number of blocks that are allowed to be encrypted with the Triple DES cipher to 220 (8 MB of data). This document defines a rekeying mechanism that allows the mitigation of weak security of a 64-bit block cipher by frequently changing the encryption key.¶
For transforms defined in this document, [GOST-ESP] recommends limiting the number of octets protected with a single K_msg key by the following values:¶
These values are based on combinatorial properties and may be further restricted if side-channel attacks are taken into consideration. Note that the limit for transforms based on the "Kuznyechik" cipher is unreachable because, due to the construction of the transforms, the number of protected messages is limited to 224 and each message (either IKEv2 messages or ESP datagrams) is limited to 216 octets in size, giving 240 octets as the maximum amount of data that can be protected with a single K_msg.¶
Section 4 of [RFC9058] discusses the possibility of truncating authentication tags in MGM as a trade-off between message expansion and the probability of forgery. This specification truncates an authentication tag length for transforms based on the "Kuznyechik" cipher to 96 bits. This decreases message expansion while still providing a very low probability of forgery: 2-96.¶
An attacker can send a lot of packets with arbitrarily chosen i1, i2, and i3 parameters. This will 1) force a recipient to recalculate the leaf key for every received packet if i1, i2, and i3 are different from these values in previously received packets, thus consuming CPU resources and 2) force a recipient to make verification attempts (that would fail) on a large amount of data, thus allowing the attacker a deeper analysis of the underlying cryptographic primitive (see [AEAD-USAGE-LIMITS]). Implementations MAY initiate rekeying if they deem that they receive too many packets with an invalid ICV.¶
Security properties of MGM are discussed in [MGM-SECURITY].¶
IANA maintains a registry called "Internet Key Exchange Version 2 (IKEv2) Parameters" with a subregistry called "Transform Type Values". IANA has added the following four Transform IDs to the "Transform Type 1 - Encryption Algorithm Transform IDs" subregistry.¶
Number | Name | ESP Reference | IKEv2 Reference |
---|---|---|---|
32 | ENCR_KUZNYECHIK_MGM_KTREE | RFC 9227 | RFC 9227 |
33 | ENCR_MAGMA_MGM_KTREE | RFC 9227 | RFC 9227 |
34 | ENCR_KUZNYECHIK_MGM_MAC_KTREE | RFC 9227 | Not allowed |
35 | ENCR_MAGMA_MGM_MAC_KTREE | RFC 9227 | Not allowed |
In the following test vectors, binary data is represented in hexadecimal format. The numbers in square brackets indicate the size of the corresponding data in decimal format.¶
ENCR_KUZNYECHIK_MGM_KTREE (Example 1):¶
transform key [44]: b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 K [32]: b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 salt [12]: 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 K_msg [32]: 2f f1 c9 0e de 78 6e 06 1e 17 b3 74 d7 82 af 7b d8 80 bd 52 7c 66 a2 ba dc 3e 56 9a ab 27 1d a4 nonce [16]: 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 IV [8]: 00 00 00 00 00 00 00 00 AAD [8]: 51 46 53 6b 00 00 00 01 plaintext [64]: 45 00 00 3c 23 35 00 00 7f 01 ee cc 0a 6f 0a c5 0a 6f 0a 1d 08 00 f3 5b 02 00 58 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 ciphertext [64]: 18 9d 12 88 b7 18 f9 ea be 55 4b 23 9b ee 65 96 c6 d4 ea fd 31 64 96 ef 90 1c ac 31 60 05 aa 07 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e 7b 9d eb 31 85 ff e9 17 9c a9 bf 0b db af c2 3e ae 4d a5 6f ESP ICV [12]: 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed ESP packet [112]: 45 00 00 70 00 4d 00 00 ff 32 91 4f 0a 6f 0a c5 0a 6f 0a 1d 51 46 53 6b 00 00 00 01 00 00 00 00 00 00 00 00 18 9d 12 88 b7 18 f9 ea be 55 4b 23 9b ee 65 96 c6 d4 ea fd 31 64 96 ef 90 1c ac 31 60 05 aa 07 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e 7b 9d eb 31 85 ff e9 17 9c a9 bf 0b db af c2 3e ae 4d a5 6f 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed¶
ENCR_KUZNYECHIK_MGM_KTREE (Example 2):¶
transform key [44]: b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 K [32]: b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 salt [12]: 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 K_msg [32]: 9a ba c6 57 78 18 0e 6f 2a f6 1f b8 d5 71 62 36 66 c2 f5 13 0d 54 e2 11 6c 7d 53 0e 6e 7d 48 bc nonce [16]: 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 IV [8]: 00 00 01 00 01 00 00 00 AAD [8]: 51 46 53 6b 00 00 00 10 plaintext [64]: 45 00 00 3c 23 48 00 00 7f 01 ee b9 0a 6f 0a c5 0a 6f 0a 1d 08 00 e4 5b 02 00 67 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 ciphertext [64]: 78 0a 2c 62 62 32 15 7b fe 01 76 32 f3 2d b4 d0 a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b ac 1d fc 4b 15 4b 69 03 4d c2 1d ef 20 90 6d 59 62 81 12 7c ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 a4 d4 9a 4d ESP ICV [12]: c2 2f 87 40 83 8e 3d fa ce 91 cc b8 ESP packet [112]: 45 00 00 70 00 5c 00 00 ff 32 91 40 0a 6f 0a c5 0a 6f 0a 1d 51 46 53 6b 00 00 00 10 00 00 01 00 01 00 00 00 78 0a 2c 62 62 32 15 7b fe 01 76 32 f3 2d b4 d0 a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b ac 1d fc 4b 15 4b 69 03 4d c2 1d ef 20 90 6d 59 62 81 12 7c ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 a4 d4 9a 4d c2 2f 87 40 83 8e 3d fa ce 91 cc b8¶
ENCR_MAGMA_MGM_KTREE (Example 1):¶
transform key [36]: 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 cf 36 63 12 K [32]: 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 salt [4]: cf 36 63 12 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 K_msg [32]: 25 65 21 e2 70 b7 4a 16 4d fc 26 e6 bf 0c ca 76 5e 9d 41 02 7d 4b 7b 19 76 2b 1c c9 01 dc de 7f nonce [8]: 00 00 00 00 cf 36 63 12 IV [8]: 00 00 00 00 00 00 00 00 AAD [8]: c8 c2 b2 8d 00 00 00 01 plaintext [64]: 45 00 00 3c 24 2d 00 00 7f 01 ed d4 0a 6f 0a c5 0a 6f 0a 1d 08 00 de 5b 02 00 6d 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 ciphertext [64]: fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c 4a 91 7e 0c d8 6f 8e 61 04 03 87 64 6b b9 df bd 91 50 3f 4a f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc 99 ac ee 9e 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 15 52 cc e8 ESP ICV [8]: 5f 4a fa 8b 02 94 0f 5c ESP packet [108]: 45 00 00 6c 00 62 00 00 ff 32 91 3e 0a 6f 0a c5 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 01 00 00 00 00 00 00 00 00 fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c 4a 91 7e 0c d8 6f 8e 61 04 03 87 64 6b b9 df bd 91 50 3f 4a f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc 99 ac ee 9e 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 15 52 cc e8 5f 4a fa 8b 02 94 0f 5c¶
ENCR_MAGMA_MGM_KTREE (Example 2):¶
transform key [36]: 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 cf 36 63 12 K [32]: 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 salt [4]: cf 36 63 12 i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 K_msg [32]: 20 e0 46 d4 09 83 9b 23 f0 66 a5 0a 7a 06 5b 4a 39 24 4f 0e 29 ef 1e 6f 2e 5d 2e 13 55 f5 da 08 nonce [8]: 00 00 00 00 cf 36 63 12 IV [8]: 00 00 01 00 01 00 00 00 AAD [8]: c8 c2 b2 8d 00 00 00 10 plaintext [64]: 45 00 00 3c 24 40 00 00 7f 01 ed c1 0a 6f 0a c5 0a 6f 0a 1d 08 00 cf 5b 02 00 7c 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 ciphertext [64]: 7a 71 48 41 a5 34 b7 58 93 6a 8e ab 26 91 40 a8 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c 9b 88 db 72 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b d7 7a 07 1d 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 bf fe a1 dd ESP ICV [8]: dd 5d 50 9a fd b8 09 98 ESP packet [108]: 45 00 00 6c 00 71 00 00 ff 32 91 2f 0a 6f 0a c5 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 10 00 00 01 00 01 00 00 00 7a 71 48 41 a5 34 b7 58 93 6a 8e ab 26 91 40 a8 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c 9b 88 db 72 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b d7 7a 07 1d 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 bf fe a1 dd dd 5d 50 9a fd b8 09 98¶
ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 1):¶
transform key [44]: 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be 6c 51 cb ac 93 c4 5b ea 99 62 79 1d K [32]: 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be salt [12]: 6c 51 cb ac 93 c4 5b ea 99 62 79 1d i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 K_msg [32]: 98 f1 03 01 81 0a 04 1c da dd e1 bd 85 a0 8f 21 8b ac b5 7e 00 35 e2 22 c8 31 e3 e4 f0 a2 0c 8f nonce [16]: 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d IV [8]: 00 00 00 00 00 00 00 00 AAD [80]: 3d ac 92 6a 00 00 00 01 00 00 00 00 00 00 00 00 45 00 00 3c 0c f1 00 00 7f 01 05 11 0a 6f 0a c5 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 plaintext [0]: ciphertext [0]: ESP ICV [12]: ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d ESP packet [112]: 45 00 00 70 00 01 00 00 ff 32 91 9b 0a 6f 0a c5 0a 6f 0a 1d 3d ac 92 6a 00 00 00 01 00 00 00 00 00 00 00 00 45 00 00 3c 0c f1 00 00 7f 01 05 11 0a 6f 0a c5 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d¶
ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 2):¶
transform key [44]: 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be 6c 51 cb ac 93 c4 5b ea 99 62 79 1d K [32]: 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be salt [12]: 6c 51 cb ac 93 c4 5b ea 99 62 79 1d i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 K_msg [32]: 02 c5 41 87 7c c6 23 f3 f1 35 91 9a 75 13 b6 f8 a8 a1 8c b2 63 99 86 2f 50 81 4f 52 91 01 67 84 nonce [16]: 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d IV [8]: 00 00 00 00 01 00 00 00 AAD [80]: 3d ac 92 6a 00 00 00 06 00 00 00 00 01 00 00 00 45 00 00 3c 0c fb 00 00 7f 01 05 07 0a 6f 0a c5 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 plaintext [0]: ciphertext [0]: ESP ICV [12]: ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91 ESP packet [112]: 45 00 00 70 00 06 00 00 ff 32 91 96 0a 6f 0a c5 0a 6f 0a 1d 3d ac 92 6a 00 00 00 06 00 00 00 00 01 00 00 00 45 00 00 3c 0c fb 00 00 7f 01 05 07 0a 6f 0a c5 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91¶
ENCR_MAGMA_MGM_MAC_KTREE (Example 1):¶
transform key [36]: d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 88 79 8f 29 K [32]: d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 salt [4]: 88 79 8f 29 i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 K_msg [32]: 4c 61 45 99 a0 a0 67 f1 94 87 24 0a e1 00 e1 b7 ea f2 3e da f8 7e 38 73 50 86 1c 68 3b a4 04 46 nonce [8]: 00 00 00 00 88 79 8f 29 IV [8]: 00 00 00 00 00 00 00 00 AAD [80]: 3e 40 69 9c 00 00 00 01 00 00 00 00 00 00 00 00 45 00 00 3c 0e 08 00 00 7f 01 03 fa 0a 6f 0a c5 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 plaintext [0]: ciphertext [0]: ESP ICV [8]: 4d d4 25 8a 25 35 95 df ESP packet [108]: 45 00 00 6c 00 13 00 00 ff 32 91 8d 0a 6f 0a c5 0a 6f 0a 1d 3e 40 69 9c 00 00 00 01 00 00 00 00 00 00 00 00 45 00 00 3c 0e 08 00 00 7f 01 03 fa 0a 6f 0a c5 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 4d d4 25 8a 25 35 95 df¶
ENCR_MAGMA_MGM_MAC_KTREE (Example 2):¶
transform key [36]: d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 88 79 8f 29 K [32]: d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 salt [4]: 88 79 8f 29 i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 K_msg [32]: b4 f3 f9 0d c4 87 fa b8 c4 af d0 eb 45 49 f2 f0 e4 36 32 b6 79 19 37 2e 1e 96 09 ea f0 b8 e2 28 nonce [8]: 00 00 00 00 88 79 8f 29 IV [8]: 00 00 00 00 01 00 00 00 AAD [80]: 3e 40 69 9c 00 00 00 06 00 00 00 00 01 00 00 00 45 00 00 3c 0e 13 00 00 7f 01 03 ef 0a 6f 0a c5 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 plaintext [0]: ciphertext [0]: ESP ICV [8]: 84 84 a9 23 30 a0 b1 96 ESP packet [108]: 45 00 00 6c 00 18 00 00 ff 32 91 88 0a 6f 0a c5 0a 6f 0a 1d 3e 40 69 9c 00 00 00 06 00 00 00 00 01 00 00 00 45 00 00 3c 0e 13 00 00 7f 01 03 ef 0a 6f 0a c5 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 84 84 a9 23 30 a0 b1 96¶
The author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer, and Stanislav Smyshlyaev for valuable input during the publication process for this document.¶