Network Working Group R. Housley
Request for Comments: 5084 Vigil Security
Category: Standards Track November 2007
Network Working Group R. Housley
Request for Comments: 5084 Vigil Security
Category: Standards Track November 2007
Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)
在加密消息语法（CMS）中使用AES-CCM和AES-GCM认证加密
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 specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type.
本文件规定了使用AES-CCM和AES-GCM认证加密算法以及加密消息语法（CMS）认证信封数据内容类型的约定。
This document specifies the conventions for using Advanced Encryption Standard-Counter with Cipher Block Chaining-Message Authentication Code (AES-CCM) and AES-Galois/Counter Mode (GCM) authenticated encryption algorithms as the content-authenticated-encryption algorithm with the Cryptographic Message Syntax [CMS] authenticated-enveloped-data content type [AuthEnv].
本文件规定了使用具有密码块链接消息认证码（AES-CCM）的高级加密标准计数器和AES伽罗瓦/计数器模式（GCM）认证加密算法作为具有加密消息语法[CMS]的内容认证加密算法的约定已验证的信封数据内容类型[AuthEnv]。
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 RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
CMS values are generated using ASN.1 [X.208-88], which uses the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88].
CMS值是使用ASN.1[X.208-88]生成的，它使用基本编码规则（BER）[X.209-88]和可分辨编码规则（DER）[X.509-88]。
Dr. Joan Daemen and Dr. Vincent Rijmen, both from Belgium, developed the Rijndael block cipher algorithm, and they submitted it for consideration as the Advanced Encryption Standard (AES). Rijndael
来自比利时的Joan Daemen博士和Vincent Rijmen博士开发了Rijndael分组密码算法，并将其作为高级加密标准（AES）提交考虑。分组密码
was selected by the National Institute for Standards and Technology (NIST), and it is specified in a U.S. Federal Information Processing Standard (FIPS) Publication [AES]. NIST selected the Rijndael algorithm for AES because it offers a combination of security, performance, efficiency, ease of implementation, and flexibility. Specifically, the algorithm performs well in both hardware and software across a wide range of computing environments. Also, the very low memory requirements of the algorithm make it very well suited for restricted-space environments. The AES is widely used by organizations, institutions, and individuals outside of the U.S. Government.
由国家标准与技术研究所（NIST）选定，并在美国联邦信息处理标准（FIPS）出版物[AES]中规定。NIST选择Rijndael算法用于AES，因为它提供了安全性、性能、效率、易于实现和灵活性的组合。具体来说，该算法在各种计算环境中的硬件和软件性能都很好。此外，该算法对内存的要求非常低，因此非常适合受限空间环境。AES被美国政府以外的组织、机构和个人广泛使用。
The AES specifies three key sizes: 128, 192, and 256 bits.
AES指定三种密钥大小：128、192和256位。
The Counter with CBC-MAC (CCM) mode of operation is specified in [CCM]. CCM is a generic authenticated encryption block cipher mode. CCM is defined for use with any 128-bit block cipher, but in this document, CCM is used with the AES block cipher.
[CCM]中规定了具有CBC-MAC（CCM）操作模式的计数器。CCM是一种通用的认证加密分组密码模式。CCM定义用于任何128位分组密码，但在本文档中，CCM用于AES分组密码。
AES-CCM has four inputs: an AES key, a nonce, a plaintext, and optional additional authenticated data (AAD). AES-CCM generates two outputs: a ciphertext and a message authentication code (also called an authentication tag).
AES-CCM有四个输入：AES密钥、nonce、明文和可选的附加认证数据（AAD）。AES-CCM生成两个输出：密文和消息认证码（也称为认证标签）。
The nonce is generated by the party performing the authenticated encryption operation. Within the scope of any authenticated-encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties.
nonce由执行经过身份验证的加密操作的一方生成。在任何经过身份验证的加密密钥的范围内，nonce值必须是唯一的。也就是说，与任何给定键一起使用的nonce值集不得包含任何重复值。对使用相同密钥加密的两条不同消息使用相同的nonce会破坏安全属性。
AAD is authenticated but not encrypted. Thus, the AAD is not included in the AES-CCM output. It can be used to authenticate plaintext packet headers. In the CMS authenticated-enveloped-data content type, authenticated attributes comprise the AAD.
AAD经过身份验证，但未加密。因此，AAD不包括在AES-CCM输出中。它可用于验证明文数据包头。在CMS认证的封装数据内容类型中，认证属性包括AAD。
The Galois/Counter Mode (GCM) is specified in [GCM]. GCM is a generic authenticated encryption block cipher mode. GCM is defined for use with any 128-bit block cipher, but in this document, GCM is used with the AES block cipher.
伽罗瓦/计数器模式（GCM）在[GCM]中指定。GCM是一种通用的认证加密分组密码模式。GCM定义用于任何128位分组密码，但在本文档中，GCM用于AES分组密码。
AES-GCM has four inputs: an AES key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). AES-GCM generates two outputs: a ciphertext and message
AES-GCM有四个输入：AES密钥、初始化向量（IV）、明文内容和可选的附加认证数据（AAD）。AES-GCM生成两个输出：密文和消息
authentication code (also called an authentication tag). To have a common set of terms for AES-CCM and AES-GCM, the AES-GCM IV is referred to as a nonce in the remainder of this document.
身份验证代码（也称为身份验证标签）。为了获得AES-CCM和AES-GCM的通用术语集，AES-GCM IV在本文件的其余部分中被称为nonce。
The nonce is generated by the party performing the authenticated encryption operation. Within the scope of any authenticated-encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties.
nonce由执行经过身份验证的加密操作的一方生成。在任何经过身份验证的加密密钥的范围内，nonce值必须是唯一的。也就是说，与任何给定键一起使用的nonce值集不得包含任何重复值。对使用相同密钥加密的两条不同消息使用相同的nonce会破坏安全属性。
AAD is authenticated but not encrypted. Thus, the AAD is not included in the AES-GCM output. It can be used to authenticate plaintext packet headers. In the CMS authenticated-enveloped-data content type, authenticated attributes comprise the AAD.
AAD经过身份验证，但未加密。因此，AES-GCM输出中不包括AAD。它可用于验证明文数据包头。在CMS认证的封装数据内容类型中，认证属性包括AAD。
The reuse of an AES-CCM or AES-GCM nonce/key combination destroys the security guarantees. As a result, it can be extremely difficult to use AES-CCM or AES-GCM securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system [KEYMGMT].
重用AES-CCM或AES-GCM nonce/key组合会破坏安全保证。因此，当使用静态配置的密钥时，安全地使用AES-CCM或AES-GCM可能非常困难。为了安全起见，实施必须使用自动密钥管理系统[KEYMGMT]。
The CMS authenticated-enveloped-data content type supports four general key management techniques:
CMS认证的信封数据内容类型支持四种通用密钥管理技术：
Key Transport: the content-authenticated-encryption key is encrypted in the recipient's public key;
密钥传输：内容认证加密密钥在接收方公钥中加密；
Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key, then the content-authenticated-encryption key is encrypted in the pairwise symmetric key;
密钥协议：使用接收方的公钥和发送方的私钥生成成对对称密钥，然后在成对对称密钥中加密内容认证的加密密钥；
Symmetric Key-Encryption Keys: the content-authenticated-encryption key is encrypted in a previously distributed symmetric key-encryption key; and
对称密钥加密密钥：内容认证加密密钥在先前分发的对称密钥加密密钥中加密；和
Passwords: the content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value.
密码：内容身份验证加密密钥在密钥加密密钥中加密，该密钥加密密钥源自密码或其他共享密钥值。
All of these key management techniques meet the automated key management system requirement as long as a fresh content-authenticated-encryption key is generated for the protection of each content. Note that some of these key management techniques use one key-encryption key to encrypt more than one content-authenticated-
所有这些密钥管理技术都满足自动密钥管理系统的要求，只要生成新的内容认证加密密钥以保护每个内容。请注意，其中一些密钥管理技术使用一个密钥加密密钥加密多个经过身份验证的内容-
encryption key during the system life cycle. As long as fresh content-authenticated-encryption key is used each time, AES-CCM and AES-GCM can be used safely with the CMS authenticated-enveloped-data content type.
系统生命周期内的加密密钥。只要每次都使用新鲜内容认证加密密钥，AES-CCM和AES-GCM就可以安全地与CMS认证的信封数据内容类型一起使用。
In addition to these four general key management techniques, CMS supports other key management techniques. See Section 6.2.5 of [CMS]. Since the properties of these key management techniques are unknown, no statement can be made about whether these key management techniques meet the automated key management system requirement. Designers and implementers must perform their own analysis if one of these other key management techniques is supported.
除了这四种通用密钥管理技术外，CMS还支持其他密钥管理技术。见[CMS]第6.2.5节。由于这些密钥管理技术的特性未知，因此无法说明这些密钥管理技术是否满足自动密钥管理系统的要求。如果支持这些其他关键管理技术之一，则设计者和实现者必须执行他们自己的分析。
This section specifies the conventions employed by CMS implementations that support content-authenticated encryption using AES-CCM or AES-GCM.
本节规定了CMS实施采用的约定，这些约定支持使用AES-CCM或AES-GCM进行内容认证加密。
Content-authenticated encryption algorithm identifiers are located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.
内容认证加密算法标识符位于AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm字段中。
Content-authenticated encryption algorithms are used to encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field and to provide the message authentication code for the AuthEnvelopedData mac field. Note that the message authentication code provides integrity protection for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent.
内容认证加密算法用于加密AuthEnvelopedData EncryptedContentInfo encryptedContent字段中的内容，并为AuthEnvelopedData mac字段提供消息认证代码。请注意，消息身份验证代码为AuthEnvelopedData authAttrs和AuthEnvelopedData EncryptedContentInfo encryptedContent提供完整性保护。
The AES-CCM authenticated encryption algorithm is described in [CCM]. A brief summary of the properties of AES-CCM is provided in Section 1.4.
[CCM]中描述了AES-CCM认证加密算法。第1.4节简要概述了AES-CCM的特性。
Neither the plaintext content nor the optional AAD inputs need to be padded prior to invoking AES-CCM.
在调用AES-CCM之前，无需填充纯文本内容或可选AAD输入。
There are three algorithm identifiers for AES-CCM, one for each AES key size:
AES-CCM有三个算法标识符，每个AES密钥大小一个：
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 }
id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 }
id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 }
id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 }
id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 }
id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 }
With all three AES-CCM algorithm identifiers, the AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a CCMParameter:
对于所有三个AES-CCM算法标识符，必须存在AlgorithmIdentifier parameters字段，并且parameters字段必须包含CCM参数：
CCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING (SIZE(7..13)),
aes-ICVlen AES-CCM-ICVlen DEFAULT 12 }
CCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING (SIZE(7..13)),
aes-ICVlen AES-CCM-ICVlen DEFAULT 12 }
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
The aes-nonce parameter field contains 15-L octets, where L is the size of the length field. With the CMS, the normal situation is for the content-authenticated-encryption key to be used for a single content; therefore, L=8 is RECOMMENDED. See [CCM] for a discussion of the trade-off between the maximum content size and the size of the nonce. Within the scope of any content-authenticated-encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values.
aes nonce参数字段包含15-L个八位字节，其中L是长度字段的大小。对于CMS，通常情况下，内容认证加密密钥用于单个内容；因此，建议L=8。请参阅[CCM]，了解最大内容大小和nonce大小之间的权衡。在任何内容认证加密密钥的范围内，nonce值必须是唯一的。也就是说，与任何给定键一起使用的nonce值集不得包含任何重复值。
The aes-ICVlen parameter field tells the size of the message authentication code. It MUST match the size in octets of the value in the AuthEnvelopedData mac field. A length of 12 octets is RECOMMENDED.
aes ICVlen参数字段指示消息身份验证代码的大小。它必须与AuthEnvelopedData mac字段中值的大小（以八位字节为单位）匹配。建议长度为12个八位字节。
The AES-GCM authenticated encryption algorithm is described in [GCM]. A brief summary of the properties of AES-CCM is provided in Section 1.5.
[GCM]中描述了AES-GCM认证加密算法。第1.5节简要概述了AES-CCM的特性。
Neither the plaintext content nor the optional AAD inputs need to be padded prior to invoking AES-GCM.
在调用AES-GCM之前，无需填充纯文本内容或可选AAD输入。
There are three algorithm identifiers for AES-GCM, one for each AES key size:
AES-GCM有三个算法标识符，每个AES密钥大小一个：
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }
id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }
id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }
id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }
id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }
id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }
With all three AES-GCM algorithm identifiers, the AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a GCMParameter:
对于所有三个AES-GCM算法标识符，必须存在AlgorithmIdentifier parameters字段，并且parameters字段必须包含GCM参数：
GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
The aes-nonce is the AES-GCM initialization vector. The algorithm specification permits the nonce to have any number of bits between 1 and 2^64. However, the use of OCTET STRING within GCMParameters requires the nonce to be a multiple of 8 bits. Within the scope of any content-authenticated-encryption key, the nonce value MUST be unique, but need not have equal lengths. A nonce value of 12 octets can be processed more efficiently, so that length is RECOMMENDED.
aes nonce是aes-GCM初始化向量。算法规范允许nonce具有1到2^64之间的任意位数。但是，在GCM参数中使用八位字符串要求nonce是8位的倍数。在任何内容认证加密密钥的范围内，nonce值必须是唯一的，但不必具有相同的长度。可以更有效地处理12个八位字节的nonce值，因此建议使用长度。
The aes-ICVlen parameter field tells the size of the message authentication code. It MUST match the size in octets of the value in the AuthEnvelopedData mac field. A length of 12 octets is RECOMMENDED.
aes ICVlen参数字段指示消息身份验证代码的大小。它必须与AuthEnvelopedData mac字段中值的大小（以八位字节为单位）匹配。建议长度为12个八位字节。
AES-CCM and AES-GCM make use of the AES block cipher in counter mode to provide encryption. When used properly, counter mode provides strong confidentiality. Bellare, Desai, Jokipii, and Rogaway show in [BDJR] that the privacy guarantees provided by counter mode are at least as strong as those for Cipher Block Chaining (CBC) mode when using the same block cipher.
AES-CCM和AES-GCM在计数器模式下使用AES分组密码进行加密。正确使用时，计数器模式可提供很强的保密性。Bellare、Desai、Jokipii和Rogaway在[BDJR]中表明，计数器模式提供的隐私保证至少与使用相同分组密码时的密码块链接（CBC）模式提供的隐私保证一样强。
Unfortunately, it is easy to misuse counter mode. If counter block values are ever used for more than one encryption operation with the same key, then the same key stream will be used to encrypt both plaintexts, and the confidentiality guarantees are voided.
不幸的是，很容易误用计数器模式。如果计数器块值曾用于具有相同密钥的多个加密操作，则相同的密钥流将用于加密两个明文，并且机密性保证无效。
Fortunately, the CMS AuthEnvelopedData provides all the tools needed to avoid misuse of counter mode. Automated key management is discussed in Section 2.
幸运的是，CMS AuthEnvelopedData提供了避免误用计数器模式所需的所有工具。第2节讨论了自动密钥管理。
There are fairly generic precomputation attacks against the use of any block cipher in counter mode that allow a meet-in-the-middle attack against the key [H][B][MF]. AES-CCM and AES-GCM both make use of counter mode for encryption. These precomputation 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 any block cipher in counter 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. Use of an unpredictable nonce value in the counter block significantly increases the size of the table that the attacker must compute to mount a successful precomputation attack.
对于在计数器模式下使用任何分组密码，存在相当普遍的预计算攻击，允许对密钥[H][B][MF]进行中间相遇攻击。AES-CCM和AES-GCM都使用计数器模式进行加密。这些预计算攻击需要创建和搜索与已知明文和已知密钥相关的大量密文表。假设内存和处理器资源可用于预计算攻击，则计数器模式下任何分组密码的理论强度限制为2^（n/2）位，其中n是密钥中的位数。使用长密钥是对付预计算攻击的最佳对策。在计数器块中使用不可预测的nonce值会显著增加表的大小，攻击者必须计算该表才能成功发起预计算攻击。
Implementations must randomly generate content-authenticated-encryption keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, and then searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area.
实现必须随机生成经过内容验证的加密密钥。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境，然后搜索生成的一小部分可能性，比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 4086[随机]在这方面提供了重要的指导。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", November 2001.
[AES]NIST，FIPS PUB 197，“高级加密标准（AES）”，2001年11月。
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[CCM]Whiting，D.，Housley，R.，和N.Ferguson，“与CBC-MAC（CCM）对抗”，RFC 36102003年9月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[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
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-
800-38D.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
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-
800-38D.pdf
[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月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88]CCITT。建议X.208：抽象语法符号1（ASN.1）的规范。1988
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88]CCITT。建议X.209：抽象语法符号1（ASN.1）的基本编码规则规范。1988
[X.509-88] CCITT. Recommendation X.509: The Directory-Authentication Framework. 1988.
[X.509-88]CCITT。建议X.509：目录认证框架。1988
[AuthEnv] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[AuthEnv]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，2007年11月。
[B] Biham, E., "How to Forge DES-Encrypted Messages in 2^28 Steps", Technion Computer Science Department Technical Report CS0884, 1996.
[B] Biham，E.，“如何在2^28个步骤中伪造DES加密消息”，Technion计算机科学部技术报告CS0884，1996年。
[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年。
[H] Hellman, M. E., "A cryptanalytic time-memory trade-off", IEEE Transactions on Information Theory, July 1980, pp. 401-406.
[H] 赫尔曼，M.E.，“密码分析的时间记忆权衡”，IEEE信息论交易，1980年7月，第401-406页。
[KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[KEYMGMT]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[MF] McGrew, D., and S. Fluhrer, "Attacks on Additive Encryption of Redundant Plaintext and Implications on Internet Security", The Proceedings of the Seventh Annual Workshop on Selected Areas in Cryptography (SAC 2000), Springer-Verlag, August, 2000.
[MF]McGrew，D.和S.Fluhrer，“对冗余明文加性加密的攻击及其对互联网安全的影响”，第七届密码学选定领域年度研讨会论文集（SAC 2000），Springer Verlag，2000年8月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
Appendix: ASN.1 Module
附录：ASN.1模块
CMS-AES-CCM-and-AES-GCM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) }
CMS-AES-CCM-and-AES-GCM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
DEFINITIONS IMPLICIT TAGS ::= BEGIN
-- EXPORTS All
--全部出口
-- Object Identifiers
--对象标识符
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 }
id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 }
id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 }
id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 }
id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 }
id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 }
id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }
id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }
id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }
id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }
id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }
id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }
-- Parameters for AigorithmIdentifier
--算法标识符的参数
CCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING (SIZE(7..13)),
aes-ICVlen AES-CCM-ICVlen DEFAULT 12 }
CCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING (SIZE(7..13)),
aes-ICVlen AES-CCM-ICVlen DEFAULT 12 }
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
END
终止
Author's Address
作者地址
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
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.