[要約] 要約：RFC 3686は、IPsec Encapsulating Security Payload（ESP）でAdvanced Encryption Standard（AES） Counter Modeを使用する方法について説明しています。 目的：このRFCの目的は、AES Counter Modeを使用してIPsec ESPでデータを暗号化するためのガイドラインとセキュリティ上の考慮事項を提供することです。
Network Working Group R. Housley
Request for Comments: 3686 Vigil Security
Category: Standards Track January 2004
Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
IPSECをカプセル化するセキュリティペイロード（ESP）を使用した高度な暗号化標準（AES）カウンターモードの使用
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
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）カウンターモードの使用について、セキュリティペイロード（ESP）の機密性メカニズムをカプセル化するIPSECとして説明します。
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
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
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）は最近、Rijndaelとも呼ばれるAdvanced暗号化標準（AES）[AES]を選択しました。AESはブロック暗号であり、多くの異なるモードで使用できます。このドキュメントでは、AESカウンターモード（AES-CTR）の使用について、明示的な初期化ベクトル（IV）を使用して、セキュリティペイロードをカプセル化するIPSEC（ESP）[ESP]機密性メカニズムとして説明しています。
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]および[ロードマップ]で利用可能です。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[stdwords]で説明されていると解釈されます。
This section contains a brief description of the relevant characteristics of the AES block cipher. Implementation requirements are also discussed.
このセクションには、AESブロック暗号の関連する特性の簡単な説明が含まれています。実装要件についても説明します。
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およびその他のFIPS承認ブロック暗号の5つの動作モード[モード]を定義しています。これらの各モードには異なる特性があります。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 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カウンターモード（AES-CTR）のみが説明されています。AES-CTRでは、暗号化業者が一意のパケットごとの値を生成し、この値を復号化者に伝える必要があります。この仕様は、このパケットごとの値を初期化ベクトル（IV）と呼びます。同じIVとキーの組み合わせを複数回使用してはなりません。暗号化業者は、一意性を保証するあらゆる方法でIVを生成できます。IV生成への一般的なアプローチには、各パケットおよび線形フィードバックシフトレジスタ（LFSR）のカウンターの増分が含まれます。
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.
この仕様では、事前計算攻撃に対する追加の保護のためにNonCEを使用する必要があります。ノンセの値は秘密である必要はありません。ただし、AES-CTRを使用しているIPSECセキュリティ協会の設立前に、NonCEは予測不可能でなければなりません。
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ブロック暗号を使用してストリーム暗号を作成します。データは、AESによって生成されたキーストリームを使用してシーケンシャルカウンターブロック値を暗号化することにより、暗号化および復号化されます。AES-CTRは簡単に実装でき、AES-CTRはパイプライン化および並列化できます。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を参照）。ハードウェアの実装（および一部のソフトウェア実装）は、このラウンド構造によって暗示されるループを巻き戻すことにより、パイプラインを作成できます。たとえば、16オクセットのブロックが入力された後、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暗号化の実装を使用して、パフォーマンスを向上させることもできます。たとえば、2つのAESを使用して実装を並行して暗号化して、一連のカウンターブロック値を処理して、効果的なスループットを2倍にすることができます。
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.
送信者は、キーストリームをプリピュートできます。キーストリームはパケット内のデータに依存しないため、NonCeと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の唯一の暗号化操作（暗号化と復号化の両方）を使用して、他の多くのAESモードの実装よりもAES-CTR実装を小さくします。
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 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.
正しく使用すると、AES-CTRは高レベルの機密性を提供します。残念ながら、AES-CTRは誤って使いやすいです。ストリーム暗号であるため、IVと呼ばれるパケットごとの値の再利用は、同じノンセとキーを使用して壊滅的です。IVの衝突は、両方のパケットの平文に関する情報をすぐに漏らします。このため、静的キーでこの動作モードを使用することは不適切です。電源サイクル全体で静的キーを使用したIV値の再利用を防ぐには、並外れた測定が必要です。安全にするには、実装がAES-CTRを備えた新鮮なキーを使用する必要があります。インターネットキーエクスチェンジ（IKE）[IKE]プロトコルを使用して、新しいキーを確立できます。Ikeは、NonCe値を提供することもできます。
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を使用してペイロードを暗号化するには、暗号化者がプレーンテキストPTを128ビットブロックに分割します。最終ブロックは128ビットである必要はありません。それは少ないかもしれません。
PT = PT[1] PT[2] ... PT[n]
pt = pt [1] pt [2] ... pt [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ブロックは、キーストリームのブロックでXoredで、Ciphertext、CT。各カウンターブロックのAES暗号化は、128ビットのキーストリームになります。最も重要な96ビットのカウンターブロックは、32ビットであるNonCE値に設定され、その後、パケットごとのIV値（64ビット）が続きます。最も重要な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))
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暗号操作の出力を最終的なプレーンテキストブロックと同じ長さに切り捨て、最も重要なビットを返します。
Decryption is similar. The decryption of n ciphertext blocks can be summarized as:
復号化は似ています。n ciphertextブロックの復号化は、次のように要約できます。
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))
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は、128ビット、192ビット、256ビットの3つのキーサイズをサポートしています。デフォルトのキーサイズは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ラウンドを使用する必要があります。
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です。生成されたキーストリームがPlantextまたはciphertextよりも長い場合、追加のキーストリームビットは単に破棄されます。このため、AES-CTRでは、プレーンテキストをブロックサイズの倍数にパッドでパッドにする必要はありません。ただし、[ESP]で指定されているように、トラフィックフローの機密性が限られているため、パディングが含まれる場合があります。
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.
ESPペイロードは、IVで構成され、その後のCiphertextが続きます。[ESP]で定義されているペイロードフィールドは、図1に示すように構成されています。
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. ESP Payload Encrypted with AES-CTR
図1. AES-CTRで暗号化されたESPペイロード
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値が1回だけ使用されることを保証する方法で、暗号化業者によって選択される必要があります。暗号化業者は、一意性を保証するあらゆる方法でIVを生成できます。IV生成への一般的なアプローチには、各パケットおよび線形フィードバックシフトレジスタ（LFSR）のカウンターの増分が含まれます。
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を含めることで、一部のパケットが紛失または再注文された場合でも、復号化に必要なキーストリームを復号化できることが保証されます。
The encrypted payload contains the ciphertext.
暗号化されたペイロードには、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モードでは、プレーンテキストパディングは必要ありません。ただし、ESPでは、認証データを32ビットワードアライに合わせてパディングが必要です。[ESP]で説明されているように、暗号化を実行する前に、パディング、パッドの長さ、および次のヘッダーをプレーンテキストと連結する必要があります。
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 ciphertextから偽造AES-CTR暗号文を構築することは些細なことであるため、AES-CTR実装は非ヌルESP認証方法を採用する必要があります。HMAC-SHA-1-96 [HMAC-SHA]は選択肢です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 nonceフィールドは32ビットです。名前が示すように、ノンセは単一の使用値です。つまり、セキュリティ協会ごとに新たなNONCE値を割り当てる必要があります。セキュリティ協会の開始時に割り当てる必要があります。ノンセの値は秘密である必要はありませんが、セキュリティ協会の開始前に予測不可能でなければなりません。
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.
初期化ベクター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.
ブロックカウンターブロックカウンターフィールドは、カウンターブロックの最も重要ではない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）-1ブロック= 4,294,967,295ブロック= 68,719,476,720オクテット
This construction can produce enough key stream for each packet sufficient to handle any IPv6 jumbogram [JUMBO].
この構造は、IPv6ジャンボグラム[ジャンボ]を処理するのに十分なパケットごとに十分なキーストリームを生成できます。
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.
このセクションでは、インターネットキーエクスチェンジ（IKE）[IKE]プロトコルを使用して、AES-CTRで使用するためのキーイング材料と非能力を生成するために使用される規則について説明します。AES-CTRを使用するセキュリティ協会をネゴシエートするために必要な識別子と属性も定義されています。
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から予測不可能なNonCe値を取得するための慣習について説明します。この条約は、予測不可能であると同時に秘密であるNonCE値を提供していることに注意してください。
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）を使用してキーイング材料を導き出します。PRFは、keymatと呼ばれる任意のサイズのキーイング材料を導き出すために繰り返し使用されます。キーイング材料は、境界に関係なく出力文字列から抽出されます。
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:
要求されたキーマットのサイズは、関連する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.
128ビットキー付きAES-CTR各AES-CTRキーに対して要求されたキーマットは20オクテットです。最初の16個のオクテットは128ビットAESキーで、残りの4個のオクテットはカウンターブロックのNonCE値として使用されます。
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.
192ビットキー付きAES-CTRは、各AES-CTRキーに対して要求されたキーマットが28オクテットです。最初の24個のオクテットは192ビットAESキーであり、残りの4個のオクテットはカウンターブロックのNonCE値として使用されます。
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.
256ビットキー付きAES-CTR各AES-CTRキーに対して要求されるキーマットは36オクテットです。最初の32個のオクテットは256ビットAESキーであり、残りの4個のオクテットはカウンターブロックのNonCE値として使用されます。
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フェーズ1交渉にAES-CTRを使用するための規則を指定していません。この方法でAES-CTRを使用するには、個別の仕様が必要であり、暗号化アルゴリズム識別子を割り当てる必要があります。
For IKE Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 13 for AES-CTR with an explicit IV.
IKEフェーズ2の交渉では、IANAは明示的なIVでAES-CTRのESP変換識別子13を割り当てました。
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フェーズ2エクスチェンジ[DOI]でキー長属性を指定する必要があります。キー長属性の値は、128、192、または256の値を持っている必要があります。
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.
このセクションには、実装がAES-CTRを正しく実装していることを確認するために使用できる9つのテストベクトルが含まれています。最初の3つのテストベクトルは、128ビットキーを持つAEを使用します。次の3つのテストベクトルは、192ビットキーでAEを使用します。最後の3つのテストベクトルは、256ビットキーのAEを使用します。
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キーを使用してAES-CTRを使用して16オクテットを暗号化するキー：AE 68 52 F8 12 10 67 CC 4B F7 A5：00 00 00 30 PLANTEXT STRING： 'シングルブロックMSG' PLANTEXT：53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67カウンターブロック（1）：00 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 01キーストリーム（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 B88
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キーを使用したAES-CTRを使用した32オクテットの暗号化キー：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プレーンテキスト：00 01 02 03 04 05 06 07 07 08 09 0A 0B 0C 0D 0E 0F：10 11 12 13 14 15 16 17 18 19 1A 1B 1D 1E 1Fカウンターブロック（1）：00 6C B6 db dbC0 54 3B 59 DA 48 D9 0B 00 00 00 01キーストリーム（1）：51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87カウンターブロック（2）：00 6C B6 DB C0 54 3B 59 DA 48D9 0B 00 00 00 02キーストリーム（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 2E 1E 1E 1EFC 46 DA 57 C8 FC E6 30 DF 91 41 BE 28
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
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キーを使用してAES-CTRを使用して16オクテットを暗号化します：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 Plantext String： 'シングルブロックMSG'プレーンテキスト：53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67カウンターブロック（1）：00 00 00 48 4836 73 3c 14 7d 6d 93 CB 00 00 00 01キーストリーム（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 CBE9 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
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
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キーを使用してAES-CTRを使用して16オクテットを暗号化するキー：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 E6C1 C1 04 AES-CTR IV：DB 56 72 C9 7A 7A A8 F0 B2 NONCE：00 00 00 60 PLANTEXT STRING： 'SINGR BLOCK MSG' PLANTEXT：53 69 6E 67 6C 65 20 62 6C 6F 63 6b 20 6d 73 67カウンターブロックブロックブロックブロック（1）：00 00 00 60 dB 56 72 C9 7A A8 F0 B2 00 00 00 01キーストリーム（1）：47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7 CIPHERTEXT：14 5A D0 1D BF 8282824E C7 56 08 63 DC 71 E3 E0 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
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
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モードは強力な機密性を提供します。[BDJR]のBellare、Desai、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:
暗号化者が2つの異なるプレーンテキストを備えた同じキーストリームをXorした場合はどうなりますか？2つのプレーンテキストバイトシーケンスP1、P2、P3、Q1、Q2、Q3が両方ともキーストリームK1、K2、K3で暗号化されているとします。対応する2つの暗号文は次のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1 XOR K1）、（P2 XOR K2）、（P3 XOR K3）
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
（Q1 XOR K1）、（Q2 XOR K2）、（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
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.
攻撃者が2つのプレーンテキストを一緒に取得すると、それらを分離するのは比較的簡単です。したがって、AES-CTRを含むストリーム暗号を使用して、同じキーストリームの下で2つのプレーンテキストを暗号化すると、プレーンテキストが漏れます。
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を使用することは不適切です。パワーサイクル全体で静的キーを使用したカウンターブロック値の再利用を防ぐためには、並外れた測定が必要です。安全には、ESP実装では、AES-CTRを備えた新鮮なキーを使用する必要があります。インターネットキーエクスチェンジ（IKE）プロトコル[IKE]を使用して、新しいキーを確立できます。Ikeは、セキュリティ協会の開始時にNonCEを確立するためにも使用できます。
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.
ESPの実装は、アウトバウンドトラフィックを暗号化し、同じピアで入ってくるトラフィックを復号化するために同じキーを使用しているため、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、K2、K3で暗号化されている場合、攻撃者はプレーンテキストを自分の選択の1つに置き換えることができます。ciphertextは次のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1 XOR K1）、（P2 XOR K2）、（P3 XOR K3）
The attacker simply XORs a selected sequence Q1, Q2, Q3 with the ciphertext to obtain:
攻撃者は、選択したシーケンスQ1、Q2、Q3をXARSでXORSするだけで、取得します。
(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
（Q1 XOR（P1 XOR K1））、（Q2 XOR（P2 XOR K2））、（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)
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）
Accordingly, ESP implementations MUST use of AES-CTR in conjunction with ESP authentication.
したがって、ESPの実装は、ESP認証と組み合わせて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ビットブロックサイズを持っているため、AES暗号化によって生成される暗号文は、2^64ブロックが単一のキーで暗号化された後、ランダム値と区別できます。シーケンス番号が拡張されたESPは、単一のセキュリティアソシエーションで最大2^64パケットを可能にするため、2^64を超えるブロックを1つのキーで暗号化する実際の可能性があります。したがって、2^64ブロックが同じキーで暗号化される前に、実装は新しいキーを生成する必要があります。すべてのパケットが最大長のIPv6ジャンボグラム[ジャンボ]であっても、32ビットシーケンス番号を持つESPは2^64ブロックを超えないことに注意してください。
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）ビットに制限されます。キー。長いキーを使用することは、事前計算攻撃に対する最良の対策です。したがって、128ビットのAESキーを使用する実装は、事前計算攻撃をより困難にするための予防策を講じる必要があります。カウンターブロック内の予測不可能なNONCE値は、攻撃者が成功した攻撃を実施するために計算しなければならないテーブルのサイズを大幅に増加させます。
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フィールドの代わりにESPシーケンス番号フィールドの使用が考慮されました。どちらのアプローチもカウンターブロックの衝突を防ぐため、この選択は暗号化のセキュリティの問題ではありません。
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ビット以下が必要です。ESP拡張シーケンス数は64ビットであるため、暗黙的なIVとして使用する明らかな候補です。これにより、カウンターブロックにパケットごとの値を割り当てるための単一の方法が決定されます。明示的なIVの使用は、そのような方法を指示するものではなく、いくつかの理由で望ましいです。
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. 暗号化業者のみが、値が複数のパケットに使用されないことを保証できるため、復号化者がカウンターブロック値が衝突するかどうかを判断できるメカニズムを選択する利点はありません。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. テクニックが各パケットに一意の値をもたらす限り、暗号化装置の時間予算を満たす追加者、LFSR、およびその他の手法を許可します。加算器は実装するのが簡単で簡単ですが、キャリーのために、一定の時間では実行されません。LFSRは、一定の時間で実行される代替品を提供します。
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. 複雑さは実装者を制御しています。さらに、エンクリープターの実装者による決定は、復号化者をより複雑にするものではありません。
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. 暗号化業者に複数の暗号化ハードウェアデバイスがある場合、IVプレフィックスを各デバイスに割り当てて、衝突が発生しないようにします。しかし、復号化者はIV構造を調べる必要がないため、復号化師は暗号化者によって選択されたIV構造の影響を受けません。ESPシーケンス番号を使用して同じ手法を使用することはできません。これらのセマンティクスには、シーケンシャル値生成が必要だからです。
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 Pub 140-1またはFIPS Pub 140-2 [SECRQMTS]に対して評価される実装にとって非常に重要です。パケットごとのカウンターブロック値の割り当ては、保証境界内にある必要があります。いくつかの実装は、保証境界内にシーケンス番号を割り当てますが、他のものはそうではありません。シーケンス数の衝突には悲惨な結果はありませんが、セクション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 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フィールドの使用は、シーケンス番号とパケットごとのカウンターブロック値のデカップリングから直接続きます。IVフィールドの64ビットに関連付けられたオーバーヘッドは許容されます。このオーバーヘッドは、暗号ブロックチェーン（CBC）モードに関連付けられたオーバーヘッドよりも大幅に少ないです。通常使用されているように、CBCはIVの完全なブロックを必要とし、平均してパディングのブロックの半分を必要とします。明示的なIVを持つAES-CTRは、オーバーヘッドの約3分の1をAES-CBCとして持ち、各パケットのオーバーヘッドは一定です。
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ジャンボグラム[ジャンボ]を暗号化するためにキーストリームの生成に十分です。ただし、32ビットフィールドが使用されます。このサイズは、ハードウェアとソフトウェアの両方の実装に便利です。
IANA has assigned 13 as the ESP transform number for AES-CTR with an explicit IV.
IANAは、明示的なIVでAES-CTRのESP変換番号として13を割り当てました。
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は、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができます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エグゼクティブディレクターに宛ててください。
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.
このドキュメントは、広範な議論と妥協の結果です。すべての参加者が結果に完全に満足しているわけではありませんが、この文書は貢献により優れています。
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.
著者は、（アルファベット順の）スティーブベロビン、デビッドブラック、ニールズファーガソン、チャーリーカウフマン、スティーブケント、テロキビネン、ポールコニング、ポールコニングの努力について特に言及して、デザインへの貢献についてIPSECワーキンググループのメンバーに感謝します。デビッド・マクグリュー、ロバート・モスコビッツ、ジェシー・ウォーカー、ダグ・ホワイティング。
The author thanks and Alireza Hodjat, John Viega, and Doug Whiting for assistance with the test vectors.
著者は、テストベクターの支援を求めて、Alireza Hodjat、John Viega、Doug Whitingの感謝とDoug Whiting。
This section provides normative and informative references.
このセクションでは、規範的で有益な参照を提供します。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", November 2001.
[AES] Nist、Fips Pub 197、「Advanced Encryption Standard（AES）」、2001年11月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[doi] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", NIST Special Publication 800-38A, December 2001.
[Modes] Dworkin、M。、「操作のブロックモードの推奨：方法とテクニックの推奨」、NIST Special Publication 800-38A、2001年12月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[stdwords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[Arch] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[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、Desai、A.、Jokipii、E。、およびP. Rogaway、「対称暗号化の具体的なセキュリティ処理：DESモードの分析」、議事録38th Annual Symposium on Computer Science、1997。
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMAC-SHA] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[JUMBO] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[Jumbo] Borman、D.、Deering、S。and R. Hinden、「IPv6 Jumbograms」、RFC 2675、1999年8月。
[ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ロードマップ] Thayer、R.、Doraswamy、N。and R. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[SECRQMTS] National Institute of Standards and Technology. FIPS Pub 140-1: Security Requirements for Cryptographic Modules. 11 January 1994.
[SECRQMTS]国立標準技術研究所。FIPS Pub 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 PUB 140-2：暗号化モジュールのセキュリティ要件。2001年5月25日。[Supercedes Fips Pub 140-1]
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。