RFC3602 日本語訳
3602 The AES-CBC Cipher Algorithm and Its Use with IPsec. S. Frankel,R. Glenn, S. Kelly. September 2003. (Format: TXT=30254 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Frankel
Request for Comments: 3602 R. Glenn
Category: Standards Track NIST
S. Kelly
Airespace
September 2003
コメントを求めるワーキンググループS.フランケル要求をネットワークでつないでください: 3602年のR.グレンカテゴリ: 標準化過程NIST S.ケリーAirespace2003年9月
The AES-CBC Cipher Algorithm and Its Use with IPsec
AES-CBC暗号アルゴリズムとIPsecとのその使用
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).
このドキュメントはCipher Block Chaining(CBC)モードにおけるエー・イー・エス(AES)暗号Algorithmの使用について説明します、明白な初期設定Vector(IV)と共に、IPsec Encapsulating Security有効搭載量(超能力)の文脈の中の秘密性メカニズムとして。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
2. The AES Cipher Algorithm . . . . . . . . . . . . . . . . . . . 3
2.1. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Key Size and Number of Rounds. . . . . . . . . . . . . . 4
2.3. Weak Keys. . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Block Size and Padding . . . . . . . . . . . . . . . . . 4
2.5. Additional Information . . . . . . . . . . . . . . . . . 4
2.6. Performance. . . . . . . . . . . . . . . . . . . . . . . 5
3. ESP Payload . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ESP Algorithmic Interactions . . . . . . . . . . . . . . 6
3.2. Keying Material. . . . . . . . . . . . . . . . . . . . . 6
4. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IKE Interactions . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . 10
5.2. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . 10
5.3. Key Length Attribute . . . . . . . . . . . . . . . . . . 10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 要件の仕様。 . . . . . . . . . . . . . 3 2. AESはアルゴリズム. . . . . . . . . . . . . . . . . . . 3 2.1を解きます。 モード. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2。 主要なサイズと数のラウンド。 . . . . . . . . . . . . . 4 2.3. 弱いキー。 . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. サイズと詰め物. . . . . . . . . . . . . . . . . 4 2.5を妨げてください。 追加情報. . . . . . . . . . . . . . . . . 4 2.6。 パフォーマンス。 . . . . . . . . . . . . . . . . . . . . . . 5 3. 超能力有効搭載量. . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1。 超能力のアルゴリズムの相互作用. . . . . . . . . . . . . . 6 3.2。 材料を合わせます。 . . . . . . . . . . . . . . . . . . . . 6 4. ベクトル. . . . . . . . . . . . . . . . . . . . . . . . . 6 5をテストしてください。 IKE相互作用. . . . . . . . . . . . . . . . . . . . . . . 10 5.1。 1つの識別子. . . . . . . . . . . . . . . . . . . 10 5.2の位相を合わせてください。 2識別子. . . . . . . . . . . . . . . . . . . 10 5.3の位相を合わせてください。 キー長属性. . . . . . . . . . . . . . . . . . 10
Frankel, et al. Standards Track [Page 1] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[1ページ]。
5.4. Hash Algorithm Considerations. . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Intellectual Property Rights Statement . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
5.4. アルゴリズム問題を論じ尽くしてください。 . . . . . . . . . . . . . 10 6. セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 11 8。 知的所有権は声明. . . . . . . . . . . . 11 9を正します。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1。 引用規格. . . . . . . . . . . . . . . . . . 12 9.2。 有益な参照. . . . . . . . . . . . . . . . . 12 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 13 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 14 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 序論
As the culmination of a four-year competitive process, NIST (the National Institute of Standards and Technology) has selected the AES (Advanced Encryption Standard), the successor to the venerable DES (Data Encryption Standard). The competition was an open one, with public participation and comment solicited at each step of the process. The AES [AES], formerly known as Rijndael, was chosen from a field of five finalists.
4年の競争力がある過程の頂点として、NIST(米国商務省標準技術局)はAES(エー・イー・エス)(立派なDES(データ暗号化規格)の後継者)を選定しました。 競争は公共の参加とコメントが過程の各ステップで請求されている開いているものでした。 以前ラインダールとして知られているAES[AES]は5人の決勝戦出場者の分野から選ばれました。
The AES selection was made on the basis of several characteristics:
いくつかの特性に基づいてAES選択をしました:
+ security
+ セキュリティ
+ unclassified
非分類された+
+ publicly disclosed
公的に明らかにされた+
+ available royalty-free, worldwide
利用可能な+、ロイヤリティのいらなく、世界中。
+ capable of handling a block size of at least 128 bits
+、少なくとも128ビットのブロック・サイズを扱うことができます。
+ at a minimum, capable of handling key sizes of 128, 192, and
256 bits
+ 128、192、および256ビットの取り扱いキーサイズができる最小限で
+ computational efficiency and memory requirements on a variety
of software and hardware, including smart cards
+ スマートカードを含むさまざまなソフトウェアとハードウェアに関する計算効率とメモリ要件
+ flexibility, simplicity and ease of implementation
+ 柔軟性、簡単さ、および実現の容易さ
The AES will be the government's designated encryption cipher. The expectation is that the AES will suffice to protect sensitive (unclassified) government information until at least the next century. It is also expected to be widely adopted by businesses and financial institutions.
AESは政府の指定された暗号化暗号になるでしょう。 期待はAESが少なくとも次の世紀まで機密(非分類される)の政府情報を保護するために十分であるということです。 また、それはビジネスと金融機関によって広く採用されると予想されます。
Frankel, et al. Standards Track [Page 2] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[2ページ]。
It is the intention of the IETF IPsec Working Group that AES will eventually be adopted as the default IPsec ESP cipher and will obtain the status of MUST be included in compliant IPsec implementations.
それは対応するIPsec実現に超能力が解いて、状態を得るデフォルトIPsecを含まなければならないときAESが結局採用されるというIETF IPsec作業部会の意志です。
The remainder of this document specifies the use of the AES within the context of IPsec ESP. For further information on how the various pieces of ESP fit together to provide security services, refer to [ARCH], [ESP], and [ROAD].
このドキュメントの残りはIPsecの文脈の中でAESの使用を指定します。超能力。 超能力の様々な断片がセキュリティー・サービスを提供するためにどう一緒に合うかに関する詳細について、[ARCH]、[超能力]、および[ROAD]を参照してください。
1.1. Specification of Requirements
1.1. 要件の仕様
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 「5月」、「任意」は「推薦され」て、現れる中[RFC-2119]で説明されるように本書では解釈しないべきであることですか?
2. The AES Cipher Algorithm
2. AES暗号アルゴリズム
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 the AES cipher.
すべての左右対称のブロック暗号アルゴリズムがモード、主要なサイズ、弱いキー、ブロック・サイズ、およびラウンドを含む共通する特徴と変数を共有します。 以下のセクションはAES暗号の関連特性の記述を含みます。
2.1. Mode
2.1. モード
NIST has defined 5 modes of operation for 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 AES cipher in 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 which have identical data that spans the first block of the cipher algorithm's block size.
NISTはAESと他のFIPSによって承認された暗号[MODES]のために5つの運転モードを定義しました: CBC(暗号ブロック連鎖)、ECB(電子符号表)、CFB(暗号フィードバック)、OFB(出力フィードバック)、およびCTR(カウンタ)。 CBCモードが、明確であり、左右対称の暗号のためによく分かって、現在、他のすべての超能力暗号に必要です。 このドキュメントは超能力の中でCBCモードにおけるAES暗号の使用を指定します。 このモードはブロック・サイズと同じサイズである初期設定Vector(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によるXORがそれの前の最初の平文ブロックでコード化されたということです。 連続したブロック、前の暗号文ブロックがXORであるので、それがコード化されている前に、その時は現在の平文でそうするでしょう。
More information on CBC mode can be obtained in [MODES, CRYPTO-S]. For the use of CBC mode in ESP with 64-bit ciphers, see [CBC].
[MODES、CRYPTO-S]でCBCモードに関する詳しい情報を得ることができます。 64ビットの暗号がある超能力におけるCBCモードの使用に関しては、[CBC]を見てください。
Frankel, et al. Standards Track [Page 3] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[3ページ]。
2.2. Key Size and Number of Rounds
2.2. 主要なサイズと数のラウンド
AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The default key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
AESは3つの主要なサイズを支持します: 128ビット、192ビット、および256ビット。 デフォルトキーサイズは128ビットです、そして、すべての実現がこの主要なサイズを支持しなければなりません。 また、実現は192ビットと256ビットの主要なサイズを支持するかもしれません。
AES uses a different number of rounds for each of the defined key sizes. When a 128-bit key is used, implementations MUST use 10 rounds. When a 192-bit key is used, implementations MUST use 12 rounds. When a 256-bit key is used, implementations MUST use 14 rounds.
AESはそれぞれの定義された主要なサイズに異なった数のラウンドを使用します。 128ビットのキーが使用されているとき、実現は10ラウンドを使用しなければなりません。 192ビットのキーが使用されているとき、実現は12ラウンドを使用しなければなりません。 256ビットのキーが使用されているとき、実現は14ラウンドを使用しなければなりません。
2.3. Weak Keys
2.3. 弱いキー
At the time of writing this document there are no known weak keys for the AES.
このドキュメントを書く時点で、どんな知られているAESに、弱いキーもありません。
Some cipher algorithms have weak keys or keys that MUST not be used due to their interaction with some aspect of the cipher's definition. If weak keys are discovered for the AES, then weak keys SHOULD be checked for and discarded when using manual key management. When using dynamic key management, such as [IKE], weak key checks SHOULD NOT be performed as they are seen as an unnecessary added code complexity that could weaken the intended security [EVALUATION].
いくつかの暗号アルゴリズムが暗号の定義の何らかの局面とのそれらの相互作用のため使用してはいけない弱いキーかキーを持っています。 手動のかぎ管理を使用するとき、チェックで捨てられて、弱いキーがAESの、そして、次に、弱いキーSHOULDに関して発見されるなら。 弱者が[IKE]などのように合わせるダイナミックなかぎ管理を使用するとSHOULD NOTがチェックするときには、彼らが意図しているセキュリティを弱めることができた不要な加えられたコードの複雑さと考えられるので[EVALUATION]、実行されてください。
2.4. Block Size and Padding
2.4. ブロック・サイズと詰め物
The AES uses a block size of sixteen octets (128 bits).
AESは16の八重奏(128ビット)のブロック・サイズを使用します。
Padding is required by the AES 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ビット)がblocksizeされると主張するためにAESによって必要とされます。 詰め物を加えなければなりません、[超能力]で指定されるように、コード化されるべきデータ(超能力Pad LengthとNext Header分野を含んでいる)には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八重奏が超能力Pad LengthとNext Header分野が正しくなるという保証をblocksizeすると主張するのが4八重奏の単語の中に並びました)。 [超能力]で指定されるように16八重奏がblocksizeされるとき長さが維持されるように含まれていて、追加詰め物はそうするかもしれません。
2.5. Additional Information
2.5. 追加情報
AES was invented by Joan Daemen from Banksys/PWI and Vincent Rijmen from ESAT-COSIC, both in Belgium, and is available world-wide on a royalty-free basis. It is not covered by any patents, and the Rijndael homepage contains the following statement: "Rijndael is
AESはともにベルギーでジョーンDaemenによってBanksys/PWIとヴィンセントRijmenからESAT-チョシッチから発明されて、世界中でロイヤリティのいらないベースで入手できます。 それはどんな特許でも覆われていません、そして、ラインダールホームページは以下の声明を含んでいます: 「ラインダールはそうです」
Frankel, et al. Standards Track [Page 4] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[4ページ]。
available for free. You can use it for whatever purposes you want, irrespective of whether it is accepted as AES or not." AES's description can be found in [AES]. The Rijndael homepage is: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/.
ただで利用可能です。 「あなたはそれがAESとして認められるかどうかの如何にかかわらず欲しいどんな目的にもそれを使用できます。」 [AES]でAESの記述を見つけることができます。 ラインダールホームページは以下の通りです。 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/ 。
The AES homepage, http://www.nist.gov/aes, contains a wealth of information about the AES, including a definitive description of the AES algorithm, performance statistics, test vectors and intellectual property information. This site also contains information on how to obtain an AES reference implementation from NIST.
AESホームページ( http://www.nist.gov/aes )はAESの豊富な情報を含んでいます、AESアルゴリズム、性能統計、テストベクトル、および知的所有権情報の決定的な記述を含んでいて。 また、このサイトはNISTからAES参照実現をどう得るかの情報を含んでいます。
2.6. Performance
2.6. パフォーマンス
For a comparison table of the estimated speeds of AES and other cipher algorithms, please see [PERF-1], [PERF-2], [PERF-3], or [PERF-4]. The AES homepage has pointers to other analyses.
AESと他の暗号アルゴリズムのおよそ速度の比較テーブルに関しては、[PERF-1]、[PERF-2]、[PERF-3]、または[PERF-4]を見てください。 AESホームページは他の分析にポインタを持っています。
3. ESP Payload
3. 超能力有効搭載量
The ESP payload is made up of the IV followed by raw cipher-text. Thus the payload field, as defined in [ESP], is broken down according to the following diagram:
超能力ペイロードは生の暗号文があとに続いたIVで作られます。 以下のダイヤグラムによると、したがって[超能力]で定義されるペイロード分野は砕けています:
+---------------+---------------+---------------+---------------+ | | + Initialization Vector (16 octets) + | | +---------------+---------------+---------------+---------------+ | | ~ Encrypted Payload (variable length, a multiple of 16 octets) ~ | | +---------------------------------------------------------------+
+---------------+---------------+---------------+---------------+ | | + 初期設定Vector(16の八重奏)+| | +---------------+---------------+---------------+---------------+ | | ~ コード化された有効搭載量(可変長、16の八重奏の倍数)~| | +---------------------------------------------------------------+
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 datagrams are 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暗号化を避けるために、実現はIVsにカウンタか他の低いハミング距離ソースを使用してはいけません。
Frankel, et al. Standards Track [Page 5] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[5ページ]。
3.1. ESP Algorithmic Interactions
3.1. 超能力のアルゴリズムの相互作用
Currently, there are no known issues regarding interactions between the AES and other aspects of ESP, such as use of certain authentication schemes.
現在、AESの間の相互作用に関する問題と超能力の他の局面は知られていません、ある認証計画の使用などのように。
3.2. Keying Material
3.2. 材料を合わせます。
The minimum number of bits sent from the key exchange protocol to the ESP algorithm must be greater than or equal to the key size.
主要な交換プロトコルから超能力アルゴリズムに送られた最小の数のビットはそう以上であるに違いありません。主要なサイズ。
The cipher's encryption and decryption key is taken from the first <x> bits of the keying material, where <x> represents the required key size.
合わせることの材料の最初の<x>かけらから暗号の暗号化と復号化キーを取ります。(そこでは、<x>が必要な主要なサイズを表します)。
4. Test Vectors
4. テストベクトル
The first 4 test cases test AES-CBC encryption. Each test case
includes the key, the plaintext, and the resulting ciphertext. The
values of keys and data are either hexadecimal numbers (prefixed by
"0x") or ASCII character strings (surrounded by double quotes). If a
value is an ASCII character string, then the AES-CBC computation for
the corresponding test case DOES NOT include the trailing null
character ('%%BODY%%') of the string. The computed cyphertext values are
all hexadecimal numbers.
最初の4つのテストケースがAES-CBC暗号化をテストします。 各テストケースはキー、平文、および結果として起こる暗号文を含んでいます。 キーとデータの値は、16進数("0x"によって前に置かれている)かASCII文字列(二重引用符で、囲まれる)のどちらかです。 値がASCII文字列であるなら、そして、DOES NOTが引きずっているヌル文字('0円')含むストリングの対応するテストケースのためにAES-CBC計算します。 計算されたcyphertext値はすべて16進数です。
The last 4 test cases illustrate sample ESP packets using AES-CBC for encryption. All data are hexadecimal numbers (not prefixed by "0x").
ベスト4テストケースは、暗号化にAES-CBCを使用することでサンプル超能力パケットを例証します。 すべてのデータが16進数("0x"によって前に置かれていない)です。
These test cases were verified using 2 independent implementations:
the NIST AES-CBC reference implementation and an implementation
provided by the authors of the Rijndael algorithm
(http://csrc.nist.gov/encryption/aes/rijndael/
rijndael-unix-refc.tar).
これらのテストケースは2つの独立している実現を使用することで確かめられました: ラインダールアルゴリズム( http://csrc.nist.gov/encryption/aes/rijndael/ rijndael unix refc.tar)の作者によって提供されたNIST AES-CBC参照実現と実現。
Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key Key : 0x06a9214036b8a15b512e03d534120006 IV : 0x3dafba429d9eb430b422da802c9fac41 Plaintext : "Single block msg" Ciphertext: 0xe353779c1079aeb82708942dbe77181a
#1、をケースに入れてください: 128ビットの主要なKeyとAES-CBCを使用することで16バイト(1ブロック)をコード化します: 0x06a9214036b8a15b512e03d534120006IV: 0x3dafba429d9eb430b422da802c9fac41平文: 「単滑車msg」Ciphertext: 0xe353779c1079aeb82708942dbe77181a
Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
Key : 0xc286696d887c9aa0611bbb3e2025a45a
IV : 0x562e17996d093d28ddb3ba695a2e6f58
Plaintext : 0x000102030405060708090a0b0c0d0e0f
101112131415161718191a1b1c1d1e1f
Ciphertext: 0xd296cd94c2cccf8a3a863028b5e1dc0a
7586602d253cfff91b8266bea6d61ab1
#2、をケースに入れてください: 128ビットの主要なKeyとAES-CBCを使用することで32バイト(2ブロック)をコード化します: 0xc286696d887c9aa0611bbb3e2025a45a IV: 0x562e17996d093d28ddb3ba695a2e6f58平文: 0x000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f暗号文: 0xd296cd94c2cccf8a3a863028b5e1dc0a 7586602d253cfff91b8266bea6d61ab1
Frankel, et al. Standards Track [Page 6] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[6ページ]。
Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key
Key : 0x6c3ea0477630ce21a2ce334aa746c2cd
IV : 0xc782dc4c098c66cbd9cd27d825682c81
Plaintext : "This is a 48-byte message (exactly 3 AES blocks)"
Ciphertext: 0xd0a02b3836451753d493665d33f0e886
2dea54cdb293abc7506939276772f8d5
021c19216bad525c8579695d83ba2684
#3、をケースに入れてください: 128ビットの主要なKeyとAES-CBCを使用することで48バイト(3ブロック)をコード化します: 0x6c3ea0477630ce21a2ce334aa746c2cd IV: 0xc782dc4c098c66cbd9cd27d825682c81平文: 「これは48バイトのメッセージ(ちょうど3つのAESブロック)です」Ciphertext: 0xd0a02b3836451753d493665d33f0e886 2dea54cdb293abc7506939276772f8d5 021c19216bad525c8579695d83ba2684
Case #4: Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key
Key : 0x56e47a38c5598974bc46903dba290349
IV : 0x8ce82eefbea0da3c44699ed7db51b7d9
Plaintext : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf
b0b1b2b3b4b5b6b7b8b9babbbcbdbebf
c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
Ciphertext: 0xc30e32ffedc0774e6aff6af0869f71aa
0f3af07a9a31a9c684db207eb0ef8e4e
35907aa632c3ffdf868bb7b29d3d46ad
83ce9f9a102ee99d49a53e87f4c3da55
#4、をケースに入れてください: 128ビットの主要なKeyとAES-CBCを使用することで64バイト(4ブロック)をコード化します: 0x56e47a38c5598974bc46903dba290349IV: 0x8ce82eefbea0da3c44699ed7db51b7d9平文: 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf b0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf Ciphertext: 0xc30e32ffedc0774e6aff6af0869f71aa 0f3af07a9a31a9c684db207eb0ef8e4e35907aa632c3ffdf868bb7b29d3d46ad 83ce9f9a102ee99d49a53e87f4c3da55
Case #5: 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
#5、をケースに入れてください: 交通機関超能力パケットを抽出してください。(192.168.123.100)キーを確認してください: 90d382b4 10eeba7a d938c46c ec1a82bf SPI: 4321年のソースアドレス: 192.168.123.3 送付先アドレス: 192.168.123.100 一連番号: 1、IV: e96e8c08 ab465763 fd098d45 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 Data(64バイト): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 34353637
Augment data with: Padding: 01020304 05060708 090a0b0c 0d0e Pad length: 0e Next header: 01 (ICMP)
以下でデータを増大させてください。 詰め物: 01020304 05060708 090a0b0c 0d0e Padの長さ: 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
詰め物があるプレ暗号化Data、パッドの長さ、および次のヘッダー(80バイト): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01
Frankel, et al. Standards Track [Page 7] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[7ページ]。
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64 SPI/Seq #: 00004321 00000001 IV: e96e8c08 ab465763 fd098d45 dd3ff893 Encrypted Data (80 bytes): f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a a269add0 47ad2d59 13ac19b7 cfbad4a6
SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64 SPI/Seq#: 00004321 00000001、IV: e96e8c08 ab465763 fd098d45 dd3ff893 Encrypted Data(80バイト): f663c25d 325c18c6 a9453e19 4e120849a4870b66 cc6b9965 330013b4 898dc856 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1db34ed9c 538ab50c 551b874a a269add0 47ad2d59 13ac19b7 cfbad4a6
Case #6: 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
#6、をケースに入れてください: 交通機関超能力パケットを抽出してください。(-p77-s20 192.168.123.100)キーを確認してください: 90d382b4 10eeba7a d938c46c ec1a82bf SPI: 4321年のソースアドレス: 192.168.123.3 送付先アドレス: 192.168.123.100 一連番号: 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 Data(28バイト): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777
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
詰め物があるプレ暗号化Data、パッドの長さ、および次のヘッダー(32バイト): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201
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): f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75
SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI/Seq#: 00004321 00000008、IV: 69d08df7 d203329d b093fc49 24e5bd80 Encrypted Data(32バイト): f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75
Case #7: 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
#7、をケースに入れてください: トンネルモード超能力パケットを抽出してください。(192.168.123.200)キーを確認してください: 01234567 89abcdef 01234567 89abcdef SPI: 8765年のソースアドレス: 192.168.123.3 送付先アドレス: 192.168.123.200 一連番号: 2、IV: f4e76524 4f6407ad f13dc138 0f673f37
Frankel, et al. Standards Track [Page 8] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[8ページ]。
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 Data(64バイト): 08009f76 a90a0100 b49c083d 02a20400 08090a0b0c0d0e0f 10111213 14151617 18191a1b1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 34353637
Augment data with: Padding: 01020304 05060708 090a Pad length: 0a Next header: 04 (IP-in-IP)
以下でデータを増大させてください。 詰め物: 01020304 05060708 090a Padの長さ: 0a Nextヘッダー: 04 (IPにおける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
オリジナルのIPヘッダーがあるプレ暗号化Data(詰め物)は長さと次のヘッダー(96バイト)を水増しします: 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 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): 773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8 e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5 c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d
SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 SPI/Seq#: 00008765 00000002、IV: f4e76524 4f6407ad f13dc138 0f673f37 Encrypted Data(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
Case #8: 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
#8、をケースに入れてください: トンネルモード超能力パケット(ピング-p ff-s40 192.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
オリジナルのパケット: IPヘッダー(20バイト): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 Data(48バイト): 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 Padの長さ: 0a Nextヘッダー: 04 (IPにおけるIP)
Frankel, et al. Standards Track [Page 9] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[9ページ]。
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
オリジナルのIPヘッダーがあるプレ暗号化Data(詰め物)は長さと次のヘッダー(80バイト)を水増しします: 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff01020304 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): 15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3 d2726d9b 5ef6affc 6d17a0de cbb13892
SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI/Seq#: 00008765 00000005、IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22 Encrypted Data(80バイト): 047232ccの15b92683 819596a8 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 0f980a08c9843fd3 a1b06d5c 07ff9639b7eb7dfb 3512e5de 435e7207 ed971ef3 d2726d9b 5ef6affc 6d17a0de cbb13892
5. IKE Interactions
5. IKE相互作用
5.1. Phase 1 Identifier
5.1. フェーズ1識別子
For Phase 1 negotiations, IANA has assigned an Encryption Algorithm ID of 7 for AES-CBC.
Phase1交渉のために、IANAはAES-CBCのための7のEncryption Algorithm IDを割り当てました。
5.2. Phase 2 Identifier
5.2. フェーズ2識別子
For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 12 for ESP_AES.
Phase2交渉のために、IANAは超能力_AESのための12の超能力Transform Identifierを割り当てました。
5.3. Key Length Attribute
5.3. キー長属性
Since the AES allows variable key lengths, the Key Length attribute MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 exchange [DOI].
AESが可変キー長を許容するので、Phase1交換[IKE]とPhase2交換[DOI]の両方でKey Length属性を指定しなければなりません。
5.4. Hash Algorithm Considerations
5.4. 細切れ肉料理アルゴリズム問題
A companion competition, to select the successor to SHA-1, the widely-used hash algorithm, recently concluded. The resulting hashes, called SHA-256, SHA-384 and SHA-512 [SHA2-1, SHA2-2] are capable of producing output of three different lengths (256, 384 and 512 bits), sufficient for the generation (within IKE) and authentication (within ESP) of the three AES key sizes (128, 192 and 256 bits).
仲間競争であり、最近SHA-1の後継者、広く使用された細切れ肉料理アルゴリズムを選択するのは結論を下しました。 SHA-256と呼ばれて、結果になるのはSHA-384を論じ尽くします、そして、SHA-512[SHA2-1、SHA2-2]は3つの異なった長さ(256、384、および512ビット)の出力を起こすことができます、3つのAESの主要なサイズ(128、192、および256ビット)の世代(IKEの中の)と認証(超能力の中の)では、十分です。
However, 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 AES keys and as ESP authenticators for AES encryption using 128-bit keys.
しかしながら、現在、十分な力についてHMAC-SHA-1[HMAC-SHA]とHMAC-MD5[HMAC-MD5]が128ビットのAESキーのIKEジェネレータとしてAES暗号化のための超能力固有識別文字として128ビットのキーを使用することで機能すると考えられます。
Frankel, et al. Standards Track [Page 10] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[10ページ]。
6. Security Considerations
6. セキュリティ問題
Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well. However, a key size of 128 bits is considered secure for the foreseeable future.
実現がそれらの特定のハードウェアとソフトウェア構成によって性能問題を考慮に入れるときそうすることができる中で最も大きい主要なサイズを使用するよう奨励されます。 そのような考慮がクライアント側だけではなく、また、サーバも考慮に入れなければならないように、暗号化が必ず安全なチャンネルの両側に影響を与えることに注意してください。 しかしながら、128ビットの主要なサイズは安全であると予見できる未来と考えられます。
For more information regarding the necessary use of random IV values, see [CRYPTO-B].
無作為のIV値の必要な使用に関する詳しい情報に関しては、[CRYPTO-B]を見てください。
For further security considerations, the reader is encouraged to read [AES].
さらなるセキュリティ問題において、読者が[AES]を読むよう奨励されます。
7. IANA Considerations
7. IANA問題
IANA has assigned Encryption Algorithm ID 7 to AES-CBC. IANA has assigned ESP Transform Identifier 12 to ESP_AES.
IANAはAES-CBCへのID7をEncryption Algorithmに割り当てました。 IANAは超能力Transform Identifier12を超能力_AESに割り当てました。
8. Intellectual Property Rights Statement
8. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
Frankel, et al. Standards Track [Page 11] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[11ページ]。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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 PUB197、「エー・イー・エス(AES)」11月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.
[CBC] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
9.2. Informative References
9.2. 有益な参照
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[アーチ形に曲げます] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[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-B] Bellovin、S.、「IPセキュリティー・プロトコルのありえそうな平文暗号文解読術」、Networkの上のSymposiumとDistributed System Security、サンディエゴ(カリフォルニア)のページのProceedings 155-160 2月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.
[暗号S] B.シュナイアー、「適用された暗号第2版」、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1995、ISBN0-471-12845-7。
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[EVALUATION] Ferguson, N. and B. Schneier, "A Cryptographic
Evaluation of IPsec," Counterpane Internet Security,
Inc., January 2000.
http://www.counterpane.com/ipsec.pdf
[評価] ファーガソンとN.B.シュナイアー、「IPsecの暗号の評価」ベッドカバーインターネットセキュリティInc.、2000年1月の 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-MD5] マドソン、C.、およびR.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」、RFC2403、11月1998日
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", RFC 2404, November 1998.
そして、[HMAC-SHA] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Frankel, et al. Standards Track [Page 12] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[12ページ]。
[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
[モード]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「方法とテクニック」、NISTの特別な公表800-38A、12月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-1]Bassham、L.III、「エー・イー・エスがないかどうかRound1候補アルゴリズムのANSI C実現をテストする効率」、 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-2]Lipmaa、Helger、「AES/ラインダール:」 「速度」 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-3] NechvetalとJ.とE.バーカーとD.ダドソンとM.ドーキンとJ.FotiとE.Roback、「エー・イー・エスの開発の最初のラウンドに関する現状報告」、 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
[PERF-4] シュナイアー、B.、J.ケルシー、D.ホワイティング、D.ワグナー、C.ホール、およびN.ファーガソン、「AES差出のパフォーマンス比較」、 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.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[ROAD] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[道路] セイヤーとR.とDoraswamyとN.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。
[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-1]NIST、FIPS PUB、180-2 「安全な細切れ肉料理規格のための仕様」、8月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
[SHA2-2] 「SHA-256、SHA-384、およびSHA-512の記述」、 http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf
10. Acknowledgments
10. 承認
Portions of this text, as well as its general structure, were unabashedly lifted from [CBC].
本稿の部分、およびその一般構造体は[CBC]から平気で撤廃されました。
The authors want to thank Hilarie Orman for providing expert advice (and a sanity check) on key sizes, requirements for Diffie-Hellman groups, and IKE interactions. We also thank Scott Fluhrer for his helpful comments and recommendations.
作者は、主要なサイズ、ディフィー-ヘルマングループのための要件、およびIKE相互作用で専門家の助言(そして、健全度チェック)を提供して頂いて、Hilarie Ormanに感謝したがっています。 また、私たちは彼の役に立つコメントと推薦についてスコットFluhrerに感謝します。
Frankel, et al. Standards Track [Page 13] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[13ページ]。
11. Authors' Addresses
11. 作者のアドレス
Sheila Frankel NIST 820 West Diamond Ave. Room 677 Gaithersburg, MD 20899
シェイラフランケルNIST820の西ダイヤモンドAve。 部屋677ゲイザースバーグ(MD)20899
Phone: +1 (301) 975-3297 EMail: sheila.frankel@nist.gov
以下に電話をしてください。 +1 (301) 975-3297 メールしてください: sheila.frankel@nist.gov
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134
スコットケリーAirespace110Nortech Pkwyサンノゼカリフォルニア 95134
Phone: +1 408 635 2000 EMail: scott@hyperthought.com
以下に電話をしてください。 +1 2000年の408 635メール: scott@hyperthought.com
Rob Glenn NIST 820 West Diamond Ave. Room 605 Gaithersburg, MD 20899
グレンNIST820の西ダイヤモンドAveから、略奪してください。 部屋605ゲイザースバーグ(MD)20899
Phone: +1 (301) 975-3667 EMail: rob.glenn@nist.gov
以下に電話をしてください。 +1 (301) 975-3667 メールしてください: rob.glenn@nist.gov
Frankel, et al. Standards Track [Page 14] RFC 3602 AES-CBC Cipher Algorithm Use with IPsec September 2003
フランケル、他 規格は2003年9月にIPsecとのRFC3602AES-CBC暗号アルゴリズム使用を追跡します[14ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Frankel, et al. Standards Track [Page 15]
フランケル、他 標準化過程[15ページ]
一覧
スポンサーリンク
