RFC 9227
Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols
RFC 9227: Using GOST Ciphers in ESP and IKEv2 💖
(part 1 of 5)
Title block, bestie: this is an Independent Submission 🎀 by V. Smyslov from ELVIS-PLUS. It's Informational (so it's not a Standards Track thing), it was published in March 2022, and its ISSN is 2070-1721. The title block has no "Obsoletes" or "Updates" line, so it doesn't claim to replace or change any other RFC. 🦋
Abstract ✨
okay so this doc defines a bunch of encryption transforms for ESP and IKEv2, which are both parts of the IPsec suite 🔐. The transforms are built on the GOST R 34.12-2015 block ciphers, which are called "Magma" and "Kuznyechik", and they run in Multilinear Galois Mode (MGM) with an external rekeying approach 🌸.
It was written so that implementers who want to support GOST algorithms have something to work from 💅. It is NOT the IETF saying "yes, we endorse these crypto algorithms." Just so we're clear 🙈
Status of This Memo 📜
This doc is not an Internet Standards Track spec. It's published just for information 🧚
It's a contribution to the RFC Series, and it's independent of any other RFC stream. The RFC Editor picked to publish it at their own discretion and doesn't say anything about whether it's good to implement or deploy 🫶. Docs the RFC Editor approves aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that. 📚
For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9227 ✨
Copyright Notice ©️
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) as they were in effect on the date of publication. Please actually read these, because they describe your rights and restrictions for this document 📖
Table of Contents 🗺️
1. Introduction
2. Requirements Language
3. Overview
4. Description of Transforms
4.1. Tree-Based External Rekeying
4.2. Initialization Vector Format
4.3. Nonce Format for MGM
4.3.1. MGM Nonce Format for Transforms Based on the
"Kuznyechik" Cipher
4.3.2. MGM Nonce Format for Transforms Based on the "Magma"
Cipher
4.4. Keying Material
4.5. Integrity Check Value
4.6. Plaintext Padding
4.7. AAD Construction
4.7.1. ESP AAD
4.7.2. IKEv2 AAD
4.8. Using Transforms
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Test Vectors
Acknowledgments
Author's Address1. Introduction 🌈
okay so IPsec is a whole suite of protocols, and the two main stars are ESP [RFC4303] and IKEv2 [RFC7296] 👑. This doc adds four transforms for ESP and IKEv2 that are based on Russian cryptographic standard algorithms (usually called "GOST" algorithms) 🇷🇺.
These definitions come from the recommendations [GOST-ESP] from Rosstandart (the Federal Agency on Technical Regulating and Metrology), which explain how those Russian algorithms get used in ESP and IKEv2 💖
The transforms use two block ciphers from the Russian standard, and they are: "Kuznyechik" [GOST3412-2015] [RFC7801] and "Magma" [GOST3412-2015] [RFC8891], both in Multilinear Galois Mode (MGM) [GOST-MGM] [RFC9058] ✨. They give you Authenticated Encryption with Associated Data (AEAD) 🔒. There's also an external rekeying mechanism from [RFC8645] that limits how much load goes on any session key 🦋
Since the GOST spec defines both a 128-bit cipher ("Kuznyechik") and a 64-bit cipher ("Magma"), this doc includes both 💅. Implementers should get familiar with how the two ciphers compare on security and other cost-benefit stuff. More on that in Section 5 🙈
Same disclaimer as the abstract: this was written to help implementations that want GOST support, and it does NOT mean IETF endorsement of these crypto algorithms 🫶
2. Requirements Language 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are the BCP 14 key words 🔑. They're only to be read as described in BCP 14 [RFC2119] [RFC8174] when they show up in ALL CAPS, exactly like that. If they're lowercase, they're just normal English 💜
3. Overview 🧚
Russian cryptographic standard algorithms (aka "GOST" algorithms) are a whole family of crypto stuff: ciphers, hash functions, digital signatures, and more 🌸. The Russian standard [GOST3412-2015] defines two block ciphers, which are "Kuznyechik" (also in [RFC7801]) and "Magma" (also in [RFC8891]). Both use a 256-bit key 🗝️. Kuznyechik has a 128-bit block size and Magma has a 64-bit block ✨
Multilinear Galois Mode (MGM) is an AEAD mode from [GOST-MGM] and [RFC9058]. People say it defends against some attacks that hit well-known AEAD modes like Galois/Counter Mode (GCM) 💅. Claimed, not proven in this doc, so vibe check it yourself 🙈
[RFC8645] has mechanisms for limiting how many times any one session key gets used 🔁. One of them is external rekeying with a tree-based construction (from Section 5.2.3 of [RFC8645]), and the defined transforms use it 🌳. To derive the subordinate keys, they use the Key Derivation Function (KDF) KDF_GOSTR3411_2012_256 from Section 4.5 of [RFC7836] 🔑. That KDF is built on a Hashed Message Authentication Code (HMAC) construction [RFC2104] using the Russian GOST hash function from [GOST3411-2012] (also [RFC6986]) 🫶
4. Description of Transforms 💎
There are four transforms of Type 1 (Encryption Algorithm) for ESP and IKEv2 🎀. All of them use MGM as the mode of operation, with tree-based external rekeying 💖. They differ in which underlying cipher they use and in what cryptographic services they give you ✨
ENCR_KUZNYECHIK_MGM_KTREE(Transform ID 32) is an AEAD transform based on "Kuznyechik". It gives you confidentiality and message authentication, so it can be used in both ESP and IKEv2 🦋ENCR_MAGMA_MGM_KTREE(Transform ID 33) is an AEAD transform based on "Magma". It also gives confidentiality and message authentication, so it works in both ESP and IKEv2 🌸ENCR_KUZNYECHIK_MGM_MAC_KTREE(Transform ID 34) is a MAC-only transform based on "Kuznyechik". It gives NO confidentiality, so it can only be used in ESP, not in IKEv2 🙈ENCR_MAGMA_MGM_MAC_KTREE(Transform ID 35) is a MAC-only transform based on "Magma". It gives NO confidentiality either, so it's ESP-only too 💀
Quick note: the two MAC-only transforms (ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MGM_MAC_KTREE) don't give you any confidentiality. They're still defined as Type 1 (Encryption Algorithm) transforms, though, because they need an Initialization Vector (IV). Type 3 (Integrity Algorithm) transforms can't carry an IV, so that's why 🧠
4.1. Tree-Based External Rekeying 🌳
All four transforms use the same tree-based external rekeying mechanism 💅. The big idea: the key you hand to the transform isn't used directly to protect messages. Instead, you derive a whole tree of keys with that key as the root 🌲. The tree can have several levels. Leaf keys protect messages, and intermediate-node keys are used to derive the lower-level keys, leaf keys included. See Section 5.2.3 of [RFC8645] for more details ✨
This setup lets you protect a huge amount of data while also bounding how many times any particular key in the tree gets used. That helps defend against some side-channel attacks, and it stretches the key lifetime limits based on combinatorial properties 🧚
The transforms here use a three-level tree. The leaf key that protects a message is computed like this 👇
K_msg = KDF (KDF (KDF (K, l1, 0x00 | i1), l2, i2), l3, i3)Here's what each piece means 💖
- KDF (k, l, s): the Key Derivation Function KDF_GOSTR3411_2012_256 (from Section 4.5 of [RFC7836]). It takes three inputs, which are a key (k), a label (l), and a seed (s), and it spits out a new key 🔑
- K: the root key for the tree (see Section 4.4) 🌳
- l1, l2, l3: labels that are 6-octet ASCII strings with no null termination 🎀
l1 = "level1"
l2 = "level2"
l3 = "level3"- i1, i2, i3: parameters that pick which keys out of the tree get used at each level. Together they determine the leaf key that protects the message. i1 is one octet long, and i2 and i3 are two-octet integers in network byte order ✨
- |: means concatenation 🧩
Okay, the math here: this construction lets you generate up to 2^8 keys on level 1 and up to 2^16 keys on levels 2 and 3. So the total number of leaf keys you can make from one Security Association (SA) key is 2^40. Absolutely unhinged amount 😭🌈
This spec doesn't put any requirements on how often external rekeying has to happen. It's expected that the sending application will follow its own policy about how many times each level's keys get used 🫶
4.2. Initialization Vector Format 🦋
Every message protected by these transforms MUST contain an IV 💖. The IV is 64 bits and has four fields. The fields i1, i2, and i3 are the parameters that pick out the exact leaf key the message was protected with (see Section 4.1). The fourth field is a counter that tracks the message number for that key 🔢
Here's the layout, bestie 👇
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i1 | i2 | i3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i3 (cont) | pnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IV FormatField breakdown 🧁
- i1 (1 octet), i2 (2 octets), i3 (2 octets): the parameters that pick the particular key used to protect this message. The 2-octet ones are integers in network byte order 🧚
- pnum (3 octets): the message counter in network byte order for the leaf key protecting this message. You can protect up to 2^24 messages with a single leaf key. That's a lot of messages, periodt 🌸
Heads up, bestie: for any given SA, the IV MUST NOT be used more than once. The IV doesn't have to be unpredictable though, so there's no requirement there 🙈
4.3. Nonce Format for MGM ✨
okay so MGM needs a per-message nonce (the Initial Counter Nonce, or ICN, per [RFC9058]) and it MUST be unique in the context of any leaf key 🔑 the ICN is n-1 bits long, where n is the block size of the underlying cipher. the two ciphers used in these transforms have different block sizes, so there are two different ICN formats, bestie 🎀
the MGM spec says the nonce has to be n-1 bits. this document defines MGM nonces that are n bits instead (the full block size of the cipher) 💅 n is always a multiple of 8, so these nonces are always a whole number of octets. when the nonce gets used inside MGM, the most significant bit of the first octet (read as an octet string) gets dropped, so the effective size lands at n-1 bits. the dropped bit belongs to the "zero" field (see Figures 2 and 3), which is always set to 0, so nothing is lost when it's dropped. no info gone, periodt 🦋
4.3.1. MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher
for the "Kuznyechik" cipher transforms (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the ICN is made of three parts: a "zero" octet, a 24-bit message counter, and a 96-bit secret salt. the salt is fixed for the SA and is never sent over the wire 🌸
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | pnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| salt |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Nonce Format for Transforms Based on the "Kuznyechik"
Cipherhere's what each piece is:
zero(1 octet): set to 0pnum(3 octets): the counter for the messages protected by the given leaf key. this field MUST be equal to the pnum field in the IV 🫶salt(12 octets): the secret salt. it's a string of bits formed when the SA is created (see Section 4.4 for the deets). the salt never changes during the SA's lifetime, it's not sent on the wire, and every SA gets its own salt 🔐
4.3.2. MGM Nonce Format for Transforms Based on the "Magma" Cipher
same energy for the "Magma" cipher transforms (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE): a "zero" octet, a 24-bit message counter, and a 32-bit secret salt that's fixed for the SA and not transmitted 🧚
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | pnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Nonce Format for Transforms Based on the "Magma" Cipherzero(1 octet): set to 0pnum(3 octets): the counter for the messages protected by the given leaf key. this field MUST be equal to the pnum field in the IV 🍓salt(4 octets): the secret salt. it's formed when the SA is created (see Section 4.4 for details), it doesn't change during the SA's lifetime, it's not transmitted on the wire, and every SA has its own 💜
4.4. Keying Material 🗝️
we'll call a string of bits used to initialize the transforms in this spec a "transform key". it's a composite thing made of the root key for the tree plus the secret salt 👑
the transform key for ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE is 352 bits (44 octets). the first 256 bits are the root key for the tree (called K in Section 4.1), and the remaining 96 bits are the secret salt (see Section 4.3.1) 🌈
the transform key for ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE is 288 bits (36 octets). the first 256 bits are the root key for the tree (K in Section 4.1), and the remaining 32 bits are the secret salt (see Section 4.3.2) ⭐
in ESP, the transform keys get pulled out of the KEYMAT, as defined in Section 2.17 of [RFC7296]. in IKEv2, the transform keys are either SK_ei or SK_er, generated as defined in Section 2.14 of [RFC7296]. these transforms give you authenticated encryption, so no extra keys are needed for authentication. that means in IKEv2 the keys SK_ai/SK_ar aren't used and MUST be treated as having zero length 🙈
4.5. Integrity Check Value 🛡️
the authentication tag length MGM can compute is anywhere from 32 bits up to the block size of the underlying cipher. Section 4 of [RFC9058] says the authentication tag length MUST be fixed for a particular protocol, so no mixing and matching 🙅♀️
for the "Kuznyechik" transforms (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the resulting Integrity Check Value (ICV) length is set to 96 bits. for the "Magma" transforms (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE), the full ICV length is set to the block size, which is 64 bits 💖
4.6. Plaintext Padding 🎀
the transforms in this document don't need any plaintext padding, as specified in [RFC9058]. so only the padding requirements the protocol itself imposes get applied: 4 bytes for ESP, and no padding for IKEv2 ✨
4.7. AAD Construction 🧩
4.7.1. ESP AAD
Additional Authenticated Data (AAD) in ESP is built differently depending on which transform you're using and whether the Extended Sequence Number (ESN) is in play 🌸 the ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE transforms provide confidentiality, so the ESP body content gets encrypted and the AAD is the ESP Security Parameter Index (SPI) plus the (E)SN. the AAD is built similarly to the AAD in [RFC4106] 🔥
the ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MGM_MAC_KTREE transforms are different: they don't provide confidentiality, only message authentication 🙌 so the IV and the part of the ESP packet that would normally be encrypted go into the AAD. for these transforms, MGM's encryption capability isn't used. the AAD is built similarly to the AAD in [RFC4543] 🦋
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: AAD for AEAD Transforms with 32-Bit SN 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AAD for AEAD Transforms with 64-Bit ESN 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Payload Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: AAD for Authentication-Only Transforms with 32-Bit SN 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Payload Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: AAD for Authentication-Only Transforms with 64-Bit ESN4.7.2. IKEv2 AAD ✨
okay so for IKEv2, the AAD is made of the IKEv2 Header, any unencrypted payloads that come after it (if there are any 🎀), and then 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 being used 💅. It's built pretty much the same way as the AAD in [RFC5282], so bestie already knows the vibe 🦋.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKEv2 Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Unencrypted IKE Payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: AAD for IKEv2 in the Case of the Encrypted Payload 🌸
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKEv2 Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Unencrypted IKE Payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Number | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: AAD for IKEv2 in the Case of the Encrypted Fragment Payload 🧚
4.8. Using Transforms 🦋
okay bestie, this is where the key juggling happens 🔑✨. When the SA is set up, the i1, i2, and i3 parameters are all set to 0 by the sender, and a leaf key gets calculated 🌱. The pnum parameter starts at 0 and goes up by one for every message protected by the same leaf key 🔢. When the sender decides the leaf should change, it bumps i3 and makes a brand new leaf key 💖. pnum gets reset to 0 for that new leaf key, and the whole process just keeps going 🏃♀️. If the sender decides the third-level key for i3 has been used enough times, it increments i2, resets i3 to 0, and calculates a new leaf key 🎀. pnum is reset to 0 again (same as with every new leaf key), and the process keeps going 💅. 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 🙅♀️. That means wrapping these counters around is not allowed 🚫: when i2, i3, or pnum hits its maximum value, the leaf key changing procedure from above gets run, and if all four parameters reach their maximum values, the IPsec SA becomes unusable 💀.
There may be other reasons to recalculate leaf keys besides the counters hitting their maximums 👀. For example, as described in Section 5, it is RECOMMENDED that the sender counts the number of octets protected by a particular leaf key and generates a new key once 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're different from the values in previously received packets, a new leaf key gets calculated 🍓. The pnum parameter is always taken from the received packet ✨. To improve performance, implementations MAY cache recently used leaf keys 🚀 (MAY here, so it's optional, no pressure 💜). When a new leaf key is calculated (based on the values from the received message), the old key may be kept around for a while, which helps if packets get reordered 🐢➡️🐇. Like, packets protected by the old leaf key can get delayed and show up later, and keeping that old key means they still work 🙌.
5. Security Considerations 🔐
okay bestie, this section is SERIOUS 😭🚨. Read it all, no skipping!!
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 🙅♀️💀.
Using the same key way too much can give an attacker advantages in breaking the security properties of the transforms defined in this document 😱. So the amount of data any particular key protects should be limited 🧱. This is especially important for algorithms with a 64-bit block size (like "Magma") 🥺, which are currently 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 can be encrypted with the Triple DES cipher to 2^20 (8 MB of data) 📉. This document defines a rekeying mechanism that helps mitigate the weak security of a 64-bit block cipher by changing the encryption key frequently 🔄✨.
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 📏:
- 2^41 octets for transforms based on the "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) 🌟
- 2^28 octets for transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE) 🍀
These values are based on combinatorial properties and may be restricted further if side-channel attacks are taken into consideration 🕵️♀️. Note that the limit for transforms based on the "Kuznyechik" cipher is unreachable 🤯, because due to how the transforms are built, the number of protected messages is limited to 2^24 and each message (either IKEv2 messages or ESP datagrams) is limited to 2^16 octets in size, giving 2^40 octets as the maximum amount of data that can be protected with a single K_msg 🧮.
Section 4 of [RFC9058] talks about possibly truncating authentication tags in MGM as a trade-off between message expansion and the probability of forgery ⚖️. This specification truncates the authentication tag length for transforms based on the "Kuznyechik" cipher to 96 bits ✂️. That cuts down on message expansion and still gives 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 differ from the values in previously received packets, which eats up CPU resources 🔥, and (2) force a recipient to make verification attempts (that would fail) on a large amount of data, which lets the attacker do 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] 📚✨.
6. IANA Considerations 🗂️
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 | IKEv2 |
| | | Reference | 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 |
+--------+-------------------------------+-----------+-----------+Table 1: Transform IDs 🦄
7. References 📚
7.1. Normative References 💎
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>.
[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
2013, <https://www.rfc-editor.org/info/rfc6986>.
[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
<https://www.rfc-editor.org/info/rfc7801>.
[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:
Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,
September 2020, <https://www.rfc-editor.org/info/rfc8891>.
[RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E.
Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058,
DOI 10.17487/RFC9058, June 2021,
<https://www.rfc-editor.org/info/rfc9058>.
[RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
on the Cryptographic Algorithms to Accompany the Usage of
Standards GOST R 34.10-2012 and GOST R 34.11-2012",
RFC 7836, DOI 10.17487/RFC7836, March 2016,
<https://www.rfc-editor.org/info/rfc7836>.7.2. Informative References 📚✨
okay so these are the extra reads, the "go deeper if you're curious" list 🧚 Here they are, every single one:
[GOST3411-2012] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Hash function", GOST R 34.11-2012, August 2012. (In Russian)
[GOST3412-2015] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Block ciphers", GOST R 34.12-2015, June 2015. (In Russian)
[GOST-MGM] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic information security. Block Cipher Modes Implementing Authenticated Encryption", R 1323565.1.026-2019, September 2019. (In Russian)
[GOST-ESP] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic information protection. The use of Russian cryptographic algorithms in the ESP information protection protocol", R 1323565.1.035-2021, January 2021. (In Russian)
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, DOI 10.17487/RFC4543, May 2006, <https://www.rfc-editor.org/info/rfc4543>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 10.17487/RFC5282, August 2008, <https://www.rfc-editor.org/info/rfc5282>.
[RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, <https://www.rfc-editor.org/info/rfc8645>.
[MGM-SECURITY] Akhmetzyanova, L., Alekseev, E., Karpunin, G., and V. Nozdrunov, "Security of Multilinear Galois Mode (MGM)", 2019, <https://eprint.iacr.org/2019/123.pdf>.
[SP800-67] National Institute of Standards and Technology, "Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", DOI 10.6028/NIST.SP.800-67r2, November 2017, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-67r2.pdf>.
[AEAD-USAGE-LIMITS] Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-04, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-04>.
Appendix A. Test Vectors 🧪💜
bestie, this is the good stuff! 😭 The test vectors are the worked examples, so you can check your own code against them. All the binary data is written in hexadecimal, and the numbers in square brackets tell you the size of each piece in decimal. Every value below is copied exactly, so don't touch a single digit 🫶
- 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):
- 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 96Acknowledgments ✨
The author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer, and Stanislav Smyshlyaev for valuable input during the publication process for this document. Huge thanks, besties 🫶
Author's Address 🎀
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)
124460
Russian Federation
Phone: +7 495 276 0211
Email: svan@elvis.ru📦 where this page comes from
- ietf: rfc9227 2022-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms