RFC 8103: Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc8103
标题 : RFC 8103
翻译类型 : 自动生成

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 8103                                Vigil Security
Category: Standards Track                                  February 2017
ISSN: 2070-1721

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 8103                                Vigil Security
Category: Standards Track                                  February 2017
ISSN: 2070-1721

Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)

在加密消息语法（CMS）中使用ChaCha20-Poly1305认证加密

Abstract

摘要

This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.

本文档描述了在加密消息语法（CMS）中使用ChaCha20-Poly1305认证加密的约定。ChaCha20-Poly1305是一种由ChaCha流密码和Poly1305认证器构成的认证加密算法。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8103.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8103.

版权公告

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。

Table of Contents

   1. Introduction ....................................................2
      1.1. The ChaCha20 and Poly1305 AEAD Construction ................3
      1.2. ASN.1 ......................................................3
      1.3. Terminology ................................................3
   2. Key Management ..................................................4
   3. Using the AEAD_CHACHA20_POLY1305 Algorithm with
      AuthEnvelopedData ...............................................4
   4. S/MIME Capabilities Attribute ...................................5
   5. IANA Considerations .............................................6
   6. Security Considerations .........................................6
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................8
   Appendix A. ASN.1 Module ...........................................9
   Acknowledgements ...................................................9
   Author's Address ...................................................9

   1. Introduction ....................................................2
      1.1. The ChaCha20 and Poly1305 AEAD Construction ................3
      1.2. ASN.1 ......................................................3
      1.3. Terminology ................................................3
   2. Key Management ..................................................4
   3. Using the AEAD_CHACHA20_POLY1305 Algorithm with
      AuthEnvelopedData ...............................................4
   4. S/MIME Capabilities Attribute ...................................5
   5. IANA Considerations .............................................6
   6. Security Considerations .........................................6
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................8
   Appendix A. ASN.1 Module ...........................................9
   Acknowledgements ...................................................9
   Author's Address ...................................................9

1. Introduction

1. 介绍

This document specifies the conventions for using ChaCha20-Poly1305 Authenticated Encryption with the Cryptographic Message Syntax (CMS) [CMS] authenticated-enveloped-data content type [AUTHENV].

本文件规定了使用ChaCha20-Poly1305认证加密和加密消息语法（CMS）[CMS]认证信封数据内容类型[AUTHENV]的约定。

ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 2008. It is a refinement of Salsa20, which is one of the ciphers in the eSTREAM portfolio [ESTREAM].

ChaCha[ChaCha]是D.J.Bernstein在2008年开发的一种流密码。它是Salsa20的改进，Salsa20是eSTREAM组合[eSTREAM]中的密码之一。

ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key and a 96-bit nonce. [FORIETF] provides a detailed algorithm description, examples, and test vectors of ChaCha20.

ChaCha20是ChaCha的20轮变体；它需要256位密钥和96位nonce。[FORIETF]提供了CHA20的详细算法描述、示例和测试向量。

Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator designed by D. J. Bernstein. Poly1305 produces a 16-byte authentication tag; it requires a 256-bit, single-use key. [FORIETF] also provides a detailed algorithm description, examples, and test vectors of Poly1305.

Poly1305[Poly1305]是由D.J.Bernstein设计的Wegman-Carter一次性验证器。Poly1305产生一个16字节的认证标签；它需要一个256位的一次性密钥。[FORIETF]还提供了Poly1305的详细算法描述、示例和测试向量。

ChaCha20 and Poly1305 have been designed for high-performance software implementations. They can typically be implemented with few resources and inexpensive operations, making them suitable on a wide range of systems. They have also been designed to minimize leakage of information through side channels.

ChaCha20和Poly1305是为高性能软件实现而设计的。它们通常可以用很少的资源和廉价的操作来实现，这使得它们适用于广泛的系统。它们还被设计用于最大限度地减少通过旁道的信息泄漏。

1.1. The ChaCha20 and Poly1305 AEAD Construction

1.1. ChaCha20和Poly1305 AEAD结构

ChaCha20 and Poly1305 have been combined to create an Authenticated Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is described in [FORIETF].

ChaCha20和Poly1305已经结合起来，创建了一个带有关联数据的认证加密（AEAD）算法[AEAD]。这种AEAD算法通常被称为AEAD_CHACHA20_POLY1305，并在[FORIETF]中进行了描述。

AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit nonce, an arbitrary-length plaintext, and an arbitrary-length additional authenticated data (AAD). As the name implies, a nonce value cannot be used securely more than once with the same key.

AEAD_CHACHA20_POLY1305接受四个输入：256位密钥、96位nonce、任意长度的明文和任意长度的附加认证数据（AAD）。顾名思义，nonce值不能与同一密钥一起安全地使用多次。

AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same length as the plaintext and a 128-bit authentication tag.

AEAD_CHACHA20_POLY1305产生两个输出：与明文长度相同的密文和128位认证标签。

AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar to the encryption processing. Of course, the roles of ciphertext and plaintext are reversed, so the ChaCha20 encryption function is applied to the ciphertext, producing the plaintext. The Poly1305 function is run over the AAD and the ciphertext, not the plaintext, and the resulting authentication tag is bitwise compared to the received authentication tag. The message is authenticated if and only if the calculated and received authentication tags match.

AEAD_CHACHA20_POLY1305认证解密处理与加密处理类似。当然，密文和明文的作用是相反的，因此对密文应用ChaCha20加密函数，生成明文。Poly1305函数在AAD和密文（而不是明文）上运行，并且生成的身份验证标签与接收到的身份验证标签按位进行比较。当且仅当计算的身份验证标记与接收的身份验证标记匹配时，才会对消息进行身份验证。

1.2. ASN.1

CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690].

CMS值是使用ASN.1[X680]生成的，它使用基本编码规则（BER）和可分辨编码规则（DER）[X690]。

1.3. Terminology

1.3. 术语

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]中所述进行解释。

2. Key Management

2. 密钥管理

The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key destroys the security guarantees. It can be extremely difficult to use a statically configured AEAD_CHACHA20_POLY1305 key and never repeat a nonce value; however, the CMS authenticated-enveloped-data content type supports four key management techniques that allow a fresh AEAD_CHACHA20_POLY1305 key to be used as the content-authenticated-encryption key for a single protected content:

使用相同密钥重用AEAD_CHACHA20_POLY1305 nonce值会破坏安全保证。使用静态配置的AEAD_CHACHA20_POLY1305密钥并且从不重复nonce值可能非常困难；但是，CMS认证的信封数据内容类型支持四种密钥管理技术，允许使用新的AEAD_CHACHA20_POLY1305密钥作为单个受保护内容的内容认证加密密钥：

Key Transport: the fresh 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-encryption key, then the fresh content-authenticated-encryption key is encrypted in the pairwise symmetric key;

密钥协议：使用接收方的公钥和发送方的私钥生成一个成对对称密钥加密密钥，然后在成对对称密钥中加密新内容认证的加密密钥；

Symmetric Key-Encryption Keys: the fresh content-authenticated-encryption key is encrypted in a previously distributed symmetric key-encryption key; and

对称密钥加密密钥：新鲜内容认证加密密钥在先前分发的对称密钥加密密钥中加密；和

Passwords: the fresh content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value.

密码：新内容认证的加密密钥在密钥加密密钥中加密，该密钥加密密钥源自密码或其他共享密钥值。

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 about their support of fresh content-authenticated-encryption keys can be made. Designers and implementers must perform their own analysis if one of these other key management techniques is supported.

除了这四种通用密钥管理技术外，CMS还支持其他密钥管理技术。见[CMS]第6.2.5节。由于这些密钥管理技术的属性未知，因此无法说明它们支持新内容认证的加密密钥。如果支持这些其他关键管理技术之一，则设计者和实现者必须执行他们自己的分析。

3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData

3. 在AuthEnvelopedData中使用AEAD_CHACHA20_POLY1305算法

This section specifies the conventions employed by CMS implementations that support the authenticated-enveloped-data content type and the AEAD_CHACHA20_POLY1305 algorithm.

本节规定了CMS实现所采用的约定，这些约定支持经过身份验证的信封数据内容类型和AEAD_CHACHA20_POLY1305算法。

The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.

AEAD_CHACHA20_POLY1305算法标识符位于AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm字段中。

The AEAD_CHACHA20_POLY1305 algorithm is used to (1) authenticate the attributes located in the AuthEnvelopedData authAttrs field, if any are present, (2) encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field, and (3) provide the message authentication code (MAC) located in the AuthEnvelopedData mac field. The authenticated attributes are DER encoded to produce the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm. The ciphertext and the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 algorithm. Note that the MAC, which is called the authentication tag in [FORIETF], provides integrity protection for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent.

AEAD_CHACHA20_POLY1305算法用于（1）验证AuthEnvelopedData authAttrs字段中的属性（如果存在），（2）加密AuthEnvelopedData EncryptedContentInfo encryptedContent字段中的内容，以及（3）提供消息验证码（MAC）位于AuthEnvelopedData mac字段中。对认证属性进行DER编码，以产生AEAD_CHACHA20_POLY1305算法的AAD输入值。密文和MAC是AEAD_CHACHA20_POLY1305算法的两个输出。请注意，MAC（在[FORIETF]中称为身份验证标签）为AuthEnvelopedData authAttrs和AuthEnvelopedData EncryptedContentInfo encryptedContent提供完整性保护。

Neither the plaintext content nor the optional AAD inputs need to be padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm.

在调用AEAD_CHACHA20_POLY1305算法之前，无需填充纯文本内容或可选AAD输入。

There is one algorithm identifier for the AEAD_CHACHA20_POLY1305 algorithm:

AEAD_CHACHA20_POLY1305算法有一个算法标识符：

      id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
          { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs9(9) smime(16) alg(3) 18 }

      id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
          { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs9(9) smime(16) alg(3) 18 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain an AEADChaCha20Poly1305Nonce:

AlgorithmIdentifier parameters字段必须存在，并且parameters字段必须包含AEADChaCha20Poly1305Nonce：

      AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

      AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the CMS, the content-authenticated-encryption key is normally used for a single content. 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.

AEADChaCha20Poly1305Nonce包含一个12个八位字节的nonce。对于CMS，内容认证加密密钥通常用于单个内容。在任何内容认证加密密钥的范围内，nonce值必须是唯一的。也就是说，与任何给定键一起使用的nonce值集不得包含任何重复值。

4. S/MIME Capabilities Attribute

4. S/MIME功能属性

Section 2.5.2 of RFC 5751 [MSG] defines the SMIMECapabilities attribute, which is used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. When constructing a CMS signed-data content type, compliant software MAY include the SMIMECapabilities signed attribute to announce support for the AEAD_CHACHA20_POLY1305 algorithm.

RFC 5751[MSG]第2.5.2节定义了SMIMECapability属性，该属性用于指定宣布SMIMECapability的软件可以支持的算法的部分列表。在构建CMS签名数据内容类型时，兼容软件可能包括SMIMECapabilities signed属性，以宣布对AEAD_CHACHA20_POLY1305算法的支持。

The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305 algorithm MUST include the id-alg-AEADChaCha20Poly1305 object identifier in the capabilityID field and MUST omit the parameters field.

表示AEAD_CHACHA20_POLY1305算法的SMIMECapability序列必须在capabilityID字段中包含id-alg-AEADcha20Poly1305对象标识符，并且必须省略parameters字段。

The DER encoding of an SMIMECapability SEQUENCE is the same as the DER encoding of an AlgorithmIdentifier. The DER encoding for the AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in hexadecimal) is:

SMIMECapability序列的DER编码与算法标识符的DER编码相同。AEAD_CHACHA20_POLY1305算法在SMIMECapability序列（十六进制）中的DER编码为：

30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 12

5. IANA Considerations

5. IANA考虑

IANA has added the following entry in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry:

IANA在“S/MIME算法的SMI安全性（1.2.840.113549.1.9.16.3）”注册表中添加了以下条目：

18 id-alg-AEADChaCha20Poly1305 RFC 8103

IANA has added the following entry in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:

IANA在“S/MIME模块标识符的SMI安全性（1.2.840.113549.1.9.16.0）”注册表中添加了以下条目：

66 id-mod-CMS-AEADChaCha20Poly1305 RFC 8103

66 id-mod-CMS-AEADCHA20POLY1305 RFC 8103

6. Security Considerations

6. 安全考虑

The CMS AuthEnvelopedData provides all of the tools needed to avoid reuse of the same nonce value under the same key. See the discussion in Section 2 of this document. RFC 7539 [FORIETF] describes the consequences of using a nonce value more than once:

CMS AuthEnvelopedData提供了避免在同一密钥下重复使用相同nonce值所需的所有工具。见本文件第2节中的讨论。RFC 7539[FORIETF]描述了多次使用nonce值的后果：

Consequences of repeating a nonce: If a nonce is repeated, then both the one-time Poly1305 key and the keystream are identical between the messages. This reveals the XOR of the plaintexts, because the XOR of the plaintexts is equal to the XOR of the ciphertexts.

重复一个nonce的后果：如果一个nonce被重复，那么消息之间的一次性Poly1305密钥和密钥流都是相同的。这揭示了明文的XOR，因为明文的XOR等于密文的XOR。

When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always the same size as the original plaintext. Some other mechanism needs to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure of the size of the plaintext is a concern.

使用AEAD_CHACHA20_POLY1305时，生成的密文始终与原始明文大小相同。如果涉及到明文大小的披露，则需要结合AEAD_CHACHA20_POLY1305使用其他一些机制。

The amount of encrypted data possible in a single invocation of AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of the size of the block counter field in the ChaCha20 block function. This gives a total of 247,877,906,880 octets, which is likely to be sufficient to handle the size of any CMS content type. Note that the ciphertext length field in the authentication buffer will accommodate 2^64 octets, which is much larger than necessary.

由于CHACHA20 block函数中块计数器字段的大小，AEAD_CHACHA20_POLY1305单次调用中可能的加密数据量为2^32-1个块，每个块有64个八位字节。这提供了总共247877906880个八位字节，这可能足以处理任何CMS内容类型的大小。请注意，身份验证缓冲区中的密文长度字段将容纳2^64个八位字节，这比需要的大得多。

The AEAD_CHACHA20_POLY1305 construction is a novel composition of ChaCha20 and Poly1305. A security analysis of this composition is given in [PROCTER].

AEAD_CHACHA20_POLY1305结构是CHACHA20和POLY1305的一种新型组合物。[PROCTER]中给出了该组合的安全性分析。

Implementations must randomly generate content-authenticated-encryption keys. The use of inadequate pseudorandom 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, 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[随机]在这方面提供了重要的指导。

7. References

7. 工具书类

7.1. Normative References

7.1. 规范性引用文件

[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, <http://www.rfc-editor.org/info/rfc5083>.

[AUTHENV]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，DOI 10.17487/RFC5083，2007年11月<http://www.rfc-editor.org/info/rfc5083>.

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.

[CMS]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.

[FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <http://www.rfc-editor.org/info/rfc7539>.

[FORIETF]Nir，Y.和A.Langley，“IETF协议的ChaCha20和Poly1305”，RFC 7539，DOI 10.17487/RFC7539，2015年5月<http://www.rfc-editor.org/info/rfc7539>.

[MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.

[MSG]Ramsdell，B.和S.Turner，“安全/多用途互联网邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<http://www.rfc-editor.org/info/rfc5751>.

[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.

[X680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>.

[X680]ITU-T，“信息技术-抽象语法符号1（ASN.1）：基本符号规范”，ITU-T建议X.680，ISO/IEC 8824-12015年8月<https://www.itu.int/rec/T-REC-X.680/en>.

[X690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.

[X690]ITU-T，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-12015年8月<https://www.itu.int/rec/T-REC-X.690/en>.

7.2. Informative References

7.2. 资料性引用

[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.

[AEAD]McGrew，D.，“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.

[CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>.

[CHACHA]Bernstein，D.，“CHACHA，Salsa20的变体”，2008年1月<http://cr.yp.to/chacha/chacha-20080128.pdf>.

[ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., Gilbert, H., Johansson, T., Parker, M., Preneel, B., Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio (rev. 1)", September 2008, <http://www.ecrypt.eu.org/stream/finallist.html>.

[ESTREAM]Babbage，S.，DeCanniere，C.，Cantenau，A.，Cid，C.，Gilbert，H.，Johansson，T.，Parker，M.，Preneel，B.，Rijmen，V.，和M.Robshaw，“ESTREAM投资组合（第1版）”，2008年9月<http://www.ecrypt.eu.org/stream/finallist.html>.

[POLY1305] Bernstein, D., "The Poly1305-AES message-authentication code", March 2005, <http://cr.yp.to/mac/poly1305-20050329.pdf>.

[POLY1305]Bernstein，D.，“POLY1305 AES报文认证码”，2005年3月<http://cr.yp.to/mac/poly1305-20050329.pdf>.

[PROCTER] Procter, G., "A Security Analysis of the Composition of ChaCha20 and Poly1305", August 2014, <http://eprint.iacr.org/2014/613.pdf>.

[PROCTER]PROCTER，G.“ChaCha20和Poly1305组成的安全分析”，2014年8月<http://eprint.iacr.org/2014/613.pdf>.

[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.

[RANDOM]Eastlake 3rd，D.，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.

Appendix A. ASN.1 Module

附录A.ASN.1模块

   CMS-AEADChaCha20Poly1305
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) 66 }

   CMS-AEADChaCha20Poly1305
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) 66 }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   IMPORTS
      CONTENT-ENCRYPTION
      FROM AlgorithmInformation-2009
          { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-mod-algorithmInformation-02(58) };

   IMPORTS
      CONTENT-ENCRYPTION
      FROM AlgorithmInformation-2009
          { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-mod-algorithmInformation-02(58) };

-- EXPORTS All

--全部出口

   AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::=
       { cea-AEADChaCha20Poly1305, ... }

   AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::=
       { cea-AEADChaCha20Poly1305, ... }

   cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= {
       IDENTIFIER id-alg-AEADChaCha20Poly1305
       PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required
       SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }

   cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= {
       IDENTIFIER id-alg-AEADChaCha20Poly1305
       PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required
       SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }

   id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs9(9) smime(16) alg(3) 18 }

   id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs9(9) smime(16) alg(3) 18 }

   AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

   AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

END

终止

Acknowledgements

致谢

Thanks to Jim Schaad, Daniel Migault, Stephen Farrell, Yoav Nir, and Niclas Comstedt for their review and insightful comments.

感谢Jim Schaad、Daniel Migault、Stephen Farrell、Yoav Nir和Niclas Comstedt的评论和见解。

Author's Address

作者地址

Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America

美国弗吉尼亚州赫恩登斯普林诺尔大道918号Russell Housley Vigil Security有限责任公司，邮编：20170

   Email: housley@vigilsec.com

   Email: housley@vigilsec.com