RFC 4196 - The SEED Cipher Algorithm and Its Use with IPsec 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4196
タイトル : RFC 4196 - シード暗号アルゴリズムとIPSECでの使用
翻訳編集 : 自動生成

[要約] 要約： RFC 4196は、SEED暗号アルゴリズムとそのIPsecでの使用について説明しています。SEEDは韓国の国家標準暗号アルゴリズムであり、IPsecにおいてセキュリティを提供するために使用されます。目的： RFC 4196の目的は、SEED暗号アルゴリズムの詳細な説明と、IPsecでの使用方法を提供することです。これにより、セキュリティ専門家やネットワーク管理者がSEEDを使用してIPsecを実装する際のガイドラインを得ることができます。

Network Working Group                                           H.J. Lee
Request for Comments: 4196                                     J.H. Yoon
Category: Standards Track                                       S.L. Lee
                                                                J.I. Lee
                                                                    KISA
                                                            October 2005

The SEED Cipher Algorithm and Its Use with IPsec

シード暗号アルゴリズムとIPSECでの使用

Status of This Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

このドキュメントでは、セキュリティペイロードをカプセル化するIPSEC（ESP）のコンテキスト内での機密保持メカニズムとして、明示的なIVを使用した、暗号ブロックチェーンモードでのシードブロック暗号アルゴリズムの使用について説明します。

1. Introduction

1. はじめに

1.1. SEED

1.1. シード

SEED is a national industrial association standard [TTASSEED] and is widely used in South Korea for electronic commerce and financial services that are operated on wired and wireless communications.

SEEDは、国立産業協会の基準[TTASSEED]であり、韓国では、有線通信および無線通信で運営されている電子商業と金融サービスのために広く使用されています。

SEED is a 128-bit symmetric key block cipher that has been developed by KISA (Korea Information Security Agency) and a group of experts since 1998. The input/output block size of SEED is 128-bit and the key length is also 128-bit. SEED has the 16-round Feistel structure. A 128-bit input is divided into two 64-bit blocks, and the right 64- bit block is an input to the round function with a 64-bit subkey that is generated from the key scheduling.

Seedは、1998年以来、KISA（韓国情報セキュリティ機関）と専門家グループによって開発された128ビット対称キーブロック暗号です。シードの入力/出力ブロックサイズは128ビットで、キーの長さも128ビットです。少し。種子には16ラウンドのファイストル構造があります。128ビットの入力は2つの64ビットブロックに分割され、右64ビットブロックは、キースケジューリングから生成される64ビットのサブキーを備えたラウンド関数への入力です。

SEED is easily implemented in various software and hardware, and it can be effectively adopted to a computing environment with restricted resources, such as mobile devices and smart cards.

シードはさまざまなソフトウェアやハードウェアに簡単に実装され、モバイルデバイスやスマートカードなどの制限されたリソースを備えたコンピューティング環境に効果的に採用できます。

SEED is robust against known attacks including DC (Differential cryptanalysis), LC (Linear cryptanalysis), and related key attacks. SEED has gone through wide public scrutinizing procedures. It has been evaluated and is considered cryptographically secure by credible organizations such as ISO/IEC JTC 1/SC 27 and Japan CRYPTREC (Cryptography Research and Evaluation Committees)[ISOSEED][CRYPTREC].

種子は、DC（微分暗号化）、LC（線形暗号化）、および関連するキー攻撃を含む既知の攻撃に対して堅牢です。種子は、幅広い公的精査手順を経験しています。それは評価されており、ISO/IEC JTC 1/SC 27やJapan Cryptrec（暗号化研究および評価委員会）[Isoseed] [Cryptrec]などの信頼できる組織によって暗号化的に安全であると考えられています。

The remainder of this document specifies the use of SEED within the context of IPsec ESP. For further information on how the various pieces of ESP fit together to provide security services, please refer to [ARCH], [ESP], and [ROAD].

このドキュメントの残りの部分は、IPSEC espのコンテキスト内で種子の使用を指定しています。ESPのさまざまな部分がどのように適合してセキュリティサービスを提供するかの詳細については、[Arch]、[ESP]、および[Road]を参照してください。

1.2. Terminology

1.2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119 [KEYWORDS].

「必須」、「「必要」、「必須」、「必要」、「はない」、「必要」、「推奨」、「5月」、および「オプション」（上記のように、図示）は次のとおりです。RFC 2119 [キーワード]で説明されているように解釈されます。

2. The SEED Cipher Algorithm

2. シード暗号アルゴリズム

All symmetric block cipher algorithms share common characteristics and variables, including mode, key size, weak keys, block size, and rounds. The following sections contain descriptions of the relevant characteristics of SEED.

すべての対称ブロック暗号アルゴリズムは、モード、キーサイズ、弱いキー、ブロックサイズ、ラウンドなど、共通の特性と変数を共有します。次のセクションには、種子の関連する特性の説明が含まれています。

The algorithm specification and object identifiers are described in [ISOSEED] [SEED]. The SEED homepage, http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of information about SEED, including a detailed specification, evaluation report, test vectors, and so on.

アルゴリズムの仕様とオブジェクト識別子は、[アイソセド] [種子]で説明されています。シードホームページhttp://www.kisa.or.kr/seed/seed_eng.htmlには、詳細な仕様、評価レポート、テストベクトルなど、種子に関する豊富な情報が含まれています。

2.1. Mode

2.1. モード

NIST has defined 5 modes of operation for the Advanced Encryption Standard (AES) [AES] and other FIPS-approved ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic Codebook), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter). The CBC mode is well-defined and well-understood for symmetric ciphers, and is currently required for all other ESP ciphers. This document specifies the use of the SEED cipher in the CBC mode within ESP. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets that have identical data that spans the first block of the cipher algorithm's block size

NISTは、高度な暗号化標準（AES）[AES]およびその他のFIPS承認の暗号の5つの操作モードを定義しました[モード]：CBC（CIPHERブロックチェーン）、ECB（電子コードブック）、CFB（CIPHERフィードバック）、OFB（出力）フィードバック）、およびCTR（カウンター）。CBCモードは、対称的な暗号に明確に定義されており、よく理解されており、現在、他のすべてのESP暗号に必要です。このドキュメントは、ESP内のCBCモードでのシード暗号の使用を指定しています。このモードには、ブロックサイズと同じサイズの初期化ベクトル（IV）が必要です。ランダムに生成されたIVを使用すると、暗号アルゴリズムのブロックサイズの最初のブロックに及ぶ同一のデータを持つパケットから同一の暗号文の生成を防ぎます

The IV is XOR'd with the first plaintext block before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext before it is encrypted.

IVは、暗号化される前に最初のPlantextブロックでXor'dです。次に、連続したブロックの場合、以前の暗号文ブロックは、暗号化される前に現在のプレーンテキストでXor'dです。

More information on the CBC mode can be obtained in [MODES] [CRYPTO-S]. For use of the CBC mode in ESP with 64-bit ciphers, please see [CBC].

CBCモードの詳細については、[モード] [Crypto-S]で取得できます。64ビット暗号でESPでCBCモードを使用するには、[CBC]を参照してください。

2.2. Key Size and Numbers of Rounds

2.2. キーサイズとラウンド数

SEED supports 128-bit key and has the 16-round Feistel structure.

シードは128ビットキーをサポートし、16ラウンドのファイスター構造を持っています。

2.3. Weak Keys

2.3. 弱いキー

At the time this document was written, there were no known weak keys for SEED.

このドキュメントが書かれた時点で、種子の弱い鍵は知られていませんでした。

2.4. Block Size and Padding

2.4. ブロックサイズとパディング

SEED uses a block size of 16 octets (128 bits).

シードは、16オクテット（128ビット）のブロックサイズを使用します。

Padding is required by SEED to maintain a 16-octet (128-bit) blocksize. Padding MUST be added, as specified in [ESP], such that the data to be encrypted (which includes the ESP Pad Length and Next Header fields) has a length that is a multiple of 16 octets.

16オクテット（128ビット）ブロックサイズを維持するために、種子でパディングが必要です。[ESP]で指定されているように、パディングを追加する必要があります。そのため、暗号化されるデータ（ESPパッドの長さと次のヘッダーフィールドを含む）の長さは、16オクテットの倍数です。

Because of the algorithm specific padding requirement, no additional padding is required to ensure that the ciphertext terminates on a 4- octet boundary (i.e., maintaining a 16-octet blocksize guarantees that the ESP Pad Length and Next Header fields will be right aligned within a 4-octet word). Additional padding MAY be included, as specified in [ESP], as long as the 16-octet blocksize is maintained.

アルゴリズムの固有のパディング要件のため、暗号文が4-オクテットの境界で終了することを確認するために追加のパディングは必要ありません（つまり、16オクテットブロックサイズの保証を維持することで、ESPパッドの長さと次のヘッダーフィールドが正しく整列されることを保証します。4-オクテットワード）。16オクテットのブロックサイズが維持されている限り、[ESP]で指定されているように、追加のパディングを含めることができます。

2.5. Performance

2.5. パフォーマンス

Performance figures of SEED are available at http://www.kisa.or.kr/seed/seed_eng.html

シードのパフォーマンス数値は、http：//www.kisa.or.kr/seed/seed_eng.htmlで入手できます

3. ESP Payload

3. 特にペイロード

The ESP Payload is made up of the Initialization Vector(IV) of 16 octets followed by the encrypted payload. Thus, the payload field, as defined in [ESP], is broken down according to the following diagram:

ESPペイロードは、16個のオクテットの初期化ベクトル（IV）に続いて暗号化されたペイロードで構成されています。したがって、[esp]で定義されているペイロードフィールドは、次の図に従って分解されます。

      +---------------+---------------+---------------+---------------+
      |                                                               |
      +               Initialization Vector (16 octets)               +
      |                                                               |
      +---------------+---------------+---------------+---------------+
      |                                                               |
      ~ Encrypted Payload (variable length, a multiple of 16 octets)  ~
      |                                                               |
      +---------------------------------------------------------------+

The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random and MUST be unpredictable.

IVフィールドは、使用されている暗号アルゴリズムのブロックサイズと同じサイズでなければなりません。IVはランダムに選択する必要があり、予測不可能でなければなりません。

Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped or re-ordered in transit.

各データグラムにIVを含めることで、一部のデータグラムがトランジットでドロップまたは再注文された場合でも、受信した各データグラムの復号化を実行できます。

To avoid CBC encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-hamming distance source for IVs.

さまざまなパケット内の非常に類似したプレーンテキストブロックのCBC暗号化を回避するために、実装はIVのカウンターまたはその他の低ハミング距離ソースを使用してはなりません。

4. Test Vectors

4. テストベクトル

The first 2 test cases test SEED-CBC encryption. Each test case includes key, the plaintext, and the resulting ciphertext. All data are hexadecimal numbers (not prefixed by "0x").

最初の2つのテストケースは、シードCBC暗号化をテストします。各テストケースには、キー、プレーンテキスト、および結果の暗号文が含まれます。すべてのデータは16進数です（「0x」で前に付けられていません）。

The last 4 test cases illustrate sample ESP packets using SEED-CBC for encryption. All data are hexadecimal numbers (not prefixed by "0x").

最後の4つのテストケースは、暗号化にシードCBCを使用してサンプルESPパケットを示しています。すべてのデータは16進数です（「0x」で前に付けられていません）。

Case #1 : Encrypting 32 bytes (2 blocks) using SEED-CBC with 128-bit key Key : ed2401ad 22fa2559 91bafdb0 1fefd697 IV : 93eb149f 92c9905b ae5cd34d a06c3c8e PlainText : b40d7003 d9b6904b 35622750 c91a2457 5bb9a632 364aa26e 3ac0cf3a 9c9d0dcb CipherText : f072c5b1 a0588c10 5af8301a dcd91dd0 67f68221 55304bf3 aad75ceb 44341c25

ケース＃1：128ビットキーキーを使用してシードCBCを使用して32バイト（2ブロック）を暗号化します：ED2401AD 22FA2559 91BAFDB0 1FEFD697 IV：93EB149F 92C9905B AE5CD34D A06C3C8E PLAINTEXT：B40D7003 D9B6904B84848484848484848484848484848484 2457 5BB9A632 364AA26E 3AC0CF3A 9C9D0DCB CIPHERTEXT：F072C5B1 A05888C10 5AF8301A DCD91DD0 67F68221 55304BF33AAD75CEB 44341C25

Case #2 : Encrypting 64 bytes (4 blocks) using SEED-CBC with 128-bit key Key : 88e34f8f 081779f1 e9f39437 0ad40589 IV : 268d66a7 35a81a81 6fbad9fa 36162501 PlainText : d76d0d18 327ec562 b15e6bc3 65ac0c0f 8d41e0bb 938568ae ebfd92ed 1affa096 394d20fc 5277ddfc 4de8b0fc e1eb2b93 d4ae40ef 4768c613 b50b8942 f7d4b9b3 CipherText : a293eae9 d9aebfac 37ba714b d774e427 e8b706d7 e7d9a097 228639e0 b62b3b34 ced11609 cef2abaa ec2edf97 9308f379 c31527a8 267783e5 cba35389 82b48d06

ケース＃2：128ビットキーキーを使用してシードCBCを使用して64バイト（4ブロック）を暗号化します：88E34F8F 081779F1 E9F39437 0AD40589 IV：268D66A7 35A81A81 6FBAD9FA 36162501 PLANTEXT：D76D0CD18 327EC56 0C0F 8D41E0BB 938568AE EBFD92ED 1AFFA096 394D20FC 5277DDFC 4DE8B0FC E1EB2B93 D40EF 4768C68C613 B50B8942 F7D4B9B9B33333333333

Case #3 : Sample transport-mode ESP packet (ping 192.168.123.100) Key : 90d382b4 10eeba7a d938c46c ec1a82bf SPI : 4321 Source address : 192.168.123.3 Destination address : 192.168.123.100 Sequence number : 1 IV : e96e8c08 ab465763 fd098d45 dd3ff893

ケース＃3：サンプルトランスポートモードESPパケット（Ping 192.168.123.100）キー：90D382B4 10EEBA7A D938C46C EC1A82BF SPI：4321ソースアドレス：192.168.123.3目的地アドレス：192.168.23.100シーケンス番号：1 e9608d 1. 5 DD3FF893

Original packet : IP header (20 bytes) : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 Data (64 bytes) : 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

元のパケット：IPヘッダー（20バイト）：45000054 08F20000 4001F9FE C0A87B03 C0A87B64データ（64バイト）：08000EBD A70A0000 D1E1F 20212223 24252627 28292A2B 2C2D2E2F 30313233 34353637

Augment data with : Padding : 01020304 05060708 090a0b0c 0d0e Pad length : 0e Next header : 01 (ICMP)

データの増強：パディング：01020304 05060708 090A0B0C 0D0Eパッド長：0E次のヘッダー：01（ICMP）

Pre-encryption Data with padding, pad length and next header(80 bytes): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01 Post-encryption packet with SPI, Sequence number, IV : IP Header : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 SPI/Seq # : 00004321 00000001 IV : e96e8c08 ab465763 fd098d45 dd3ff893 Encrypted Data (80 bytes) : e7ebaa03 cf45ef09 021b3011 b40d3769 be96ebae cd4222f6 b6f84ce5 b2d5cdd1 60eb6b0e 5a47d16a 501a4d10 7b2d7cc8 ab86ba03 9a000972 66374fa8 f87ee0fb ef3805db faa144a2 334a34db 0b0f81ca

ヘッダー：45000054 08F20000 4001F9FE C0A87B03 C0A87B64 SPI/SEQ＃：00004321 00000001 IV：E96E8C08 AB465763 FD098D45 DD3FF893 0D3769 BE96EBAE CD4222F6 B6F84CE5 B2D5CDD1 60EB6B0E 5A47D16A 501A4D10 7B2D7CC8 AB86BA03 9A000972 66374FA8 F87EE0fB EF3805DB FA144A44A144A44A144A144a

   Case #4 : Sample transport-mode ESP packet
   (ping -p 77 -s 20 192.168.123.100)
   Key : 90d382b4 10eeba7a d938c46c ec1a82bf
   SPI                 : 4321
   Source address      : 192.168.123.3
   Destination address : 192.168.123.100
   Sequence number     : 8
   IV : 69d08df7 d203329d b093fc49 24e5bd80

Original packet: IP header (20 bytes) : 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64 Data (28 bytes) : 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

オリジナルパケット：IPヘッダー（20バイト）：45000030 08FE0000 4001FA16 C0A87B03 C0A87B64データ（28バイト）：0800B5E8 A80A0500 A69C083D 0B660E00 77777777777777777777777777777777777777777777777777777777777777777777777777777777

Augment data with : Padding : 0102 Pad length : 02 Next header : 01 (ICMP)

データの増強：パディング：0102パッド長：02次のヘッダー：01（ICMP）

Pre-encryption Data with padding, pad length and next header(32 bytes): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201

パディング、パッドの長さ、次のヘッダー（32バイト）を備えた前駆前データ：0800B5E8 A80A0500 A69C083D 0B660E00 7777777777777777777777777701020201

Post-encryption packet with SPI, Sequence number, IV : IP header : 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI/Seq # : 00004321 00000008 IV : 69d08df7 d203329d b093fc49 24e5bd80 Encrypted Data (32 bytes) : b9ad6e19 e9a6a2fa 02569160 2c0af541 db0b0807 e1f660c7 3ae2700b 5bb5efd1 Case #5 : Sample tunnel-mode ESP packet (ping 192.168.123.200) Key : 01234567 89abcdef 01234567 89abcdef SPI : 8765 Source address : 192.168.123.3 Destination address : 192.168.123.200 Sequence number : 2 IV : f4e76524 4f6407ad f13dc138 0f673f37

SPI、シーケンス番号、IV：IPヘッダー：4500004C 08FE0000 4032F9C9 C0A87B03 C0A87B64 SPI/SEQ＃：00004321 00000008 IV：69D08DF7 D203329D B093FC49 END B093FC49 24EPTED（32PC49 249249222492492222249249）IV：B093FC49 IV（ AD6E19 E9A6A2FA 02569160 2C0AF541 DB0B0807 E1F660C7 3AE2700B 5BB5EFD1ケース＃5：サンプルトンネルモードESPパケット（Ping 192.168.123.200）キー：01234567 89ABCDEF 01234567 89ABCDEF SPI：8765ソースアドレス：192.168.123.3宛先アドレス：192.168.123.200シーケンス番号：2 IIB F.F44444444444444444444444444444444444440 0F673F37

Original packet : IP header (20 bytes) : 45000054 09040000 4001f988 c0a87b03 c0a87bc8 Data (64 bytes) : 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

元のパケット：IPヘッダー（20バイト）：45000054 09040000 4001F988 C0A87B03 C0A87BC8データ（64バイト）：08009F76 A90A0100 B49C083D 02A20400 C1D1E1F 20212223 24252627 28292A2B 2C2D2E2F 30313233 34353637

Augment data with : Padding : 01020304 05060708 090a Pad length : 0a Next header : 04 (IP-in-IP)

データの増強：パディング：01020304 05060708 090Aパッド長：0A次のヘッダー：04（IP-in-IP）

Pre-encryption Data with original IP header, padding, pad length and next header (96 bytes) : 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04

Post-encryption packet with SPI, Sequence number, IV : IP header : 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 SPI/Seq # : 00008765 00000002 IV : f4e76524 4f6407ad f13dc138 0f673f37 Encrypted Data (96 bytes): 2638aa7b 05e71b54 9348082b 67b47b26 c565aed4 737f0bcb 439c0f00 73e7913c 3c8a3e4f 5f7a5062 003b78ed 7ca54a08 c7ce047d 5bec14e4 8cba1005 32a12097 8d7f5503 204ef661 729b4ea1 ae6a9178 59a5caac 46e810bd 7875bd13 d6f57b3d Case #6 : Sample tunnel-mode ESP packet (ping -p ff -s 40 192.168.123.200) Key : 01234567 89abcdef 01234567 89abcdef SPI : 8765 Source address : 192.168.123.3 Destination address : 192.168.123.200 Sequence number : 5 IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22

SPI、シーケンス番号、IV：IPヘッダー：4500008C 09050000 4032F91E C0A87B03 C0A87BC8 SPI/SEQ＃：00008765 00000002 IV：F4E76524 4F6407AD F13DC138 0（96738 0（ 2638AA7B 05E71B54 9348082B 67B47B26 C565AED4 737F0BCB 439C0F00 73E7913C 3C8A3E4F 5F7A50622003B78ED 7CA54A08 C7CE047D 5BEC14E4 8CBA1005 32A12097 8D7F5503 204EF661 729B4EA1 AE6A9178 2.168.123.200）キー：01234567 89ABCDEF 01234567 89ABCDEF SPI：8765ソースアドレス：192.168。123.3宛先アドレス：192.168.123.200シーケンス番号：5 IV：85D47224 B5F3DD5D 2101D4EA 8DFFAB22

Original packet : IP header (20 bytes) : 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 Data (48 bytes) : 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

Augment data with : Padding : 01020304 05060708 090a Pad length : 0a Next header : 04 (IP-in-IP)

データの増強：パディング：01020304 05060708 090Aパッド長：0A次のヘッダー：04（IP-in-IP）

Pre-encryption Data with original IP header, padding, pad length and next header (80 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 01020304 05060708 090a0a04

Post-encryption packet with SPI, Sequence number, IV : IP header : 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI/Seq # : 00008765 00000005 IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22 Encrypted Data (80 bytes) : 311168e0 bc36ac4e 59802bd5 192c5734 8f3d29c8 90bab276 e9db4702 91f79ac7 79571929 c170f902 ffb2f08b d448f782 31671414 ff29b7e0 168e1c87 09ba2b67 a56e0fbc 4ff6a936 d859ed57 6c16ef1b

SPI、シーケンス番号、IV：IPヘッダー：4500007C 090D0000 4032F926 C0A87B03 C0A87BC8 SPI/SEQ＃：00008765 00000005 IV：85D47224 B5F3DD5D 2101D4EDED ANC（85D47222）（80101EA（85D47222）（85d47222）：85d4765 00000005 00000005 00000005 00000005 00000005 IV（ E0 BC36AC4E 59802BD5 192C5734 8F3D29C8 90BAB276 E9DB4702 91F79AC7 79571929 C170F902FFB2F08B D448F782 31671414 FF29B7E0 168E1C87 09BA2B67 A56E0FBC 4FF6A936 D859ED57 6C16EF1BB

5. Interaction with IKE

5. IKEとの相互作用

This section describes the use of IKE [IKE] to establish IPsec ESP security associations (SAs) that employ SEED in CBC mode.

このセクションでは、CBCモードで種子を使用するIPSEC ESPセキュリティ協会（SAS）を確立するためのIKE [IKE]の使用について説明します。

5.1. Phase 1 Identifier

5.1. フェーズ1識別子

For Phase 1 negotiations, the object identifier of SEED-CBC is defined in [SEED].

フェーズ1交渉の場合、種子CBCのオブジェクト識別子は[種子]で定義されます。

   algorithm OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410)
   kisa(200004) algorithm(1) }

   id-seedCBC OBJECT IDENTIFIER ::= { algorithm seedCBC(4) }

5.2. Phase 2 Identifier

5.2. フェーズ2識別子

For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of (21) for ESP_SEED_CBC.

フェーズ2の交渉のために、IANAはESP_SEED_CBCの（21）のESP変換識別子を割り当てました。

5.3. Key Length Attribute

5.3. キー長属性

Since the SEED supports 128-bit key lengths, the Key Length attribute is set with 128 bits.

シードは128ビットのキー長をサポートするため、キー長属性は128ビットで設定されます。

5.4. Hash Algorithm Considerations

5.4. ハッシュアルゴリズムの考慮事項

HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered of sufficient strength to serve both as IKE generators of 128-bit SEED keys and as ESP authenticators for SEED encryption using 128-bit keys.

HMAC-SHA-1 [HMAC-SHA]およびHMAC-MD5 [HMAC-MD5]は現在、128ビットシードキーのIKEジェネレーターとして、および128ビットキーを使用したシード暗号化のESP認証器の両方として機能するのに十分な強度があると考えられています。

6. Security Considerations

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

No security problem has been found on SEED. SEED is secure against all known attacks including Differential cryptanalysis, Linear cryptanalysis, and related key attacks. The best known attack is only an exhaustive search for the key (by [CRYPTREC]). For further security considerations, the reader is encouraged to read [CRYPTREC], [ISOSEED], and [SEED-EVAL].

種子にセキュリティの問題は見つかりませんでした。種子は、微分暗号化、線形暗号化、および関連する主要攻撃など、既知のすべての攻撃に対して安全です。最もよく知られている攻撃は、キー（[Cryptrec]による）の徹底的な検索にすぎません。さらなるセキュリティ上の考慮事項のために、読者は[Cryptrec]、[Isoseed]、および[Seed-Eval]を読むことをお勧めします。

7. IANA Considerations

7. IANAの考慮事項

IANA has assigned ESP Transform Identifier (21) to ESP_SEED_CBC.

IANAはESP変換識別子（21）をESP_SEED_CBCに割り当てました。

8. Acknowledgments

8. 謝辞

The authors want to thank Ph.D Haesuk Kim of Future Systems Inc. and Brian Kim of OULLIM Information Technology Inc. for providing expert advice on Test Vector examples.

著者は、Test Vectorの例に関する専門家のアドバイスを提供してくれたPh.D Haesuk Kim of Future Systems Inc.とBrian Kim of Oullim Information Technology Inc.に感謝したいと考えています。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.

[CBC] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。

[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。

[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[SEED] Park, J., Lee, S., Kim, J., and J. Lee, "The SEED Encryption Algorithm", RFC 4009, February 2005.

[Seed] Park、J.、Lee、S.、Kim、J。、およびJ. Lee、「The Seed Encryption Algorithm」、RFC 4009、2005年2月。

[TTASSEED] Telecommunications Technology Association (TTA), South Korea, "128-bit Symmetric Block Cipher (SEED)", TTAS.KO-12.0004, September, 1998 (In Korean) http://www.tta.or.kr/English/new/main/index.htm

[TTASSEED]韓国、テレコミュニケーションテクノロジー協会（TTA）、「128ビット対称ブロック暗号（シード）」、TTAS.KO-12.0004、1998年9月（韓国語）http：//www.tta.or.kr/英語/new/main/index.htm

9.2. Informative Reference

9.2. 有益なリファレンス

[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard(AES), November 2001. http://csrc.nist.gov/publications/fips/fips197/fips-197. {ps,pdf}

[AES] Nist、Fips Pub 197、「Advanced Encryption Standard（AES）、2001年11月。http：//csrc.nist.gov/publications/fips/fips197/fips-197。{ps、pdf}

[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[Arch] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。

[CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.

[Crypto-S] Schneier、B。、「Applied Cryptography Second Edition」、John Wiley＆Sons、New York、NY、1995、ISBN 0-471-12845-7。

[CRYPTREC] Information-technology Promotion Agency (IPA), Japan, CRYPTREC. "SEED Evaluation Report", February, 2002 http://www.kisa.or.kr/seed/seed_eng.html

[CRYPTREC]情報技術プロモーションエージェンシー（IPA）、日本、Cryptrec。「シード評価レポート」、2002年2月http://www.kisa.or.kr/seed/seed_eng.html

[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[HMAC-MD5] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-MD5-96の使用」、RFC 2403、1998年11月。

[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

[HMAC-SHA] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。

[ISOSEED] ISO/IEC JTC 1/SC 27 N3979, "IT Security techniques - Encryption Algorithms - Part3 : Block ciphers", June 2004.

[Isoseed] ISO/IEC JTC 1/SC 27 N3979、「ITセキュリティ手法 - 暗号化アルゴリズム-PART3：ブロック暗号」、2004年6月。

[MODES] Symmetric Key Block Cipher Modes of Operation, http://www.nist.gov/modes/.

[モード]対称キーブロック操作モード、http：//www.nist.gov/modes/。

[ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

[Road] Thayer、R.、N。DoraswamyおよびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。

[SEED-EVAL] KISA, "Self Evaluation Report", http://www.kisa.or.kr/seed/data/Document_pdf/ SEED_Self_Evaluation.pdf"

[Seed-Eval] Kisa、「自己評価レポート」、http：//www.kisa.or.kr/seed/data/document_pdf/ seed_self_evaluation.pdf "

Authors' Address

著者の住所

Hyangjin Lee Korea Information Security Agency Phone: +82-2-405-5446 Fax : +82-2-405-5319 EMail : jiinii@kisa.or.kr

Hyangjin leea韓国情報セキュリティ機関電話：82-2-405-5446ファックス：82-2-405-5319メール：jiinii@kisa.or.kr

Jaeho Yoon Korea Information Security Agency Phone: +82-2-405-5434 Fax : +82-2-405-5219 EMail : jhyoon@kisa.or.kr

Jaeho Yoon Korea Information Security Agency電話：82-2-405-5434 FAX：82-2-405-5219メール：jhyoon@kisa.or.kr

Seoklae Lee Korea Information Security Agency Phone: +82-2-405-5230 Fax : +82-2-405-5219 EMail : sllee@kisa.or.kr

seoklae leea韓国情報セキュリティ機関電話：82-2-405-5230ファックス：82-2-405-5219メール：sllee@kisa.or.kr

Jaeil Lee Korea Information Security Agency Phone: +82-2-405-5200 Fax : +82-2-405-5219 EMail: jilee@kisa.or.kr

Jaeil Lee韓国情報セキュリティエージェンシー電話：82-2-405-5200ファックス：82-2-405-5219メール：jilee@kisa.or.kr

Full Copyright Statement

完全な著作権声明

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。