RFC3686 日本語訳
3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsecEncapsulating Security Payload (ESP). R. Housley. January 2004. (Format: TXT=43777 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley Request for Comments: 3686 Vigil Security Category: Standards Track January 2004
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3686年の不寝番セキュリティカテゴリ: 標準化過程2004年1月
Using Advanced Encryption Standard (AES) Counter Mode
With IPsec Encapsulating Security Payload (ESP)
IPsecがセキュリティ有効搭載量を要約しているエー・イー・エス(AES)カウンタモードを使用します。(超能力)
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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.
このドキュメントはエー・イー・エス(AES)カウンタModeの使用について説明します、明白な初期化ベクトルで、IPsec Encapsulating Security有効搭載量(超能力)秘密性メカニズムとして。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document. . . . . . . . . . . . 2
2. AES Block Cipher . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Counter Mode . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Key Size and Rounds. . . . . . . . . . . . . . . . . . . 5
2.3. Block Size . . . . . . . . . . . . . . . . . . . . . . . 5
3. ESP Payload. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Initialization Vector. . . . . . . . . . . . . . . . . . 6
3.2. Encrypted Payload. . . . . . . . . . . . . . . . . . . . 6
3.3. Authentication Data. . . . . . . . . . . . . . . . . . . 6
4. Counter Block Format . . . . . . . . . . . . . . . . . . . . . 7
5. IKE Conventions. . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Keying Material and Nonces . . . . . . . . . . . . . . . 8
5.2. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . 9
5.3. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . 9
5.4. Key Length Attribute . . . . . . . . . . . . . . . . . . 9
6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 本書では使用されるコンベンション。 . . . . . . . . . . . 2 2. AESは暗号. . . . . . . . . . . . . . . . . . . . . . . 2 2.1を妨げます。 モード. . . . . . . . . . . . . . . . . . . . . . 2 2.2を打ち返してください。 主要なサイズとラウンド。 . . . . . . . . . . . . . . . . . . 5 2.3. サイズ. . . . . . . . . . . . . . . . . . . . . . . 5 3を妨げてください。 超能力有効搭載量。 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. 初期設定ベクトル。 . . . . . . . . . . . . . . . . . 6 3.2. コード化された有効搭載量。 . . . . . . . . . . . . . . . . . . . 6 3.3. 認証データ。 . . . . . . . . . . . . . . . . . . 6 4. ブロックフォーマット. . . . . . . . . . . . . . . . . . . . . 7 5を打ち返してください。 IKEコンベンション。 . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. 材料と一回だけ. . . . . . . . . . . . . . . 8 5.2を合わせます。 1つの識別子. . . . . . . . . . . . . . . . . . . 9 5.3の位相を合わせてください。 2識別子. . . . . . . . . . . . . . . . . . . 9 5.4の位相を合わせてください。 キー長属性. . . . . . . . . . . . . . . . . . 9 6。 ベクトル. . . . . . . . . . . . . . . . . . . . . . . . . 9 7をテストしてください。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 8. 原理. . . . . . . . . . . . . . . . . . . . . . . 14 9を設計してください。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 16
Housley Standards Track [Page 1] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[1ページ]RFC3686
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 16
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
10. 知的所有権声明。 . . . . . . . . . . . . . . . 16 11. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 16 12. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1。 引用規格. . . . . . . . . . . . . . . . . . 17 12.2。 有益な参照. . . . . . . . . . . . . . . . . 17 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 18 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
The National Institute of Standards and Technology (NIST) recently selected the Advanced Encryption Standard (AES) [AES], also known as Rijndael. The AES is a block cipher, and it can be used in many different modes. This document describes the use of AES Counter Mode (AES-CTR), with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) [ESP] confidentiality mechanism.
米国商務省標準技術局(NIST)は最近、Standard(AES)[AES]であって、また、ラインダールとして知られているAdvanced Encryptionを選択しました。 AESはブロック暗号です、そして、多くの異なったモードでそれは使用できます。 このドキュメントはAES Counter Mode(AES-CTR)の使用について説明します、明白な初期化ベクトル(IV)で、IPsec Encapsulating Security有効搭載量(超能力)[超能力]秘密性メカニズムとして。
This document does not provide an overview of IPsec. However, information about how the various components of IPsec and the way in which they collectively provide security services is available in [ARCH] and [ROADMAP].
このドキュメントはIPsecの概観を提供しません。 しかしながら、IPsecの様々な部品とそれらがセキュリティー・サービスをまとめて提供する方法がどう利用可能なコネ[ARCH]と[ROADMAP]であるかの情報。
1.1. Conventions Used In This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [STDWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[STDWORDS]で説明されるように本書では解釈されることであるべきですか?
2. AES Block Cipher
2. AESブロック暗号
This section contains a brief description of the relevant characteristics of the AES block cipher. Implementation requirements are also discussed.
このセクションはAESブロック暗号の関連特性の簡単な説明を含みます。 また、実現要件について議論します。
2.1. Counter Mode
2.1. カウンタモード
NIST has defined five modes of operation for AES and other FIPS- approved block ciphers [MODES]. Each of these modes has different characteristics. The five modes are: ECB (Electronic Code Book), CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter).
NISTはAESのために5つの運転モードを定義しました、そして、他のFIPSはブロック暗号[MODES]を承認しました。 それぞれのこれらのモードには、異なった特性があります。 5つのモードは以下の通りです。 ECB(電子コードブック)、CBC(暗号ブロック連鎖)、CFB(暗号フィードバック)、OFB(出力フィードバック)、およびCTR(カウンタ)。
Only AES Counter mode (AES-CTR) is discussed in this specification. AES-CTR requires the encryptor to generate a unique per-packet value, and communicate this value to the decryptor. This specification calls this per-packet value an initialization vector (IV). The same IV and key combination MUST NOT be used more than once. The
この仕様でAES Counterモード(AES-CTR)だけについて議論します。 AES-CTRは、1パケットあたり1つのユニークな値を発生させて、この値をdecryptorに伝えるために暗号化する人を必要とします。 この仕様は、この1パケットあたりの値を初期化ベクトル(IV)と呼びます。 一度より同じIVと主要な組み合わせを使用してはいけません。 The
Housley Standards Track [Page 2] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[2ページ]RFC3686
encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
暗号化する人はユニークさを確実にするどんな方法でもIVを発生させることができます。 IV世代への一般的なアプローチは、各パケットと直線的なフィードバック・シフト・レジスタ(LFSRs)のためにカウンタを増加するのを含んでいます。
This specification calls for the use of a nonce for additional protection against precomputation attacks. The nonce value need not be secret. However, the nonce MUST be unpredictable prior to the establishment of the IPsec security association that is making use of AES-CTR.
この仕様は一回だけの前計算攻撃に対する追加保護の使用を求めます。 一回だけの値は秘密である必要はありません。 しかしながら、一回だけはAES-CTRを利用しているIPsecセキュリティ協会の設立の前に予測できるはずがありません。
AES-CTR has many properties that make it an attractive encryption algorithm for in high-speed networking. AES-CTR uses the AES block cipher to create a stream cipher. Data is encrypted and decrypted by XORing with the key stream produced by AES encrypting sequential counter block values. AES-CTR is easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation.
AES-CTRには、それが高速ネットワークでそれを魅力的な暗号化アルゴリズムにする多くの特性があります。 AES-CTRは、ストリーム暗号を作成するのにAESブロック暗号を使用します。 データは、XORingによってコード化されて、主要な流れが連続したカウンタブロック値をコード化するAESによって起こされている状態で、解読されます。 AES-CTRは実行しやすくて、AES-CTRをpipelinedして、parallelizedすることができます。 また、AES-CTRは主要な流れの前計算を支持します。
Pipelining is possible because AES has multiple rounds (see section 2.2). A hardware implementation (and some software implementations) can create a pipeline by unwinding the loop implied by this round structure. For example, after a 16-octet block has been input, one round later another 16-octet block can be input, and so on. In AES- CTR, these inputs are the sequential counter block values used to generate the key stream.
AESには複数のラウンドがあるので(セクション2.2を見てください)、パイプライン処理は可能です。 ハードウェア実装(そして、いくつかのソフトウェア実行)はこの丸い構造のそばで暗示していた状態で輪を解くのによるパイプラインを作成できます。 例えば、1ぐるりと後に、入力された後に、別の16八重奏のブロックは、入力などであるかもしれません。 AES- CTRでは、これらの入力は主要な流れを発生させるのに使用される連続したカウンタブロック値です。
Multiple independent AES encrypt implementations can also be used to improve performance. For example, one could use two AES encrypt implementations in parallel, to process a sequence of counter block values, doubling the effective throughput.
複数の独立しているAESが実現缶をコード化します、また、使用されて、性能を向上させてください。 例えば、1つは、カウンタブロック値の系列を処理するために平行な実現をコード化して、有効なスループットを倍にしながら、2AESを使用するかもしれません。
The sender can precompute the key stream. Since the key stream does not depend on any data in the packet, the key stream can be precomputed once the nonce and IV are assigned. This precomputation can reduce packet latency. The receiver cannot perform similar precomputation because the IV will not be known before the packet arrives.
送付者はキーが流すprecomputeをそうすることができます。 主要な流れがパケットのどんなデータにもよらないので、一回だけとIVがいったん割り当てられると、主要な流れを前計算できます。 この前計算はパケットレイテンシを減少させることができます。 パケットが到着する前にIVが知られていないので、受信機は同様の前計算を実行できません。
AES-CTR uses the only AES encrypt operation (for both encryption and decryption), making AES-CTR implementations smaller than implementations of many other AES modes.
AES-CTRは、操作(暗号化と復号化の両方のための)をコード化して、AES-CTR実現を他の多くのAESモードの実現より小さくしながら、唯一のAESを使用します。
When used correctly, AES-CTR provides a high level of confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. Being a stream cipher, any reuse of the per-packet value, called the IV, with the same nonce and key is catastrophic. An IV collision immediately leaks information about the plaintext in both packets. For this reason, it is inappropriate to use this mode of operation
正しく使用されると、AES-CTRは高いレベルの秘密性を提供します。 残念ながら、AES-CTRは不当に使用しやすいです。 ストリーム暗号(1パケットあたりの価値のどんな再利用)が同じ一回だけでIVを呼んで、キーが壊滅的であるということです。 IV衝突はすぐに、両方のパケットで平文に関して情報を漏らします。 この理由で、この運転モードを使用するのは不適当です。
Housley Standards Track [Page 3] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[3ページ]RFC3686
with static keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) [IKE] protocol can be used to establish fresh keys. IKE can also provide the nonce value.
静的なキーで。 並はずれた測定が、パワーサイクルの向こう側に静的なキーによるIV価値の再利用を防ぐのに必要でしょう。 安全に、なるように、実現はAES-CTRがある新鮮なキーを使用しなければなりません。 新鮮なキーを証明するのにインターネット・キー・エクスチェンジ(IKE)[IKE]プロトコルを使用できます。 また、IKEは一回だけの値を提供できます。
With AES-CTR, it is trivial to use a valid ciphertext to forge other (valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to use AES-CTR without a companion authentication function. Implementations MUST use AES-CTR in conjunction with an authentication function, such as HMAC-SHA-1-96 [HMAC-SHA].
AES-CTRがあるので、他の(decryptorに有効な)暗号文を鍛造するのに有効な暗号文を使用するのは些細です。 したがって、仲間認証機能なしでAES-CTRを使用するのは等しく壊滅的です。 実現はHMAC-SHA-1-96などの認証機能[HMAC-SHA]に関連してAES-CTRを使用しなければなりません。
To encrypt a payload with AES-CTR, the encryptor partitions the plaintext, PT, into 128-bit blocks. The final block need not be 128 bits; it can be less.
AES-CTRと共にペイロードをコード化するために、暗号化する人は太平洋標準時に128ビットのブロックに平文を仕切ります。 最終的なブロックは128ビットである必要はありません。 それは、より少ない場合があります。
PT = PT[1] PT[2] ... PT[n]
PT=PT[1]PT[2]… 太平洋標準時[n]
Each PT block is XORed with a block of the key stream to generate the ciphertext, CT. The AES encryption of each counter block results in 128 bits of key stream. The most significant 96 bits of the counter block are set to the nonce value, which is 32 bits, followed by the per-packet IV value, which is 64 bits. The least significant 32 bits of the counter block are initially set to one. This counter value is incremented by one to generate subsequent counter blocks, each resulting in another 128 bits of key stream. The encryption of n plaintext blocks can be summarized as:
それぞれのPTブロックは暗号文、コネチカットを発生させる主要な流れの1ブロックがあるXORedです。 それぞれのカウンタブロックのAES暗号化は主要な流れの128個のかけらをもたらします。 カウンタブロックの最も重要な96ビットは一回だけの値に設定されます。(1パケットあたりのIV値は64ビットである32ビットであるとそれを、いうことになりました)。 カウンタブロックの最も重要でない32ビットは初めは、1つに設定されます。 この対価はその後のカウンタブロックを発生させるように1つ増加されます、それぞれ主要な流れの別の128個のかけらをもたらして。 以下としてn平文ブロックの暗号化をまとめることができます。
CTRBLK := NONCE || IV || ONE
FOR i := 1 to n-1 DO
CT[i] := PT[i] XOR AES(CTRBLK)
CTRBLK := CTRBLK + 1
END
CT[n] := PT[n] XOR TRUNC(AES(CTRBLK))
CTRBLK:=一回だけ|| IV|| n-1へのONE FOR i:=1はコネチカット[i]:=PT[i]XOR AES(CTRBLK)CTRBLK:=CTRBLK+1END CT[n]:=PT[n]XOR TRUNCをします。(AES(CTRBLK))
The AES() function performs AES encryption with the fresh key.
AES()機能は新鮮なキーによるAES暗号化を実行します。
The TRUNC() function truncates the output of the AES encrypt operation to the same length as the final plaintext block, returning the most significant bits.
TRUNC()機能は、最終的な平文ブロックと同じ長さに操作をコード化して、ビットを最も重要に返しながら、AESの出力に先端を切らせます。
Housley Standards Track [Page 4] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[4ページ]RFC3686
Decryption is similar. The decryption of n ciphertext blocks can be summarized as:
復号化は同様です。 以下としてn暗号文ブロックの復号化をまとめることができます。
CTRBLK := NONCE || IV || ONE
FOR i := 1 to n-1 DO
PT[i] := CT[i] XOR AES(CTRBLK)
CTRBLK := CTRBLK + 1
END
PT[n] := CT[n] XOR TRUNC(AES(CTRBLK))
CTRBLK:=一回だけ|| IV|| n-1へのONE FOR i:=1はPT[i]:=コネチカット[i]XOR AES(CTRBLK)CTRBLK:=CTRBLK+1END PT[n]:=コネチカット[n]XOR TRUNCをします。(AES(CTRBLK))
2.2. Key Size and 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. Block Size
2.3. ブロック・サイズ
The AES has a block size of 128 bits (16 octets). As such, when using AES-CTR, each AES encrypt operation generates 128 bits of key stream. AES-CTR encryption is the XOR of the key stream with the plaintext. AES-CTR decryption is the XOR of the key stream with the ciphertext. If the generated key stream is longer than the plaintext or ciphertext, the extra key stream bits are simply discarded. For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. However, to provide limited traffic flow confidentiality, padding MAY be included, as specified in [ESP].
AESには、128ビット(16の八重奏)のブロック・サイズがあります。 そういうものとして、使用AES-CTR、各AESがいつ操作をコード化するかが主要な流れの128個のかけらを発生させます。 AES-CTR暗号化は平文がある主要な流れのXORです。 AES-CTR復号化は暗号文がある主要な流れのXORです。 発生している主要な流れが平文か暗号文より長いなら、スペアキー流れのビットは単に捨てられます。 この理由で、AES-CTRは、平文がブロック・サイズの倍数に水増しされるのを必要としません。 しかしながら、限られた交通の流れ秘密性、そっと歩いている5月に提供するには、[超能力]で指定されるように、含められてください。
3. ESP Payload
3. 超能力有効搭載量
The ESP payload is comprised of the IV followed by the ciphertext. The payload field, as defined in [ESP], is structured as shown in Figure 1.
超能力ペイロードは暗号文があとに続いたIVから成ります。 [超能力]で定義されるペイロード分野は図1に示されるように構造化されます。
Housley Standards Track [Page 5] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[5ページ]RFC3686
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 初期設定ベクトル| | (8つの八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ コード化された有効搭載量(可変)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 認証データ(可変)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. ESP Payload Encrypted with AES-CTR
図1。 AES-CTRと共にコード化された超能力有効搭載量
3.1. Initialization Vector
3.1. 初期設定ベクトル
The AES-CTR IV field MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
AES-CTR IV分野は8つの八重奏であるに違いありません。 暗号化する人は同じIV値が与えられたキーに一度だけ使用されるのを確実にする方法でIVを選ばなければなりません。 暗号化する人はユニークさを確実にするどんな方法でもIVを発生させることができます。 IV世代への一般的なアプローチは、各パケットと直線的なフィードバック・シフト・レジスタ(LFSRs)のためにカウンタを増加するのを含んでいます。
Including the IV in each packet ensures that the decryptor can generate the key stream needed for decryption, even when some packets are lost or reordered.
各パケットにIVを含んでいるのは、decryptorが復号化に必要である主要な流れを発生させることができるのを確実にします、いくつかのパケットが失われているか、または再命令されると。
3.2. Encrypted Payload
3.2. コード化された有効搭載量
The encrypted payload contains the ciphertext.
コード化されたペイロードは暗号文を含んでいます。
AES-CTR mode does not require plaintext padding. However, ESP does require padding to 32-bit word-align the authentication data. The padding, Pad Length, and the Next Header MUST be concatenated with the plaintext before performing encryption, as described in [ESP].
AES-CTRモードは平文詰め物を必要としません。 しかしながら、超能力は、32ビットにそっと歩くのを必要とします。認証データを単語で並べてください。 暗号化を実行する前の平文で詰め物、Pad Length、およびNext Headerを連結しなければなりません、[超能力]で説明されるように。
3.3. Authentication Data
3.3. 認証データ
Since it is trivial to construct a forgery AES-CTR ciphertext from a valid AES-CTR ciphertext, AES-CTR implementations MUST employ a non- NULL ESP authentication method. HMAC-SHA-1-96 [HMAC-SHA] is a likely choice.
有効なAES-CTR暗号文から偽造AES-CTR暗号文を構成するのが些細であるので、AES-CTR実現は非NULL ESPの認証方法を使わなければなりません。 HMAC-SHA-1-96[HMAC-SHA]はありそうな選択です。
Housley Standards Track [Page 6] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[6ページ]RFC3686
4. Counter Block Format
4. カウンタブロックフォーマット
Each packet conveys the IV that is necessary to construct the sequence of counter blocks used to generate the key stream necessary to decrypt the payload. The AES counter block cipher block is 128 bits. Figure 2 shows the format of the counter block.
各パケットはペイロードを解読するのに必要な主要な流れを発生させるのに使用されるカウンタブロックの系列を構成するのに必要なIVを運びます。 AESカウンタブロック暗号ブロックは128ビットです。 図2はカウンタブロックの書式を示しています。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一回だけ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 初期設定ベクトル(IV)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ブロックカウンタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Counter Block Format
図2。 カウンタブロックフォーマット
The components of the counter block are as follows:
カウンタブロックの部品は以下の通りです:
Nonce
The Nonce field is 32 bits. As the name implies, the nonce is a
single use value. That is, a fresh nonce value MUST be assigned
for each security association. It MUST be assigned at the
beginning of the security association. The nonce value need not
be secret, but it MUST be unpredictable prior to the beginning of
the security association.
Nonceがさばく一回だけは32ビットです。 名前が含意するように、一回だけはただ一つの使用価値です。 それぞれのセキュリティ協会のためにすなわち、新鮮な一回だけの値を割り当てなければなりません。 セキュリティ協会の始めにそれを割り当てなければなりません。 一回だけの値は秘密である必要はありませんが、それはセキュリティ協会の始まりの前に予測できるはずがありません。
Initialization Vector
The IV field is 64 bits. As described in section 3.1, the IV MUST
be chosen by the encryptor in a manner that ensures that the same
IV value is used only once for a given key.
Vector IVがさばく初期設定は64ビットです。 セクションで説明されて、3.1、IVが選ばなければならないように、同じIV値が与えられたキーに一度だけ使用されるのを確実にする方法で暗号化する人によって選ばれてください。
Block Counter
The block counter field is the least significant 32 bits of the
counter block. The block counter begins with the value of one,
and it is incremented to generate subsequent portions of the key
stream. The block counter is a 32-bit big-endian integer value.
Counterを妨げてください。ブロックカウンタ分野は最も重要でない32ビットのカウンタブロックです。 ブロックカウンタは1の値で始まります、そして、主要な流れのその後の部分を発生させるのは増加されています。 ブロックカウンタは32ビットのビッグエンディアン整数価値です。
Using the encryption process described in section 2.1, this construction permits each packet to consist of up to:
セクション2.1で説明された暗号化の過程を使用して、この工事は以下のことのために成る各パケットの起きるのを許します。
(2^32)-1 blocks = 4,294,967,295 blocks
= 68,719,476,720 octets
(2^32) 42億9496万7295-1ブロック=ブロックが687億1947万6720の八重奏と等しいです。
Housley Standards Track [Page 7] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[7ページ]RFC3686
This construction can produce enough key stream for each packet sufficient to handle any IPv6 jumbogram [JUMBO].
この工事はどんなIPv6 jumbogram[JUMBO]も扱うことができるくらいのそれぞれのパケットのための十分なキーストリームを起こすことができます。
5. IKE Conventions
5. IKEコンベンション
This section describes the conventions used to generate keying material and nonces for use with AES-CTR using the Internet Key Exchange (IKE) [IKE] protocol. The identifiers and attributes needed to negotiate a security association which uses AES-CTR are also defined.
このセクションはAES-CTRがインターネット・キー・エクスチェンジ(IKE)[IKE]プロトコルを使用している使用のために材料を合わせて、一回だけを発生させるのに使用されるコンベンションについて説明します。 また、AES-CTRを使用するセキュリティ協会を交渉するのに必要である識別子と属性は定義されます。
5.1. Keying Material and Nonces
5.1. 材料と一回だけを合わせます。
As described in section 2.1, implementations MUST use fresh keys with AES-CTR. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable nonce value from IKE. Note that this convention provides a nonce value that is secret as well as unpredictable.
セクション2.1で説明されるように、実現はAES-CTRがある新鮮なキーを使用しなければなりません。 新鮮なキーを証明するのにIKEを使用できます。 このセクションは、IKEから予測できない一回だけの値を得るためにコンベンションについて説明します。 このコンベンションが秘密の、そして、予測できない一回だけの値を提供することに注意してください。
IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, called KEYMAT. Keying material is extracted from the output string without regard to boundaries.
IKEは材料を合わせる引き出す擬似ランダム機能(PRF)を利用します。 KEYMATは、PRFが任意のサイズの合わせることの材料を誘導するのに繰り返しに使用されると呼びました。 材料を合わせるのは関係のない出力ストリングから境界まで抽出されます。
The size of the requested KEYMAT MUST be four octets longer than is needed for the associated AES key. The keying material is used as follows:
サイズ、要求されたKEYMAT MUSTでは、関連AESキーに必要とされるより長い4つの八重奏になってください。 合わせることの材料は以下の通り使用されます:
AES-CTR with a 128 bit key
The KEYMAT requested for each AES-CTR key is 20 octets. The first
16 octets are the 128-bit AES key, and the remaining four octets
are used as the nonce value in the counter block.
KEYMATがそれぞれのAES-CTRキーのために要求した128ビットのキーがあるAES-CTRは20の八重奏です。 最初の16の八重奏が128ビットのAESキーです、そして、残っている4つの八重奏が一回だけの値としてカウンタブロックで使用されます。
AES-CTR with a 192 bit key
The KEYMAT requested for each AES-CTR key is 28 octets. The first
24 octets are the 192-bit AES key, and the remaining four octets
are used as the nonce value in the counter block.
KEYMATがそれぞれのAES-CTRキーのために要求した192ビットのキーがあるAES-CTRは28の八重奏です。 最初の24の八重奏が192ビットのAESキーです、そして、残っている4つの八重奏が一回だけの値としてカウンタブロックで使用されます。
AES-CTR with a 256 bit key
The KEYMAT requested for each AES-CTR key is 36 octets. The first
32 octets are the 256-bit AES key, and the remaining four octets
are used as the nonce value in the counter block.
KEYMATがそれぞれのAES-CTRキーのために要求した256ビットのキーがあるAES-CTRは36の八重奏です。 最初の32の八重奏が256ビットのAESキーです、そして、残っている4つの八重奏が一回だけの値としてカウンタブロックで使用されます。
Housley Standards Track [Page 8] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[8ページ]RFC3686
5.2. Phase 1 Identifier
5.2. フェーズ1識別子
This document does not specify the conventions for using AES-CTR for IKE Phase 1 negotiations. For AES-CTR to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned.
このドキュメントはIKE Phase1交渉にAES-CTRを使用するのにコンベンションを指定しません。 AES-CTRがこの様に使用されるのに、別々の仕様が必要です、そして、Encryption Algorithm Identifierは割り当てられる必要があります。
5.3. Phase 2 Identifier
5.3. フェーズ2識別子
For IKE Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 13 for AES-CTR with an explicit IV.
IKE Phase2交渉のために、IANAは明白なIVと共にAES-CTRのための13の超能力Transform Identifierを割り当てました。
5.4. Key Length Attribute
5.4. キー長属性
Since the AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length attribute MUST have a value of 128, 192, or 256.
AESが3つのキー長を支持するので、IKE Phase2交換[DOI]でKey Length属性を指定しなければなりません。 Key Length属性に、128、192、または256の値がなければなりません。
6. Test Vectors
6. テストベクトル
This section contains nine test vectors, which can be used to confirm that an implementation has correctly implemented AES-CTR. The first three test vectors use AES with a 128 bit key; the next three test vectors use AES with a 192 bit key; and the last three test vectors use AES with a 256 bit key.
このセクションは9つのテストベクトルを含みます。(実現が正しくAES-CTRを実行したと確認するのにベクトルを使用できます)。 最初の3つのテストベクトルが128ビットのキーがあるAESを使用します。 次の3つのテストベクトルが192ビットのキーがあるAESを使用します。 そして、最後の3つのテストベクトルが256ビットのキーがあるAESを使用します。
Test Vector #1: Encrypting 16 octets using AES-CTR with 128-bit key AES Key : AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E AES-CTR IV : 00 00 00 00 00 00 00 00 Nonce : 00 00 00 30 Plaintext String : 'Single block msg' Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 Counter Block (1): 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01 Key Stream (1): B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF Ciphertext : E4 09 5D 4F B7 A7 B3 79 2D 61 75 A3 26 13 11 B8
テストベクトル#1: 128ビットの主要なAES KeyとAES-CTRを使用するコード化16八重奏: AE68 52F8 12 10 67は4B F7 A5 76 55 77F3 9E AES-CTR IVをCCします: 00 00 00 00 00 00 00 00一回だけ: 00 00 00 30平文ストリング: '単滑車msg'Plaintext: 53 69 6E67 6C65 20 62 6C6F63 6B20 6D73 67はブロック(1)を打ち返します: 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01の主要な流れ(1): 62EのB7 60 33 28DB C2 93 1B41 0E16C8 06 7DF暗号文: E4 09 5D 4F B7 A7 B3 79 2D61 75A3 26 13 11B8
Test Vector #2: Encrypting 32 octets using AES-CTR with 128-bit key
AES Key : 7E 24 06 78 17 FA E0 D7 43 D6 CE 1F 32 53 91 63
AES-CTR IV : C0 54 3B 59 DA 48 D9 0B
Nonce : 00 6C B6 DB
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
Counter Block (1): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 01
Key Stream (1): 51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87
Counter Block (2): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 02
Key Stream (2): FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37
Ciphertext : 51 04 A1 06 16 8A 72 D9 79 0D 41 EE 8E DA D3 88
: EB 2E 1E FC 46 DA 57 C8 FC E6 30 DF 91 41 BE 28
テストベクトル#2: 128ビットの主要なAES KeyとAES-CTRを使用するコード化32八重奏: 7E24 06 78 17 0ファEのD7 43D6Ce1F32 53 91 63AES-CTR IV: C0 54 3B59DA48D9 0B一回だけ: 00 6C B6 DB平文: 00 01 02 03 04 05 06 07 08 09 0A 0B0C0D0 0E F: 10 11 12 13 14 15 16 17 18 19 1A 1B1C1D1E1Fカウンタブロック(1): 00 6C B6 DB C0 54 3B59DA48D9 0B00 00 00 01の主要な流れ(1): 51 05A3 05 12 8F74DE71 04 4B E5 82D7 DD87はブロック(2)を打ち返します: 00 6C B6 DB C0 54 3B59DA48D9 0B00 00 00 02の主要な流れ(2): FB3F0C EF52Cf41DF4Eのff2A C4 8D 5C A0 37暗号文: 51 04A1 06 16 8A72D9 79 0D41EE8E DA D3 88: EB2 1EのE FC46DA57C8 FC E6 30DF91 41、28になってください。
Housley Standards Track [Page 9] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[9ページ]RFC3686
Test Vector #3: Encrypting 36 octets using AES-CTR with 128-bit key
AES Key : 76 91 BE 03 5E 50 20 A8 AC 6E 61 85 29 F9 A0 DC
AES-CTR IV : 27 77 7F 3F 4A 17 86 F0
Nonce : 00 E0 01 7B
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
: 20 21 22 23
Counter Block (1): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 01
Key Stream (1): C1 CE 4A AB 9B 2A FB DE C7 4F 58 E2 E3 D6 7C D8
Counter Block (2): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 02
Key Stream (2): 55 51 B6 38 CA 78 6E 21 CD 83 46 F1 B2 EE 0E 4C
Counter Block (3): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 03
Key Stream (3): 05 93 25 0C 17 55 36 00 A6 3D FE CF 56 23 87 E9
Ciphertext : C1 CF 48 A8 9F 2F FD D9 CF 46 52 E9 EF DB 72 D7
: 45 40 A4 2B DE 6D 78 36 D5 9A 5C EA AE F3 10 53
: 25 B2 07 2F
テストベクトル#3: 128ビットの主要なAES KeyとAES-CTRを使用するコード化36八重奏: 76 91、03 5E50 20A8西暦6年のE61 85 29F9 A0DC AES-CTR IVになってください: 27 77 7F3F4A17 86F0一回だけ: 00E0 01 7B平文: 00 01 02 03 04 05 06 07 08 09 0A 0B0C0D0 0E F: 10 11 12 13 14 15 16 17 18 19 1A 1B1C1D1 1E F: 20 21 22 23はブロック(1)を打ち返します: 00 0 01 7B27 77 7EのF3F4A17 86F0 00 00 00 01の主要な流れ(1): D6 7C D8が打ち返すC1Ce4A AB9B 2A FB DE C7 4F58E2E3は(2)を妨げます: 00 0 01 7B27 77 7EのF3F4A17 86F0 00 00 00 02の主要な流れ(2): 55 51B6 38カリフォルニア78 6 21EのCD83 46F1B2 EE0E4Cカウンタブロック(3): 00 0 01 7B27 77 7EのF3F4A17 86F0 00 00 00 03の主要な流れ(3): 05 93 25の0のC17 55 36 00のA6の3D FE Cf56 23 87E9暗号文: C1Cf48A8 9F2F FD D9Cf46 52 9EのEF DB72D7: 45 40A4 2B DE6D78 36D5 9A5C EA AE F3 10 53: 25 B2 07 2F
Test Vector #4: Encrypting 16 octets using AES-CTR with 192-bit key
AES Key : 16 AF 5B 14 5F C9 F5 79 C1 75 F9 3E 3B FB 0E ED
: 86 3D 06 CC FD B7 85 15
AES-CTR IV : 36 73 3C 14 7D 6D 93 CB
Nonce : 00 00 00 48
Plaintext String : 'Single block msg'
Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
Counter Block (1): 00 00 00 48 36 73 3C 14 7D 6D 93 CB 00 00 00 01
Key Stream (1): 18 3C 56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F
Ciphertext : 4B 55 38 4F E2 59 C9 C8 4E 79 35 A0 03 CB E9 28
テストベクトル#4: 192ビットの主要なAES KeyとAES-CTRを使用するコード化16八重奏: 16 AF 5B14 5F C9 F5 79C1 75F9 3E 3B FB0Eエド: 86 3D06はFD B7 85 15AES-CTR IVをCCします: 36 73 3C14 7D 6D93CB一回だけ: 00 00 00 48平文ストリング: '単滑車msg'Plaintext: 53 69 6E67 6C65 20 62 6C6F63 6B20 6D73 67はブロック(1)を打ち返します: 00 00 00 48 36 73 3C14 7D 6D93CB00 00 00 01の主要な流れ(1): 18 3 C56 28 8Eの3C E9 AA22 16 56CB23A6 9A4F暗号文: 4B55 38 4F E2 59C9 C8 4E79 35A0 03CB E9 28
Test Vector #5: Encrypting 32 octets using AES-CTR with 192-bit key
AES Key : 7C 5C B2 40 1B 3D C3 3C 19 E7 34 08 19 E0 F6 9C
: 67 8C 3D B8 E6 F6 A9 1A
AES-CTR IV : 02 0C 6E AD C2 CB 50 0D
Nonce : 00 96 B0 3B
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
Counter Block (1): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 01
Key Stream (1): 45 33 41 FF 64 9E 25 35 76 D6 A0 F1 7D 3C C3 90
Counter Block (2): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 02
Key Stream (2): 94 81 62 0F 4E C1 B1 8B E4 06 FA E4 5E E9 E5 1F
Ciphertext : 45 32 43 FC 60 9B 23 32 7E DF AA FA 71 31 CD 9F
: 84 90 70 1C 5A D4 A7 9C FC 1F E0 FF 42 F4 FB 00
テストベクトル#5: 192ビットの主要なAES KeyとAES-CTRを使用するコード化32八重奏: 7 C5C B2 40 1B3D C3 3C19E7 34 08 19の0EのF6 9C: 67 8 Cの3D B8E6F6 A9 1A AES-CTR IV: 02 0 C6E AD C2 CB50 0D一回だけ: 00 96B0 3B平文: 00 01 02 03 04 05 06 07 08 09 0A 0B0C0D0 0E F: 10 11 12 13 14 15 16 17 18 19 1A 1B1C1D1E1Fカウンタブロック(1): 00 96B0 3B02 0のC6のE ADのC2 CB50 0D00 00 00 01の主要な流れ(1): 45 33 41ff64 9E25 35 76D6 A0F1 7D 3C C3 90はブロック(2)を打ち返します: 00 96B0 3B02 0のC6のE ADのC2 CB50 0D00 00 00 02の主要な流れ(2): 94 81 62 0F4EのC1B1 8B E4 06ファE4 5Eの9EのE5 1F暗号文: 45 32 43FC60 9B23 32 7EのDF AAファ71 31CD9F: 84 90 70、1C5A D4 A7 9C FC 1F E0ff42F4 FB00
Housley Standards Track [Page 10] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[10ページ]RFC3686
Test Vector #6: Encrypting 36 octets using AES-CTR with 192-bit key
AES Key : 02 BF 39 1E E8 EC B1 59 B9 59 61 7B 09 65 27 9B
: F5 9B 60 A7 86 D3 E0 FE
AES-CTR IV : 5C BD 60 27 8D CC 09 12
Nonce : 00 07 BD FD
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
: 20 21 22 23
Counter Block (1): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 01
Key Stream (1): 96 88 3D C6 5A 59 74 28 5C 02 77 DA D1 FA E9 57
Counter Block (2): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 02
Key Stream (2): C2 99 AE 86 D2 84 73 9F 5D 2F D2 0A 7A 32 3F 97
Counter Block (3): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 03
Key Stream (3): 8B CF 2B 16 39 99 B2 26 15 B4 9C D4 FE 57 39 98
Ciphertext : 96 89 3F C5 5E 5C 72 2F 54 0B 7D D1 DD F7 E7 58
: D2 88 BC 95 C6 91 65 88 45 36 C8 11 66 2F 21 88
: AB EE 09 35
テストベクトル#6: 192ビットの主要なAES KeyとAES-CTRを使用するコード化36八重奏: 02 BF39 1Eの8EのEC B1 59B9 59 61 7B09 65 27 9B: F5 9B60A7 86D3E0FE AES-CTR IV: 5 C BD60 27 8D CC09 12一回だけ: 00 07BD FD平文: 00 01 02 03 04 05 06 07 08 09 0A 0B0C0D0 0E F: 10 11 12 13 14 15 16 17 18 19 1A 1B1C1D1 1E F: 20 21 22 23はブロック(1)を打ち返します: 00 07BD FD5C BD60 27の8D cc09 12 00 00 00 01の主要な流れ(1): 57が打ち返す96 88の3D C6 5A59 74 28 5C02 77DA D1ファE9は(2)を妨げます: 00 07BD FD5C BD60 27の8D cc09 12 00 00 00 02の主要な流れ(2): C2 99AE86D2 84 73 9F5D 2F D2 0A 7A32 3F97がブロック(3)を打ち返します: 00 07BD FD5C BD60 27の8D cc09 12 00 00 00 03の主要な流れ(3): 8B Cf2B16 39 99B2 26 15B4 9C D4 FE57 39 98暗号文: 96 89 3F C5 5E5C72 2F54 0B 7D D1 DD F7E7 58: D2 88紀元前95年のC6 91 65 88 45 36C8 11 66 2F21 88: AB EE09 35
Test Vector #7: Encrypting 16 octets using AES-CTR with 256-bit key
AES Key : 77 6B EF F2 85 1D B0 6F 4C 8A 05 42 C8 69 6F 6C
: 6A 81 AF 1E EC 96 B4 D3 7F C1 D6 89 E6 C1 C1 04
AES-CTR IV : DB 56 72 C9 7A A8 F0 B2
Nonce : 00 00 00 60
Plaintext String : 'Single block msg'
Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
Counter Block (1): 00 00 00 60 DB 56 72 C9 7A A8 F0 B2 00 00 00 01
Key Stream (1): 47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7
Ciphertext : 14 5A D0 1D BF 82 4E C7 56 08 63 DC 71 E3 E0 C0
テストベクトル#7: 256ビットの主要なAES KeyとAES-CTRを使用するコード化16八重奏: 77 6 6B EF F2 85 1D B0 6F4C8A05 42C8 69 6F C: 6A81AF1E EC96B4 D3 7F C1 D6 89 6EのC1 C1 04AES-CTR IV: DB56 72C9 7A A8 F0 B2一回だけ: 00 00 00 60平文ストリング: '単滑車msg'Plaintext: 53 69 6E67 6C65 20 62 6C6F63 6B20 6D73 67はブロック(1)を打ち返します: 00 00 00 60DB56 72C9 7A A8 F0 B2 00 00 00 01の主要な流れ(1): 47 33、93Eの7A D3E7 6E Aの5 3A67 00B7 51 8A7暗号文になってください: 14 5A D0 1D BF82 4EのC7 3ユーロの71E0の56 08 63DC C0
Test Vector #8: Encrypting 32 octets using AES-CTR with 256-bit key
AES Key : F6 D6 6D 6B D5 2D 59 BB 07 96 36 58 79 EF F8 86
: C6 6D D5 1A 5B 6A 99 74 4B 50 59 0C 87 A2 38 84
AES-CTR IV : C1 58 5E F1 5A 43 D8 75
Nonce : 00 FA AC 24
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
Counter block (1): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 01
Key stream (1): F0 5F 21 18 3C 91 67 2B 41 E7 0A 00 8C 43 BC A6
Counter block (2): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 02
Key stream (2): A8 21 79 43 9B 96 8B 7D 4D 29 99 06 8F 59 B1 03
Ciphertext : F0 5E 23 1B 38 94 61 2C 49 EE 00 0B 80 4E B2 A9
: B8 30 6B 50 8F 83 9D 6A 55 30 83 1D 93 44 AF 1C
テストベクトル#8: 256ビットの主要なAES KeyとAES-CTRを使用するコード化32八重奏: F6 D6 6D 6B D5 2D59掲示板07 96 36 58 79EF F8 86: C6 6D D5 1A 5B 6A99 74 4B50 59 0C87A2 38 84AES-CTR IV: C1 58 5EのF1 5A43D8 75一回だけ: 00 ファ西暦24年の平文: 00 01 02 03 04 05 06 07 08 09 0A 0B0C0D0 0E F: 1Eの10 11 12 13 14 15 16 17 18 19 1A 1B1C1D1F Counterは(1)を妨げます: 00 FA AC24C1 58 5EのF1 5A43D8 75 00 00 00 01Keyは(1)を流します: F0 5F21 18 3C91 67 2B41の7 0A00 8EのC43紀元前A6 Counterは(2)を妨げます: 00 FA AC24C1 58 5EのF1 5A43D8 75 00 00 00 02Keyは(2)を流します: A8 21 79 43 9B96 8B 7D 4D29 99 06 8F59B1 03暗号文: F0 5E23 1B38 94 61 2C49EE00 0B80 4EのB2A9: B8 30 6B50 8F83 9D 6A55 30 83 1D93 44AF1C
Housley Standards Track [Page 11] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[11ページ]RFC3686
Test Vector #9: Encrypting 36 octets using AES-CTR with 256-bit key
AES Key : FF 7A 61 7C E6 91 48 E4 F1 72 6E 2F 43 58 1D E2
: AA 62 D9 F8 05 53 2E DF F1 EE D6 87 FB 54 15 3D
AES-CTR IV : 51 A5 1D 70 A1 C1 11 48
Nonce : 00 1C C5 B7
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
: 20 21 22 23
Counter block (1): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 01
Key stream (1): EB 6D 50 81 19 0E BD F0 C6 7C 9E 4D 26 C7 41 A5
Counter block (2): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 02
Key stream (2): A4 16 CD 95 71 7C EB 10 EC 95 DA AE 9F CB 19 00
Counter block (3): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 03
Key stream (3): 3E E1 C4 9B C6 B9 CA 21 3F 6E E2 71 D0 A9 33 39
Ciphertext : EB 6C 52 82 1D 0B BB F7 CE 75 94 46 2A CA 4F AA
: B4 07 DF 86 65 69 FD 07 F4 8C C0 B5 83 D6 07 1F
: 1E C0 E6 B8
テストベクトル#9: 256ビットの主要なAES KeyとAES-CTRを使用するコード化36八重奏: 7A61 7C E6 91 48 4EのF1 72 6ff2E F43 58 1D E2: AA62D9 F8 05 53 2EのDF F1EE D6 87FB54 15 3D AES-CTR IV: 51 A5 1D70A1 C1 11 48一回だけ: 00 1C C5 B7平文: 00 01 02 03 04 05 06 07 08 09 0A 0B0C0D0 0E F: 10 11 12 13 14 15 16 17 18 19 1A 1B1C1D1 1E F: 20 21 22 23はブロック(1)を打ち返します: 00 1C C5 B7 51A5 1D70A1 C1 11 48 00 00 00 01Keyは(1)を流します: EB 6D50 81 19 0EのBD F0 C6 7C9E4D26C7 41A5 Counterは(2)を妨げます: 00 1C C5 B7 51A5 1D70A1 C1 11 48 00 00 00 02Keyは(2)を流します: A4 16CD95 71 7C EB10EC95DA AE9F CB19 00Counterは(3)を妨げます: 00 1C C5 B7 51A5 1D70A1 C1 11 48 00 00 00 03Keyは(3)を流します: 3Eの1EのC4 9B C6 B9カリフォルニア21 3F6E E2 71D0 A9 33 39暗号文: EB6C52 82 1D 0B掲示板F7Ce75 94 46 2Aカリフォルニア4F AA: B4 07DF86 65 69FD07F4 8C C0 B5 83D6 07 1F: 6Eの1EのC0B8
7. Security Considerations
7. セキュリティ問題
When used properly, AES-CTR mode provides strong confidentiality. Bellare, Desai, Jokipii, Rogaway show in [BDJR] that the privacy guarantees provided by counter mode are at least as strong as those for CBC mode when using the same block cipher.
適切に使用されると、AES-CTRモードは強い秘密性を提供します。 Bellare、デセイ、Jokipii、Rogawayは[BDJR]にカウンタモードで提供されたプライバシー保証が同じブロックを使用するとき、CBCモードのためのそれらに解かれるのと少なくとも同じくらい強いのを示します。
Unfortunately, it is very easy to misuse this counter mode. If counter block values are ever used for more that one packet with the same key, then the same key stream will be used to encrypt both packets, and the confidentiality guarantees are voided.
残念ながら、このカウンタモードを誤用するのは非常に簡単です。 カウンタブロック値が今までに以上に使用されると、同じ主要で、次に、同じ主要な流れがあるその1つのパケットが両方のパケットをコード化するのに使用されるでしょう、そして、秘密性保証は欠如します。
What happens if the encryptor XORs the same key stream with two different plaintexts? Suppose two plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3 are both encrypted with key stream K1, K2, K3. The two corresponding ciphertexts are:
同じくらいが合わせる暗号化する人XORsが2つの異なった平文であふれるなら、何が起こりますか? 2平文のバイト列のP1とP2とP3とQ1、Q2、Q3が主要な流れのK1、ケーツー(K3)と共にともにコード化されると仮定してください。 2つの対応する暗号文は以下の通りです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
(P1 XOR K1)、(P2 XORケーツー)(P3 XOR K3)
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
(Q1 XOR K1)、(Q2 XORケーツー)(Q3 XOR K3)
If both of these two ciphertext streams are exposed to an attacker, then a catastrophic failure of confidentiality results, since:
これらの2つの暗号文の流れの両方が攻撃者に露出されるなら、以下以来秘密性の突発故障は結果として生じます。
(P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
(P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
(P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3
P2 XOR Q2(P3 XOR K3)P1 XOR Q1(P2 XORケーツー)(P1 XOR K1)XOR(Q1 XOR K1)=XOR(Q2 XORケーツー)=XOR(Q3 XOR K3)はP3 XOR Q3と等しいです。
Housley Standards Track [Page 12] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[12ページ]RFC3686
Once the attacker obtains the two plaintexts XORed together, it is relatively straightforward to separate them. Thus, using any stream cipher, including AES-CTR, to encrypt two plaintexts under the same key stream leaks the plaintext.
一緒にXORed、攻撃者がいったん2つの平文を得ると、それらを切り離すのは比較的簡単です。 したがって、同じ主要な流れで2つの平文をコード化するのにAES-CTRを含むどんなストリーム暗号も使用すると、平文は漏らされます。
Therefore, stream ciphers, including AES-CTR, should not be used with static keys. It is inappropriate to use AES-CTR with static keys. Extraordinary measures would be needed to prevent reuse of a counter block value with the static key across power cycles. To be safe, ESP implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) protocol [IKE] can be used to establish fresh keys. IKE can also be used to establish the nonce at the beginning of the security association.
したがって、静的なキーと共にAES-CTRを含むストリーム暗号を使用するべきではありません。 静的なキーがあるAES-CTRを使用するのは不適当です。 並はずれた測定が、パワーサイクルの向こう側に静的なキーによるカウンタブロック価値の再利用を防ぐのに必要でしょう。 安全に、なるように、超能力実現はAES-CTRがある新鮮なキーを使用しなければなりません。 新鮮なキーを証明するのに、インターネット・キー・エクスチェンジ(IKE)プロトコル[IKE]を使用できます。 また、セキュリティ協会の始めに一回だけを証明するのにIKEを使用できます。
When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows. When a mechanism other than IKE is used to establish fresh keys, and that mechanism establishes only a single key to encrypt packets, then there is a high probability that the peers will select the same IV values for some packets. Thus, to avoid counter block collisions,
IKEが2つの同輩実体の間の新鮮なキーを証明するのに使用されるとき、別々のキーは2回の交通の流れのために設立されます。 IKE以外のメカニズムが新鮮なキーを証明するのに使用されて、そのメカニズムがパケットをコード化するために単一のキーだけを設立すると、同輩がいくつかのパケットのために同じIV値を選択するという高い確率があります。 したがって、カウンタを避けるには、衝突を妨げてください。
ESP implementations that permit use of the same key for encrypting outbound traffic and decrypting incoming traffic with the same peer MUST ensure that the two peers assign different Nonce values to the security association.
同じキーの同じ同輩と共にアウトバウンドトラフィックをコード化して、入って来る交通を解読する使用を可能にする超能力実現は、2人の同輩が異なったNonce値をセキュリティ協会に配属するのを確実にしなければなりません。
Data forgery is trivial with CTR mode. The demonstration of this attack is similar to the key stream reuse discussion above. If a known plaintext byte sequence P1, P2, P3 is encrypted with key stream K1, K2, K3, then the attacker can replace the plaintext with one of his own choosing. The ciphertext is:
データ偽造はCTRモードで些細です。 この攻撃のデモンストレーションは上の主要な流れの再利用議論と同様です。 知られている平文バイト列P1、P2であるなら、コード化されたP3はキーでK1、ケーツー、K3を流して、次に、攻撃者は平文を彼自身の選ぶことの1つに取り替えることができます。 暗号文は以下の通りです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
(P1 XOR K1)、(P2 XORケーツー)(P3 XOR K3)
The attacker simply XORs a selected sequence Q1, Q2, Q3 with the ciphertext to obtain:
単に攻撃者XORsは選択された系列Q1、Q2、以下を得る暗号文があるQ3です。
(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
(Q1 XOR(P1 XOR K1))、(Q2 XOR(P2 XORケーツー))(Q3 XOR(P3 XOR K3))
Which is the same as:
どれが以下と同じですか?
((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)
((Q1 XOR P1) XOR K1)、(Q2 XOR P2)XORケーツー)((Q3 XOR P3)XOR K3)
Decryption of the attacker-generated ciphertext will yield exactly what the attacker intended:
攻撃者が発生している暗号文の復号化はまさに攻撃者が意図したことをもたらすでしょう:
(Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)
(Q1 XOR P1)、(Q2 XOR P2)(Q3 XOR P3)
Housley Standards Track [Page 13] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[13ページ]RFC3686
Accordingly, ESP implementations MUST use of AES-CTR in conjunction with ESP authentication.
それに従って、超能力実現は超能力認証に関連したAES-CTRの使用がそうしなければなりません。
Additionally, since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Since ESP with Enhanced Sequence Numbers allows for up to 2^64 packets in a single security association, there is real potential for more than 2^64 blocks to be encrypted with one key. Therefore, implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. Note that ESP with 32- bit Sequence Numbers will not exceed 2^64 blocks even if all of the packets are maximum-length IPv6 jumbograms [JUMBO].
使われたモードにかかわらずAESには128ビットのブロック・サイズがあるので、2^64ブロックが単一のキーでコード化された後に、さらに、AES暗号化で発生する暗号文は無作為の値から区別可能になります。 Enhanced Sequence民数記がある超能力が2^まで単一のセキュリティ協会での64のパケットを許容するので、2^64が妨げる以上が1個のキーでコード化される本当の可能性があります。 したがって、2^64ブロックが同じキーでコード化される前に実現SHOULDは新鮮なキーを発生させます。 Sequence民数記が2^64ブロック超えていない32ビットでパケットのすべてが最大の長さのIPv6 jumbograms[JUMBO]であってもその超能力に注意してください。
There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES-CTR (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. Therefore, implementations that employ 128-bit AES keys should take precautions to make the precomputation attacks more difficult. The unpredictable nonce value in the counter block significantly increases the size of the table that the attacker must compute to mount a successful attack.
一般的な前計算攻撃はキーに対して中央で会っている攻撃を許すすべてのブロック暗号モードに反対して公正にいます。 これらの攻撃は知られている平文と知られているキーに関連している暗号文の巨大なテーブルを創造と探すことを必要とします。 メモリとプロセッサ資源が前計算攻撃に利用可能であると仮定する場合、AES-CTR(そして、いかなる他のブロック暗号モードも)の理論上の強さは2^(n/2)ビットに制限されます。そこでは、nがキーのビットの数です。 長いキーの使用は前計算攻撃への最も良い対策です。 したがって、前計算攻撃をより難しくするように128ビットのAESキーを使う実現の予防策を講されるべきです。 カウンタブロックの予測できない一回だけの値は攻撃者がうまくいっている攻撃を仕掛けるために計算しなければならないテーブルのサイズをかなり増加させます。
8. Design Rationale
8. デザイン原理
In the development of this specification, the use of the ESP sequence number field instead of an explicit IV field was considered. This selection is not a cryptographic security issue, as either approach will prevent counter block collisions.
この仕様の開発では、明白なIV分野の代わりに超能力一連番号分野の使用は考えられました。 アプローチがカウンタブロック衝突を防ぐので、この選択は暗号の安全保障問題ではありません。
In a very conservative model of encryption security, at most 2^64 blocks ought to be encrypted with AES-CTR under a single key. Under this constraint, no more than 64 bits are needed to identify each packet within a security association. Since the ESP extended sequence number is 64 bits, it is an obvious candidate for use as an implicit IV. This would dictate a single method for the assignment of per-packet value in the counter block. The use of an explicit IV does not dictate such a method, which is desirable for several reasons.
暗号化セキュリティの非常に保守的なモデルでは、高々2^64ブロックしか単一のキーの下のAES-CTRと共にコード化されるべきではありません。 この規制で、64ビット未満が、セキュリティ協会の中の各パケットを特定するのに必要です。 超能力拡張配列番号が64ビットであるので、それは暗黙のIVとしての使用の明白な候補です。 これはカウンタブロックの1パケットあたりの価値の課題のためのただ一つの方法を書き取るでしょう。 明白なIVの使用はそのような方法を決めません。(それは、いくつかの理由で望ましいです)。
Housley Standards Track [Page 14] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[14ページ]RFC3686
1. Only the encryptor can ensure that the value is not used for more
than one packet, so there is no advantage to selecting a mechanism
that allows the decryptor to determine whether counter block
values collide. Damage from the collision is done, whether the
decryptor detects it or not.
1. 暗号化する人だけが、値が1つ以上のパケットに使用されないのを確実にすることができるので、decryptorがカウンタブロック値が衝突するかどうか決定できるメカニズムを選択する利点が全くありません。 decryptorがそれを検出するか否かに関係なく、衝突からの損害は与えられます。
2. Allows adders, LFSRs, and any other technique that meets the time
budget of the encryptor, so long as the technique results in a
unique value for each packet. Adders are simple and
straightforward to implement, but due to carries, they do not
execute in constant time. LFSRs offer an alternative that
executes in constant time.
2. 毒蛇、LFSRs、および各パケットのためのユニークな値をもたらす限り、暗号化する人の時間予算に間に合ういかなる他のテクニックも許容します。 毒蛇は、実行するために簡単であって、簡単ですが、桁上げのため、それらは中で一定の時間を実行しません。 LFSRsはそれが一定の時間で実行する代替手段を提供します。
3. Complexity is in control of the implementer. Further, the
decision made by the implementer of the encryptor does not make
the decryptor more (or less) complex.
3. 複雑さはimplementerのコントロール中です。 さらに、暗号化する人のimplementerによってされた決定は、より多くの(それほど)複合体をdecryptorにしません。
4. When the encryptor has more than one cryptographic hardware
device, an IV prefix can be assigned to each device, ensuring that
collisions will not occur. Yet, since the decryptor does not need
to examine IV structure, the decryptor is unaffected by the IV
structure selected by the encryptor. One cannot make use of the
same technique with the ESP sequence numbers, because the
semantics for them require sequential value generation.
4. 暗号化する人に1個以上の暗号のハードウェアデバイスがあると、IV接頭語を各装置に割り当てることができます、衝突が起こらないのを確実にして。 しかし、decryptorがIV構造を調べる必要はないので、decryptorは暗号化する人によって選択されたIV構造のそばで影響を受けないです。 1つは超能力一連番号がある同じテクニックを利用できません、それらのための意味論が連続した値の世代を必要とするので。
5. Assurance boundaries are very important to implementations that
will be evaluated against the FIPS Pub 140-1 or FIPS Pub 140-2
[SECRQMTS]. The assignment of the per-packet counter block value
needs to be inside the assurance boundary. Some implementations
assign the sequence number inside the assurance boundary, but
others do not. A sequence number collision does not have the dire
consequences, but, as described in section 6, a collision in
counter block values has disastrous consequences.
5. 保証境界はFIPS Pub140-1かFIPS Pub140-2[SECRQMTS]に対して評価される実現に非常に重要です。 1パケットあたりのカウンタブロック価値の課題は、保証境界の中にある必要があります。 いくつかの実現が保証境界の中で一連番号を割り当てますが、他のものは割り当てるというわけではありません。 一連番号衝突には、恐ろしい結果がありませんが、セクション6で説明されるように、カウンタブロック値における衝突に惨憺たる結果があります。
6. Coupling with the sequence number is possible in those
architectures where the sequence number assignment is performed
within the assurance boundary. In this situation, the sequence
number and the IV field will contain the same value.
6. 一連番号に結合するのは一連番号課題が保証境界の中で実行されるそれらの構造で可能です。 この状況で、一連番号とIV分野は同じ値を含むでしょう。
7. Decoupling from the sequence number is possible in those
architectures where the sequence number assignment is performed
outside the assurance boundary.
7. 一連番号からのデカップリングは一連番号課題が保証境界の外で実行されるそれらの構造で可能です。
The use of an explicit IV field directly follows from the decoupling of the sequence number and the per-packet counter block value. The overhead associated with 64 bits for the IV field is acceptable. This overhead is significantly less than the overhead associated with Cipher Block Chaining (CBC) mode. As normally employed, CBC requires
明白なIV分野の使用は一連番号のデカップリングと1パケットあたりのカウンタブロック価値から直接続きます。 IV分野への64ビットに関連しているオーバーヘッドは許容できます。 このオーバーヘッドはCipher Block Chaining(CBC)モードに関連しているオーバーヘッドよりかなり少ないです。 通常、使われるとして必要である、CBCが必要です。
Housley Standards Track [Page 15] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[15ページ]RFC3686
a full block for the IV and, on average, half of a block for padding. AES-CTR with an explicit IV has about one-third of the overhead as AES-CBC, and the overhead is constant for each packet.
IVのための1つのまるブロックと詰め物のための半分の平均的にブロック。 明白なIVとAES-CTRには、AES-CBCとしてオーバーヘッドのおよそ1/3があります、そして、各パケットに、オーバーヘッドは一定です。
The inclusion of the nonce provides a weak countermeasure against precomputation attacks. For this countermeasure to be effective, the attacker must not be able to predict the value of the nonce well in advance of security association establishment. The use of long keys provides a strong countermeasure to precomputation attacks, and AES offers key sizes that thwart these attacks for many decades to come.
一回だけの包含は前計算攻撃に対して弱い対策を提供します。 この対策が効果的であるように、攻撃者はセキュリティ協会設立のよく前に一回だけの値を予測できるはずがありません。 長いキーの使用は、前計算への強硬策に攻撃を提供して、数十年が来るためにこれらの攻撃を阻む主要なサイズをAES申し出に提供します。
A 28-bit block counter value is sufficient for the generation of a key stream to encrypt the largest possible IPv6 jumbogram [JUMBO]; however, a 32-bit field is used. This size is convenient for both hardware and software implementations.
28ビットのブロックカウンタ価値は可能な限り大きいIPv6 jumbogram[JUMBO]をコード化する主要な流れの世代のために十分です。 しかしながら、32ビットの分野は使用されています。 ハードウェアとソフトウェア実行の両方はこのサイズが都合がよいです。
9. IANA Considerations
9. IANA問題
IANA has assigned 13 as the ESP transform number for AES-CTR with an explicit IV.
IANAは明白なIVと共にAES-CTRの超能力変換番号として13を割り当てました。
10. Intellectual Property Statement
10. 知的所有権声明
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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
11. Acknowledgements
11. 承認
This document is the result of extensive discussions and compromises. While not all of the participants are completely satisfied with the outcome, the document is better for their contributions.
このドキュメントは大規模な議論と妥協の結果です。 関係者のすべてを結果に完全に満たすというわけではありませんが、彼らの貢献には、ドキュメントは、より良いです。
Housley Standards Track [Page 16] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[16ページ]RFC3686
The author thanks the members of the IPsec working group for their contributions to the design, with special mention of the efforts of (in alphabetical order) Steve Bellovin, David Black, Niels Ferguson, Charlie Kaufman, Steve Kent, Tero Kivinen, Paul Koning, David McGrew, Robert Moskowitz, Jesse Walker, and Doug Whiting.
作者はデザインへの(アルファベット順に)スティーブBellovin、デヴィッドBlack、ニールズファーガソン、チャーリー・カウフマン、スティーブ・ケント、Tero Kivinen、ポール・コウニング、デヴィッド・マグリュー、ロバート・マスコウィッツ、ジェシー・ウォーカー、およびダグ・ホワイティングの努力の特記による彼らの貢献についてIPsecワーキンググループのメンバーに感謝します。
The author thanks and Alireza Hodjat, John Viega, and Doug Whiting for assistance with the test vectors.
テストベクトルがある支援のための作者感謝、Alireza Hodjat、ジョンViega、およびダグ・ホワイティング。
12. References
12. 参照
This section provides normative and informative references.
このセクションは規範的で有益な参照を提供します。
12.1. Normative References
12.1. 引用規格
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)",
November 2001.
FIPSパブ197、「エー・イー・エス(AES)」2001年11月の[AES]NIST。
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques", NIST Special
Publication 800-38A, December 2001.
[モード]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「方法とテクニック」、NISTの特別な公表800-38A、12月2001
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
12.2. Informative References
12.2. 有益な参照
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[アーチ形に曲げます] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[BDJR] Bellare, M, Desai, A., Jokipii, E. and P. Rogaway, "A
Concrete Security Treatment of Symmetric Encryption:
Analysis of the DES Modes of Operation", Proceedings 38th
Annual Symposium on Foundations of Computer Science,
1997.
[BDJR] Bellare、M、デセイ、A.、Jokipii、E.、およびP.Rogaway、「左右対称の暗号化の具体的なセキュリティ処理:」 「DES運転モードの分析」、コンピュータサイエンスの財団、1997に関する議事第38年次シンポジウム。
[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月。
Housley Standards Track [Page 17] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[17ページ]RFC3686
[JUMBO] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[ジャンボ]のボーマンとD.とデアリングとS.とR.Hinden、「IPv6 Jumbograms」、RFC2675 1999年8月。
[ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[道路地図] セイヤーとR.とDoraswamyとN.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。
[SECRQMTS] National Institute of Standards and Technology. FIPS Pub
140-1: Security Requirements for Cryptographic Modules.
11 January 1994.
[SECRQMTS]米国商務省標準技術局。 FIPSパブ140-1: 暗号のモジュールのためのセキュリティ要件。 1994年1月11日。
National Institute of Standards and Technology. FIPS Pub
140-2: Security Requirements for Cryptographic Modules.
25 May 2001. [Supercedes FIPS Pub 140-1]
米国商務省標準技術局。 FIPSパブ140-2: 暗号のモジュールのためのセキュリティ要件。 2001年5月25日。 [Supercedes FIPSパブ140-1]
13. Author's Address
13. 作者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley不寝番セキュリティ、スプリング小山Driveハーンドン、LLC918ヴァージニア20170米国
EMail: housley@vigilsec.com
メール: housley@vigilsec.com
Housley Standards Track [Page 18] RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
超能力2004年1月にIPsecがあるAESカウンタモードを使用するHousley標準化過程[18ページ]RFC3686
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 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機能のための基金は現在、インターネット協会によって提供されます。
Housley Standards Track [Page 19]
Housley標準化過程[19ページ]
一覧
スポンサーリンク
