ネットワーク WG
Request for Comments： 3602
分類：スタンダードトラック

S. Frankel
R. Glenn
NIST
S. Kelly
Airespace
2003年9月

AES-CBC暗号アルゴリズムとIPsecでのその使用法
(The AES-CBC Cipher Algorithm and Its Use with IPsec)

この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。このメモの配布に制限はない。

著作権表記

この文書では、IPsec暗号ペイロード(Encapsulating Security Payload：ESP)における機密性の仕組みとして、明示的初期ベクトル(Initialization Vector：IV)を伴う暗号ブロック連鎖(CBC)モードでのAES(Advanced Encryption Standard)暗号アルゴリズムの使用法について記述する。

1. はじめに
1. 1.1. 要求条件を指定する用語
2. AES 暗号アルゴリズム
3. ESP ペイロード
1. 3.1. ESPアルゴリズム相互作用
2. 3.2. 鍵素材
4. テストベクトル
5. IKE相互作用
6. セキュリティに関する考慮事項
7. IANAに関する考慮事項
8. 知的財産権表示
9. 参考文献
1. 9.1. 基準としている参考文献
2. 9.2. 基準としていない参考文献
10. 謝辞
11. 著者の連絡先
12. 著作権表示全文

4年に渡る選考の結果、NIST(National Institute of Standards and Technology)は、由緒あるDES (Data Encryption Standard)の後継であるAES (Advanced Encryption Standard)を選出した。選考会は開かれたものであり、その過程の各ステップにおいて、一般からの参加とコメントが求められた。そして、かつてはRijndaelとして知られていたAES [AES] が5つの最終候補の中から選出された。

AESの選考は、以下のいくつかの特性を基本として行われた。

セキュリティ
機密扱いではないこと
一般に公開されていること
世界中で特許権使用料が無料で利用できること
最低128ビットのブロックサイズを扱えること
最低、128ビット、192ビット、256ビットの鍵長を扱えること
スマートカードを含め、様々なソフトウェアおよびハードウェアにおける計算効率とメモリ要件
実装の柔軟性、単純性、そして、容易性

AESは、政府指定の暗号となるだろう。 AESは、最低でも次世紀までは、政府の取扱注意(機密扱いなし)情報を保護するのに十分であると予測される。また、それは、ビジネスや金融機関にも広く採用されると予測される。

IETF IPsecワーキンググループは、将来的にはAESをIPsec ESPのデフォルト暗号として採用し、仕様に適合したIPsec実装に含まれるMUSTのステータスにするつもりである。

この文書の残りの部分では、 IPsec ESPにおけるAESの使用法について定義する。セキュリティサービスを提供するために、 ESPの様々な要素がどのように適合しあうのかということへのさらなる情報については、 [ARCH]、[ESP]、そして、 [ROAD] を参照すること。

この文書において、しなければならない(MUST)、してはならない(MUST NOT)、要求される(REQUIRED)、することになる(SHALL)、することはない(SHALL NOT)、する必要がある(SHOULD)、しないほうがよい(SHOULD NOT)、推奨される(RECOMMENDED)、してもよい(MAY)、選択できる(OPTIONAL)のキーワードが使用された場合は、 [RFC-2119] における定義に沿って解釈されるものとする。

すべての対称ブロック暗号アルゴリズムは、モードや鍵長、脆弱鍵、ブロックサイズ、ラウンドなどの共通の特性と変数を持っている。この後に続く節では、AES 暗号に関係する特性について記述する。

NISTは、AESおよびその他のFIPSとして承認された暗号について、 5つの動作モード(CBC (Cipher Block Chaining)、ECB (Electronic CodeBook)、CFB (Cipher FeedBack)、OFB (Output FeedBack)、CTR (Counter))を定義した。 CBCモードは、対称暗号に対して十分に定義され、かつ、理解しやすいものであり、現在、他のすべてのESP暗号に対して要求されている。この文書では、 ESPにおけるCBCモードでのAES暗号の使用法について指定する。このモードでは、ブロックサイズと同じサイズの初期ベクトル(IV)を必要とする。ランダムに生成されたIVを使用することにより、暗号アルゴリズムのブロックサイズ分の最初のブロックに同一のデータを持つパケットから同一の暗号文を生成することを防ぐことができる。

IVは、暗号化される前の最初の平文ブロックとXORされる。そして、続くブロックに対しては、前の暗号文ブロックが、暗号化される前の現在の平文とXORされる。

CBCモードに関するさらなる情報は、 [MODES, CRYPTO-S] から得ることができる。 64ビット暗号を使用したESPにおけるCBCモードの使用法については、 [CBC] を見ること。

AESは、128ビット、192ビット、256ビットの3つの鍵長をサポートする。デフォルトの鍵長は128ビットであり、すべての実装は、この鍵長をサポートしなければならない(MUST)。実装は、 192ビットおよび256ビットの鍵長をサポートしてもよい(MAY)。

AESは、定義された鍵長のそれぞれに対して、異なるラウンド数を使用する。
128ビットの鍵が使用された場合、実装は10ラウンドを使用しなければならない(MUST)。
192ビットの鍵が使用された場合、実装は12ラウンドを使用しなければならない(MUST)。
256ビットの鍵が使用された場合、実装は14ラウンドを使用しなければならない(MUST)。

本文書執筆時点では、AESに対して既知の脆弱鍵は存在しない。

いくつかの暗号アルゴリズムは、脆弱鍵、または、その暗号定義のある状況との相互作用により使用されてはならない(MUST)鍵を持っている。もし、脆弱鍵がAESに対して発見された場合は、手動鍵管理を使用している場合は、脆弱鍵はチェックされ、破棄される必要がある(SHOULD)。 [IKE] のような動的鍵管理を使用している場合は、脆弱鍵のチェックは、意図したセキュリティを弱める可能性のある、不必要に付加された複雑なコードと見なされるため、実行しないほうがよい(SHOULD NOT)[EVALUATION]。

AESは、16オクテット(128 ビット)のブロックサイズを使用する。

パディングは、 AESにおいて16オクテット(128ビット)のブロックサイズを維持するために必要とされる。パディングは、暗号化されるデータ(ESPのパディング長フィールドおよび次ヘッダフィールドを含む)が16オクテットの倍数の長さを持つように、 [ESP] において指定されているように付加されなければならない(MUST)。

アルゴリズム特有のパディング要件により、暗号文が4オクテット境界で終了することを保証するために付加するパディングは必要ない(つまり、 16オクテットのブロックサイズが、 ESPのパディング長フィールドおよび次ヘッダフィールドを4オクテットワード内で正確に整列することを保証する)。 16オクテットのブロックサイズが維持されている限り、 [ESP] において指定されているように、付加的なパディングが含まれてもよい(MAY)。

AESは、Banksys/PWIのJoan DaemenとESAT-COSICのVincent Rijmen(ともにベルギー)によって発明され、世界中で無料で利用可能である。それは、特許で保護されておらず、Rijndaelのホームページには、「Rijndaelは無料で利用できる。それがAESとして採用されるかどうかに関わらず、あなたは、あなたが求めるどのような目的に対してもそれを利用することができる。」という声明がある。 AESの記述は [AES] で見つけることができる。 Rijndaelのホームページは、 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/である。

AESのホームページ(http://www.nist.gov/aes)には、 AESのアルゴリズム、性能統計、テストベクトル、知的財産情報についての信頼ある記述を含め、 AESに関する豊富な情報が含まれている。このサイトには、 NISTからのAESの参照実装の入手方法に関する情報も含まれている。

AESと他の暗号アルゴリズムのスピードの見積もりの比較表については、 [PERF-1]、[PERF-2]、 [PERF-3]、[PERF-4] を参照すること。 AESホームページには、その他の分析に対するポインタがある。

ESPペイロードは、IVにバイナリの暗号テキストが続くように構成される。そのため、 [ESP] で定義されているように、ペイロードフィールドは、次の図に従って分類される。

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

IVフィールドは、使用される暗号アルゴリズムのブロックサイズと同じ長さでなければならない(MUST)。 IVはランダムに選ばれなければならず(MUST)、予測不可能でなければならない(MUST)。

各データグラムにIVを含むことにより、一部のデータグラムがドロップした場合、あるいはデータグラムが配送中に再送要求された場合でも、各受信データグラムの復号処理が可能となる。

異なるパケットの非常に似通った平文ブロックのCBC暗号化を避けるため、実装では、 IVにカウンタまたはその他のロウハミングディスタンスソースを使用してはならない(MUST NOT)。

現在、AESと、ある種の認証スキームの使用のような、 ESPの他の側面との間の相互作用に関して、既知の問題は存在しない。

鍵交換プロトコルからESPアルゴリズムに送られる最小ビット数は、鍵長以上でなければならない。

暗号化および復号化用の鍵は、鍵素材の最初の<x>ビット分(<x>は必要な鍵長をあらわす)から取得される。

最初の4つのテストケースは、AES-CBCの暗号化をテストするものである。各テストケースには、鍵、平文、そして、結果として生じる暗号文が含まれている。鍵およびデータの値は、 16進数表記(最初に"0x"が付く)またはASCII文字列(ダブルクォーテーションでくくられている)のいずれかである。値がASCII文字列である場合は、該当するテストケースにおけるAES-CBC計算では、文字列の最後のNULL文字('\0')は含めない(DOES NOT)。計算された暗号文は、すべて16進数表記である。

最後の4つのテストケースは、 AES-CBCを使用して暗号化したESPパケットの例を示したものである。すべてのデータは16進数表記である(最初に"0x"は付かない)。

これらのテストケースは、 2つの独立した実装(NIST AES-CBC参照実装、および、 Rijndaelアルゴリズムの著者によって提供された実装(http://csrc.nist.gov/encryption/aes/rijndael/rijndael-unix-refc.tar))によって検証された。

ケース #1：16バイト(1ブロック)を128ビットの鍵でAES-CBCを使用して暗号化
鍵：0x06a9214036b8a15b512e03d534120006
IV ：0x3dafba429d9eb430b422da802c9fac41
平文："Single block msg"
暗号文：0xe353779c1079aeb82708942dbe77181a

ケース #2：32バイト(2ブロック)を128ビットの鍵でAES-CBCを使用して暗号化
鍵：0xc286696d887c9aa0611bbb3e2025a45a
IV ：0x562e17996d093d28ddb3ba695a2e6f58
平文：0x000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f
暗号文：0xd296cd94c2cccf8a3a863028b5e1dc0a 7586602d253cfff91b8266bea6d61ab1

ケース #3：48バイト(3ブロック)を128ビットの鍵でAES-CBCを使用して暗号化
鍵：0x6c3ea0477630ce21a2ce334aa746c2cd
IV ：0xc782dc4c098c66cbd9cd27d825682c81
平文："This is a 48-byte message (exactly 3 AES blocks)"
暗号文：0xd0a02b3836451753d493665d33f0e886 2dea54cdb293abc7506939276772f8d5 021c19216bad525c8579695d83ba2684

ケース #4：64バイト(4ブロック)を128ビットの鍵でAES-CBCを使用して暗号化
鍵：0x56e47a38c5598974bc46903dba290349
IV ：0x8ce82eefbea0da3c44699ed7db51b7d9
平文：0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf b0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
暗号文：0xc30e32ffedc0774e6aff6af0869f71aa 0f3af07a9a31a9c684db207eb0ef8e4e 35907aa632c3ffdf868bb7b29d3d46ad 83ce9f9a102ee99d49a53e87f4c3da55

ケース #5：トランスポートモードESPパケットの例(ping 192.168.123.100)
鍵：90d382b4 10eeba7a d938c46c ec1a82bf
SPI：4321
送信元アドレス：192.168.123.3
宛先アドレス：192.168.123.100
シーケンス番号：1
IV：e96e8c08 ab465763 fd098d45 dd3ff893

オリジナルパケット：
IPヘッダ(20バイト)：45000054 08f20000 4001f9fe c0a87b03 c0a87b64
データ(64バイト)：
08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

増加データ：
パディング：01020304 05060708 090a0b0c 0d0e
パディング長：0e
次ヘッダ：01(ICMP)

パディング、パディング長、次ヘッダを伴った暗号化前のデータ(80バイト)：
08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01

SPI、シーケンス番号、IVを伴った暗号化後のパケット：
IPヘッダ：4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64
SPI/シーケンス番号：00004321 00000001
IV：e96e8c08 ab465763 fd098d45 dd3ff893
暗号化後のデータ(80バイト)：
f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a a269add0 47ad2d59 13ac19b7 cfbad4a6

ケース #6：トランスポートモードESPパケットの例(ping -p 77 -s 20 192.168.123.100)
鍵：90d382b4 10eeba7a d938c46c ec1a82bf
SPI：4321
送信元アドレス：192.168.123.3
宛先アドレス：192.168.123.100
シーケンス番号：8
IV：69d08df7 d203329d b093fc49 24e5bd80

オリジナルパケット：
IP ヘッダ(20バイト)：45000030 08fe0000 4001fa16 c0a87b03 c0a87b64
データ(28バイト)：
0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

増加データ：
パディング：0102
パディング長：02
次ヘッダ：01(ICMP)

パディング、パディング長、次ヘッダを伴った暗号化前のデータ(32バイト)：
0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201

SPI、シーケンス番号、IVを伴った暗号化後のパケット：
IPヘッダ：4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64
SPI/シーケンス番号：00004321 00000008
IV：69d08df7 d203329d b093fc49 24e5bd80
暗号化後のデータ(32バイト)：
f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75

ケース #7：トンネルモードESPパケットの例(ping 192.168.123.200)
鍵：01234567 89abcdef 01234567 89abcdef
SPI：8765
送信元アドレス：192.168.123.3
宛先アドレス：192.168.123.200
シーケンス番号：2
IV：f4e76524 4f6407ad f13dc138 0f673f37

オリジナルパケット：
IPヘッダ(20バイト)：45000054 09040000 4001f988 c0a87b03 c0a87bc8
データ(64バイト)：
08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

増加データ：
パディング：01020304 05060708 090a
パディング長：0a
次ヘッダ：04(IP-in-IP)

オリジナルのIPヘッダ、パディング、パディング長、次ヘッダを伴った暗号化前のデータ(96バイト)：
45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04

SPI、シーケンス番号、IVを伴った暗号化後のパケット：
IPヘッダ：4500008c 09050000 4032f91e c0a87b03 c0a87bc8
SPI/シーケンス番号：00008765 00000002
IV：f4e76524 4f6407ad f13dc138 0f673f37
暗号化後のデータ(96バイト)：
773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8 e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5 c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d

ケース #8：トンネルモードESPパケットの例(ping -p ff -s 40 192.168.123.200)
鍵：01234567 89abcdef 01234567 89abcdef
SPI：8765
送信元アドレス：192.168.123.3
宛先アドレス：192.168.123.200
シーケンス番号：5
IV：85d47224 b5f3dd5d 2101d4ea 8dffab22

オリジナルパケット：
IPヘッダ(20バイト)：45000044 090c0000 4001f990 c0a87b03 c0a87bc8
データ(48バイト)：
0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

増加データ：
パディング：01020304 05060708 090a
パディング長：0a
次ヘッダ：04(IP-in-IP)

オリジナルのIPヘッダ、パディング、パディング長、次ヘッダを伴った暗号化前のデータ(80バイト)：
45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 01020304 05060708 090a0a04

SPI、シーケンス番号、IVを伴った暗号化後のパケット：
IPヘッダ：4500007c 090d0000 4032f926 c0a87b03 c0a87bc8
SPI/シーケンス番号：00008765 00000005
IV：85d47224 b5f3dd5d 2101d4ea 8dffab22
暗号化後のデータ(80バイト)：
15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3 d2726d9b 5ef6affc 6d17a0de cbb13892

フェーズ1折衝のために、IANAは、暗号化アルゴリズムID 7をAEC-CBCに割り当てた。

フェーズ2折衝のために、IANAは、 ESPトランスフォームID 12をESP_AESに割り当てた。

AESは、可変長の鍵を許可するため、鍵長属性は、フェーズ1交換 [IKE] とフェーズ2交換 [DOI] の両方で指定されなければならない(MUST)。

最近、広く使用されているハッシュアルゴリズムであるSHA-1の後継を選出するためのもう一方の選考会が終了した。選出されたSHA-256、SHA-384、SHA-512 [SHA2-1, SHA2-2] と呼ばれるハッシュは、 3つのAESの鍵長(128、192、 256ビット)の(IKEでの)生成および(ESPでの)認証に十分な3つの異なる長さの出力(256、 384、512 ビット)を生成することができる。

しかしながら、 HMAC-SHA-1 [HMAC-SHA] およびHMAC-MD5 [HMAC-MD5] は、現在、 128ビットのAES鍵のIKE生成子として、そして、 128ビットの鍵を使用したAES暗号化のためのESP認証子として、十分な強度を提供すると考えられている。

特定のハードウェアおよびソフトウェアの設定に対して性能を考慮した場合、実装は、可能な限り最大の鍵長を使用することが推奨される。暗号化は、必然的にセキュアチャネルの両側に影響を及ぼすということに注意すること。そのため、このような考慮はクライアント側だけでなく、サーバ側に対してもなされなければならない。しかしながら、128ビットの鍵長は、近い将来に対しては安全であると考えられている。

ランダムなIV値の使用の必要性に関するさらなる情報については、 [CRYPTO-B] を参照すること。

さらなるセキュリティに関する考察については、読者は [AES] を読むことを推奨する。

IANAは、暗号化アルゴリズムID 7をAEC-CBCに割り当てた。 IANAは、ESPトランスフォームID 12をESP_AESに割り当てた。

この文書に記述される技術の実装および使用に関係すると主張される、知的財産権およびその他の権利の有効性または範囲に関して、またこのような権利の下でのあらゆる権利が効力を持つ範囲に関して、 IETFはいかなる立場もとらず、また、 IETFはそのような権利を確認するためのいかなる取り組みを行ったことも表明しない。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きは、 BCP-11で見ることができる。出版を目的に利用可能な権利主張のコピーおよび利用可能となるライセンス保証のコピー、あるいは、この仕様の実装者やユーザによる所有権の使用に対する一般的な権利や許可を得るために行われた試みの結果は、 IETF事務局から入手可能である。

IETFは、どのような利害関係者に対しても、この標準を実行するために必要な技術をカバーする著作権や特許、特許出願、その他の所有権に対して注意を払うように依頼する。どうかIETFのExecutive Directorに情報を伝えてください。

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

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

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

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

[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997. http://www.research.att.com/~smb/papers/probtxt.pdf

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

[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[EVALUATION] Ferguson, N. and B. Schneier, "A Cryptographic Evaluation of IPsec," Counterpane Internet Security, Inc., January 2000. http://www.counterpane.com/ipsec.pdf

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

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

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

[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

[PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C Implementations of Round1 Candidate Algorithms for the Advanced Encryption Standard." http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf

[PERF-2] Lipmaa, Helger, "AES/Rijndael: speed." http://www.tcs.hut.fi/~helger/aes/rijndael.html

[PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J. Foti and E. Roback, "Status Report on the First Round of the Development of the Advanced Encryption Standard." http://csrc.nist.gov/encryption/aes/round1/r1report.pdf

[PERF-4] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions." http://www.counterpane.com/aes-performance.pdf

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

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

[SHA2-1] NIST, FIPS PUB 180-2 "Specifications for the Secure Hash Standard," August 2002. http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

[SHA2-2] "Descriptions of SHA-256, SHA-384, and SHA-512." http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf

この文章のある部分は、全体的な文書構造と同様に、厚かましくも [CBC] から拝借させていただいた。

著者はHilarie Ormanに、鍵長、Diffie-Hellmanグループ用の必要条件、および、IKE相互作用における専門的な助言(そしてサニティチェック(sanity check))を与えてくれたことに対して感謝したい。さらに、私たちは、有用なコメントおよび薦めに対して、 Scott Fluhrer

Sheila Frankel
NIST
820 West Diamond Ave.
Room 677
Gaithersburg, MD 20899

電話： +1 (301) 975-3297
EMail： sheila.frankel＠nist.gov

Scott Kelly
Airespace
110 Nortech Pkwy
San Jose CA 95134

電話： +1 408 635 2000
EMail： scott＠hyperthought.com

Rob Glenn
NIST
820 West Diamond Ave.
Room 605
Gaithersburg, MD 20899

電話： +1 (301) 975-3667
EMail： rob.glenn＠nist.gov

翻訳者のアドレス

株式会社 NTTデータ
技術開発本部
馬場達也

EMail： babatt＠nttdata.co.jp

本文書とその翻訳は、複製および他に提供することができる。また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、 RFCを英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよびIETFはすべての保証を明示的にも暗黙的にもおこなわない。その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。

謝辞

現在、RFCエディタの機能に対する資金は、インターネットソサエティによって提供されている。

AES-CBC暗号アルゴリズムとIPsecでのその使用法
(The AES-CBC Cipher Algorithm and Its Use with IPsec)

このメモの位置付け

著作権表記

要旨

目次

1. はじめに

1.1. 要求条件を指定する用語

2. AES暗号アルゴリズム

2.1. モード

2.2. 鍵長とラウンド数

2.3. 脆弱鍵

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

2.5. 付加情報

2.6. 性能

3. ESP ペイロード

3.1. ESPアルゴリズム相互作用

3.2. 鍵素材

4. テストベクトル

5. IKE相互作用

5.1. フェーズ1識別子

5.2. フェーズ 2 識別子

5.3. 鍵長属性

5.4. ハッシュアルゴリズムに関する考慮事項

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

7. IANAに関する考慮事項

8. 知的財産権表示

9. 参考文献

9.1. 基準としている参考文献

9.2. 基準としていない参考文献

10. 謝辞

11. 著者のアドレス

12. 著作権表示全文

謝辞

AES-CBC暗号アルゴリズムとIPsecでのその使用法 (The AES-CBC Cipher Algorithm and Its Use with IPsec)

このメモの位置付け

著作権表記

要旨

目次

1. はじめに

1.1. 要求条件を指定する用語

2. AES暗号アルゴリズム

2.1. モード

2.2. 鍵長とラウンド数

2.3. 脆弱鍵

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

2.5. 付加情報

2.6. 性能

3. ESP ペイロード

3.1. ESPアルゴリズム相互作用

3.2. 鍵素材

4. テストベクトル

5. IKE相互作用

5.1. フェーズ1識別子

5.2. フェーズ 2 識別子

5.3. 鍵長属性

5.4. ハッシュアルゴリズムに関する考慮事項

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

7. IANAに関する考慮事項

8. 知的財産権表示

9. 参考文献

9.1. 基準としている参考文献

9.2. 基準としていない参考文献

10. 謝辞

11. 著者のアドレス

12. 著作権表示全文

謝辞

AES-CBC暗号アルゴリズムとIPsecでのその使用法
(The AES-CBC Cipher Algorithm and Its Use with IPsec)