Network Working Group J. Viega
Request for Comments: 4106 Secure Software, Inc.
Category: Standards Track D. McGrew
Cisco Systems, Inc.
June 2005
Network Working Group J. Viega
Request for Comments: 4106 Secure Software, Inc.
Category: Standards Track D. McGrew
Cisco Systems, Inc.
June 2005
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
Galois/Counter模式（GCM）在IPsec封装安全负载（ESP）中的应用
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.
本备忘录描述了在Galois/计数器模式（GCM）中使用高级加密标准（AES）作为IPsec封装安全有效负载（ESP）机制，以提供机密性和数据源身份验证。这种方法可以在10千兆比特每秒或更高速度的硬件中有效地实现，并且非常适合于软件实现。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. AES-GCM .........................................................3
3. ESP Payload Data ................................................3
3.1. Initialization Vector (IV) .................................3
3.2. Ciphertext .................................................4
4. Nonce Format ....................................................4
5. AAD Construction ................................................5
6. Integrity Check Value (ICV) .....................................5
7. Packet Expansion ................................................6
8. IKE Conventions .................................................6
8.1. Keying Material and Salt Values ............................6
8.2. Phase 1 Identifier .........................................6
8.3. Phase 2 Identifier .........................................7
8.4. Key Length Attribute .......................................7
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. AES-GCM .........................................................3
3. ESP Payload Data ................................................3
3.1. Initialization Vector (IV) .................................3
3.2. Ciphertext .................................................4
4. Nonce Format ....................................................4
5. AAD Construction ................................................5
6. Integrity Check Value (ICV) .....................................5
7. Packet Expansion ................................................6
8. IKE Conventions .................................................6
8.1. Keying Material and Salt Values ............................6
8.2. Phase 1 Identifier .........................................6
8.3. Phase 2 Identifier .........................................7
8.4. Key Length Attribute .......................................7
9. Test Vectors ....................................................7
10. Security Considerations ........................................7
11. Design Rationale ...............................................8
12. IANA Considerations ............................................8
13. Acknowledgements ...............................................9
14. Normative References ...........................................9
15. Informative References .........................................9
9. Test Vectors ....................................................7
10. Security Considerations ........................................7
11. Design Rationale ...............................................8
12. IANA Considerations ............................................8
13. Acknowledgements ...............................................9
14. Normative References ...........................................9
15. Informative References .........................................9
This document describes the use of AES in GCM mode (AES-GCM) as an IPsec ESP mechanism for confidentiality and data origin authentication. We refer to this method as AES-GCM-ESP. This mechanism is not only efficient and secure, but it also enables high-speed implementations in hardware. Thus, AES-GCM-ESP allows IPsec connections that can make effective use of emerging 10-gigabit and 40-gigabit network devices.
本文档介绍了在GCM模式下使用AES（AES-GCM）作为IPsec ESP机制进行机密性和数据源身份验证。我们将这种方法称为AES-GCM-ESP。这种机制不仅高效、安全，而且可以在硬件上实现高速实现。因此，AES-GCM-ESP允许IPsec连接，可以有效利用新兴的10千兆和40千兆网络设备。
Counter mode (CTR) has emerged as the preferred encryption method for high-speed implementations. Unlike conventional encryption modes such as Cipher Block Chaining (CBC) and Cipher Block Chaining Message Authentication Code (CBC-MAC), CTR can be efficiently implemented at high data rates because it can be pipelined. The ESP CTR protocol describes how this mode can be used with IPsec ESP [RFC3686].
计数器模式（CTR）已成为高速实现的首选加密方法。与传统的加密模式（如密码块链接（CBC）和密码块链接消息身份验证码（CBC-MAC））不同，CTR可以高效地以高数据速率实现，因为它可以流水线实现。ESP CTR协议描述了如何将此模式用于IPsec ESP[RFC3686]。
Unfortunately, CTR provides no data origin authentication, and thus the ESP CTR standard requires the use of a data origin authentication algorithm in conjunction with CTR. This requirement is problematic, because none of the standard data origin authentication algorithms can be efficiently implemented for high data rates. GCM solves this problem, because under the hood, it combines CTR mode with a secure, parallelizable, and efficient authentication mechanism.
不幸的是，CTR不提供数据源身份验证，因此ESP CTR标准要求结合CTR使用数据源身份验证算法。这一要求是有问题的，因为没有一种标准的数据源身份验证算法能够有效地实现高数据速率。GCM解决了这个问题，因为它将CTR模式与安全、可并行和高效的身份验证机制结合在一起。
This document does not cover implementation details of GCM. Those details can be found in [GCM], along with test vectors.
本文件不包括GCM的实施细节。这些细节可以在[GCM]中找到，以及测试向量。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
GCM is a block cipher mode of operation providing both confidentiality and data origin authentication. The GCM authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD). It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag. In the following, we describe how the IV, plaintext, and AAD are formed from the ESP fields, and how the ESP packet is formed from the ciphertext and authentication tag.
GCM是一种分组密码操作模式，提供机密性和数据源身份验证。GCM认证加密操作有四个输入：一个密钥、一个初始化向量（IV）、一个明文和一个用于附加认证数据（AAD）的输入。它有两个输出，一个长度与明文相同的密文和一个身份验证标签。在下文中，我们将描述如何从ESP字段形成IV、明文和AAD，以及如何从密文和身份验证标签形成ESP数据包。
ESP also defines an IV. For clarity, we refer to the AES-GCM IV as a nonce in the context of AES-GCM-ESP. The same nonce and key combination MUST NOT be used more than once.
ESP还定义了IV。为清楚起见，我们将AES-GCM IV称为AES-GCM-ESP上下文中的nonce。同一nonce和键组合不得多次使用。
Because reusing an nonce/key combination destroys the security guarantees of AES-GCM mode, it can be difficult to use this mode securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system, such as the Internet Key Exchange (IKE) [RFC2409], to ensure that this requirement is met.
由于重用nonce/密钥组合会破坏AES-GCM模式的安全保证，因此在使用静态配置密钥时，很难安全地使用此模式。为了安全起见，实现必须使用自动密钥管理系统，如Internet密钥交换（IKE）[RFC2409]，以确保满足此要求。
The ESP Payload Data is comprised of an eight-octet initialization vector (IV), followed by the ciphertext. The payload field, as defined in [RFC2406], is structured as shown in Figure 1, along with the ICV associated with the payload.
ESP有效负载数据由八个八位字节的初始化向量（IV）和密文组成。[RFC2406]中定义的有效载荷字段的结构如图1所示，以及与有效载荷相关的ICV。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ciphertext (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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ciphertext (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ESP Payload Encrypted with AES-GCM.
图1：使用AES-GCM加密的ESP有效负载。
The AES-GCM-ESP IV field MUST be eight octets. For a given key, the IV MUST NOT repeat. The most natural way to implement this is with a counter, but anything that guarantees uniqueness can be used, such as
AES-GCM-ESP IV字段必须为八个八位字节。对于给定的钥匙，IV不得重复。实现这一点最自然的方法是使用计数器，但可以使用任何保证唯一性的方法，例如
a linear feedback shift register (LFSR). Note that the encrypter can use any IV generation method that meets the uniqueness requirement, without coordinating with the decrypter.
线性反馈移位寄存器（LFSR）。请注意，加密程序可以使用满足唯一性要求的任何IV生成方法，而无需与解密程序协调。
The plaintext input to AES-GCM is formed by concatenating the plaintext data described by the Next Header field with the Padding, the Pad Length, and the Next Header field. The Ciphertext field consists of the ciphertext output from the AES-GCM algorithm. The length of the ciphertext is identical to that of the plaintext.
AES-GCM的明文输入是通过将下一个标头字段描述的明文数据与填充、填充长度和下一个标头字段连接起来而形成的。密文字段由AES-GCM算法的密文输出组成。密文的长度与明文相同。
Implementations that do not seek to hide the length of the plaintext SHOULD use the minimum amount of padding required, which will be less than four octets.
不隐藏明文长度的实现应该使用所需的最小填充量，即小于四个八位字节。
The nonce passed to the GCM-AES encryption algorithm has the following layout:
传递给GCM-AES加密算法的nonce具有以下布局：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Nonce Format
图2：Nonce格式
The components of the nonce are as follows:
nonce的组件如下所示：
Salt The salt field is a four-octet value that is assigned at the beginning of the security association, and then remains constant for the life of the security association. The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret. We describe how to set the salt for a Security Association established via the Internet Key Exchange in Section 8.1.
Salt Salt字段是在安全关联开始时指定的四个八位组的值，然后在安全关联的生命周期内保持不变。盐在被选择之前应该是不可预测的（即随机选择的），但不必是秘密的。我们在第8.1节中描述了如何为通过Internet密钥交换建立的安全关联设置salt。
Initialization Vector The IV field is described in Section 3.1.
第3.1节描述了IV字段的初始化向量。
The authentication of data integrity and data origin for the SPI and (Extended) Sequence Number fields is provided without encryption. This is done by including those fields in the AES-GCM Additional Authenticated Data (AAD) field. Two formats of the AAD are defined: one for 32-bit sequence numbers, and one for 64-bit extended sequence numbers. The format with 32-bit sequence numbers is shown in Figure 3, and the format with 64-bit extended sequence numbers is shown in Figure 4.
SPI和（扩展）序列号字段的数据完整性和数据来源的验证不需要加密。这是通过将这些字段包括在AES-GCM附加认证数据（AAD）字段中来实现的。定义了两种AAD格式：一种用于32位序列号，另一种用于64位扩展序列号。带有32位序列号的格式如图3所示，带有64位扩展序列号的格式如图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AAD Format with 32-bit Sequence Number
图3:32位序列号的AAD格式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: AAD Format with 64-bit Extended Sequence Number
图4:64位扩展序列号的AAD格式
The ICV consists solely of the AES-GCM Authentication Tag. Implementations MUST support a full-length 16-octet ICV, and MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. Although ESP does not require that an ICV be present, AES-GCM-ESP intentionally does not allow a zero-length ICV. This is because GCM provides no integrity protection whatsoever when used with a zero-length Authentication Tag.
ICV仅由AES-GCM认证标签组成。实施必须支持全长16个八位组的ICV，并且可以支持8或12个八位组的ICV，并且不得支持其他ICV长度。尽管ESP不要求ICV存在，但AES-GCM-ESP故意不允许零长度ICV。这是因为GCM在与零长度身份验证标记一起使用时不提供任何完整性保护。
The IV adds an additional eight octets to the packet, and the ICV adds an additional 8, 12, or 16 octets. These are the only sources of packet expansion, other than the 10-13 octets taken up by the ESP SPI, Sequence Number, Padding, Pad Length, and Next Header fields (if the minimal amount of padding is used).
IV向数据包添加额外的8个八位字节，ICV向数据包添加额外的8、12或16个八位字节。除了ESP SPI占用的10-13个八位字节、序列号、填充、填充长度和下一个报头字段（如果使用最小填充量）之外，这些是数据包扩展的唯一来源。
This section describes the conventions used to generate keying material and salt values, for use with AES-GCM-ESP, using the Internet Key Exchange (IKE) [RFC2409] protocol. The identifiers and attributes needed to negotiate a security association using AES-GCM-ESP are also defined.
本节描述了使用互联网密钥交换（IKE）[RFC2409]协议生成密钥材料和salt值以与AES-GCM-ESP一起使用的约定。还定义了使用AES-GCM-ESP协商安全关联所需的标识符和属性。
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 KEYMAT for the AES-GCM-ESP MUST be four octets longer than is needed for the associated AES key. The keying material is used as follows:
AES-GCM-ESP的键盘大小必须比相关AES密钥所需的长度长四个八位字节。键控材料的使用方式如下：
AES-GCM-ESP with a 128 bit key The KEYMAT requested for each AES-GCM key is 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the salt value in the nonce.
具有128位密钥的AES-GCM-ESP为每个AES-GCM密钥请求的密钥为20个八位字节。前16个八位字节是128位AES密钥，其余四个八位字节用作nonce中的salt值。
AES-GCM-ESP with a 192 bit key The KEYMAT requested for each AES-GCM key is 28 octets. The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the salt value in the nonce.
具有192位密钥的AES-GCM-ESP为每个AES-GCM密钥请求的密钥为28个八位字节。前24个八位字节是192位AES密钥，其余四个八位字节用作nonce中的salt值。
AES-GCM-ESP with a 256 bit key The KEYMAT requested for each AES GCM key is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the salt value in the nonce.
带256位密钥的AES-GCM-ESP为每个AES GCM密钥请求的键盘为36个八位字节。前32个八位字节是256位AES密钥，其余四个八位字节用作nonce中的salt值。
This document does not specify the conventions for using AES-GCM for IKE Phase 1 negotiations. For AES-GCM to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned. Implementations SHOULD use an IKE
本文件未规定将AES-GCM用于IKE第1阶段协商的约定。要以这种方式使用AES-GCM，需要单独的规范，并且需要分配加密算法标识符。实现应该使用IKE
Phase 1 cipher that is at least as strong as AES-GCM. The use of AES CBC [RFC3602] with the same key size used by AES-GCM-ESP is RECOMMENDED.
至少与AES-GCM一样强大的第1阶段密码。建议使用与AES-GCM-ESP使用的密钥大小相同的AES CBC[RFC3602]。
For IKE Phase 2 negotiations, IANA has assigned three ESP Transform Identifiers for AES-GCM with an eight-byte explicit IV:
对于IKE第2阶段协商，IANA为AES-GCM分配了三个ESP转换标识符，并带有一个8字节的显式IV：
18 for AES-GCM with an 8 octet ICV; 19 for AES-GCM with a 12 octet ICV; and 20 for AES-GCM with a 16 octet ICV.
18个AES-GCM，带有8个八位组的ICV；19用于AES-GCM，带有12个八位组ICV；AES-GCM和16个八位组ICV各20个。
Because the AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [RFC2407]. The Key Length attribute MUST have a value of 128, 192, or 256.
由于AES支持三种密钥长度，因此必须在IKE第2阶段交换[RFC2407]中指定密钥长度属性。密钥长度属性的值必须为128、192或256。
Appendix B of [GCM] provides test vectors that will assist implementers with AES-GCM mode.
[GCM]的附录B提供了测试向量，可帮助实施者使用AES-GCM模式。
GCM is provably secure against adversaries that can adaptively choose plaintexts, ciphertexts, ICVs, and the AAD field, under standard cryptographic assumptions (roughly, that the output of the underlying cipher, under a randomly chosen key, is indistinguishable from a randomly selected output). Essentially, this means that, if used within its intended parameters, a break of GCM implies a break of the underlying block cipher. The proof of security for GCM is available in [GCM].
GCM可证明对敌方是安全的，敌方可以在标准密码假设下自适应地选择明文、密文、ICV和AAD字段（大致上，在随机选择的密钥下，基础密码的输出与随机选择的输出无法区分）。本质上，这意味着，如果在其预期参数内使用，GCM的中断意味着基础分组密码的中断。[GCM]中提供了GCM的安全证明。
The most important security consideration is that the IV never repeat for a given key. In part, this is handled by disallowing the use of AES-GCM when using statically configured keys, as discussed in Section 2.
最重要的安全考虑是，对于给定的密钥，IV不会重复。在某种程度上，这是通过在使用静态配置密钥时不允许使用AES-GCM来解决的，如第2节所述。
When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows. If a different mechanism is used to establish fresh keys (one that 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, ESP
当IKE用于在两个对等实体之间建立新密钥时，将为两个业务流建立单独的密钥。如果使用不同的机制来建立新密钥（仅建立一个密钥来加密数据包的机制），则对等方很可能会为某些数据包选择相同的IV值。因此，为了避免计数器块冲突，ESP
implementations that permit use of the same key for encrypting and decrypting packets with the same peer MUST ensure that the two peers assign different salt values to the security association (SA).
允许使用同一密钥对同一对等方的数据包进行加密和解密的实现必须确保两个对等方为安全关联（SA）分配不同的salt值。
The other consideration is that, as with any encryption mode, the security of all data protected under a given security association decreases slightly with each message.
另一个考虑因素是，与任何加密模式一样，在给定安全关联下受保护的所有数据的安全性都会随着每条消息的发送而略有降低。
To protect against this problem, implementations MUST generate a fresh key before encrypting 2^64 blocks of data with a given key. Note that it is impossible to reach this limit when using 32-bit Sequence Numbers.
为了防止此问题，实现必须在使用给定密钥加密2^64个数据块之前生成一个新密钥。请注意，使用32位序列号时不可能达到此限制。
Note that, for each message, GCM calls the block cipher once for each full 16-octet block in the payload, once for any remaining octets in the payload, and one additional time for computing the ICV.
注意，对于每条消息，GCM为有效载荷中的每个完整16个八位字节块调用一次分组密码，为有效载荷中的任何剩余八位字节调用一次，并为计算ICV再调用一次。
Clearly, smaller ICV values are more likely to be subject to forgery attacks. Implementations SHOULD use as large a size as reasonable.
显然，较小的ICV值更容易受到伪造攻击。实现应该使用尽可能大的大小。
This specification was designed to be as similar to the AES-CCM ESP [CCM-ESP] and AES-CTR ESP [RFC3686] mechanisms as reasonable, while promoting simple, efficient implementations in both hardware and software. We re-use the design and implementation experience from those standards.
本规范旨在合理地与AES-CCM ESP[CCM-ESP]和AES-CTR ESP[RFC3686]机制相似，同时促进硬件和软件的简单高效实现。我们重复使用这些标准的设计和实现经验。
The major difference with CCM is that the CCM ESP mechanism requires an 11-octet nonce, whereas the GCM ESP mechanism requires using a 12-octet nonce. GCM is specially optimized to handle the 12-octet nonce case efficiently. Nonces of other lengths would cause unnecessary, additional complexity and delays, particularly in hardware implementations. The additional octet of nonce is used to increase the size of the salt.
与CCM的主要区别在于，CCM ESP机制需要11个八位字节的nonce，而GCM ESP机制需要使用12个八位字节的nonce。GCM经过特别优化，可有效处理12个八位组的非同步情况。其他长度的nonce将导致不必要的额外复杂性和延迟，特别是在硬件实现中。额外的八位字节nonce用于增加盐的大小。
IANA has assigned three ESP Transform Identifiers for AES-GCM with an eight-byte explicit IV:
IANA已为AES-GCM分配了三个ESP转换标识符，带有8字节的显式IV：
18 for AES-GCM with an 8 octet ICV; 19 for AES-GCM with a 12 octet ICV; and 20 for AES-GCM with a 16 octet ICV.
18个AES-GCM，带有8个八位组的ICV；19用于AES-GCM，带有12个八位组ICV；AES-GCM和16个八位组ICV各20个。
This work is closely modeled after Russ Housley's AES-CCM transform [CCM-ESP]. Portions of this document are directly copied from that work in progress. We thank Russ for his support of this work.
这项工作与Russ Housley的AES-CCM变换[CCM-ESP]非常相似。本文件的部分内容直接从正在进行的工作中复制。我们感谢罗斯对这项工作的支持。
Additionally, the GCM mode of operation was originally conceived as an improvement to Carter-Wegman Counter (CWC) mode [CWC], the first unencumbered block cipher mode capable of supporting high-speed authenticated encryption.
此外，GCM操作模式最初被认为是对Carter-Wegman计数器（CWC）模式[CWC]的改进，CWC是第一种能够支持高速认证加密的无阻碍分组密码模式。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", Submission to NIST. http:// csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ gcm-spec.pdf, January 2004.
[GCM]McGrew，D.和J.Viega，“伽罗瓦/计数器操作模式（GCM）”，提交给NIST。http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf，2004年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC3602] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[CCM-ESP] Housley, R., "Using AES CCM Mode With IPsec ESP", Work In Progress.
[CCM-ESP]Housley，R.，“将AES CCM模式与IPsec ESP结合使用”，正在进行中。
[CWC] Kohno, T., Viega, J. and D. Whiting, "CWC: A high-performance conventional authenticated encryption mode", Fast Software Encryption. http://eprint.iacr.org/ 2003/106.pdf, February 2004.
[CWC]Kohno，T.，Viega，J.和D.Whiting，“CWC：一种高性能传统认证加密模式”，快速软件加密。http://eprint.iacr.org/ 2003/106.pdf，2004年2月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
Authors' Addresses
作者地址
John Viega Secure Software, Inc. 4100 Lafayette Center Dr., Suite 100 Chantilly, VA 20151 US
约翰·维加安全软件公司，美国弗吉尼亚州尚蒂利市拉斐特中心4100室，邮编：20151
Phone: (703) 814 4402 EMail: viega@securesoftware.com
电话：（703）8144402电子邮件：viega@securesoftware.com
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035 US
David A.McGrew思科系统公司，位于麦卡锡大道510号。加利福尼亚州米尔皮塔斯95035美国
Phone: (408) 525 8651
EMail: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
Phone: (408) 525 8651
EMail: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。