RFC 9227 - Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9227.html
タイトル : RFC 9227 - カプセル化セキュリティペイロード（ESP）およびインターネットキー交換バージョン2（IKEv2）プロトコルのGOST暗号を使用する
翻訳編集 : 自動生成

[要約] RFC 9227 は、ESPおよびIKEv2プロトコルで使用するためのGOST暗号変換を定義し、GOSTアルゴリズムをサポートする実装を容易にすることを目的としています。IETFはこの文書で使用される暗号アルゴリズムを推奨しているわけではありません。

Independent Submission                                        V. Smyslov
Request for Comments: 9227                                    ELVIS-PLUS
Category: Informational                                       March 2022
ISSN: 2070-1721

Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols

カプセル化セキュリティペイロード（ESP）およびインターネットキー交換バージョン2（IKEv2）プロトコルのGOST暗号を使用する

Abstract

概要

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.

このドキュメントは、Concapsulating Security Payload（ESP）およびインターネットキー交換バージョン2（IPSEC）プロトコル（IPSec）プロトコルスイートであるインターネットキー交換バージョン2（IKEV2）プロトコルで使用するための一連の暗号化変換を定義しています。変換は、マルチニアガロアモード（MGM）のGOST R 34.12-2015ブロック暗号（「Magma」と「Kuznyechik」）と外部の生後のアプローチに基づいています。

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.

この仕様は、GOSTアルゴリズムをサポートしたい実装を容易にするために開発されました。この文書は、この文書で使用されている暗号化アルゴリズムのIETFの承認を意味するものではありません。

Status of This Memo

本文書の位置付け

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.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディタは、この文書をその判断で公開することを選択し、実装または展開の値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補ではありません。RFC 7841のセクション2を参照してください。

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.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc927で取得できます。

著作権表示

著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。

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.

この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。

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 Address

1. Introduction

1. はじめに

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.

IPセキュリティ（IPSec）プロトコルスイートは、カプセル化セキュリティペイロード（ESP）[RFC4303]とインターネットキー交換バージョン2（RFC7296]が最も広く使用されているいくつかのプロトコルで構成されています。この文書は、ロシアの暗号化標準アルゴリズム（しばしば「GOST」アルゴリズムと呼ばれる）に基づいて、ESPとIKEV2の4つの変換を定義しています。これらの定義は、ESPとIKEV2でどのように使用されているかを説明する技術的規制と計測（RosStandart）に関する連邦機関によって確立された勧告[GOST-ESP]に基づいています。この文書で定義されている変換は、ロシアの暗号化標準アルゴリズム - 「Kuznyechik」[GOST3412-2015] [RFC7801] [RFC7801]と「マグマ」[GOST3412-2015] [RFC8891]（MGM）の2つのブロック暗号に基づいています。 GOST-MGM] [RFC9058]。これらの変換は、認証された暗号化を関連付けられたデータ（AEAD）を提供します。 [RFC8645]で説明されている外部の生後メカニズムも、セッションキーの負荷を制限するためにこれらの変換でも使用されます。

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.

GOST仕様には、128ビット（ "Kuznyechik"）と64ビット（ "Magma"）ブロック暗号の両方の定義が含まれているため、両方ともこのドキュメントに含まれています。実装者は、2つの暗号の相対的なセキュリティやその他の費用対効果の影響を知らせるべきである。詳細についてはセクション5を参照してください。

2. Requirements Language

2. 要件言語

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.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

3. Overview

3. 概要

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.

しばしば「GOST」アルゴリズムと呼ばれるロシアの暗号化標準アルゴリズムは、異なるタイプ、ハッシュ関数、デジタル署名などの一連の暗号化アルゴリズムを構成し、特にロシアの暗号化標準[GOST3412-2015] 2つのブロック暗号を定義する - 「Kuznyechik」（[RFC7801]でも定義）と「マグマ」（[RFC8891]でも定義）。両方の暗号は256ビットキーを使用します。"Kuznyechik"は128ビットのブロックサイズを持ち、 "Magma"は64ビットブロックを持っています。

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).

多層ガロアモード（MGM）は、[GOST-MGM]と[RFC9058]で定義されているAEADモードです。Galois / Counter Mode（GCM）のように、有名なAEADモードに対するいくつかの攻撃に対して防御を提供すると主張されています。

[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]).

[RFC8645]特定のセッションキーを使用する回数を制限するために使用できるメカニズムを定義します。これらのメカニズムの1つ（[RFC8645]のセクション5.2.3で定義されている）で、定義された変換では、ツリーベースの構造と呼ばれるこのメカニズムの1つが使用されます。下位キーを導出する目的で、[RFC7836]のセクション4.5で定義されているキー派生機能（KDF）KDF_GOSTR3411_2012_256が使用されます。このKDFは、ロシアの暗号化標準[GOST3411-2012]で定義されているロシアのGOSTハッシュ関数（[RFC6986]で定義されています）を持つハッシュメッセージ認証コード（HMAC）構造[RFC2104]に基づいています。

4. Description of Transforms

4. 変換の説明

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.

この文書は、ESPとIKEv2で使用するためのタイプ1（暗号化アルゴリズム）の4つの変換を定義しています。すべてのそれらのすべてが、ツリーベースの外部リークを使用した動作モードとしてMGMを使用します。変換は、基礎となる暗号化およびそれらが提供する暗号化サービスが異なります。

* ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transform based on the "Kuznyechik" algorithm; it provides confidentiality and message authentication and thus can be used in both ESP and IKEv2.

* encr_kuznyechik_mgm_ktree（変換ID 32）は、 "kuznyechik"アルゴリズムに基づくAED変換です。機密性とメッセージ認証を提供し、したがってESPとIKEv2の両方で使用できます。

* ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform based on the "Magma" algorithm; it provides confidentiality and message authentication and thus can be used in both ESP and IKEv2.

* ENCR_MAGMA_MGM_KTREE（変換ID 33）は、「マグマ」アルゴリズムに基づくAED変換です。機密性とメッセージ認証を提供し、したがってESPとIKEv2の両方で使用できます。

* ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only transform based on the "Kuznyechik" algorithm; it provides no confidentiality and thus can only be used in ESP, but not in IKEv2.

* encr_kuznyechik_mgm_mac_ktree（変換ID 34）は、 "kuznyechik"アルゴリズムに基づくMAC専用変換です。それは機密性を与えず、したがってESPでしか使用できませんが、IKEv2では使用できません。

* ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only transform based on the "Magma" algorithm; it provides no confidentiality and thus can only be used in ESP, but not in IKEv2.

* encr_magma_mgm_mac_ktree（変換ID 35）は、 "Magma"アルゴリズムに基づくMACのみの変換です。それは機密性を与えず、したがってESPでしか使用できませんが、IKEv2では使用できません。

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.

変換ENCR_KUZNYECHIK_MGM_MAC_KTREEおよびENCR_MAGMA_MGM_MAC_KTREEは機密性を提供しませんが、タイプ3（Integrity Algorithm）変換が不可能である初期化ベクトル（IV）を含める必要があるため、タイプ1（暗号化アルゴリズム）変換として定義されています。

4.1. Tree-Based External Rekeying

4.1. ツリーベースの外部リーケイ

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.

4つの変換すべては、同じツリーベースの外部リカイズメカニズムを使用します。このアイデアは、変換に提供されているキーがメッセージを保護するために直接使用されないことです。代わりに、キーのツリーがこのキーをrootとして使用して派生します。この木にはいくつかのレベルがあります。リーフキーはメッセージ保護に使用され、中間ノードキーはリーフキーを含む下位レベルのキーを導き出すために使用されます。詳細については、[RFC8645]のセクション5.2.3を参照してください。この構成により、大量のデータを保護することができ、同時にツリー内の特定のキーが使用され、したがっていくつかのサイドチャネル攻撃に対して防御し、また主要な生涯の制限を増大させることができる。コンビナトリアル特性

The transforms defined in this document use a three-level tree. The leaf key that protects a message is computed as follows:

この文書で定義されている変換は3レベルのツリーを使用します。メッセージを保護するリーフキーは次のように計算されます。

K_msg = KDF (KDF (KDF (K, l1, 0x00 | i1), l2, i2), l3, i3)

K_MSG = KDF（KDF（KDF（K、L1、0x00 | I1）、L2、I2）、L3、I3）

where:

ただし：

KDF (k, l, s) Key Derivation Function KDF_GOSTR3411_2012_256 (defined in Section 4.5 of [RFC7836]), which accepts three input parameters -- a key (k), a label (l), and a seed (s) -- and provides a new key as output

KDF（K、L、S）キー導出機能KDF_GOSTR3411_2012_256（[RFC7836]のセクション4.5で定義）。そして、出力として新しいキーを提供します

K the root key for the tree (see Section 4.4)

kツリーのルートキー（セクション4.4を参照）

l1, l2, l3 labels defined as 6-octet ASCII strings without null termination:

L1、L2、L3ラベルは、NULL終了なしで6オクテットASCII文字列として定義されます。

                   l1 =  "level1"

                   l2 =  "level2"

                   l3 =  "level3"

i1, i2, i3 parameters that determine which keys out of the tree are used on each level. Together, they determine a leaf key that is used for message protection; the length of i1 is one octet, and i2 and i3 are two-octet integers in network byte order

各レベルでどのキーがツリーから使用されているかを決定するI1、I2、I3パラメータ。一緒に、彼らはメッセージ保護に使用されるリーフキーを決定します。I1の長さは1つのオクテットで、I2とI3はネットワークバイトオーダーの2オクテットの整数です。

| indicates concatenation

| ..連結を示します

This construction allows us to 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 possible leaf keys generated from a single Security Association (SA) key is 2^40.

この構成により、レベル2と最大2 ^ 16キーで最大2 ^ 8キーを生成することができ、1つのセキュリティアソシエーション（SA）キーから生成された可能なリーフキーの総数は2 ^です。40。

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.

この仕様は、頻繁に外部の回復が行われるのかについての要件を課していません。送信側アプリケーションは、各レベルのキーを数回使用する必要があるかを決定する独自のポリシーに従うことが予想されます。

4.2. Initialization Vector Format

4.2. 初期化ベクトルフォーマット

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.

定義された変換によって保護されている各メッセージにはIVが含まれていなければなりません。IVは64ビットのサイズを有し、4つのフィールドで構成されています。フィールドI1、I2、およびI3は、このメッセージが保護されている特定のリーフキーを決定するパラメータです（セクション4.1を参照）。4番目のフィールドはカウンタで、このキーのメッセージ番号を表します。

                          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 Format

図1：IV形式

where:

ただし：

i1 (1 octet), i2 (2 octets), i3 (2 octets): parameters that determine the particular key used to protect this message; 2-octet parameters are integers in network byte order

I1（1オクテット）、I2（2オクテット）、I3（2オクテット）：このメッセージを保護するために使用される特定のキーを決定するパラメータ。2オクテットパラメータはネットワークバイト順の整数です。

pnum (3 octets): message counter in network byte order for the leaf key protecting this message; up to 2^24 messages may be protected using a single leaf key

PNUM（3オクテット）：このメッセージを保護するリーフキーのネットワークバイト順にメッセージカウンタ。1つのリーフキーを使用して保護される可能性がある

For any given SA, the IV MUST NOT be used more than once, but there is no requirement that IV be unpredictable.

特定のSAの場合、IVは複数回使用してはいけませんが、IVは予測不可能な要件はありません。

4.3. Nonce Format for MGM

4.3. MGMのノンスフォーマット

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には、leafキーのコンテキストで一意である必要があるメッセージごとのNonce（初期カウンタNonce、または[RFC9058]のICN）が必要です。ICNのサイズはN - 1ビットであり、ここでNは基礎となる暗号のブロックサイズです。この文書で定義されている変換で使用されている2つの暗号は異なるブロックサイズを持っているので、ICNの2つの異なるフォーマットが定義されています。

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.

MGM仕様では、N-1ビットがN-1ビットである必要があります。ここで、nは基礎となる暗号のブロックサイズです。この文書は、Nビット（基礎となる暗号のブロックサイズ）を有するMGMノンスを規定している。nは常に8ビットの倍数であるので、これはMGMノンスを整数のオクテットを有する。MGM内部で使用されると、Nonceの最初のオクテットの最上位ビット（オクテット文字列として表されます）がドロップされ、N-1ビットの有効サイズが同じです。ドロップされたビットは「ゼロ」フィールドの一部です（図2と図3を参照）。これは常に0に設定されているため、ドロップされたときに情報は失われません。

4.3.1. MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher

4.3.1. "kuznyechik"暗号に基づく変換のためのMGMノンスフォーマット

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.

"kuznyechik"暗号（encr_kuznyechik_mgm_ktreeとencr_kuznyechik_mgm_mac_ktree）に基づく変換のために、ICNは「ゼロ」オクテットで構成されています。24ビットメッセージカウンタ。そして、SAに固定されておらず、96ビットの秘密塩が送信されていない。

                          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" Cipher

図2：「kuznyechik」暗号に基づく変換のためのノンスフォーマット

where:

ただし：

zero (1 octet): set to 0

ゼロ（1オクテット）：0に設定します

pnum (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

PNUM（3オクテット）：与えられたリーフキーによって保護されているメッセージのカウンタ。このフィールドはIVのPNUMフィールドに等しくなければなりません

salt (12 octets): secret salt. The salt is a string of bits that are formed when the SA is created (see Section 4.4 for details). The salt does not change during the SA's lifetime and is not transmitted on the wire. Every SA will have its own salt.

塩（12オクテット）：シークレット塩。SALTは、SAが作成されたときに形成される一連のビットです（詳細はセクション4.4を参照）。SAの寿命の間に塩は変化しないため、ワイヤ上では送信されません。すべてのSAはそれ自身の塩を持っています。

4.3.2. MGM Nonce Format for Transforms Based on the "Magma" Cipher

4.3.2. "Magma"暗号に基づく変換のためのMGMのノンスフォーマット

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.

「Magma」暗号（ENCR_MAGMA_MGM_KTREEおよびENCR_MAGMA_MGM_MAC_KTREE）に基づく変換の場合、ICNは「ゼロ」オクテットで構成されています。24ビットメッセージカウンタ。そして、SAに固定されておらず、送信されていない32ビットの秘密塩。

                          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" Cipher

図3：「Magma」暗号に基づく変換のためのノンスフォーマット

where:

ただし：

zero (1 octet): set to 0

ゼロ（1オクテット）：0に設定します

pnum (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): secret salt. The salt is a string of bits that are formed when the SA is created (see Section 4.4 for details). The salt does not change during the SA's lifetime and is not transmitted on the wire. Every SA will have its own salt.

塩（4オクテット）：シークレット塩。SALTは、SAが作成されたときに形成される一連のビットです（詳細はセクション4.4を参照）。SAの寿命の間に塩は変化しないため、ワイヤ上では送信されません。すべてのSAはそれ自身の塩を持っています。

4.4. Keying Material

4.4. キーイング材料

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).

ENC_KUZNYECHIK_MGM_KTREEおよびENCR_KUZNYECHIK_MGM_MAC_KTREE変換のトランスフォームキーは、最初の256ビットがツリーのルートキー（セクション4.1でkと表記）である352ビット（44オクテット）で構成されており、残りの96ビットが秘密の塩です（参照）。セクション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).

ENC_MAGMA_MGM_KTREEおよびENCR_MAGMA_MGM_MAC_KTREE変換のトランスフォームキーは288ビット（36オクテット）で構成されており、そのうちの最初の256ビットはツリーのルートキー（セクション4.1でkと表記）で、残りの32ビットは秘密の塩です（セクション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.

ESPの場合、変換キーは[RFC7296]のセクション2.17で定義されているようにキーマットから抽出されます。IKEv2の場合、トランスフォームキーはSK_EIまたはSK_ERのいずれかです。[RFC7296]のセクション2.14で定義されているように生成されます。これらの変換は認証された暗号化を提供するため、認証には追加のキーは必要ありません。つまり、IKEv2の場合、キーSK_AI / SK_ARは使用されず、長さがゼロになるように扱われなければなりません。

4.5. Integrity Check Value

4.5. 整合性チェック値

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).

MGMが計算できる認証タグの長さは、基礎となる暗号のブロックサイズから32ビットの範囲内です。[RFC9058]のセクション4は、認証タグの長さを特定のプロトコルに対して固定しなければならないことを示しています。「kuznyechik」暗号（ENCR_KUZNYECHIK_MGM_KTREEとENCR_KUZNYECHIK_MGM_MAC_KTREE）に基づく変換の場合、結果の整合性チェック値（ICV）長は96ビットに設定されます。「Magma」暗号（ENCR_MAGMA_MGM_KTREEとENCR_MAGMA_MGM_MAC_KTREE）に基づく変換の場合、フルICV長はブロックサイズ（64ビット）に設定されます。

4.6. Plaintext Padding

4.6. 平文のパディング

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).

この文書で定義されている変換には、[RFC9058]で指定されているように、平文のパディングは必要ありません。これは、プロトコルによって課されるパディング要件のみが適用されます（ESPの4バイト、IKEV2のパディングはありません）。

4.7. AAD Construction

4.7. AADの建設

4.7.1. ESP AAD

4.7.1. ESP AAD.

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].

使用されている変換および拡張シーケンス番号（ESN）が使用されているかどうかに応じて、ESPの追加の認証データ（AAD）は異なります。ENCR_KUZNYECHIK_MGM_KTREEおよびENCR_MAGMA_MGM_KTREE変換は機密性を提供するため、ESP本体の内容が暗号化され、AADはESPセキュリティパラメータインデックス（SPI）と（E）SNで構成されています。AADは、[RFC4106]のAADと同様に構成されています。

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].

一方、encr_kuznyechik_mgm_mac_ktreeおよびencr_magma_mgm_mac_ktree変換は機密性を提供しません。それらはメッセージ認証のみを提供します。この目的のために、通常暗号化されているESPパケットの一部はAADに含まれています。これらの変換には、MGMによって提供される暗号化機能は使用されません。AADは、[RFC4543]のAADと同様に構成されています。

                          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

図4：32ビットSNを搭載したAAD変換用AAD

                          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

図5：64ビットESNを搭載したAADのAAD

                          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

図6：32ビットSNでの認証のみの変換のためのAAD

                          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 ESN

図7：64ビットESNを使用した認証専用変換のためのAAD

4.7.2. IKEv2 AAD

4.7.2. IKEV2 Aad.

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].

IKEV2の場合、AADはIKEv2ヘッダー、それに続く（存在する場合）、暗号化されていないペイロード、および暗号化されたペイロードヘッダー（[RFC7296]のセクション3.14）または暗号化されたフラグメントペイロード（[RFC7383]のセクション2.5）で構成されています。IKEフラグメンテーションが使用されているかどうかについて。AADは、[RFC5282]のAADと同様に構成されています。

                          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

図8：暗号化されたペイロードの場合のIKEv2のAAD

                          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

図9：暗号化されたフラグメントペイロードの場合のIKEV2のAAD

4.8. Using Transforms

4.8. 変換を使う

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.

SAが確立されると、送信者によってI1、I2、およびI3のパラメータが0に設定され、リーフキーが計算されます。PNUMパラメータは0から始まり、同じリーフキーによって保護されている各メッセージでインクリメントされます。葉が変更されるべきであることを送信者が決定すると、i3パラメータをインクリメントして新しいリーフキーを生成します。新しいリーフキーのPNUMパラメータは0にリセットされ、プロセスは続行されます。送信者がI3に対応する3番目のレベルのキーが十分に使用されていることを決定した場合、I2をインクリメントし、I3を0にリセットして新しいリーフキーを計算します。PNUMは（すべての新しいリーフキーと同様に）0にリセットされ、プロセスは続行されます。第2レベルのキーを変更する必要がある場合も同様の手順が使用されます。

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.

I1、I2、I3、およびPNUMの組み合わせは、特定のSAについて繰り返されてはいけません。つまり、これらのカウンタのラッピングは許可されていないことを意味します.I2、I3、またはPNUMがそれぞれ最大値に達すると、上述のリーフキーを変更するための手順が実行され、4つのパラメータすべてが最大値に達すると、IPSec SAは使用できなくなります。

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.

カウンタの最大値に達するだけでなく、リーフキーを再計算する理由があるかもしれません。たとえば、セクション5で説明されているように、送信者は特定のリーフキーによって保護されているオクテットの数をカウントし、一部のしきい値に達したときに新しいキーを生成することをお勧めします。最新のセクション5暗号のそれぞれについて。

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).

受信側は常に受信したメッセージからI1、I2、およびI3を使用します。以前に受信したパケットの値と異なる場合は、新しいリーフキーが計算されます。PNUMパラメータは常に受信したパケットから使用されます。パフォーマンスを向上させるために、実装は最近使用されたリーフキーをキャッシュすることがあります。新しいリーフキーが（受信したメッセージからの値に基づいて）計算されると、パケットの並べ替えの可能性がある場合のパフォーマンスを向上させるためにしばらくの間、古いキーを保持することができます（古いリーフキーによって保護されているパケットが遅くなって到着する場合後で）。

5. Security Considerations

5. セキュリティに関する考慮事項

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.

MGMの最も重要なセキュリティ上の検討は、Nonceが特定のキーに対して繰り返されてはいけません。このため、この文書で定義されている変換は手動キーイングで使用してはいけません。

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 2^20 (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.

同じキーを過度に使用すると、このドキュメントで定義されている変換のセキュリティプロパティを破るのに攻撃者の利点があります。このため、特定のキーが保護するために使用されるデータ量は制限されるべきです。これは、64ビットブロックサイズ（「マグマ」のような）を持つアルゴリズムにとって特に重要です。これは、現在、比較的少量のデータを保護した後に一般的には安全でないと考えられています。たとえば、[SP800-67]のセクション3.4は、トリプルDES暗号で2 ^ 20（8 MBのデータ）で暗号化されることが許可されているブロック数を制限します。この文書は、暗号化キーを頻繁に変更することによって、64ビットブロック暗号の弱いセキュリティを軽減することを可能にする回復メカニズムを定義しています。

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:

このドキュメントで定義されている変換の場合、[GOST-ESP]は、単一のK_MSGキーで保護されているオクテット数を次の値で制限することをお勧めします。

* 2^41 octets for transforms based on the "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE)

* "kuznyechik"暗号（encr_kuznyechik_mgm_ktreeとencr_kuznyechik_mgm_mac_ktree）に基づく変換のための2 ^ 41オクテット

* 2^28 octets for transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE)

* 「Magma」暗号（ENCR_MAGMA_MGM_KTREEおよびENCR_MAGMA_MGM_MAC_KTREE）に基づく変換のための2 28オクテット

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 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.

これらの値はコンビナトリアル特性に基づいており、サイドチャネル攻撃が考慮される場合、さらに制限されている可能性があります。変換の構築により、「KuznyChik」暗号に基づく変換の制限は到達不能であり、保護されたメッセージの数は2 ^ 24に制限され、各メッセージ（IKEv2メッセージまたはESPデータグラム）が限られています。2 ^ 16オクテットのサイズで、単一のK_MSGで保護できるデータの最大量として2 ^ 40オクテットを与えます。

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.

[RFC9058]のセクション4では、メッセージの拡大と偽造の可能性との間のトレードオフとして、MGMで認証タグを切り捨てる可能性について説明します。この仕様は、「Kuznyechik」暗号に基づく変換のための認証タグの長さを96ビットに切り捨てます。これは、依然として偽造の確率が非常に低い間に、メッセージ拡張を減少させる：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.

攻撃者は、任意に選択されたI1、I2、およびI3のパラメータを持つ多くのパケットを送信することができます。これは、I1、I2、およびI3が以前に受信されたパケット内のこれらの値と異なる場合、受信者にリーフキーを再計算し、CPUリソースを消費するCPUリソースを消費します。大量のデータで失敗し、したがって、攻撃者が基礎となる暗号化プリミティブのより深い分析を可能にします（[aead-usage-limits]を参照）。それらが無効なICVを持つパケットが多すぎると判断した場合、実装は再確認を開始するかもしれません。

Security properties of MGM are discussed in [MGM-SECURITY].

MGMのセキュリティプロパティは[MGM-Security]で説明しています。

6. IANA Considerations

6. IANAの考慮事項

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.

IANAは、「トランスフォームタイプ値」と呼ばれるサブレジストを使用して、「インターネットキー交換バージョン2（IKEv2）パラメータ」と呼ばれるレジストリを管理しています。IANAは、次の4つの変換IDを「変換タイプ1 - 暗号化アルゴリズム変換ID」サブレイストに追加しました。

    +========+===============================+===========+===========+
    | 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

表1：変換IDS

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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>.

[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.

[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<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>.

[RFC7296] Kaufman、C.、Hoffman、P.、NIR、Y.、ERONEN、P.、およびT.Kivinen、「インターネットキー交換プロトコル版2（IKEV2）」、STD 79、RFC 7296、DOI 10.17487 / RFC72962014年10月、<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>.

[RFC7383] SmySlov、V.、 "Internet Key Exchange Protocol Version 2（IKEV2）メッセージフラグメンテーション"、RFC 7383、DOI 10.17487 / RFC7383、2014年11月、<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>.

[RFC6986]ドルマトフ、V.。A.Degtyarev、 "Gost R 34.11-2012：Hash Function"、RFC 6986、DOI 10.17487 / RFC6986、2013年8月、<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>.

[RFC7801]ドルマトフ、V.、ED。、「GOST R 34.12-2015：ブロック暗号「Kuznyechik」、RFC 7801、DOI 10.17487 / RFC7801、2016年3月、<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>.

[RFC8891]ドルマトフ、V.。D. BaryShkov、 "Gost R 34.12-2015：ブロック暗号" Magma ""、RFC 8891、DOI 10.17487 / RFC8891、2020年9月、<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>.

[RFC9058] SmyShlyaev、S.、Ed。、Nozdrunov、V.、Shishkin、V.およびE.Griboedova、「多重線ガロアモード（MGM）」、RFC 9058、DOI 10.17487 / RFC9058、2021年6月、<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>.

[RFC7836] SmyShlyaev、S、ED。、AlekSeev、E.、Oshkin、I.、Popov、V.、Leontiev、S.、Podobaev、V.、およびD.Belyavsky、 "Cryptographicアルゴリズムのガイドライン2016年3月、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc7836,2016、<https://www.rfc-editor.org/info/rfc7836>の使用方法

7.2. Informative References

7.2. 参考引用

[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)

[GOST3411-2012]技術規制と計測学、「情報技術。2012年8月、GOST Rデータセキュリティ。ハッシュ機能」、GOST R 34.11-2012、GOST R 34.11-2012。（ロシア語）

[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)

[GOST3412-2015]技術規制と計測学、「情報技術。暗号データセキュリティ。ブロック暗号」、GOST R 34.12-2015、2015年6月（ロシア語）

[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-MGM]技術規制と計測学、「情報技術。暗号化情報セキュリティ。2019年9月、2019年9月、2019年9月、2019年9月、2019年9月（ロシア語）

[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)

[GOST-ESP]技術規制および計測学、「情報技術。暗号化情報保護。2021年1月1323565.1.035-2021、2021年1月1323565.1.035-2021、2021年1月1日（ロシア語）。

[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>.

[RFC2104] Krawczyk、H.、Belleare、M.、およびR. Canetti、 "HMAC：メッセージ認証のための鍵付きハッシング"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.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>.

[RFC4106] Viega、J.およびD.Mcgrew、「Galois / Counter Mode（GCM）のIPsecカプセル化セキュリティペイロード（ESP）」、RFC 4106、DOI 10.17487 / RFC4106、2005年6月、<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>.

[RFC4543] McGrew、D.およびJ.Viega、「IPSec ESPおよびAHのGALOISメッセージ認証コード（GMAC）の使用」、RFC 4543、DOI 10.17487 / RFC4543、2006年5月、<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>.

[RFC5282] Black、D.およびD.McGrew、「インターネットキー交換バージョン2（IKEV2）プロトコルの暗号化ペイロードを使用した認証された暗号化アルゴリズムの使用」、RFC 5282、DOI 10.17487 / RFC5282、2008年8月、<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>.

[RFC8645] SmyShlyaev、S.、ED。、「対称鍵のための再キーイングメカニズム」、RFC 8645、DOI 10.17487 / RFC8645、2019年8月、<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>.

[MGMセキュリティ] Akhmetzyanova、L.、Alekseev、E.、Karpunin、G.、およびV.Nozdrunov、「多重線ガロアモード（MGM）のセキュリティ（MULTINER GALOISモード（MGM）」、<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>.

[SP800-67]国立標準化学技術研究所、「トリプルデータ暗号化アルゴリズム（TDEA）ブロック暗号（TDEA）ブロック暗号の推奨事項、DOI 10.6028 / NIST.SP.800-67R2、<https：//nvlpubs.nist。GOV / NISTPUBS /スペシャルプレーション/ 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>.

[AEAD-USAGE-LIMITS]Günther、F.、Thomson、M.、およびC.A。木、「AEDアルゴリズムの使用制限」、進行中の作業、インターネットドラフト、ドラフト-IRTF-CFRG-AEAD-LIMITS-04,72022年3月、<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-04>。

Appendix A. Test Vectors

付録A.テストベクトル

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.

次のテストベクトルでは、バイナリデータは16進形式で表されます。角括弧内の数字は、対応するデータのサイズを10進形式で示しています。

1. ENCR_KUZNYECHIK_MGM_KTREE (Example 1):

1. encr_kuznyechik_mgm_ktree（例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

トランスフォームキー[44]：B6 18 0 C 14 5C 51 2D BD 69 D9 CE A9 2 C AC 1B 5C E1 BC FA 73 79 2D 61 AF 0 B 44 0 D 87 E6 F2 44 F9 7F 06 78 95 2E 45 K [32]：B6 18 0 C 14 5 C 51 2D BD 69 D9 CE A9 2 C AC 1B 5 C E1 BC FA 73 79 2D 61 AF 0 B 44 0D 84 B5 22 CC 38塩[12]：7B 67 E6 F2 44 F9 7F 06 78 95 2 4 45 I1 = 00、I 2 = 0000、I 3 = 0000、PNUM = 000000 K_MSG [32]：2F F1 C9 0E DE 78 6E 06 1 1 17 B 3 74 D7 82 AF 7 B D8 80 BD 52 7 C 66 A2 BA DC 3E 56 9A AB 27 1D A4 NNCE [16]：00 00 00 00 00 00 00×45 IV [8]：00 00 00【8】【8】：51 46 53 6B 00 00 00 00 00 00 01平文[64]：45 00 00 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 6 F 6 B 0 2 00 58 00 65 6 B 6 C 6 D 6 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 61 62 63 64 65 61 62 63 64 65 66 67 68 69 01 02 02 02 04 CipherText [64]：18 9D 12 88 B7 18 F9 EA 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 9 C A9 BF 0B DB AF C2 3E AE 4D A5 6F ES P ICV [12]：50 B0 70 A1 5A 2B D9 73 86 89 F8 ED PACKER [112]：45 00 00 70 00 4 42 C5 0 A 6F 0A 1D 51 46 53 6 B 00 00 00 001 001 00 00 00 00 00 00 1 1 18 F9 EAになる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 9 C A9 BF 0B DB AF C2 3E AE 4D A5 6F 50 B0 70 A1 5A 2B D9 73 86 89 F8 ED

2. ENCR_KUZNYECHIK_MGM_KTREE (Example 2):

2. encr_kuznyechik_mgm_ktree（例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

トランスフォームキー[44]：B6 18 0 C 14 5C 51 2D BD 69 D9 CE A9 2 C AC 1B 5C E1 BC FA 73 79 2D 61 AF 0 B 44 0 D 87 E6 F2 44 F9 7F 06 78 95 2E 45 K [32]：B6 18 0 C 14 5 C 51 2D BD 69 D9 CE A9 2 C AC 1B 5 C E1 BC FA 73 79 2D 61 AF 0 B 44 0D 84 B5 22 CC 38塩[12]：7B 67 E6 F2 44 F9 7F 06 78 95 2 4 45 I1 = 00、I 2 = 0001、I 3 = 0001、PNUM = 000000 K_MSG [32]：9A BA C6 57 78 1F B8 D5 71 62 36 66 C2 F5 13 0D 54 E2 11 6C 7D 00 00 00 00 00 00 00 00 00 00 00 00 00 06 78 95 2e 45 IV [8]：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 AAD：51 46 53 6b 00 00 00 00 00 00 00 00【64】：45 00 00 3 48 00 7 00 7 00 A C5 0 A 6F 0 A 1D 08 00 67 00 61 62 67 64 65 6 B 6 C 6 D 6 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 61 67 63 64 65 66 67 68 64 65 66 67 68 69 01 02 02 04暗号テキスト[64]：78 0A 2C 62 62 32 15 7 B 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 7 C FF 72 56 AB F0 0B A1 22 BB 5E 6C 71 A4 D4 9A 4D ES P ICV [12]：C2 2F 87 40 83 8E 3D FA CE 91 CC B8 ESPパケット[112]：45 00 00 7 C 00 5 C 5 0 A 6 F 0 A 1 D 51 46 53 6 B 00 00 00 00 10 001 001 00 00 01 00 00 78 0 A 2 C 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 7 C 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

3. ENCR_MAGMA_MGM_KTREE (Example 1):

3. encr_magma_mgm_ktree（例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

トランスフォームキー[36]：5B 50 BF 33 78 87 02 38 F3 CA 74 0F D1 24 BA 6C 22 83 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 5F 06 B2 03 SALT [4]：CF 36 63 12 I1 = 00、I 2 = 0000、I 3 = 0000、 PNUM = 000000 K_MSG [32]：25 65 21 E2 70 B7 4A 16 4D FC 26 E6 BF 0 C CA 76 5E 9D 41 02 7D 4B 7B 19 76 2B 1C C9 01 DC DE 7F Nonce [8]：00 00 00 00 00 00 CF 36 63 12 IV [8]：00 00 00 00×[8]：C8 C2 B2 8D 00 00 00 01平文×64】：45 00 00 3 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 69 65 6 B 6 C 6 D 6 E 6F 70 71 72 73 74 75 76 77 61 62 67 68 64 65 66 67 68 64 65 66 67 68 64 65 66 67 68 69 01 02 02 04暗号テキスト[ 64]：FA 08 40 33 2C 4F 3F C9 64 4D 8 C 2 C 4 A 91 7E 04 03 87 64 6 B B9 DF BD 91 50 3F 4A F5 D2 42 69 49 D3 5A 22 9E 1E 0 E 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 02 94 0F 5C ESPパケット[108]：45 00 00 6C 00 62 00 00 000A 1D C5 0A 6F 0 A 1 D C 8 C 2 B 2 8 D 00 00 A 1 D C 8 C 2 B 2 8 D 00 00 00 0 00 00 0 00】FA 08 4 4 4 D 8 C 2 C 4 A 91 7E 0 C D 8 6 F 6 F 61 04 03 87 64 6B B9 DF BD 91 50 3F 4A F5 D2 42 69 49 D3 5A 22 9E 1脚9E 32 43 E2 3B A4 D1 1E 84 52 C 91 A7 19 15 52 CC E8 5F 4A FA 8B 02 94 0F 5c

4. ENCR_MAGMA_MGM_KTREE (Example 2):

4. ENCR_MAGMA_MGM_KTREE（例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

トランスフォームキー[36]：5B 50 BF 33 78 87 02 38 F3 CA 74 0F D1 24 BA 6C 22 83 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 6A 89 4A A3 5D 5F 06 B2 03 SALT [4]：CF 36 63 12 I1 = 00、I 2 = 0001、I 3 = 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 08 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 00 AAD [8]：C8 C2 B2 8D 00 00 00 10 10 Plaintext [64]：45 00 00 3C 24 40 00 7F 01 ED C1 0A 6F 0A C5 0A 6F 0A 1D 08 00 CF 5B 02 00 7C 00 61 66 67 64 65 6F 70 71 72 73 74 75 76 77 61 62 67 68 64 65 66 67 68 64 65 66 67 68 64 65 66 67 68 64 65 66 67 68 69 01 02 02 04暗号テキスト[ 64]：7a 71 48 41 A5 34 B7 58 93 6A 8 e AB 26 91 40 A8 25 A7 F3 5D B9 99 9 C 9 B 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パケット[108]：45 00 00 6C 00 71 00 00 FF 32 91 2F 0 A 6F 0 A C 0 01 00 00 A A AB 2 26 91 40 A8 25 AB 26 91 40 A8 25 AB 26 91 40 A8 25 A7 F3 5D B9 E4 37 1F E7 6C 99 99 9 C 9 B 88 DB 72 1D C7 59 F6 56 B5 B3 7A 07 1D 4B 93 78 BD 08 97 6C 33 78 BD 08 97 6C 33 78 BF FE A1 DD DD 5D 50 9A FD B8 09 98.

5. ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 1):

5. encr_kuznyechik_mgm_mac_ktree（例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

トランスフォームキー[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は塩分[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 NNCE [16]：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00×a a c 92 6a 00 00 00 00 00 00 00 00 00 00 00 4 C 0 C F 1 00 00 7F 01 05 0 A 6F 0 A 1 D 08 00 48 5 C 02 00 03 00 61 62 63 64 65 6 B 6 B 6 6C 6D 6E 6F 70 71 72 73 74 75 76 77 66 67 63 64 65 61 67 68 64 65 66 67 63 64 65 66 67 68 64 65 66 67 68 64 65 66 67 68 64 65 66 67 68 64 65 66 67 68 64 65 66 67 68 69 01 02 02 04平文文[0]：暗号文[0]：ESP ICV [12]：CA C5 8C E5 E8 8B 4B F3 2D 6C F0 4D ESPパケット[112]：45 00 00 70 00 00 00 00 00 0 00 0 00 00 0 00 0 00 0 00 00 0 00 0 00 00 0 00 0 00 00 0 0 00 4 C 0 0 A C 5 0 A 6 F 6 B 6 B 6 C 6 D 6 C 7 7 7 1 7 2 73 74 6F 01 02 00 6F 0 0 A 1 D 08 6 4 6 F 6 B 6 C 6 D 6 C 7 7 7 1 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

6. ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 2):

6. encr_kuznyechik_mgm_mac_ktree（例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

トランスフォームキー[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は塩分[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 00 00 00 00 00 00 00 00 00件[80]：3D AC 92 6A 00 【0006】【0006】【000】00 00】001 00 00 4 00 4 00 00 00 7F 01 05 0 A 6F 0 A 1 D 08 00 43 5 C 62 63 64 65 66 67 68 65 66 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 0 E 91 ESPパケット[112]：45 00 00 70 00 00 A 6 F 3 D AC 92 6 A 00 00 0 00 00 0 6 0 00 4F 01 05 07 6F 0 0 A 1 D 08 00 6F 0 0 A 1 D 08 00 43 6 B 6 C 6 D 6 C 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 04 BA BC 67 EC 72 A8 C3 1A 89 B4 0E 91

7. ENCR_MAGMA_MGM_MAC_KTREE (Example 1):

7. ENCR_MAGMA_MGM_MAC_KTREE（例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

トランスフォームキー[36]：D0 65 B5 30 57 0 C 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 0 C 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 00 00 00 00 88 79 00 00 00 00 00×【80】【80】【80】【80】【80】60【80】60【01】40【01】40【01】40 00】7F 01 08 00 7F 01 03 FA 0A 6F 0A C5 0A 6F 0A 1D 08 00 36 5 C 02 00 15 00 61 6 B 67 68 61 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04平文[0]：暗号文[0]：ESP ICV [8]：4D D4 25 8A 25 95 DF ESPパケット[108]：45 00A C5 0A 6F 0A 1D 3E 40 69 9C 00 00 00 001 001 00 00 4 C 0 0 8 00 7F 01 0 3 FA 0 A 6F 0 A C 5 0 A 6F 0 A 1 D 08 00 36 5 C 02 00 15 0 0 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 64 65 66 67 68 69 01 02 02 04 4D D4 25 8A 25 35 95 DF

8. ENCR_MAGMA_MGM_MAC_KTREE (Example 2):

8. ENCR_MAGMA_MGM_MAC_KTREE（例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

トランスフォームキー[36]：D0 65 B5 30 57 0 C 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 07 A8 85 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 00 00 00 00 00 00 88 79 00 00 00 00 00 00×[80]：3×40 69 9 C 00 00】00 00 06 00 4 40 00 00 4 4 40 00 00 4 4 C 0 0 A 1 13 00 7F 01 03 EF 0A 6F 0A C5 0A 6F 0A 1D 08 00 31 5 C 02 00 1 A 00 61 66 6 C 6 D 6 C 6 F 6 C 7 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04平文[0]：CiphiperText [0]：ESP ICV [8]：84 84 A9 23 30 A0 B1 96 ESPパケット[108]：45 00A C5 0A 6F 0A 1D 3E 40 69 9 C 00 00】00 00 01 00 4F 0 01 C 5 0 A 6F 0 A 1 D 08 00 3 31 5 C 02 00 1 A 0 0 61 62 63 64 65 66 67 68 69 6a 6 B 6 C 6 D 6 E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 64 65 66 67 68 69 01 02 02 04 84 84 A9 23 30 A0 B1 96

Acknowledgments

謝辞

The author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer, and Stanislav Smyshlyaev for valuable input during the publication process for this document.

著者は、この文書の出版プロセス中に、Adrian Farrel、Russ Housle、Yaron Sheffer、およびStanislav SmyShlyaevに感謝します。

Author's Address

作者の住所

Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru

Valery Smyslov Elvis-Plus Po Box 81 Moscow（Zelenograd）124460ロシア連邦電話：7 495 276 0211 Eメール：svan@elvis.ru