[要約] RFC 3686は、IPsecのESPにおいて、AESブロック暗号をカウンターモード（CTR）で使用するための具体的な仕様を定義しています。従来のCBCモードと比較して、並列処理による高速化が容易であり、パディングが不要になるなどの効率上の利点があります。AES-CTRモードを安全に利用するためのノンス（Nonce）や初期化ベクトルの構造、および処理手順について詳細に記述しています。
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) における Advanced Encryption Standard (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.
このドキュメントは、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを規定するものであり、改善のための議論や提案を求めるものです。このプロトコルの標準化状態やステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。このメモの配布は制限されません。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (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.
このドキュメントでは、明示的な初期化ベクトル（IV）を伴う Advanced Encryption Standard (AES) カウンターモードを、IPsecのカプセル化セキュリティペイロード (ESP) の機密性メカニズムとして使用する方法について説明します。
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 Encryption Standard (AES) [AES] を選定しました。AESはブロック暗号であり、多くの異なるモードで使用することができます。このドキュメントでは、明示的な初期化ベクトル (IV) を伴う AESカウンターモード (AES-CTR) を、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] および [ROADMAP] で入手可能です。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[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つの動作モードを定義しています [MODES]。これらのモードはそれぞれ異なる特性を持っています。5つのモードとは、ECB (Electronic Code Book)、CBC (Cipher Block Chaining)、CFB (Cipher FeedBack)、OFB (Output FeedBack)、および CTR (Counter) です。
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と鍵の組み合わせを複数回使用してはなりません (MUST NOT)。暗号化側は、一意性を保証する任意のアルゴリズムで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 セキュリティアソシエーションの確立前に予測不可能でなければなりません (MUST)。
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暗号化することによって生成されたキーストリームとXOR演算を行うことで、暗号化および復号されます。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オクテット of ブロックが入力された後、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.
送信側はキーストリームを事前計算することができます。キーストリームはパケット内のデータに依存しないため、ノンスと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モードの実装よりも実装サイズを小さくすることができます。
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と呼ばれるパケットごとの値を一度でも再利用することは致命的（catastrophic）です。IVの衝突は、両方のパケットの平文に関する情報を即座に漏洩させます。このため、静的鍵を用いてこの動作モードを使用することは不適切です。電源サイクルをまたいで静的鍵によるIV値の再利用を防ぐには、極めて高度な対策が必要となります。安全性を確保するため、実装はAES-CTRに新しい鍵を使用しなければなりません (MUST)。新しい鍵の確立には、インターネットキーエクスチェンジ (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では、有効な暗号文を用いて別の（復号側で有効と判定される）暗号文を偽造することが容易です。したがって、併用する認証機能なしでAES-CTRを使用することも、同様に致命的です。実装は、HMAC-SHA-1-96 [HMAC-SHA] などの認証機能と組み合わせて AES-CTR を使用しなければなりません (MUST)。
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]
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ブロックはキーストリームのブロックとXOR演算され、暗号文CTが生成されます。各カウンターブロックのAES暗号化によって、128ビットのキーストリームが得られます。カウンターブロックの上位96ビットには、32ビットのノンス値と、それに続く64ビットのパケットごとのIV値が設定されます。カウンターブロックの下位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個の暗号文ブロックの復号は、次のように要約できます。
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ビットであり、すべての実装はこの鍵サイズをサポートしなければなりません (MUST)。また、実装は192ビットおよび256ビットの鍵サイズをサポートしてもよいです (MAY)。
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ラウンドを使用しなければなりません (MUST)。192ビットの鍵を使用する場合、実装は12ラウンドを使用しなければなりません (MUST)。256ビットの鍵を使用する場合、実装は14ラウンドを使用しなければなりません (MUST)。
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では平文をブロックサイズの倍数にパディングする必要はありません。ただし、[ESP]で規定されているように、限定的なトラフィックフロー機密性（TFC）を提供するためにパディングを含めてもよいです (MAY)。
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とそれに続く暗号文で構成されます。[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オクテットでなければなりません (MUST)。IVは、特定の鍵に対して同じIV値が一度しか使用されないことを保証する方法で、暗号化側によって選択されなければなりません (MUST)。暗号化側は、一意性を保証する任意の方法で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.
暗号化されたペイロードには暗号文が含まれます。
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]で説明されているように、暗号化を実行する前に、パディング、パッド長（Pad Length）、および次ヘッダー（Next Header）を平文に連結しなければなりません (MUST)。
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認証方法を採用しなければなりません (MUST)。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）：ノンスフィールドは32ビットです。その名の通り、ノンスは一度だけ使用される値（単一使用値）です。すなわち、セキュリティアソシエーションごとに新しいノンス値を割り当てなければなりません (MUST)。これはセキュリティアソシエーションの開始時に割り当てられなければなりません (MUST)。ノンスの値は秘密である必要はありませんが、セキュリティアソシエーションの開始前に予測不可能でなければなりません (MUST)。
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.
初期化ベクトル（Initialization Vector）：IVフィールドは64ビットです。セクション3.1で説明されているように、特定の鍵に対して同じIV値が一度しか使用されないことを保証する方法で、暗号化側によって選択されなければなりません (MUST)。
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.
ブロックカウンター（Block 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）-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ジャンボグラム [JUMBO] を処理するのに十分な量のキーストリームをパケットごとに生成できます。
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.
このセクションでは、Internet Key Exchange (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に新しい鍵を使用しなければなりません (MUST)。新しい鍵を確立するために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) を使用してキーイング材料を導出します。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:
要求されるKEYMATのサイズは、関連するAESキーに必要なサイズよりも4オクテット長くなければなりません (MUST)。キーイング材料は以下のように使用されます。
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鍵に対して要求されるKEYMATは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.
192ビット鍵を用いたAES-CTR：各AES-CTR鍵に対して要求されるKEYMATは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.
256ビット鍵を用いたAES-CTR：各AES-CTR鍵に対して要求されるKEYMATは36オクテットです。最初の32オクテットは256ビットのAES鍵であり、残りの4オクテットはカウンターブロックのノンス値として使用されます。
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トランスフォーム識別子（ESP Transform Identifier）として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] において鍵長（Key Length）属性を指定しなければなりません (MUST)。鍵長属性の値は128、192、または256でなければなりません (MUST)。
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ビット鍵を用いた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
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
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
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
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モードは強力な機密性を提供します。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.
しかし残念ながら、このカウンターモードは非常に誤用されやすいです。同じ鍵においてカウンターブロック値が複数のパケットで再利用された場合、双方のパケットの暗号化に同じキーストリームが使用されることになり、機密性の保証は失われます。
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)
(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.
攻撃者が、XOR演算された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に新しい鍵を使用しなければなりません (MUST)。新しい鍵の確立には、インターネットキーエクスチェンジ (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.
同じピアとの間で、送信トラフィックの暗号化と受信トラフィックの復号に同一の鍵を使用することを許可するESP実装は、2つのピアがセキュリティアソシエーションに異なるノンス値を割り当てることを保証しなければなりません (MUST)。
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 で暗号化されている場合、攻撃者はその平文を自分の好みのものに置き換えることができます。暗号文は以下の通りです。
(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 を暗号文と XOR 演算するだけで、以下を得ることができます。
(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)
Accordingly, ESP implementations MUST use of AES-CTR in conjunction with ESP authentication.
したがって、ESP実装は、ESP認証と組み合わせてAES-CTRを使用しなければなりません (MUST)。
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暗号化によって生成される暗号文がランダムな値と区別できるようになります。拡張シーケンス番号（ESN）を伴うESPでは、単一のセキュリティアソシエーションで最大 2^64 パケットの送信が許可されるため、1つの鍵で 2^64 ブロック超が暗号化される現実的な可能性があります。したがって、実装は、同一の鍵で 2^64 ブロックが暗号化される前に、新しい鍵を生成すべきです (SHOULD)。なお、すべてのパケットが最大長のIPv6ジャンボグラム [JUMBO] であっても、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.
すべてのブロック暗号モードに対して、鍵に対する中間一致（meet-in-the-middle）攻撃を可能にする、かなり一般的な事前計算攻撃が存在します。これらの攻撃は、既知の平文と既知の鍵に関連付けられた暗号文の巨大なテーブルを作成し、検索することを必要とします。事前計算攻撃を実行するのに十分なメモリとプロセッサリソースが利用可能であると仮定すると、AES-CTR（および他の任意のブロック暗号モード）の理論的な強度は 2^(n/2) ビットに制限されます（ここで n は鍵のビット数です）。長い鍵を使用することが、事前計算攻撃に対する最良の対策です。したがって、128ビットのAES鍵を使用する実装では、事前計算攻撃を困難にするための予防策を講じるべきです。カウンターブロック内の予測不可能なノンス値は、攻撃者が攻撃を成功させるために計算しなければならないテーブルのサイズを大幅に増加させます。
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.
暗号セキュリティの極めて保守的なモデルでは、単一の鍵の下でAES-CTRを用いて暗号化するブロック数は最大でも 2^64 ブロックにとどめるべきです。この制約の下では、セキュリティアソシエーション内の各パケットを識別するために必要なサイズは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. 値が複数のパケットで再利用されないことを保証できるのは暗号化側だけであるため、カウンターブロック値が衝突するかどうかを復号側が判定できるようなメカニズムを選択するメリットはありません。復号側が衝突を検出するか否かに関わらず、衝突による損害は発生してしまいます。
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. 各パケットに対して一意の値をもたらす手法である限り、加算器（adder）や線形フィードバックシフトレジスタ（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. 保証境界（Assurance boundary）は、FIPS Pub 140-1またはFIPS Pub 140-2 [SECRQMTS]に対する評価を受ける実装において非常に重要です。パケットごとのカウンターブロック値の割り当ては、保証境界内で行われる必要があります。いくつかの実装ではシーケンス番号の割り当てを保証境界内で行いますが、他の実装ではそうではありません。シーケンス番号の衝突は致命的な結果をもたらすことはありませんが、セクション7（※原文はsection 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として1フルブロックを必要とし、平均してさらに半ブロックのパディングを必要とします。明示的なIVを伴うAES-CTRのオーバーヘッドはAES-CBCの約3分の1であり、パケットごとのオーバーヘッドは一定です。
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ジャンボグラム [JUMBO] を暗号化するためのキーストリーム生成には十分ですが、実際には32ビットのフィールドが使用されています。このサイズは、ハードウェアとソフトウェアのいずれの実装にとっても好都合です。
IANA has assigned 13 as the ESP transform number for AES-CTR with an explicit IV.
IANAは、明示的なIVを伴うAES-CTRに対するESPトランスフォーム番号（ESP transform number）として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事務局長（IETF Executive Director）宛てに送付してください。
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ワーキンググループのメンバーに感謝します。特に以下のメンバーの努力に感謝します（アルファベット順）：Steve Bellovin、David Black、Niels Ferguson、Charlie Kaufman、Steve Kent、Tero Kivinen、Paul Koning、David McGrew、Robert Moskowitz、Jesse Walker、Doug Whiting。
The author thanks and Alireza Hodjat, John Viega, and Doug Whiting for assistance with the test vectors.
著者は、テストベクトルの作成を支援してくれた Alireza Hodjat、John Viega、Doug Whiting に感謝します。
This section provides normative and informative references.
このセクションでは、規準的参考文献（Normative References）と参考的参考文献（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., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, 1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (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., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", 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., "Key words for use in RFCs to Indicate Requirement Levels", 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. and R. Atkinson, "Security Architecture for the Internet Protocol", 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. 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.
[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. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE] Harkins, D. and 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.
[ROADMAP] 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] National Institute of Standards and Technology. FIPS Pub 140-1: Security Requirements for Cryptographic Modules. 11 January 1994.
National Institute of Standards and Technology. FIPS Pub 140-2: Security Requirements for Cryptographic Modules. 25 May 2001. [Supercedes FIPS Pub 140-1]
National Institute of Standards and Technology. FIPS Pub 140-2: Security Requirements for Cryptographic Modules. 25 May 2001. [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.
Copyright (C) The Internet Society (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.
このドキュメントおよびその翻訳は、複製して他者に提供することができます。また、これについてコメントしたり、説明したり、あるいはその実装を支援する派生著作物は、一切の制限なしに、全部または一部を準備、複製、公表、配布することができます。ただし、上記の著作権表示およびこの段落が、すべての複製物および派生著作物に含まれていることが条件です。しかし、このドキュメント自体は、著作権表示やインターネット協会または他のインターネット組織への参照を削除するなどのいかなる方法でも変更してはなりません。ただし、インターネット標準を開発する目的で必要な場合は除き、その場合はインターネット標準プロセスで定義されている著作権の手続きに従う必要があります。また、英語以外の言語に翻訳するために必要な場合も同様です。
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エディタ機能の資金は、現在インターネット協会によって提供されています。