idnits 2.17.1 draft-mavrogiannopoulos-chacha-tls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6347, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5246, updated by this document, for RFC5378 checks: 2006-03-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 24, 2014) is 3744 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5489 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'CHACHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'POLY1305' Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Langley 3 Internet-Draft W. Chang 4 Updates: 5246, 6347 Google Inc 5 (if approved) N. Mavrogiannopoulos 6 Intended status: Standards Track Red Hat 7 Expires: July 28, 2014 J. Strombergson 8 Secworks Sweden AB 9 S. Josefsson 10 SJD AB 11 January 24, 2014 13 The ChaCha Stream Cipher for Transport Layer Security 14 draft-mavrogiannopoulos-chacha-tls-01 16 Abstract 18 This document describes the use of the ChaCha stream cipher with 19 HMAC-SHA1 and Poly1305 in Transport Layer Security (TLS) and Datagram 20 Transport Layer Security (DTLS) protocols. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 28, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. The ChaCha Cipher . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The Poly1305 Authenticator . . . . . . . . . . . . . . . . . . 6 59 4. ChaCha20 Cipher Suites . . . . . . . . . . . . . . . . . . . . 7 60 4.1. ChaCha20 Cipher Suites with HMAC-SHA1 . . . . . . . . . . 7 61 4.2. ChaCha20 Cipher Suites with Poly1305 . . . . . . . . . . . 7 62 5. Updates to the TLS Standard Stream Cipher . . . . . . . . . . 10 63 6. Updates to DTLS . . . . . . . . . . . . . . . . . . . . . . . 11 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 70 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 17 71 A.1. ChaCha20 . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 A.2. Poly1305 . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 A.3. AEAD_CHACHA20_POLY1305 . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 This document describes the use of the ChaCha stream cipher in the 79 Transport Layer Security (TLS) version 1.0 [RFC2246], TLS version 1.1 80 [RFC4346], and TLS version 1.2 [RFC5246] protocols, as well as in the 81 Datagram Transport Layer Security (DTLS) versions 1.0 [RFC4347] and 82 1.2 [RFC6347]. It can also be used with Secure Sockets Layer (SSL) 83 version 3.0 [RFC6101]. 85 ChaCha [CHACHA] is a stream cipher that has been designed for high 86 performance in software implementations. The cipher has compact 87 implementation and uses few resources and inexpensive operations that 88 makes it suitable for implementation on a wide range of 89 architectures. It has been designed to prevent leakage of 90 information through side channel analysis, has a simple and fast key 91 setup and provides good overall performance. It is a variant of 92 Salsa20 [SALSA20SPEC] which is one of the selected ciphers in the 93 eSTREAM portfolio [ESTREAM]. 95 Recent attacks [CBC-ATTACK] have indicated problems with CBC-mode 96 cipher suites in TLS and DTLS as well as issues with the only 97 supported stream cipher (RC4) [RC4-ATTACK]. While the existing AEAD 98 (AES-GCM) ciphersuites address some of these issues, concerns about 99 the performance and ease of software implementation are sometimes 100 raised. 102 Therefore, a new stream cipher to replace RC4 and address all the 103 previous issues is needed. It is the purpose of this document to 104 describe a secure stream cipher for both TLS and DTLS that is 105 comparable to RC4 in speed on a wide range of platforms and can be 106 implemented easily without being vulnerable to software side-channel 107 attacks. 109 2. The ChaCha Cipher 111 ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 112 2008. It is a refinement of Salsa20 and was used as the core of the 113 SHA-3 finalist, BLAKE. 115 The variant of ChaCha used in this document is ChaCha with 20 rounds 116 and a 256 bit key, which will be referred to as ChaCha20 in the rest 117 of this document. This is the conservative variant (with respect to 118 security) of the ChaCha family. 120 ChaCha maps 16, 32-bit input words to 16, 32-bit output words. By 121 convention, 8 of the input words consist of a 256-bit key, 4 are 122 constants and the remaining four are a nonce and block counter. The 123 output words are converted to bytes and XORed with the plaintext to 124 produce ciphertext. In order to generate sufficient output bytes to 125 XOR with the whole plaintext, the block counter is incremented and 126 ChaCha is run again, as many times as needed, for up to 2^70 bytes of 127 output. 129 ChaCha operates on a state of 16, 32-bit words which are initialised 130 from the input words. The first four input words are constants: 132 (0x61707865, 0x3320646e, 0x79622d32, 0x6b206574) 134 Input words 4 through 11 are taken from the 256-bit key by reading 135 the bytes in little-endian order, in 4-byte chunks. Input words 12 136 and 13 are a block counter, with word 12 overflowing into word 13. 137 Lastly, words 14 and 15 are taken from an 8-byte nonce, again by 138 reading the bytes in little-endian order, in 4-byte chunks. The 139 block counter words are initially zero. 141 ChaCha20 consists of 20 rounds, alternating between "column" rounds 142 and "diagonal" rounds. Each round applies the following "quarter- 143 round" function four times, to a different set of words each time. 144 The quarter-round function updates 4, 32-bit words (a, b, c, d) as 145 follows, where <<< is a bitwise, left rotation: 147 a += b; d ^= a; d <<<= 16; 148 c += d; b ^= c; b <<<= 12; 149 a += b; d ^= a; d <<<= 8; 150 c += d; b ^= c; b <<<= 7; 152 The 16 words are conceptually arranged in a four by four grid with 153 the first word in the top-left position and the fourth word in the 154 top-right position. The "column" rounds then apply the quarter-round 155 function to the four columns, from left to right. The "diagonal" 156 rounds apply the quarter-round to the top-left, bottom-right 157 diagonal, followed by the pattern shifted one place to the right, for 158 three more quarter-rounds. 160 Specifically, a column round applies the quarter-round function to 161 the following indexes: (0, 4, 8, 12), (1, 5, 9, 13), (2, 6, 10, 14), 162 (3, 7, 11, 15). A diagonal round applies it to these indexes: (0, 5, 163 10, 15), (1, 6, 11, 12), (2, 7, 8, 13), (3, 4, 9, 14). 165 After 20 rounds of the above processing, the original 16 input words 166 are added to the 16 words to form the 16 output words. 168 The 64 output bytes are generated from the 16 output words by 169 serializing them in little-endian order and concatenating the 170 results. 172 Test vectors for this cipher can be found in Appendix A.1. 174 3. The Poly1305 Authenticator 176 Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator 177 designed by D. J. Bernstein. Poly1305 takes a 32-byte, one-time key 178 and a message and produces a 16-byte tag that authenticates the 179 message such that an attacker has a negligible chance of producing a 180 valid tag for an inauthentic message. 182 The first 16 bytes of the one-time key form an integer, _r_, as 183 follows: the top four bits of the bytes at indexes 3, 7, 11 and 15 184 are cleared, the bottom 2 bits of the bytes at indexes 4, 8 and 12 185 are cleared and the 16 bytes are taken as a little-endian value. 187 An accumulator is set to zero. For each chunk of 16 bytes from the 188 input message, a byte with value 1 is appended and the 17 bytes are 189 treated as a little-endian number. If the last chunk has less than 190 16 bytes then zero bytes are appended after the 1 byte is appended 191 until there are 17 bytes. The value is added to the accumulator and 192 then the accumulator is multiplied by _r_, all mod 2^130 - 5. 194 Finally the last 16 bytes of the one-time key are treated as a 195 little-endian number and added to the accumulator, mod 2^128. The 196 result is serialised as a little-endian number, producing the 16 byte 197 tag. Note that the original specification of Poly1305 used a 198 different construction with AES to generate the constant term of the 199 polynomial from a counter nonce. For a more recent treatment that 200 avoids the use of a block cipher in this fashion, as is done here, 201 see section 9 of the NaCl specification [NACLCRYPTO]. 203 Test vectors for this authenticator can be found in Appendix A.2. 205 4. ChaCha20 Cipher Suites 207 In the next sections different ciphersuites are defined that utilize 208 the ChaCha20 cipher combined with various message authentication 209 methods. 211 In all cases, the pseudorandom function (PRF) for TLS 1.2 is the TLS 212 PRF with SHA-256 as the hash function. When used with TLS versions 213 prior to 1.2, the PRF is calculated as specified in the appropriate 214 version of the TLS specification. 216 The RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, DHE_PSK, RSA_PSK, 217 ECDHE_PSK key exchanges are performed as defined in [RFC5246], 218 [RFC4492], and [RFC5489]. 220 4.1. ChaCha20 Cipher Suites with HMAC-SHA1 222 The following CipherSuites are defined. 224 TLS_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x20} 225 TLS_ECDHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x21} 226 TLS_ECDHE_ECDSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x22} 228 TLS_DHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x23} 229 TLS_DHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x24} 231 TLS_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x25} 232 TLS_ECDHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x26} 233 TLS_RSA_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x27} 235 Note that ChaCha20 requires a 64-bit nonce. That nonce is updated on 236 the encryption of every TLS record, and is set to be the 64-bit TLS 237 record sequence number. In case of DTLS the 64-bit nonce is formed 238 as the concatenation of the 16-bit epoch with the 48-bit sequence 239 number. 241 The MAC algorithm used in the ciphersuites above is HMAC-SHA1 242 [RFC6234]. 244 4.2. ChaCha20 Cipher Suites with Poly1305 246 The ChaCha20 and Poly1305 primitives are built into an AEAD algorithm 247 [RFC5116], AEAD_CHACHA20_POLY1305, that takes a 32 byte key and 8 248 byte nonce as follows. 250 ChaCha20 is run with the given key and nonce and with the two counter 251 words set to zero. The first 32 bytes of the 64 byte output are 252 saved to become the one-time key for Poly1305. The remainder of the 253 output is discarded. The first counter input word is set to one and 254 the plaintext is encrypted by XORing it with the output of 255 invocations of the ChaCha20 function as needed, incrementing the 256 first counter word after each block and overflowing into the second. 257 The limits on the TLS plaintext size mean that the first counter word 258 will never overflow in practice. 260 The reason for generating the Poly1305 key like this rather than 261 using key material from the handshake is that handshake key material 262 is per-session, but for a polynomial MAC, a unique, secret key is 263 needed per-record. 265 The Poly1305 key is used to calculate a tag for the following input: 266 the concatenation of the additional data, the number of bytes of 267 additional data, the ciphertext and the number of bytes of 268 ciphertext. Numbers are represented as 8-byte, little-endian values. 269 The resulting tag is appended to the ciphertext, resulting in the 270 output of the AEAD operation. 272 Authenticated decryption is largely the reverse of the encryption 273 process: generate one block of ChaCha20 keystream and use the first 274 32 bytes as a Poly1305 key. Feed Poly1305 the additional data and 275 ciphertext, with the length suffixing as described above. Verify, in 276 constant time, that the calculated Poly1305 authenticator matches the 277 final 16 bytes of the input. If not, the input can be rejected 278 immediately. Otherwise, run ChaCha20, starting with a counter value 279 of one, to decrypt the ciphertext. 281 When used in TLS, the "record_iv_length" is zero and the nonce is the 282 sequence number for the record, as an 8-byte, big-endian number. The 283 additional data is seq_num + TLSCompressed.type + 284 TLSCompressed.version + TLSCompressed.length, where "+" denotes 285 concatenation. 287 In DTLS, the nonce is formed as the concatenation of the 16-bit epoch 288 with the 48-bit sequence number. 290 In accordance with section 4 of RFC 5116 [RFC5116], the constants for 291 this AEAD algorithm are as follows: K_LEN is 32 bytes, N_MIN and 292 N_MAX are 8 bytes, P_MAX and A_MAX are 2^64, C_MAX is 2^64+16. An 293 AEAD_CHACHA20_POLY1305 ciphertext is exactly 16 octets longer than 294 its corresponding plaintext. 296 Test vectors for this authenticator can be found in Appendix A.3. 298 The following CipherSuites are defined. 300 TLS_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x12} 301 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x13} 302 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x14} 304 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x15} 305 TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x16} 307 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x17} 308 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x18} 309 TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x19} 311 5. Updates to the TLS Standard Stream Cipher 313 The ChaCha20 ciphersuites with HMAC-SHA1 defined in this document 314 differ from the TLS RC4 ciphersuites that have been the basis for the 315 definition of Standard Stream Cipher. Unlike RC4, ChaCha20 requires 316 a nonce per record. This however, does not affect the description of 317 the Standard Stream Cipher if one assumes that a nonce is optional 318 and depends on the cipher's characteristics. 320 Hence, this document modifies the Standard Stream Cipher by adding an 321 implicit nonce of 8-bytes, which is set to be the 64-bit TLS record 322 sequence number. If the stream cipher needs more than 8 byte of 323 nonce, it can obtain additional bytes for the implicit nonce from the 324 client_write_iv and server_write_iv of the key_block. 326 Stream ciphers that don't require a nonce such as RC4 shall ignore 327 it. Other stream ciphers that require a nonce, such as ChaCha20 with 328 HMAC-SHA1, will use the nonce and reset their state on each record. 330 Note that in case of DTLS the 8-byte nonce is formed as the 331 concatenation of the 16-bit epoch with the 48-bit sequence number, 332 which are sent as part of the record. 334 6. Updates to DTLS 336 The DTLS protocol requires the cipher in use to introduce no 337 dependencies between TLS Records to allow lost or rearranged records. 338 For that it explicitly bans stream ciphers (see Section 3.1 of 339 [RFC6347]). 341 As the stream cipher described in this document, unlike RC4, does not 342 require dependencies between records, this ban of stream ciphers is 343 lifted with this document. Stream ciphers can be used with DTLS if 344 they introduce no dependencies between records. 346 7. Acknowledgements 348 The authors would like to thank Zooko Wilcox-OHearn and Samuel Neves. 350 8. IANA Considerations 352 IANA is requested to assign a value for AEAD_CHACHA20_POLY1305 in the 353 registry of AEAD algorithms [RFC5116], and also allocate the 354 following Cipher Suites in the TLS Cipher Suite Registry (note that 355 the third column contains the suggested ciphersuite numbers): 357 TLS_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x12} 358 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x13} 359 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x14} 361 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x15} 362 TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x16} 364 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x17} 365 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x18} 366 TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0x19} 368 TLS_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x20} 369 TLS_ECDHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x21} 370 TLS_ECDHE_ECDSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x22} 372 TLS_DHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x23} 373 TLS_DHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x24} 375 TLS_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x25} 376 TLS_ECDHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x26} 377 TLS_RSA_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} {0xCC, 0x27} 379 9. Security Considerations 381 ChaCha20 follows the same basic principle as Salsa20, a cipher with 382 significant security review [SALSA20-SECURITY][ESTREAM]. At the time 383 of writing this document, there are no known significant security 384 problems with either cipher, and ChaCha20 is shown to be more 385 resistant in certain attacks than Salsa20 [SALSA20-ATTACK]. 386 Furthermore ChaCha20 was used as the core of the BLAKE hash function, 387 a SHA3 finalist, that had received considerable cryptanalytic 388 attention [NIST-SHA3]. 390 Poly1305 is designed to ensure that forged messages are rejected with 391 a probability of 1-(n/2^102) for a 16*n byte message, even after 392 sending 2^64 legitimate messages. 394 The cipher suites described in this document require that an nonce is 395 never repeated under the same key. The design presented ensures that 396 by using the TLS sequence number which is unique and does not wrap 397 [RFC5246]. 399 This document should not introduce any other security considerations 400 than those that directly follow from the use of the stream cipher 401 ChaCha20, the AEAD_CHACHA20_POLY1305 construction, and those that 402 directly follow from introducing any set of stream cipher suites into 403 TLS and DTLS. 405 10. References 407 10.1. Normative References 409 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 410 RFC 2246, January 1999. 412 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 413 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 415 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 416 Security", RFC 4347, April 2006. 418 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 419 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 420 for Transport Layer Security (TLS)", RFC 4492, May 2006. 422 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 423 Encryption", RFC 5116, January 2008. 425 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 426 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 428 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 429 Transport Layer Security (TLS)", RFC 5489, March 2009. 431 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 432 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 434 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 435 Security Version 1.2", RFC 6347, January 2012. 437 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", 438 January 2008, 439 . 441 [POLY1305] 442 Bernstein, D., "The Poly1305-AES message-authentication 443 code.", March 2005, 444 . 446 10.2. Informative References 448 [SALSA20SPEC] 449 Bernstein, D., "Salsa20 specification", April 2005, 450 . 452 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 453 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 454 August 2011. 456 [SALSA20-SECURITY] 457 Bernstein, D., "Salsa20 security", April 2005, 458 . 460 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 461 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 462 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio (rev. 463 1)", September 2008, 464 . 466 [CBC-ATTACK] 467 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 468 the TLS and DTLS Record Protocols", IEEE Symposium on 469 Security and Privacy , 2013. 471 [RC4-ATTACK] 472 Isobe, T., Ohigashi, T., Watanabe, Y., and M. Morii, "Full 473 Plaintext Recovery Attack on Broadcast RC4", International 474 Workshop on Fast Software Encryption , 2013. 476 [SALSA20-ATTACK] 477 Aumasson, J-P., Fischer, S., Khazaei, S., Meier, W., and 478 C. Rechberger, "New Features of Latin Dances: Analysis of 479 Salsa, ChaCha, and Rumba", 2007, 480 . 482 [NACLCRYPTO] 483 Bernstein, D., "Cryptography in NaCl", March 2009, 484 . 486 [NIST-SHA3] 487 Chang, S., Burr, W., Kelsey, J., Paul, S., and L. Bassham, 488 "Third-Round Report of the SHA-3 Cryptographic Hash 489 Algorithm Competition", 2012, 490 . 492 Appendix A. Test vectors 494 A.1. ChaCha20 496 The following blocks contain test vectors for ChaCha20. The first 497 line contains the 256-bit key, the second the 64-bit nonce and the 498 last line contains a prefix of the resulting ChaCha20 key-stream. 500 KEY: 00000000000000000000000000000000000000000000000000000000 501 00000000 502 NONCE: 0000000000000000 503 KEYSTREAM: 76b8e0ada0f13d90405d6ae55386bd28bdd219b8a08ded1aa836efcc 504 8b770dc7da41597c5157488d7724e03fb8d84a376a43b8f41518a11c 505 c387b669b2ee6586 507 KEY: 00000000000000000000000000000000000000000000000000000000 508 00000001 509 NONCE: 0000000000000000 510 KEYSTREAM: 4540f05a9f1fb296d7736e7b208e3c96eb4fe1834688d2604f450952 511 ed432d41bbe2a0b6ea7566d2a5d1e7e20d42af2c53d792b1c43fea81 512 7e9ad275ae546963 514 KEY: 00000000000000000000000000000000000000000000000000000000 515 00000000 516 NONCE: 0000000000000001 517 KEYSTREAM: de9cba7bf3d69ef5e786dc63973f653a0b49e015adbff7134fcb7df1 518 37821031e85a050278a7084527214f73efc7fa5b5277062eb7a0433e 519 445f41e3 521 KEY: 00000000000000000000000000000000000000000000000000000000 522 00000000 523 NONCE: 0100000000000000 524 KEYSTREAM: ef3fdfd6c61578fbf5cf35bd3dd33b8009631634d21e42ac33960bd1 525 38e50d32111e4caf237ee53ca8ad6426194a88545ddc497a0b466e7d 526 6bbdb0041b2f586b 528 KEY: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b 529 1c1d1e1f 530 NONCE: 0001020304050607 531 KEYSTREAM: f798a189f195e66982105ffb640bb7757f579da31602fc93ec01ac56 532 f85ac3c134a4547b733b46413042c9440049176905d3be59ea1c53f1 533 5916155c2be8241a38008b9a26bc35941e2444177c8ade6689de9526 534 4986d95889fb60e84629c9bd9a5acb1cc118be563eb9b3a4a472f82e 535 09a7e778492b562ef7130e88dfe031c79db9d4f7c7a899151b9a4750 536 32b63fc385245fe054e3dd5a97a5f576fe064025d3ce042c566ab2c5 537 07b138db853e3d6959660996546cc9c4a6eafdc777c040d70eaf46f7 538 6dad3979e5c5360c3317166a1c894c94a371876a94df7628fe4eaaf2 539 ccb27d5aaae0ad7ad0f9d4b6ad3b54098746d4524d38407a6deb3ab7 540 8fab78c9 542 A.2. Poly1305 544 The following blocks contain test vectors for Poly1305. The first 545 line contains a variable length input. The second contains the 256- 546 bit key and the last contains the resulting, 128-bit tag. 548 INPUT: 000000000000000000000000000000000000000000000000000000000000 549 0000 550 KEY: 746869732069732033322d62797465206b657920666f7220506f6c793133 551 3035 552 TAG: 49ec78090e481ec6c26b33b91ccc0307 554 INPUT: 48656c6c6f20776f726c6421 555 KEY: 746869732069732033322d62797465206b657920666f7220506f6c793133 556 3035 557 TAG: a6f745008f81c916a20dcc74eef2b2f0 559 A.3. AEAD_CHACHA20_POLY1305 561 The following block contains a test vector for the 562 AEAD_CHACHA20_POLY1305 algorithm. The first four lines consist of 563 the standard inputs to an AEAD algorithm and the last line contains 564 the encrypted and authenticated result. 566 KEY: 4290bcb154173531f314af57f3be3b5006da371ece272afa1b5dbdd110 567 0a1007 568 INPUT: 86d09974840bded2a5ca 569 NONCE: cd7cf67be39c794a 570 AD: 87e229d4500845a079c0 571 OUTPUT: e3e446f7ede9a19b62a4677dabf4e3d24b876bb284753896e1d6 573 To aid implementations, the next block contains some intermediate 574 values in the AEAD_CHACHA20_POLY1305 algorithm. The first line 575 contains the Poly1305 key that is derived and the second contains the 576 raw bytes that are authenticated by Poly1305. 578 KEY: 9052a6335505b6d507341169783dccac0e26f84ea84906b1558c05bf4815 579 0fbe 580 INPUT: 87e229d4500845a079c00a00000000000000e3e446f7ede9a19b62a40a00 581 000000000000 583 Authors' Addresses 585 Adam Langley 586 Google Inc 588 Email: agl@google.com 590 Wan-Teh Chang 591 Google Inc 593 Email: wtc@google.com 595 Nikos Mavrogiannopoulos 596 Red Hat 598 Email: nmav@redhat.com 600 Joachim Strombergson 601 Secworks Sweden AB 603 Email: joachim@secworks.se 604 URI: http://secworks.se/ 606 Simon Josefsson 607 SJD AB 609 Email: simon@josefsson.org 610 URI: http://josefsson.org/