Internet Engineering Task Force (IETF) A. Langley
Request for Comments: 7905 W. Chang
Updates: 5246, 6347 Google, Inc.
Category: Standards Track N. Mavrogiannopoulos
ISSN: 2070-1721 Red Hat
J. Strombergson
Secworks Sweden AB
S. Josefsson
SJD AB
June 2016
Internet Engineering Task Force (IETF) A. Langley
Request for Comments: 7905 W. Chang
Updates: 5246, 6347 Google, Inc.
Category: Standards Track N. Mavrogiannopoulos
ISSN: 2070-1721 Red Hat
J. Strombergson
Secworks Sweden AB
S. Josefsson
SJD AB
June 2016
ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
ChaCha20-Poly1305传输层安全密码套件（TLS）
Abstract
摘要
This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
本文档描述了在传输层安全（TLS）和数据报传输层安全（DTLS）协议中使用ChaCha流密码和Poly1305身份验证器。
This document updates RFCs 5246 and 6347.
本文件更新了RFCs 5246和6347。
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/rfc7905.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7905.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ChaCha20 Cipher Suites . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ChaCha20 Cipher Suites . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in version 1.2 or later of the Transport Layer Security (TLS) protocol [RFC5246] as well as version 1.2 or later of the Datagram Transport Layer Security (DTLS) protocol [RFC6347].
本文档描述了传输层安全（TLS）协议[RFC5246]版本1.2或更高版本以及数据报传输层安全（DTLS）协议[RFC6347]版本1.2或更高版本中ChaCha流密码和Poly1305验证器的使用。
ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 2008. It is a refinement of Salsa20, which is one of the selected ciphers in the eSTREAM portfolio [ESTREAM], and it was used as the core of the SHA-3 finalist, BLAKE.
ChaCha[ChaCha]是D.J.Bernstein在2008年开发的一种流密码。它是对Salsa20的改进，Salsa20是eSTREAM组合[eSTREAM]中选定的密码之一，它被用作SHA-3决赛选手BLAKE的核心。
The variant of ChaCha used in this document has 20 rounds, a 96-bit nonce, and a 256-bit key; it is referred to as "ChaCha20". This is the conservative variant (with respect to security) of the ChaCha family and is described in [RFC7539].
本文档中使用的ChaCha变体有20轮、96位nonce和256位密钥；它被称为“ChaCha20”。这是ChaCha家族的保守变体（关于安全性），在[RFC7539]中有描述。
Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator designed by D. J. Bernstein. Poly1305 takes a 256-bit, one-time key and a message, and it produces a 16-byte tag that authenticates the message such that an attacker has a negligible chance of producing a valid tag for an inauthentic message. It is described in [RFC7539].
Poly1305[Poly1305]是由D.J.Bernstein设计的Wegman-Carter一次性验证器。Poly1305接受256位一次性密钥和一条消息，并生成一个16字节的标记，用于验证消息，因此攻击者为不真实消息生成有效标记的可能性微乎其微。[RFC7539]对此进行了描述。
ChaCha and Poly1305 have both been designed for high performance in software implementations. They typically admit a compact implementation that uses few resources and inexpensive operations, which makes them suitable on a wide range of architectures. They have also been designed to minimize leakage of information through side-channels.
ChaCha和Poly1305都是为软件实现的高性能而设计的。它们通常承认一个紧凑的实现，使用很少的资源和廉价的操作，这使得它们适合于广泛的体系结构。它们还被设计用于最大限度地减少通过旁道的信息泄漏。
Recent attacks [CBC-ATTACK] have indicated problems with the CBC-mode cipher suites in TLS and DTLS, as well as issues with the only supported stream cipher (RC4) [RC4-ATTACK]. While the existing Authenticated Encryption with Associated Data (AEAD) cipher suites (based on AES-GCM) address some of these issues, there are concerns about their performance and ease of software implementation.
最近的攻击[CBC-ATTACK]表明TLS和DTL中的CBC模式密码套件存在问题，以及仅支持的流密码（RC4）[RC4-ATTACK]存在问题。虽然现有的关联数据认证加密（AEAD）密码套件（基于AES-GCM）解决了其中一些问题，但仍存在对其性能和软件实现易用性的担忧。
Therefore, a new stream cipher to replace RC4 and address all the previous issues is needed. It is the purpose of this document to describe a secure stream cipher for both TLS and DTLS that is comparable to RC4 in speed on a wide range of platforms and can be implemented easily without being vulnerable to software side-channel attacks.
因此，需要一种新的流密码来取代RC4并解决所有以前的问题。本文档的目的是描述TLS和DTL的安全流密码，该密码在各种平台上的速度与RC4相当，并且易于实现，不易受到软件端通道攻击。
The ChaCha20 and Poly1305 primitives are built into an AEAD algorithm [RFC5116], AEAD_CHACHA20_POLY1305, as described in [RFC7539]. This AEAD is incorporated into TLS and DTLS as specified in Section 6.2.3.3 of [RFC5246].
ChaCha20和Poly1305原语内置于AEAD算法[RFC5116]，AEAD_ChaCha20_Poly1305中，如[RFC7539]所述。本AEAD按照[RFC5246]第6.2.3.3节的规定并入TLS和DTL中。
AEAD_CHACHA20_POLY1305 requires a 96-bit nonce, which is formed as follows:
AEAD_CHACHA20_POLY1305需要96位nonce，其形式如下：
1. The 64-bit record sequence number is serialized as an 8-byte, big-endian value and padded on the left with four 0x00 bytes.
1. 64位记录序列号被序列化为8字节的大端值，并在左侧填充四个0x00字节。
2. The padded sequence number is XORed with the client_write_IV (when the client is sending) or server_write_IV (when the server is sending).
2. 填充的序列号与客户机_write_IV（当客户机发送时）或服务器_write_IV（当服务器发送时）异或。
In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the 48-bit sequence_number.
在DTLS中，64位seq_num是与48位序列号连接的16位历元。
This nonce construction is different from the one used with AES-GCM in TLS 1.2 but matches the scheme expected to be used in TLS 1.3. The nonce is constructed from the record sequence number and the shared secret, both of which are known to the recipient. The advantage is that no per-record, explicit nonce need be transmitted, which saves eight bytes per record and prevents implementations from mistakenly using a random nonce. Thus, in the terms of [RFC5246], SecurityParameters.fixed_iv_length is twelve bytes and SecurityParameters.record_iv_length is zero bytes.
此nonce构造不同于TLS 1.2中与AES-GCM一起使用的构造，但与TLS 1.3中预期使用的方案相匹配。nonce由接收方已知的记录序列号和共享秘密构成。其优点是不需要传输每个记录的显式nonce，这可以为每个记录节省8个字节，并防止实现错误地使用随机nonce。因此，在[RFC5246]中，SecurityParameters.fixed_iv_长度为12字节，SecurityParameters.record_iv_长度为零字节。
The following cipher suites are defined:
定义了以下密码套件：
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAA}
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAA}
TLS_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAB}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAD}
TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAE}
TLS_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAB}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAD}
TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAE}
The DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, ECDHE_PSK, DHE_PSK, and RSA_PSK key exchanges for these cipher suites are unaltered; thus, they are performed as defined in [RFC5246], [RFC4492], and [RFC5489].
这些密码套件的DHE_RSA、ECDHE_RSA、ECDHE_ECDSA、PSK、ECDHE_PSK、DHE_PSK和RSA_PSK密钥交换是不变的；因此，它们按照[RFC5246]、[RFC4492]和[RFC5489]中的定义执行。
The pseudorandom function (PRF) for all the cipher suites defined in this document is the TLS PRF with SHA-256 [FIPS180-4] as the hash function.
本文档中定义的所有密码套件的伪随机函数（PRF）为TLS PRF，SHA-256[FIPS180-4]为哈希函数。
IANA has added the following entries in the TLS Cipher Suite Registry:
IANA在TLS密码套件注册表中添加了以下条目：
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAA}
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAA}
TLS_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAB}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAD}
TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAE}
TLS_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAB}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAD}
TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xAE}
ChaCha20 follows the same basic principle as Salsa20 [SALSA20SPEC], a cipher with significant security review [SALSA20-SECURITY] [ESTREAM]. At the time of writing this document, there are no known significant security problems with either cipher, and ChaCha20 is shown to be more resistant in certain attacks than Salsa20 [SALSA20-ATTACK]. Furthermore, ChaCha20 was used as the core of the BLAKE hash function, a SHA3 finalist, which has received considerable cryptanalytic attention [NIST-SHA3].
ChaCha20遵循与Salsa20[SALSA20SPEC]相同的基本原则，Salsa20[SALSA20SPEC]是一种具有重大安全审查[Salsa20-security][ESTREAM]的密码。在编写本文档时，两种密码都没有已知的重大安全问题，并且ChaCha20在某些攻击中比Salsa20[Salsa20-ATTACK]更具抵抗力。此外，ChaCha20被用作BLAKE hash函数的核心，BLAKE hash函数是SHA3的最终入围者，该函数受到了相当多的密码分析关注[NIST-SHA3]。
Poly1305 is designed to ensure that forged messages are rejected with a probability of 1-(n/2^107), where n is the maximum length of the input to Poly1305. In the case of (D)TLS, this means a maximum forgery probability of about 1 in 2^93.
Poly1305设计用于确保以1-（n/2^107）的概率拒绝伪造消息，其中n是Poly1305输入的最大长度。在（D）TLS的情况下，这意味着最大伪造概率约为1/2^93。
The cipher suites described in this document require that a nonce never be repeated under the same key. The design presented ensures this by using the TLS sequence number, which is unique and does not wrap [RFC5246].
本文档中描述的密码套件要求在同一密钥下不得重复nonce。所提出的设计通过使用TLS序列号来确保这一点，该序列号是唯一的，并且不包装[RFC5246]。
It should be noted that AEADs, such as ChaCha20-Poly1305, are not intended to hide the lengths of plaintexts. When this document speaks of side-channel attacks, it is not considering traffic analysis, but rather timing and cache side-channels. Traffic analysis, while a valid concern, is outside the scope of the AEAD and is being addressed elsewhere in future versions of TLS.
应该注意的是，AEAD，如ChaCha20-Poly1305，并不打算隐藏明文的长度。当本文档提到侧通道攻击时，它不考虑流量分析，而是考虑定时和缓存侧通道。虽然流量分析是一个合理的关注点，但它不在AEAD的范围内，并且正在TLS未来版本的其他地方解决。
Otherwise, this document should not introduce any additional security considerations other than those that follow from the use of the AEAD_CHACHA20_POLY1305 construction, thus the reader is directed to the Security Considerations section of [RFC7539].
否则，除使用AEAD_CHACHA20_POLY1305构造所遵循的安全注意事项外，本文件不应引入任何其他安全注意事项，因此读者请参阅[RFC7539]的安全注意事项部分。
[FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS180-4]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS180-42015年8月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<http://www.rfc-editor.org/info/rfc4492>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)", RFC 5489, DOI 10.17487/RFC5489, March 2009, <http://www.rfc-editor.org/info/rfc5489>.
[RFC5489]Badra，M.和I.Hajjeh，“用于传输层安全（TLS）的ECDHE_PSK密码套件”，RFC 5489，DOI 10.17487/RFC5489，2009年3月<http://www.rfc-editor.org/info/rfc5489>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC7539] 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>.
[RFC7539]Nir，Y.和A.Langley，“IETF协议的ChaCha20和Poly1305”，RFC 7539，DOI 10.17487/RFC7539，2015年5月<http://www.rfc-editor.org/info/rfc7539>.
[CBC-ATTACK] AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols", IEEE Symposium on Security and Privacy, 2013, <http://www.ieee-security.org/TC/SP2013/papers/ 4977a526.pdf>.
[CBC-ATTACK]AlFardan，N.和K.Paterson，“幸运十三：打破TLS和DTLS记录协议”，IEEE安全和隐私研讨会，2013年<http://www.ieee-security.org/TC/SP2013/papers/ 4977a526.pdf>。
[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>.
[NIST-SHA3] Chang, S., Perlner, R., Burr, W., Turan, M., Kelsey, J., Paul, S., and L. Bassham, "Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition", DOI 10.6028/NIST.IR.7896, November 2012, <http://dx.doi.org/10.6028/NIST.IR.7896>.
[NIST-SHA3]Chang，S.，Perlner，R.，Burr，W.，Turan，M.，Kelsey，J.，Paul，S.，和L.Bassham，“SHA-3加密哈希算法竞赛第三轮报告”，DOI 10.6028/NIST.IR.78962012年11月<http://dx.doi.org/10.6028/NIST.IR.7896>.
[POLY1305] Bernstein, D., "The Poly1305-AES message-authentication code", FSE '05 Proceedings of the 12th international conference on Fast Software Encryption Pages 32-49, DOI 10.1007/11502760_3, February 2005, <http://cr.yp.to/mac/poly1305-20050329.pdf>.
[POLY1305]Bernstein，D.，“POLY1305 AES消息认证码”，FSE'05第12届快速软件加密国际会议论文集第32-49页，DOI 10.1007/11502760_3，2005年2月<http://cr.yp.to/mac/poly1305-20050329.pdf>.
[RC4-ATTACK] Isobe, T., Ohigashi, T., Watanabe, Y., and M. Morii, "Full Plaintext Recovery Attack on Broadcast RC4", International Workshop on Fast Software Encryption FSE, DOI 10.1007/978-3-662-43933-3_10, 2013, <http://www.iacr.org/archive/ fse2013/84240167/84240167.pdf>.
[RC4-攻击]Isobe，T.，Ohigashi，T.，Watanabe，Y.，和M.Morii，“广播RC4的全明文恢复攻击”，快速软件加密FSE国际研讨会，DOI 10.1007/978-3-662-43933-3_10，2013<http://www.iacr.org/archive/ fse2013/84240167/84240167.pdf>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.
[SALSA20-ATTACK] Aumasson, J-P., Fischer, S., Khazaei, S., Meier, W., and C. Rechberger, "New Features of Latin Dances: Analysis of Salsa, ChaCha, and Rumba", DOI 10.1007/978-3-540-71039-4_30, 2007, <http://eprint.iacr.org/2007/472.pdf>.
[SALSA20-ATTACK]Aumasson，J-P.，Fischer，S.，Khazaei，S.，Meier，W.，和C.Rechberger，“拉丁舞的新特征：萨尔萨舞，查查舞和伦巴舞的分析”，DOI 10.1007/978-3-540-71039-4砼，2007<http://eprint.iacr.org/2007/472.pdf>.
[SALSA20-SECURITY] Bernstein, D., "Salsa20 security", April 2005, <http://cr.yp.to/snuffle/security.pdf>.
[SALSA20-SECURITY]Bernstein，D.，“SALSA20-SECURITY”，2005年4月<http://cr.yp.to/snuffle/security.pdf>.
[SALSA20SPEC] Bernstein, D., "Salsa20 specification", April 2005, <http://cr.yp.to/snuffle/spec.pdf>.
[SALSA20SPEC]Bernstein，D.，“Salsa20规范”，2005年4月<http://cr.yp.to/snuffle/spec.pdf>.
Acknowledgements
致谢
The authors would like to thank Zooko Wilcox-O'Hearn, Samuel Neves, and Colm MacCarthaigh for their suggestions and guidance.
作者要感谢Zooko Wilcox-O'Hearn、Samuel Neves和Colm MacCarthaigh的建议和指导。
Authors' Addresses
作者地址
Adam Langley Google, Inc.
亚当·兰利谷歌公司。
Email: agl@google.com
Email: agl@google.com
Wan-Teh Chang Google, Inc.
万德昌谷歌公司。
Email: wtc@google.com
Email: wtc@google.com
Nikos Mavrogiannopoulos Red Hat
Nikos Mavrogiannopoulos红帽
Email: nmav@redhat.com
Email: nmav@redhat.com
Joachim Strombergson Secworks Sweden AB
Joachim Strombergson Secworks瑞典公司
Email: joachim@secworks.se
URI: http://secworks.se/
Email: joachim@secworks.se
URI: http://secworks.se/
Simon Josefsson SJD AB
西蒙·约瑟夫森SJD AB
Email: simon@josefsson.org
URI: http://josefsson.org/
Email: simon@josefsson.org
URI: http://josefsson.org/