Network Working Group R. Housley
Request for Comments: 3686 Vigil Security
Category: Standards Track January 2004
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）互联网协会（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）计数器模式（带有显式初始化向量）作为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
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
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）最近选择了高级加密标准（AES）[AES]，也称为Rijndael。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概述。但是，[ARCH]和[ROADMAP]中提供了有关IPsec各个组件如何以及它们共同提供安全服务的方式的信息。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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批准的分组密码定义了五种操作模式[模式]。每种模式都有不同的特点。这五种模式是：ECB（电子码本）、CBC（密码块链接）、CFB（密码反馈）、OFB（输出反馈）和CTR（计数器）。
Only AES Counter mode (AES-CTR) is discussed in this specification. AES-CTR requires the encryptor to generate a unique per-packet value, and communicate this value to the decryptor. This specification calls this per-packet value an initialization vector (IV). The same IV and key combination MUST NOT be used more than once. The
本规范仅讨论AES计数器模式（AES-CTR）。AES-CTR要求加密程序生成唯一的每包值，并将该值传送给解密程序。本规范将此每个数据包的值称为初始化向量（IV）。同一IV和钥匙组合不得使用多次。这个
encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
加密机可以以确保唯一性的任何方式生成IV。产生IV的常用方法包括为每个数据包增加一个计数器和线性反馈移位寄存器（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来提供额外的保护，防止预计算攻击。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加密顺序计数器块值生成的密钥流进行XORing加密和解密。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个八位字节块后，一轮之后可以输入另一个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加密实现来提高性能。例如，可以并行使用两个AES加密实现来处理计数器块值序列，使有效吞吐量加倍。
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-CTR实现比许多其他AES模式的实现更小。
When used correctly, AES-CTR provides a high level of confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. Being a stream cipher, any reuse of the per-packet value, called the IV, with the same nonce and key is catastrophic. An IV collision immediately leaks information about the plaintext in both packets. For this reason, it is inappropriate to use this mode of operation
正确使用时，AES-CTR可提供高度机密性。不幸的是，AES-CTR很容易被错误地使用。作为一种流密码，使用相同的nonce和key重用每个数据包的值（称为IV）是灾难性的。IV冲突会立即泄漏两个数据包中的明文信息。因此，使用这种操作模式是不合适的
with static keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) [IKE] protocol can be used to establish fresh keys. IKE can also provide the nonce value.
使用静态键。需要采取特殊措施，防止在整个电源循环中重复使用带有静态键的IV值。为了安全起见，实现必须使用AES-CTR的新密钥。因特网密钥交换（IKE）[IKE]协议可用于建立新密钥。IKE还可以提供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，使用有效的密文伪造其他（对解密程序有效的）密文是很简单的。因此，使用AES-CTR而不附带认证功能同样是灾难性的。实现必须将AES-CTR与身份验证功能结合使用，如HMAC-SHA-1-96[HMAC-SHA]。
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块与密钥流的块异或，以生成密文CT。每个计数器块的AES加密产生128位密钥流。计数器块的最高有效96位被设置为nonce值（32位），然后是每个分组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))
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加密。
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.
函数的作用是：将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))
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位。默认密钥大小为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加密是密钥流与明文的异或。AES-CTR解密是密钥流与密文的异或。如果生成的密钥流比明文或密文长，那么额外的密钥流位将被简单地丢弃。因此，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和密文组成。[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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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字段必须为八个八位字节。加密机必须以某种方式选择IV，以确保对给定密钥只使用一次相同的IV值。加密机可以以确保唯一性的任何方式生成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]中所述，在执行加密之前，必须将填充、填充长度和下一个标头与明文连接起来。
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实现必须采用非空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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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是一个单次使用值。也就是说，必须为每个安全关联分配一个新的nonce值。必须在安全关联开始时分配它。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个块=4294967295个块=68719476720个八位字节
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.
本节描述了使用互联网密钥交换（IKE）[IKE]协议生成用于AES-CTR的密钥材料和nonce的约定。还定义了协商使用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:
请求的KEYMAT的大小必须比关联AES密钥所需的长度长四个八位字节。键控材料的使用方式如下：
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密钥，其余四个八位字节用作计数器块中的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密钥，其余四个八位字节用作计数器块中的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密钥，其余四个八位字节用作计数器块中的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为AES-CTR分配了一个ESP转换标识符13，带有一个显式IV。
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支持三种密钥长度，因此必须在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。前三个测试向量使用具有128位密钥的AES；接下来的三个测试向量使用带有192位密钥的AES；最后三个测试向量使用带256位密钥的AES。
Test Vector #1: Encrypting 16 octets using AES-CTR with 128-bit key AES Key : AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E AES-CTR IV : 00 00 00 00 00 00 00 00 Nonce : 00 00 00 30 Plaintext String : 'Single block msg' Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 Counter Block (1): 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01 Key Stream (1): B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF Ciphertext : E4 09 5D 4F B7 A7 B3 79 2D 61 75 A3 26 13 11 B8
测试向量#1：使用128位密钥AES-CTR加密16个八位字节AES密钥：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 00 00 00 00 00 00 00 00 00 00 00 00 30明文字符串：“单块消息”明文：53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67计数器块（1）：00 00 00 00 00 00 00 00 00 00 01密钥流（1）：B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF密文：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
测试向量#2：使用AES-CTR和128位密钥加密32个八位字节AES密钥：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 07 08 09 0A 0B 0C 0D 0F:10 11 12 13 15 16 18 19 1A 1C 1D 1F计数器块（1）：00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 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 48 D9 0B 00 00 02密钥流（2）：FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37密文：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 #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：使用AES-CTR和192位密钥加密16个八位字节AES密钥：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 00 48明文字符串：“单块消息”明文：53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67计数器块（1）：00 00 00 48 36 73 3C 14 7D 6D 93 CB 00 00 01密钥流（1）：18 3C 56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F密文：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 #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 #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：使用AES-CTR和256位密钥加密16个八位字节AES密钥：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 04 AES-CTR IV:DB 56 72 C9 7A A8 F0 B2 Nonce:00 00 00 60明文字符串：“单块消息”明文：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密文：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 #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
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:
如果加密程序用两个不同的明文对同一密钥流进行异或，会发生什么情况？假设两个明文字节序列P1、P2、P3和Q1、Q2、Q3都使用密钥流K1、K2、K3加密。两个相应的密文是：
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1异或K1），（P2异或K2），（P3异或K3）
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
（Q1异或K1）、（Q2异或K2）、（Q3异或K3）
If both of these two ciphertext streams are exposed to an attacker, then a catastrophic failure of confidentiality results, since:
如果这两个密文流都暴露给攻击者，则会导致灾难性的保密失败，因为：
(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
(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.
一旦攻击者获得两个异或在一起的明文，就可以相对直接地将它们分开。因此，使用任何流密码（包括AES-CTR）对同一密钥流下的两个明文进行加密都会泄漏明文。
Therefore, stream ciphers, including AES-CTR, should not be used with static keys. It is inappropriate to use AES-CTR with static keys. Extraordinary measures would be needed to prevent reuse of a counter block value with the static key across power cycles. To be safe, ESP implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) protocol [IKE] can be used to establish fresh keys. IKE can also be used to establish the nonce at the beginning of the security association.
因此，流密码（包括AES-CTR）不应与静态密钥一起使用。使用带有静态键的AES-CTR是不合适的。需要采取特殊措施，防止在整个电源循环中重复使用带有静态键的计数器块值。为了安全起见，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用于在两个对等实体之间建立新密钥时，将为两个业务流建立单独的密钥。当使用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实现必须确保两个对等方为安全关联分配不同的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模式下，数据伪造是微不足道的。此攻击的演示类似于上面的密钥流重用讨论。如果使用密钥流K1、K2、K3对已知明文字节序列P1、P2、P3进行加密，则攻击者可以使用自己选择的明文替换明文。密文是：
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1异或K1），（P2异或K2），（P3异或K3）
The attacker simply XORs a selected sequence Q1, Q2, Q3 with the ciphertext to obtain:
攻击者只需将选定序列Q1、Q2、Q3与密文异或即可获得：
(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
（Q1-XOR（P1-XOR-K1）），（Q2-XOR（P2-XOR-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)
((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异或P1）、（Q2异或P2）、（Q3异或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个以上的数据块的可能性很大。因此，在使用相同的密钥加密2^64个块之前，实现应该生成一个新密钥。请注意，具有32位序列号的ESP不会超过2^64个块，即使所有数据包都是最大长度的IPv6巨型程序[JUMBO]。
There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES-CTR (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. Therefore, implementations that employ 128-bit AES keys should take precautions to make the precomputation attacks more difficult. The unpredictable nonce value in the counter block significantly increases the size of the table that the attacker must compute to mount a successful attack.
存在针对所有分组密码模式的相当通用的预计算攻击，这些攻击允许针对密钥的中间相遇攻击。这些攻击需要创建和搜索与已知明文和已知密钥相关的大量密文表。假设内存和处理器资源可用于预计算攻击，则AES-CTR（和任何其他分组密码模式）的理论强度限制为2^（n/2）位，其中n是密钥中的位数。使用长密钥是对付预计算攻击的最佳对策。因此，采用128位AES密钥的实现应采取预防措施，使预计算攻击更加困难。计数器块中不可预测的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.
在制定本规范时，考虑使用ESP序列号字段代替显式IV字段。此选择不是加密安全问题，因为这两种方法都可以防止计数器块冲突。
In a very conservative model of encryption security, at most 2^64 blocks ought to be encrypted with AES-CTR under a single key. Under this constraint, no more than 64 bits are needed to identify each packet within a security association. Since the ESP extended sequence number is 64 bits, it is an obvious candidate for use as an implicit IV. This would dictate a single method for the assignment of per-packet value in the counter block. The use of an explicit IV does not dictate such a method, which is desirable for several reasons.
在一个非常保守的加密安全模型中，最多2^64个块应该在一个密钥下用AES-CTR加密。在此约束下，标识安全关联中的每个数据包不需要超过64位。由于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. 允许加法器、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
显式IV字段的使用直接遵循序列号和每包计数器块值的解耦。与IV字段的64位相关的开销是可以接受的。此开销明显小于与密码块链接（CBC）模式相关联的开销。与通常使用的一样，CBC需要
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的AES-CTR的开销约为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.
包含nonce提供了一种针对预计算攻击的弱对策。要使此对策有效，攻击者必须不能在安全关联建立之前很好地预测nonce的值。长密钥的使用为预计算攻击提供了强有力的对策，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已指定13作为AES-CTR的ESP转换号，并带有一个显式IV。
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工作组成员对设计的贡献，并特别提到（按字母顺序排列）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.
本节提供了规范性和信息性参考。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", November 2001.
[AES]NIST，FIPS PUB 197，“高级加密标准（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.
[模式]德沃金，M.，“分组密码操作模式的建议：方法和技术”，NIST特别出版物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操作模式分析”，《第38届计算机科学基础年会论文集》，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，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[JUMBO] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[JUMBO]Borman，D.，Deering，S.和R.Hinden，“IPv6巨型程序”，RFC 26751999年8月。
[ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[路线图]Thayer，R.，Doraswamy，N.和R.Glenn，“IP安全文档路线图”，RFC 24111998年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日。[取代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，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（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编辑功能的资金目前由互联网协会提供。