Network Working Group D. McGrew
Request for Comments: 5116 Cisco Systems, Inc.
Category: Standards Track January 2008
Network Working Group D. McGrew
Request for Comments: 5116 Cisco Systems, Inc.
Category: Standards Track January 2008
An Interface and Algorithms for Authenticated Encryption
一种用于认证加密的接口和算法
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）。本备忘录的分发不受限制。
Abstract
摘要
This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.
本文档定义了用于关联数据认证加密（AEAD）的算法，并定义了此类算法的统一接口和注册表。接口和注册表可以用作一组独立于应用程序的加密算法套件。这种方法在效率和安全性方面具有优势，并促进了加密实现的重用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Conventions Used in This Document . . . . . . . . . . . . 4
2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 5
2.2. Authenticated Decryption . . . . . . . . . . . . . . . . . 7
2.3. Data Formatting . . . . . . . . . . . . . . . . . . . . . 7
3. Guidance on the Use of AEAD Algorithms . . . . . . . . . . . . 8
3.1. Requirements on Nonce Generation . . . . . . . . . . . . . 8
3.2. Recommended Nonce Formation . . . . . . . . . . . . . . . 9
3.2.1. Partially Implicit Nonces . . . . . . . . . . . . . . 10
3.3. Construction of AEAD Inputs . . . . . . . . . . . . . . . 11
3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
4. Requirements on AEAD Algorithm Specifications . . . . . . . . 12
5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 14
5.2. AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 15
5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 16
5.4. AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Conventions Used in This Document . . . . . . . . . . . . 4
2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 5
2.2. Authenticated Decryption . . . . . . . . . . . . . . . . . 7
2.3. Data Formatting . . . . . . . . . . . . . . . . . . . . . 7
3. Guidance on the Use of AEAD Algorithms . . . . . . . . . . . . 8
3.1. Requirements on Nonce Generation . . . . . . . . . . . . . 8
3.2. Recommended Nonce Formation . . . . . . . . . . . . . . . 9
3.2.1. Partially Implicit Nonces . . . . . . . . . . . . . . 10
3.3. Construction of AEAD Inputs . . . . . . . . . . . . . . . 11
3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
4. Requirements on AEAD Algorithm Specifications . . . . . . . . 12
5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 14
5.2. AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 15
5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 16
5.4. AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authenticated encryption [BN00] is a form of encryption that, in addition to providing confidentiality for the plaintext that is encrypted, provides a way to check its integrity and authenticity. Authenticated Encryption with Associated Data, or AEAD [R02], adds the ability to check the integrity and authenticity of some Associated Data (AD), also called "additional authenticated data", that is not encrypted.
认证加密[BN00]是一种加密形式，除了为加密的明文提供保密性外，还提供了一种检查其完整性和真实性的方法。使用关联数据进行身份验证加密，或AEAD[R02]，增加了检查未加密的某些关联数据（AD）（也称为“附加身份验证数据”）的完整性和真实性的能力。
Many cryptographic applications require both confidentiality and message authentication. Confidentiality is a security service that ensures that data is available only to those authorized to obtain it; usually it is realized through encryption. Message authentication is the service that ensures that data has not been altered or forged by unauthorized entities; it can be achieved by using a Message Authentication Code (MAC). This service is also called data integrity. Many applications use an encryption method and a MAC together to provide both of those security services, with each algorithm using an independent key. More recently, the idea of providing both security services using a single cryptoalgorithm has become accepted. In this concept, the cipher and MAC are replaced by an Authenticated Encryption with Associated Data (AEAD) algorithm.
许多加密应用程序需要保密性和消息身份验证。保密性是一种安全服务，确保数据仅可供授权获取者使用；通常是通过加密来实现的。消息认证是确保数据未被未经授权的实体篡改或伪造的服务；它可以通过使用消息身份验证码（MAC）来实现。此服务也称为数据完整性。许多应用程序同时使用加密方法和MAC来提供这两种安全服务，每种算法使用一个独立的密钥。最近，使用单一加密算法提供两种安全服务的想法已被接受。在这个概念中，密码和MAC被关联数据认证加密（AEAD）算法取代。
Several crypto algorithms that implement AEAD algorithms have been defined, including block cipher modes of operation and dedicated algorithms. Some of these algorithms have been adopted and proven useful in practice. Additionally, AEAD is close to an 'idealized' view of encryption, such as those used in the automated analysis of cryptographic protocols (see, for example, Section 2.5 of [BOYD]).
已经定义了几种实现AEAD算法的加密算法，包括分组密码操作模式和专用算法。其中一些算法已被采用，并在实践中证明是有用的。此外，AEAD接近于加密的“理想化”视图，例如用于加密协议自动分析的视图（例如，参见[BOYD]第2.5节）。
The benefits of AEAD algorithms, and this interface, are outlined in Section 1.3.
第1.3节概述了AEAD算法和该接口的优点。
In this document, we define an AEAD algorithm as an abstraction, by specifying an interface to an AEAD and defining an IANA registry for AEAD algorithms. We populate this registry with four AEAD algorithms based on the Advanced Encryption Standard (AES) in Galois/Counter Mode [GCM] with 128- and 256-bit keys, and AES in Counter and CBC MAC Mode [CCM] with 128- and 256-bit keys.
在本文中，我们将AEAD算法定义为一种抽象，方法是指定AEAD的接口并为AEAD算法定义IANA注册表。我们使用四种AEAD算法填充该注册表，这些算法基于Galois/Counter模式[GCM]中的高级加密标准（AES），具有128位和256位密钥，以及计数器和CBC MAC模式[CCM]中的AES，具有128位和256位密钥。
In the following, we define the AEAD interface (Section 2), and then provide guidance on the use of AEAD algorithms (Section 3), and outline the requirements that each AEAD algorithm must meet
在下文中，我们定义AEAD接口（第2节），然后提供AEAD算法使用指南（第3节），并概述每个AEAD算法必须满足的要求
(Section 4). Then we define several AEAD algorithms (Section 5), and establish an IANA registry for AEAD algorithms (Section 6). Lastly, we discuss some other considerations (Section 7).
（第4节）。然后我们定义了几个AEAD算法（第5节），并为AEAD算法建立了IANA注册表（第6节）。最后，我们讨论一些其他的考虑（第7节）。
The AEAD interface specification does not address security protocol issues such as anti-replay services or access control decisions that are made on authenticated data. Instead, the specification aims to abstract the cryptography away from those issues. The interface, and the guidance about how to use it, are consistent with the recommendations from [EEM04].
AEAD接口规范未解决安全协议问题，如对已验证数据做出的反重播服务或访问控制决策。相反，该规范旨在将加密技术从这些问题中抽象出来。该界面及其使用指南与[EEM04]中的建议一致。
The AEAD approach enables applications that need cryptographic security services to more easily adopt those services. It benefits the application designer by allowing them to focus on important issues such as security services, canonicalization, and data marshaling, and relieving them of the need to design crypto mechanisms that meet their security goals. Importantly, the security of an AEAD algorithm can be analyzed independent from its use in a particular application. This property frees the user of the AEAD of the need to consider security aspects such as the relative order of authentication and encryption and the security of the particular combination of cipher and MAC, such as the potential loss of confidentiality through the MAC. The application designer that uses the AEAD interface need not select a particular AEAD algorithm during the design stage. Additionally, the interface to the AEAD is relatively simple, since it requires only a single key as input and requires only a single identifier to indicate the algorithm in use in a particular case.
AEAD方法使需要加密安全服务的应用程序能够更容易地采用这些服务。它使应用程序设计人员能够专注于安全服务、规范化和数据封送等重要问题，从而使他们不再需要设计满足其安全目标的加密机制，从而使他们受益匪浅。重要的是，AEAD算法的安全性可以独立于其在特定应用中的使用进行分析。此属性释放了需要考虑安全性方面的用户的AEAD，例如认证和加密的相对顺序以及密码和MAC的特定组合的安全性，例如通过MAC的机密性的潜在损失。使用AEAD接口的应用程序设计器在设计阶段不需要选择特定的AEAD算法。此外，AEAD的接口相对简单，因为它只需要一个键作为输入，并且只需要一个标识符来指示在特定情况下使用的算法。
The AEAD approach benefits the implementer of the crypto algorithms by making available optimizations that are otherwise not possible to reduce the amount of computation, the implementation cost, and/or the storage requirements. The simpler interface makes testing easier; this is a considerable benefit for a crypto algorithm implementation. By providing a uniform interface to access cryptographic services, the AEAD approach allows a single crypto implementation to more easily support multiple applications. For example, a hardware module that supports the AEAD interface can easily provide crypto acceleration to any application using that interface, even to applications that had not been designed when the module was built.
AEAD方法通过提供不可能减少计算量、实现成本和/或存储需求的优化，使加密算法的实现者受益。界面更简单，测试更容易；这对于加密算法实现来说是一个相当大的好处。通过提供访问加密服务的统一接口，AEAD方法允许单个加密实现更轻松地支持多个应用程序。例如，支持AEAD接口的硬件模块可以轻松地向使用该接口的任何应用程序提供加密加速，即使是在模块构建时未设计的应用程序。
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]中所述进行解释。
An AEAD algorithm has two operations, authenticated encryption and authenticated decryption. The inputs and outputs of these algorithms are defined below in terms of octet strings.
AEAD算法有两种操作：认证加密和认证解密。这些算法的输入和输出在下文中以八位字节字符串的形式定义。
An implementation MAY accept additional inputs. For example, an input could be provided to allow the user to select between different implementation strategies. However, such extensions MUST NOT affect interoperability with other implementations.
实现可以接受额外的输入。例如，可以提供输入以允许用户在不同的实现策略之间进行选择。但是，此类扩展不得影响与其他实现的互操作性。
The authenticated encryption operation has four inputs, each of which is an octet string:
经过身份验证的加密操作有四个输入，每个输入都是八位字节字符串：
A secret key K, which MUST be generated in a way that is uniformly random or pseudorandom.
密钥K，必须以一致随机或伪随机的方式生成。
A nonce N. Each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, for any particular value of the key, unless each and every nonce is zero-length. Applications that can generate distinct nonces SHOULD use the nonce formation method defined in Section 3.2, and MAY use any other method that meets the uniqueness requirement. Other applications SHOULD use zero-length nonces.
一个nonce N。对于密钥的任何特定值，提供给认证加密操作的不同调用的每个nonce必须是不同的，除非每个nonce的长度为零。可以生成不同nonce的应用程序应使用第3.2节中定义的nonce形成方法，并且可以使用满足唯一性要求的任何其他方法。其他应用程序应使用零长度nonce。
A plaintext P, which contains the data to be encrypted and authenticated.
一种明文P，包含要加密和验证的数据。
The associated data A, which contains the data to be authenticated, but not encrypted.
关联数据A，其中包含要验证但未加密的数据。
There is a single output:
只有一个输出：
A ciphertext C, which is at least as long as the plaintext, or
一种密文C，至少与明文一样长，或
an indication that the requested encryption operation could not be performed.
无法执行请求的加密操作的指示。
All of the inputs and outputs are variable-length octet strings, whose lengths obey the following restrictions:
所有输入和输出均为可变长度八位字节字符串，其长度符合以下限制：
The number of octets in the key K is between 1 and 255. For each AEAD algorithm, the length of K MUST be fixed.
键K中的八位字节数在1到255之间。对于每个AEAD算法，K的长度必须是固定的。
For any particular value of the key, either 1) each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, or 2) each and every nonce MUST be zero-length. If zero-length nonces are used with a particular key, then each and every nonce used with that key MUST have a length of zero. Otherwise, the number of octets in the nonce SHOULD be twelve (12). Nonces with different lengths MAY be used with a particular key. Some algorithms cannot be used with zero-length nonces, but others can; see Section 4. Applications that conform to the recommended nonce length will avoid having to construct nonces with different lengths, depending on the algorithm that is in use. This guidance helps to keep algorithm-specific logic out of applications.
对于密钥的任何特定值，1）提供给经过身份验证的加密操作的不同调用的每个nonce必须是不同的，或者2）每个nonce的长度必须为零。如果零长度nonce与特定键一起使用，则与该键一起使用的每个nonce的长度必须为零。否则，此时的八位字节数应为十二（12）。具有不同长度的nonce可与特定键一起使用。有些算法不能用于零长度nonce，但其他算法可以；见第4节。符合建议的nonce长度的应用程序将避免构造具有不同长度的nonce，具体取决于所使用的算法。本指南有助于将特定于算法的逻辑排除在应用程序之外。
The number of octets in the plaintext P MAY be zero.
明文P中的八位字节数可以是零。
The number of octets in the associated data A MAY be zero.
关联数据A中的八位字节数可以是零。
The number of octets in the ciphertext C MAY be zero.
密文C中的八位字节数可以是零。
This specification does not put a maximum length on the nonce, the plaintext, the ciphertext, or the additional authenticated data. However, a particular AEAD algorithm MAY further restrict the lengths of those inputs and outputs. A particular AEAD implementation MAY further restrict the lengths of its inputs and outputs. If a particular implementation of an AEAD algorithm is requested to process an input that is outside the range of admissible lengths, or an input that is outside the range of lengths supported by that implementation, it MUST return an error code and it MUST NOT output any other information. In particular, partially encrypted or partially decrypted data MUST NOT be returned.
本规范未对nonce、明文、密文或其他经过身份验证的数据设置最大长度。然而，特定AEAD算法可能进一步限制这些输入和输出的长度。特定AEAD实现可能进一步限制其输入和输出的长度。如果AEAD算法的特定实现被请求处理超出允许长度范围的输入，或超出该实现支持的长度范围的输入，则必须返回错误代码，并且不得输出任何其他信息。特别是，不得返回部分加密或部分解密的数据。
Both confidentiality and message authentication are provided on the plaintext P. When the length of P is zero, the AEAD algorithm acts as a Message Authentication Code on the input A.
明文P上同时提供机密性和消息身份验证。当P的长度为零时，AEAD算法充当输入a上的消息身份验证码。
The associated data A is used to protect information that needs to be authenticated, but does not need to be kept confidential. When using an AEAD to secure a network protocol, for example, this input could include addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext or ciphertext should be handled, forwarded, or processed. In many situations, it is desirable to authenticate these fields, though they must be left in the clear to allow the network or system to function properly. When this data is included in the input A, authentication is provided without copying the data into the plaintext.
关联数据A用于保护需要验证但不需要保密的信息。例如，当使用AEAD保护网络协议时，该输入可能包括地址、端口、序列号、协议版本号和其他字段，这些字段指示应如何处理、转发或处理明文或密文。在许多情况下，需要对这些字段进行身份验证，尽管它们必须保持透明，以允许网络或系统正常运行。当该数据包含在输入A中时，提供身份验证，而无需将数据复制到明文中。
The secret key K MUST NOT be included in any of the other inputs (N, P, and A). (This restriction does not mean that the values of those inputs must be checked to ensure that they do not include substrings that match the key; instead, it means that the key must not be explicitly copied into those inputs.)
密钥K不得包含在任何其他输入（N、P和A）中。（此限制并不意味着必须检查这些输入的值，以确保它们不包含与键匹配的子字符串；相反，它意味着不能将键显式复制到这些输入中。）
The nonce is authenticated internally to the algorithm, and it is not necessary to include it in the AD input. The nonce MAY be included in P or A if it is convenient to the application.
nonce在算法内部经过身份验证，不需要将其包含在AD输入中。如果对应用方便，则可以在P或A中包含nonce。
The nonce MAY be stored or transported with the ciphertext, or it MAY be reconstructed immediately prior to the authenticated decryption operation. It is sufficient to provide the decryption module with enough information to allow it to construct the nonce. (For example, a system could use a nonce consisting of a sequence number in a particular format, in which case it could be inferred from the order of the ciphertexts.) Because the authenticated decryption process detects incorrect nonce values, no security failure will result if a nonce is incorrectly reconstructed and fed into an authenticated decryption operation. Any nonce reconstruction method will need to take into account the possibility of loss or reorder of ciphertexts between the encryption and decryption processes.
nonce可以与密文一起存储或传输，或者可以在认证解密操作之前立即对其进行重构。为解密模块提供足够的信息以允许其构造nonce就足够了。（例如，系统可以使用由特定格式的序列号组成的nonce，在这种情况下，可以从密文的顺序推断出来。）因为经过身份验证的解密过程检测到不正确的nonce值，如果nonce被错误地重新构造并输入到经过身份验证的解密操作中，则不会导致安全故障。任何nonce重建方法都需要考虑加密和解密过程之间密文丢失或重新排序的可能性。
Applications MUST NOT assume any particular structure or formatting of the ciphertext.
应用程序不得采用任何特定的密文结构或格式。
The authenticated decryption operation has four inputs: K, N, A, and C, as defined above. It has only a single output, either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic. A ciphertext C, a nonce N, and associated data A are authentic for key K when C is generated by the encrypt operation with inputs K, N, P, and A, for some values of N, P, and A. The authenticated decrypt operation will, with high probability, return FAIL whenever the inputs N, P, and A were crafted by a nonce-respecting adversary that does not know the secret key (assuming that the AEAD algorithm is secure).
经过身份验证的解密操作有四个输入：K、N、A和C，如上所述。它只有一个输出，或者是一个纯文本值P，或者是一个表示输入不真实的特殊符号FAIL。当C由输入K、N、P和A的加密操作生成时，对于密钥K，密文C、nonce N和相关数据A是可信的，对于某些值N、P和A。无论何时输入N、P，一个不知道秘密密钥的对手（假设AEAD算法是安全的）制作了一个密码。
This document does not specify any particular encoding for the AEAD inputs and outputs, since the encoding does not affect the security services provided by an AEAD algorithm.
本文件未指定AEAD输入和输出的任何特定编码，因为编码不会影响AEAD算法提供的安全服务。
When choosing the format of application data, an application SHOULD position the ciphertext C so that it appears after any other data that is needed to construct the other inputs to the authenticated
在选择应用程序数据的格式时，应用程序应定位密文C，以便它出现在构造已验证数据的其他输入所需的任何其他数据之后
decryption operation. For instance, if the nonce and ciphertext both appear in a packet, the former value should precede the latter. This rule facilitates efficient and simple hardware implementations of AEAD algorithms.
解密操作。例如，如果nonce和ciphertext都出现在数据包中，则前者的值应位于后者之前。该规则有助于AEAD算法的高效和简单的硬件实现。
This section provides advice that must be followed in order to use an AEAD algorithm securely.
本节提供了安全使用AEAD算法必须遵循的建议。
If an application is unable to meet the uniqueness requirement on nonce generation, then it MUST use a zero-length nonce. Randomized or stateful algorithms, which are defined below, are suitable for use with such applications. Otherwise, an application SHOULD use nonces with a length of twelve octets. Since algorithms are encouraged to support that length, applications should use that length to aid interoperability.
如果应用程序无法满足nonce生成的唯一性要求，则必须使用零长度nonce。下面定义的随机或有状态算法适用于此类应用程序。否则，应用程序应该使用长度为12个八位字节的nonce。由于鼓励算法支持该长度，应用程序应该使用该长度来帮助互操作性。
It is essential for security that the nonces be constructed in a manner that respects the requirement that each nonce value be distinct for each invocation of the authenticated encryption operation, for any fixed value of the key. In this section, we call attention to some consequences of this requirement in different scenarios.
对于安全性来说，nonce的构造方式必须符合以下要求：对于经过身份验证的加密操作的每次调用，对于密钥的任何固定值，每个nonce值都是不同的。在本节中，我们提请注意此需求在不同场景中的一些后果。
When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices, as described in Section 3.2. Note that there is no need to coordinate the details of the nonce format between the encrypter and the decrypter, as long the entire nonce is sent or stored with the ciphertext and is thus available to the decrypter. If the complete nonce is not available to the decrypter, then the decrypter will need to know how the nonce is structured so that it can reconstruct it. Applications SHOULD provide encryption engines with some freedom in choosing their nonces; for example, a nonce could contain both a counter and a field that is set by the encrypter but is not processed by the receiver. This freedom allows a set of encryption devices to more readily coordinate to ensure the distinctness of their nonces.
当有多个设备使用单个密钥执行加密时，这些设备必须协调以确保nonce是唯一的。一种简单的方法是使用nonce格式，该格式包含一个字段，该字段对于每个设备都是不同的，如第3.2节所述。注意，只要整个nonce与密文一起发送或存储并因此可供解密器使用，就不需要在加密器和解密器之间协调nonce格式的细节。如果解密程序无法使用完整的nonce，那么解密程序需要知道nonce是如何构造的，以便能够重新构造它。应用程序应该为加密引擎提供一些选择其nonce的自由；例如，一个nonce可以同时包含一个计数器和一个字段，该字段由加密程序设置，但不由接收方处理。这种自由度允许一组加密设备更容易地协调，以确保其nonce的明确性。
If a secret key will be used for a long period of time, e.g., across multiple reboots, then the nonce will need to be stored in non-volatile memory. In such cases, it is essential to use checkpointing of the nonce; that is, the current nonce value should be stored to provide the state information needed to resume encryption in case of
如果一个密钥将被使用很长一段时间，例如，在多次重新启动期间，则该nonce将需要存储在非易失性内存中。在这种情况下，必须使用nonce的检查点；也就是说，应存储当前的nonce值，以提供在发生错误时恢复加密所需的状态信息
unexpected failure. One simple way to provide a high assurance that a nonce value will not be used repeatedly is to wait until the encryption process receives confirmation from the storage process indicating that the succeeding nonce value has already been stored. Because this method may add significant latency, it may be desirable to store a nonce value that is several values ahead in the sequence. As an example, the nonce 100 could be stored, after which the nonces 1 through 99 could be used for encryption. The nonce value 200 could be stored at the same time that nonces 1 through 99 are being used, and so on.
意外的失败。提供不重复使用nonce值的高保证的一种简单方法是等待直到加密过程从存储过程接收到指示已存储后续nonce值的确认。由于此方法可能会增加显著的延迟，因此可能需要存储一个nonce值，该值在序列的前面有几个值。例如，可以存储nonce 100，之后可以使用nonce 1到99进行加密。可以在使用nonce 1到99的同时存储nonce值200，依此类推。
Many problems with nonce reuse can be avoided by changing a key in a situation in which nonce coordination is difficult.
在nonce协调困难的情况下，通过更改密钥可以避免许多nonce重用问题。
Each AEAD algorithm SHOULD describe what security degradation would result from an inadvertent reuse of a nonce value.
每个AEAD算法都应该描述由于无意中重用nonce值而导致的安全性降低。
The following method to construct nonces is RECOMMENDED. The nonce is formatted as illustrated in Figure 1, with the initial octets consisting of a Fixed field, and the final octets consisting of a Counter field. For each fixed key, the length of each of these fields, and thus the length of the nonce, is fixed. Implementations SHOULD support 12-octet nonces in which the Counter field is four octets long.
建议使用以下方法构造nonce。nonce的格式如图1所示，初始八位字节由一个固定字段组成，最终八位字节由一个计数器字段组成。对于每个固定键，每个字段的长度以及nonce的长度都是固定的。实现应该支持12个八位字节的nonce，其中计数器字段的长度为4个八位字节。
<----- variable ----> <----------- variable ----------->
+---------------------+----------------------------------+
| Fixed | Counter |
+---------------------+----------------------------------+
<----- variable ----> <----------- variable ----------->
+---------------------+----------------------------------+
| Fixed | Counter |
+---------------------+----------------------------------+
Figure 1: Recommended nonce format
图1：推荐的nonce格式
The Counter fields of successive nonces form a monotonically increasing sequence, when those fields are regarded as unsigned integers in network byte order. The length of the Counter field MUST remain constant for all nonces that are generated for a given encryption device. The Counter part SHOULD be equal to zero for the first nonce, and increment by one for each successive nonce that is generated. However, any particular Counter value MAY be skipped over, and left out of the sequence of values that are used, if it is convenient. For example, an application could choose to skip the initial Counter=0 value, and set the Counter field of the initial nonce to 1. Thus, at most 2^(8*C) nonces can be generated when the Counter field is C octets in length.
当这些字段被视为网络字节顺序的无符号整数时，连续非整数的计数器字段形成单调递增序列。对于为给定加密设备生成的所有nonce，计数器字段的长度必须保持不变。对于第一个nonce，计数器部分应等于零，对于生成的每个连续nonce，计数器部分应递增一。但是，如果方便的话，可以跳过任何特定的计数器值，并将其从使用的值序列中删除。例如，应用程序可以选择跳过初始计数器=0值，并将初始nonce的计数器字段设置为1。因此，当计数器字段的长度为C个八位字节时，最多可以生成2^（8*C）个nonce。
The Fixed field MUST remain constant for all nonces that are generated for a given encryption device. If different devices are performing encryption with a single key, then each distinct device MUST use a distinct Fixed field, to ensure the uniqueness of the nonces. Thus, at most 2^(8*F) distinct encrypters can share a key when the Fixed field is F octets in length.
对于为给定加密设备生成的所有nonce，固定字段必须保持不变。如果不同的设备使用单个密钥执行加密，则每个不同的设备必须使用不同的固定字段，以确保nonce的唯一性。因此，当固定字段长度为F个八位字节时，最多2^（8*F）个不同的加密机可以共享密钥。
In some cases, it is desirable to not transmit or store an entire nonce, but instead to reconstruct that value from contextual information immediately prior to decryption. As an example, ciphertexts could be stored in sequence on a disk, and the nonce for a particular ciphertext could be inferred from its location, as long as the rule for generating the nonces is known by the decrypter. We call the portion of the nonce that is stored or sent with the ciphertext the explicit part. We call the portion of the nonce that is inferred the implicit part. When part of the nonce is implicit, the following specialization of the above format is RECOMMENDED. The Fixed field is divided into two sub-fields: a Fixed-Common field and a Fixed-Distinct field. This format is shown in Figure 2. If different devices are performing encryption with a single key, then each distinct device MUST use a distinct Fixed-Distinct field. The Fixed-Common field is common to all nonces. The Fixed-Distinct field and the Counter field MUST be in the explicit part of the nonce. The Fixed-Common field MAY be in the implicit part of the nonce. These conventions ensure that the nonce is easy to reconstruct from the explicit data.
在某些情况下，不需要传输或存储整个nonce，而是在解密之前立即从上下文信息重构该值。例如，密文可以顺序存储在磁盘上，并且可以从其位置推断特定密文的nonce，只要解密程序知道生成nonce的规则。我们将与密文一起存储或发送的nonce部分称为显式部分。我们将推断出的nonce部分称为隐式部分。当nonce的一部分是隐式的时，建议对上述格式进行以下专门化。固定字段分为两个子字段：固定公共字段和固定不同字段。此格式如图2所示。如果不同的设备使用单个密钥执行加密，则每个不同的设备必须使用不同的固定字段。固定公共字段对所有nonce都是公共的。固定的不同字段和计数器字段必须位于nonce的显式部分。固定公共字段可能位于nonce的隐式部分。这些约定确保nonce易于从显式数据重建。
+-------------------+--------------------+---------------+
| Fixed-Common | Fixed-Distinct | Counter |
+-------------------+--------------------+---------------+
<---- implicit ---> <------------ explicit ------------>
+-------------------+--------------------+---------------+
| Fixed-Common | Fixed-Distinct | Counter |
+-------------------+--------------------+---------------+
<---- implicit ---> <------------ explicit ------------>
Figure 2: Partially implicit nonce format
图2：部分隐式nonce格式
The rationale for the partially implicit nonce format is as follows. This method of nonce construction incorporates the best known practice; it is used by both GCM Encapuslating Security Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the Fixed field contains the Salt value and the lowest eight octets of the nonce are explicitly carried in the ESP packet. In GCM ESP, the Fixed field must be at least four octets long, so that it can contain the Salt value. In CCM ESP, the Fixed field must be at least three octets long for the same reason. This nonce generation method is also used by several counter mode variants including CTR ESP.
部分隐式nonce格式的基本原理如下。这种临时构造方法结合了最著名的实践；GCM封装安全有效负载（ESP）[RFC4106]和CCM ESP[RFC4309]都使用它，其中固定字段包含Salt值，并且在ESP数据包中显式携带nonce的最低八个八位字节。在GCM ESP中，固定字段必须至少有四个八位字节长，以便它可以包含Salt值。在CCM ESP中，出于同样的原因，固定字段必须至少有三个八位字节长。包括CTR ESP在内的多个计数器模式变体也使用这种非同步生成方法。
If the AD input is constructed out of multiple data elements, then it is essential that it be unambiguously parseable into its constituent elements, without the use of any unauthenticated data in the parsing process. (In mathematical terms, the AD input must be an injective function of the data elements.) If an application constructs its AD input in such a way that there are two distinct sets of data elements that result in the same AD value, then an attacker could cause a receiver to accept a bogus set by substituting one set for the other. The requirement that the AD be uniquely parseable ensures that this attack is not possible. This requirement is trivially met if the AD is composed of fixed-width elements. If the AD contains a variable-length string, for example, this requirement can be met by also including the length of the string in the AD.
如果AD输入是由多个数据元素构成的，那么在解析过程中不使用任何未经验证的数据，它必须能够明确地解析为其组成元素。（用数学术语来说，AD输入必须是数据元素的内射函数。）如果应用程序构造其AD输入时存在两组不同的数据元素，从而产生相同的AD值，则攻击者可以通过用一组数据替换另一组数据，使接收者接受伪造的数据集。AD唯一可解析的要求确保了这种攻击不可能发生。如果AD由固定宽度的元素组成，则基本满足此要求。例如，如果AD包含可变长度的字符串，则也可以通过在AD中包含字符串的长度来满足此要求。
Similarly, if the plaintext is constructed out of multiple data elements, then it is essential that it be unambiguously parseable into its constituent elements, without using any unauthenticated data in the parsing process. Note that data included in the AD may be used when parsing the plaintext, though of course since the AD is not encrypted there is a potential loss of confidentiality when information about the plaintext is included in the AD.
类似地，如果明文是由多个数据元素构成的，那么它必须能够明确地解析为其组成元素，而不必在解析过程中使用任何未经验证的数据。注意，在解析明文时可以使用AD中包括的数据，尽管当然，由于AD未被加密，当关于明文的信息包括在AD中时，存在潜在的机密性损失。
To make use of an AEAD algorithm, an application must define how the encryption algorithm's inputs are defined in terms of application data, and how the ciphertext and nonce are conveyed. The clearest way to do this is to express each input in terms of the data that form it, then to express the application data in terms of the outputs of the AEAD encryption operation.
要使用AEAD算法，应用程序必须定义如何根据应用程序数据定义加密算法的输入，以及如何传递密文和nonce。实现这一点最清晰的方法是，根据构成输入的数据来表示每个输入，然后根据AEAD加密操作的输出来表示应用程序数据。
For example, AES-GCM ESP [RFC4106] can be expressed as follows. The AEAD inputs are
例如，AES-GCM ESP[RFC4106]可以表示为如下。AEAD输入为
P = RestOfPayloadData || TFCpadding || Padding || PadLength || NextHeader
P=RestOfPayloadData | | | | | | | | | | | | |下一个
N = Salt || IV
N=盐| | IV
A = SPI || SequenceNumber
A=SPI | |序列号
where the symbol "||" denotes the concatenation operation, and the fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader, SPI, and SequenceNumber are as defined in [RFC4303], and the fields Salt and IV are as defined in [RFC4106]. The field RestOfPayloadData contains the plaintext data that is described by the NextHeader
其中符号“| |”表示串联操作，字段RestOfPayloadData、TFCpadding、Padding、PadLength、NextHeader、SPI和SequenceNumber如[RFC4303]所定义，字段Salt和IV如[RFC4106]所定义。字段RestOfPayloadData包含下一个订单描述的纯文本数据
field, and no other data. (Recall that the PayloadData field contains both the IV and the RestOfPayloadData; see Figure 2 of [RFC4303] for an illustration.)
字段，没有其他数据。（回想一下PayloadData字段同时包含IV和RestOfPayloadData；请参见[RFC4303]的图2以获取说明。）
The format of the ESP packet can be expressed as
ESP数据包的格式可以表示为
ESP = SPI || SequenceNumber || IV || C
ESP=SPI | |序列号| | IV | C
where C is the AEAD ciphertext (which in this case incorporates the authentication tag). Please note that here we have not described the use of the ESP Extended Sequence Number.
其中C是AEAD密文（在本例中包含身份验证标记）。请注意，这里我们没有描述ESP扩展序列号的使用。
Each AEAD algorithm MUST only accept keys with a fixed key length K_LEN, and MUST NOT require any particular data format for the keys provided as input. An algorithm that requires such structure (e.g., one with subkeys in a particular parity-check format) will need to provide it internally.
每个AEAD算法必须仅接受具有固定密钥长度K_LEN的密钥，并且对于作为输入提供的密钥，不得要求任何特定的数据格式。需要这种结构的算法（例如，具有特定奇偶校验格式的子键的算法）需要在内部提供。
Each AEAD algorithm MUST accept any plaintext with a length between zero and P_MAX octets, inclusive, where the value P_MAX is specific to that algorithm. The value of P_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. This size is a typical upper limit for network data packets. Other applications may use even larger values of P_MAX, so it is desirable for general-purpose algorithms to support higher values.
每个AEAD算法必须接受长度介于0和P_MAX八位字节（含）之间的任何明文，其中P_MAX值特定于该算法。P_MAX的值必须大于零，并且至少应为65536（2^16）个八位字节。此大小是网络数据包的典型上限。其他应用程序可能使用更大的P_MAX值，因此希望通用算法支持更高的值。
Each AEAD algorithm MUST accept any associated data with a length between zero and A_MAX octets, inclusive, where the value A_MAX is specific to that algorithm. The value of A_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. Other applications may use even larger values of A_MAX, so it is desirable for general-purpose algorithms to support higher values.
每个AEAD算法必须接受长度介于0和a_MAX八位字节（含）之间的任何关联数据，其中a_MAX的值特定于该算法。A_MAX的值必须大于零，并且至少应为65536（2^16）个八位字节。其他应用程序可能会使用更大的_MAX值，因此希望通用算法支持更高的值。
Each AEAD algorithm MUST accept any nonce with a length between N_MIN and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are specific to that algorithm. The values of N_MAX and N_MIN MAY be equal. Each algorithm SHOULD accept a nonce with a length of twelve (12) octets. Randomized or stateful algorithms, which are described below, MAY have an N_MAX value of zero.
每个AEAD算法必须接受长度在N_MIN和N_MAX八位字节（含）之间的任何nonce，其中N_MIN和N_MAX的值特定于该算法。N_MAX和N_MIN的值可能相等。每个算法应接受长度为十二（12）个八位字节的nonce。下面描述的随机或有状态算法的N_MAX值可能为零。
An AEAD algorithm MAY structure its ciphertext output in any way; for example, the ciphertext can incorporate an authentication tag. Each algorithm SHOULD choose a structure that is amenable to efficient processing.
AEAD算法可以以任何方式构造其密文输出；例如，密文可以包含身份验证标签。每种算法都应该选择一种适合高效处理的结构。
An Authenticated Encryption algorithm MAY incorporate or make use of a random source, e.g., for the generation of an internal initialization vector that is incorporated into the ciphertext output. An AEAD algorithm of this sort is called randomized; though note that only encryption is random, and decryption is always deterministic. A randomized algorithm MAY have a value of N_MAX that is equal to zero.
经认证的加密算法可以合并或利用随机源，例如，用于生成合并到密文输出中的内部初始化向量。这种AEAD算法称为随机化算法；不过请注意，只有加密是随机的，而解密总是确定性的。随机算法的N_MAX值可能等于零。
An Authenticated Encryption algorithm MAY incorporate internal state information that is maintained between invocations of the encrypt operation, e.g., to allow for the construction of distinct values that are used as internal nonces by the algorithm. An AEAD algorithm of this sort is called stateful. This method could be used by an algorithm to provide good security even when the application inputs zero-length nonces. A stateful algorithm MAY have a value of N_MAX that is equal to zero.
经过认证的加密算法可以包括在加密操作的调用之间维护的内部状态信息，例如，允许构造不同的值，这些值被算法用作内部nonce。这种AEAD算法称为有状态算法。即使在应用程序输入零长度nonce时，算法也可以使用此方法提供良好的安全性。有状态算法的N_MAX值可能等于零。
The specification of an AEAD algorithm MUST include the values of K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above. Additionally, it MUST specify the number of octets in the largest possible ciphertext, which we denote C_MAX.
AEAD算法的规范必须包括上面定义的K_LEN、P_MAX、A_MAX、N_MIN和N_MAX的值。此外，它必须指定最大可能密文中的八位字节数，我们将其表示为C_MAX。
Each AEAD algorithm MUST provide a description relating the length of the plaintext to that of the ciphertext. This relation MUST NOT depend on external parameters, such as an authentication strength parameter (e.g., authentication tag length). That sort of dependence would complicate the use of the algorithm by creating a situation in which the information from the AEAD registry was not sufficient to ensure interoperability.
每个AEAD算法必须提供与明文长度和密文长度相关的描述。此关系不得依赖于外部参数，例如身份验证强度参数（例如，身份验证标记长度）。这种依赖性会造成AEAD注册表中的信息不足以确保互操作性的情况，从而使算法的使用复杂化。
EACH AEAD algorithm specification SHOULD describe what security degradation would result from an inadvertent reuse of a nonce value.
每个AEAD算法规范都应该描述由于无意中重用nonce值而导致的安全性降低。
Each AEAD algorithm specification SHOULD provide a reference to a detailed security analysis. This document does not specify a particular security model, because several different models have been used in the literature. The security analysis SHOULD define or reference a security model.
每个AEAD算法规范应提供详细安全分析的参考。本文档未指定特定的安全模型，因为文献中使用了几种不同的模型。安全分析应定义或引用安全模型。
An algorithm that is randomized or stateful, as defined above, SHOULD describe itself using those terms.
如上所述，随机或有状态的算法应该使用这些术语来描述自己。
This section defines four AEAD algorithms; two are based on AES GCM, two are based on AES CCM. Each pair includes an algorithm with a key size of 128 bits and one with a key size of 256 bits.
本节定义了四种AEAD算法；两个基于AES GCM，两个基于AES CCM。每对包括一个密钥大小为128位的算法和一个密钥大小为256位的算法。
The AEAD_AES_128_GCM authenticated encryption algorithm works as specified in [GCM], using AES-128 as the block cipher, by providing the key, nonce, and plaintext, and associated data to that mode of operation. An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_GCM ciphertext is formed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation. Test cases are provided in the appendix of [GCM]. The input and output lengths are as follows:
AEAD_AES_128_GCM认证加密算法按照[GCM]中的规定工作，使用AES-128作为分组密码，向该操作模式提供密钥、nonce和明文以及相关数据。使用长度为16个八位字节（128位）的身份验证标签。AEAD_AES_128_GCM密文是通过将作为GCM加密操作的输出提供的认证标签附加到该操作输出的密文上而形成的。[GCM]的附录中提供了测试用例。输入和输出长度如下所示：
K_LEN is 16 octets,
库伦是16个八位组，
P_MAX is 2^36 - 31 octets,
P_MAX为2^36-31个八位字节，
A_MAX is 2^61 - 1 octets,
A_MAX是2^61-1个八位字节，
N_MIN and N_MAX are both 12 octets, and
N_MIN和N_MAX都是12个八位字节，并且
C_MAX is 2^36 - 15 octets.
C_MAX为2^36-15个八位字节。
An AEAD_AES_128_GCM ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_128_GCM密文比其相应的明文长16个八位组。
A security analysis of GCM is available in [MV04].
[MV04]中提供了GCM的安全分析。
The inadvertent reuse of the same nonce by two invocations of the GCM encryption operation, with the same key, but with distinct plaintext values, undermines the confidentiality of the plaintexts protected in those two invocations, and undermines all of the authenticity and integrity protection provided by that key. For this reason, GCM should only be used whenever nonce uniqueness can be provided with assurance. The design feature that GCM uses to achieve minimal latency causes the vulnerabilities on the subsequent uses of the key. Note that it is acceptable to input the same nonce value multiple times to the decryption operation.
GCM加密操作的两次调用（使用相同的密钥，但具有不同的明文值）无意中重用了相同的nonce，这破坏了在这两次调用中受保护的明文的机密性，并破坏了该密钥提供的所有真实性和完整性保护。因此，只有在能够保证非唯一性的情况下，才应使用GCM。GCM用于实现最小延迟的设计功能会导致后续使用密钥时出现漏洞。请注意，可以多次向解密操作输入相同的nonce值。
The security consequences are quite serious if an attacker observes two ciphertexts that were created using the same nonce and key
如果攻击者观察到使用相同的nonce和key创建的两个密文，则安全性后果相当严重
values, unless the plaintext and AD values in both invocations of the encrypt operation were identical. First, a loss of confidentiality ensues because he will be able to reconstruct the bitwise exclusive-or of the two plaintext values. Second, a loss of integrity ensues because the attacker will be able to recover the internal hash key used to provide data integrity. Knowledge of this key makes subsequent forgeries trivial.
值，除非加密操作的两个调用中的明文和AD值相同。首先，由于他将能够重建两个明文值的位异或，因此会导致机密性丢失。其次，由于攻击者能够恢复用于提供数据完整性的内部散列密钥，因此会导致完整性丢失。知道了这把钥匙以后伪造的东西就变得微不足道了。
This algorithm is identical to AEAD_AES_128_GCM, but with the following differences:
该算法与AEAD_AES_128_GCM相同，但有以下区别：
K_LEN is 32 octets, instead of 16 octets, and
K_LEN是32个八位字节，而不是16个八位字节，并且
AES-256 GCM is used instead of AES-128 GCM.
使用AES-256 GCM代替AES-128 GCM。
The AEAD_AES_128_CCM authenticated encryption algorithm works as specified in [CCM], using AES-128 as the block cipher, by providing the key, nonce, associated data, and plaintext to that mode of operation. The formatting and counter generation function are as specified in Appendix A of that reference, and the values of the parameters identified in that appendix are as follows:
AEAD_AES_128_CCM认证加密算法按照[CCM]中的规定工作，使用AES-128作为分组密码，向该操作模式提供密钥、nonce、相关数据和明文。格式化和计数器生成功能如该参考文件附录A所规定，该附录中确定的参数值如下：
the nonce length n is 12,
当前长度n是12，
the tag length t is 16, and
标签长度t为16，且
the value of q is 3.
q的值是3。
An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_CCM ciphertext is formed by appending the authentication tag provided as an output to the CCM encryption operation to the ciphertext that is output by that operation. Test cases are provided in [CCM]. The input and output lengths are as follows:
使用长度为16个八位字节（128位）的身份验证标签。AEAD_AES_128_CCM密文通过将作为CCM加密操作的输出提供的认证标签附加到该操作输出的密文来形成。[CCM]中提供了测试用例。输入和输出长度如下所示：
K_LEN is 16 octets,
库伦是16个八位组，
P_MAX is 2^24 - 1 octets,
P_MAX是2^24-1个八位组，
A_MAX is 2^64 - 1 octets,
最大值为2^64-1个八位字节，
N_MIN and N_MAX are both 12 octets, and
N_MIN和N_MAX都是12个八位字节，并且
C_MAX is 2^24 + 15 octets.
C_MAX为2^24+15个八位字节。
An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM密文比其相应的明文长16个八位字节。
A security analysis of AES CCM is available in [J02].
[J02]中提供了AES CCM的安全性分析。
Inadvertent reuse of the same nonce by two invocations of the CCM encryption operation, with the same key, undermines the security for the messages processed with those invocations. A loss of confidentiality ensues because an adversary will be able to reconstruct the bitwise exclusive-or of the two plaintext values.
通过两次调用具有相同密钥的CCM加密操作无意中重用相同的nonce，会破坏使用这些调用处理的消息的安全性。由于对手将能够重建两个明文值的位异或，因此会导致机密性丢失。
This algorithm is identical to AEAD_AES_128_CCM, but with the following differences:
此算法与AEAD_AES_128_CCM相同，但有以下区别：
K_LEN is 32 octets, instead of 16, and
K_LEN是32个八位字节，而不是16个，并且
AES-256 CCM is used instead of AES-128 CCM.
使用AES-256 CCM代替AES-128 CCM。
The Internet Assigned Numbers Authority (IANA) has defined the "AEAD Registry" described below. An algorithm designer MAY register an algorithm in order to facilitate its use. Additions to the AEAD Registry require that a specification be documented in an RFC or another permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. Each entry in the registry contains the following elements:
互联网分配号码管理局（IANA）定义了下文所述的“AEAD注册表”。算法设计者可以注册算法以便于使用。AEAD注册表的新增要求规范记录在RFC或另一个永久且随时可用的参考文件中，详细程度足以确保独立实现之间的互操作性。注册表中的每个条目都包含以下元素：
a short name, such as "AEAD_AES_128_GCM", that starts with the string "AEAD",
以字符串“AEAD”开头的短名称，如“AEAD_AES_128_GCM”，
a positive number, and
一个正数，和
a reference to a specification that completely defines an AEAD algorithm and provides test cases that can be used to verify the correctness of an implementation.
对规范的引用，该规范完全定义AEAD算法，并提供可用于验证实现正确性的测试用例。
Requests to add an entry to the registry MUST include the name and the reference. The number is assigned by IANA. These number assignments SHOULD use the smallest available positive number. Submitters SHOULD have their requests reviewed by the IRTF Crypto
向注册表添加条目的请求必须包括名称和引用。号码由IANA分配。这些数字分配应使用最小的可用正数。提交人的请求应由IRTF加密审查
Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants that are unfamiliar with IANA processes should visit http://www.iana.org.
论坛研究小组（CFRG）在cfrg@ietf.org. 不熟悉IANA流程的有兴趣的申请人应访问http://www.iana.org.
The numbers between 32,768 (binary 1000000000000000) and 65,535 (binary 1111111111111111) inclusive, will not be assigned by IANA, and are reserved for private use; no attempt will be made to prevent multiple sites from using the same value in different (and incompatible) ways [RFC2434].
32768（二进制10000000000000）和65535（二进制1111111111）之间的数字（含）将不由IANA分配，并保留供私人使用；不会试图阻止多个站点以不同（且不兼容）的方式使用相同的值[RFC2434]。
IANA has added the following entries to the AEAD Registry:
IANA已将以下条目添加到AEAD注册表中：
+------------------+-------------+--------------------+
| Name | Reference | Numeric Identifier |
+------------------+-------------+--------------------+
| AEAD_AES_128_GCM | Section 5.1 | 1 |
| AEAD_AES_256_GCM | Section 5.2 | 2 |
| AEAD_AES_128_CCM | Section 5.3 | 3 |
| AEAD_AES_256_CCM | Section 5.4 | 4 |
+------------------+-------------+--------------------+
+------------------+-------------+--------------------+
| Name | Reference | Numeric Identifier |
+------------------+-------------+--------------------+
| AEAD_AES_128_GCM | Section 5.1 | 1 |
| AEAD_AES_256_GCM | Section 5.2 | 2 |
| AEAD_AES_128_CCM | Section 5.3 | 3 |
| AEAD_AES_256_CCM | Section 5.4 | 4 |
+------------------+-------------+--------------------+
An IANA registration of an AEAD does not constitute an endorsement of that algorithm or its security.
AEAD的IANA注册不构成对该算法或其安全性的认可。
Directly testing a randomized AEAD encryption algorithm using test cases with fixed inputs and outputs is not possible, since the encryption process is non-deterministic. However, it is possible to test a randomized AEAD algorithm using the following technique. The authenticated decryption algorithm is deterministic, and it can be directly tested. The authenticated encryption algorithm can be tested by encrypting a plaintext, decrypting the resulting ciphertext, and comparing the original plaintext to the post-decryption plaintext. Combining both of these tests covers both the encryption and decryption algorithms.
使用具有固定输入和输出的测试用例直接测试随机AEAD加密算法是不可能的，因为加密过程是不确定的。但是，可以使用以下技术测试随机AEAD算法。认证解密算法是确定性的，可以直接测试。可以通过加密明文、解密生成的密文以及将原始明文与解密后的明文进行比较来测试经过身份验证的加密算法。这两种测试的结合涵盖了加密和解密算法。
The AEAD algorithms selected reflect those that have been already adopted by standards. It is an open question as to what other AEAD algorithms should be added. Many variations on basic algorithms are possible, each with its own advantages. While it is desirable to admit any algorithms that are found to be useful in practice, it is also desirable to limit the total number of registered algorithms. The current specification requires that a registered algorithm provide a complete specification and a set of validation data; it is hoped that these prerequisites set the admission criteria appropriately.
选择的AEAD算法反映了标准已经采用的算法。至于应该添加哪些其他AEAD算法，这是一个悬而未决的问题。基本算法可能有许多变化，每一种都有自己的优点。虽然希望承认在实践中发现有用的任何算法，但也希望限制注册算法的总数。当前规范要求注册的算法提供完整的规范和一组验证数据；希望这些先决条件能够适当地确定入学标准。
It may be desirable to define an AEAD algorithm that uses the generic composition with the encrypt-then-MAC method [BN00], combining a common encryption algorithm, such as CBC [MODES], with a common message authentication code, such as HMAC-SHA1 [RFC2104] or AES CMAC [CMAC]. An AEAD algorithm of this sort would reflect the best current practice, and might be more easily supported by crypto modules that lack support for other AEAD algorithms.
可能希望定义一种AEAD算法，该算法使用通用组合和加密然后MAC方法[BN00]，将公共加密算法（例如CBC[MODES]）与公共消息认证码（例如HMAC-SHA1[RFC2104]或AES-CMAC[CMAC]）相结合。这类AEAD算法将反映当前的最佳实践，并且可能更容易被缺乏对其他AEAD算法支持的加密模块支持。
This document describes authenticated encryption algorithms, and provides guidance on their use. While these algorithms make it easier, in some ways, to design a cryptographic application, it should be borne in mind that strong cryptographic security is difficult to achieve. While AEAD algorithms are quite useful, they do nothing to address the issues of key generation [RFC4086] and key management [RFC4107].
本文档描述了经过身份验证的加密算法，并提供了使用指南。虽然这些算法在某些方面使设计密码应用程序变得更容易，但应该记住，很难实现强大的密码安全性。虽然AEAD算法非常有用，但它们对解决密钥生成[RFC4086]和密钥管理[RFC4107]的问题无能为力。
AEAD algorithms that rely on distinct nonces may be inappropriate for some applications or for some scenarios. Application designers should understand the requirements outlined in Section 3.1.
依赖不同nonce的AEAD算法可能不适用于某些应用程序或某些场景。应用程序设计人员应了解第3.1节中概述的要求。
A software implementation of the AEAD encryption operation in a Virtual Machine (VM) environment could inadvertently reuse a nonce due to a "rollback" of the VM to an earlier state [GR05]. Applications are encouraged to document potential issues to help the user of the application and the VM avoid unintentional mistakes of this sort. The possibility exists that an attacker can cause a VM rollback; threats and mitigations in that scenario are an area of active research. For perspective, we note that an attacker who can trigger such a rollback may have already succeeded in subverting the security of the system, e.g., by causing an accounting error.
虚拟机（VM）环境中AEAD加密操作的软件实现可能会由于VM“回滚”到早期状态而无意中重用nonce[GR05]。鼓励应用程序记录潜在问题，以帮助应用程序用户和VM避免此类意外错误。攻击者可能导致VM回滚；这种情况下的威胁和缓解措施是一个积极研究的领域。从长远来看，我们注意到，能够触发这种回滚的攻击者可能已经成功地破坏了系统的安全性，例如，导致了一个记帐错误。
An IANA registration of an AEAD algorithm MUST NOT be regarded as an endorsement of its security. Furthermore, the perceived security level of an algorithm can degrade over time, due to cryptanalytic advances or to "Moore's Law", that is, the diminishing cost of computational resources over time.
AEAD算法的IANA注册不得视为对其安全性的认可。此外，由于密码分析的进步或“摩尔定律”，即计算资源的成本随着时间的推移而降低，算法的感知安全级别会随着时间的推移而降低。
Many reviewers provided valuable comments on earlier drafts of this document. Some fruitful discussions took place on the email list of the Crypto Forum Research Group in 2006.
许多审稿人对本文件的早期草稿提出了宝贵的意见。2006年，在加密论坛研究小组的电子邮件列表上进行了一些富有成果的讨论。
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality", U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>.
[CCM]Dworkin，M.，“NIST特别出版物800-38C：认证和保密的CCM模式”，美国国家标准与技术研究所<http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>。
[GCM] Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.", U.S. National Institute of Standards and Technology, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>.
[GCM]Dworkin，M.，“NIST特别出版物800-38D：分组密码操作模式建议：Galois/计数器模式（GCM）和GMAC”，，美国国家标准与技术研究所，2007年11月<http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>。
[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月。
[BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: Relations among notions and analysis of the generic composition paradigm", Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-545, 2002.
[BN00]Bellare，M.和C.Namprempre，“认证加密：概念之间的关系和通用组合范式的分析”，《亚洲加密会议录》，2000年，Springer Verlag，LNCS 1976年，第531-545页，2002年。
[BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication and Key Establishment", Springer 2003.
[BOYD]BOYD，C.和A.Mathuria，“身份验证和密钥建立协议”，Springer 2003。
[CMAC] "NIST Special Publication 800-38B", <http://csrc.nist.gov/ publications/nistpubs/800-38B/SP_800-38B.pdf>.
[CMAC]“NIST特别出版物800-38B”<http://csrc.nist.gov/ 出版物/nistpubs/800-38B/SP_800-38B.pdf>。
[EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then-Encrypt-and-MAC paradigm", ACM Transactions on Information and System Security, <http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/>.
[EEM04]Bellare，M.，Namprempre，C.，和T.Kohno，“破坏并可证明地修复SSH认证加密方案：编码-然后加密和MAC范式的案例研究”，ACM信息和系统安全事务<http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/>.
[GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments", Proceedings of the 10th Workshop on Hot Topics in Operating Systems, <http://www.stanford.edu/~talg/papers/HOTOS05/ virtual-harder-hotos05.pdf>.
[GR05]Garfinkel，T.和M.Rosenblum，“当虚拟比真实更难时：基于虚拟机的计算环境中的安全挑战”，第十届操作系统热点研讨会论文集<http://www.stanford.edu/~talg/papers/HOTOS05/virtual-harder-HOTOS05.pdf>。
[J02] Jonsson, J., "On the Security of CTR + CBC-MAC", Proceedings of the 9th Annual Workshop on Selected Areas on Cryptography, 2002, <http://csrc.nist.gov/groups/ST/ toolkit/BCM/documents/proposedmodes/ccm/ccm-ad1.pdf>.
[J02]Jonsson，J.，“CTR+CBC-MAC的安全性”，第九届密码学选定领域年度研讨会论文集，2002年<http://csrc.nist.gov/groups/ST/ toolkit/BCM/documents/proposedmodes/ccm/ccm-ad1.pdf>。
[MODES] Dworkin, M., "NIST Special Publication 800-38: Recommendation for Block Cipher Modes of Operation", U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38a/ sp800-38a.pdf>.
[模式]德沃金，M.，“NIST特别出版物800-38：分组密码操作模式建议”，美国国家标准与技术研究所<http://csrc.nist.gov/publications/nistpubs/800-38a/ sp800-38a.pdf>。
[MV04] McGrew, D. and J. Viega, "The Security and Performance of the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT '04, December 2004, <http://eprint.iacr.org/2004/193>.
[MV04]McGrew，D.和J.Viega，“Galois/计数器模式（GCM）的安全性和性能”，INDOCRYPT'04会议记录，2004年12月<http://eprint.iacr.org/2004/193>.
[R02] Rogaway, P., "Authenticated encryption with Associated-Data", ACM Conference on Computer and Communication Security (CCS'02), pp. 98-107, ACM Press, 2002, <http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>.
[R02]Rogaway，P.，“相关数据的认证加密”，ACM计算机和通信安全会议（CCS'02），第98-107页，ACM出版社，2002年<http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
Author's Address
作者地址
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 IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.