Obsoleted by: 8439 INFORMATIONAL

Errata Exist

Internet Research Task Force (IRTF) Y. Nir Request for Comments: 7539 Check Point Category: Informational A. Langley ISSN: 2070-1721 Google, Inc. May 2015 ChaCha20 and Poly1305 for IETF Protocols Abstract This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG). Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. 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/rfc7539. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Nir & Langley Informational [Page 1]

RFC 7539 ChaCha20 & Poly1305 May 2015 1 . Introduction FIPS-197]) has become the gold standard in encryption. Its efficient design, widespread implementation, and hardware support allow for high performance in many areas. On most modern platforms, AES is anywhere from four to ten times as fast as the previous most-used cipher, Triple Data Encryption Standard (3DES -- [SP800-67]), which makes it not only the best choice, but the only practical choice. There are several problems with this. If future advances in cryptanalysis reveal a weakness in AES, users will be in an unenviable position. With the only other widely supported cipher being the much slower 3DES, it is not feasible to reconfigure deployments to use 3DES. [Standby-Cipher] describes this issue and the need for a standby cipher in greater detail. Another problem is that while AES is very fast on dedicated hardware, its performance on platforms that lack such hardware is considerably lower. Yet another problem is that many AES implementations are vulnerable to cache- collision timing attacks ([Cache-Collisions]). This document provides a definition and implementation guide for three algorithms: 1. The ChaCha20 cipher. This is a high-speed cipher first described in [ChaCha]. It is considerably faster than AES in software-only implementations, making it around three times as fast on platforms that lack specialized AES hardware. See Appendix B for some hard numbers. ChaCha20 is also not sensitive to timing attacks (see the security considerations in Section 4). This algorithm is described in Section 2.4 2. The Poly1305 authenticator. This is a high-speed message authentication code. Implementation is also straightforward and easy to get right. The algorithm is described in Section 2.5. 3. The CHACHA20-POLY1305 Authenticated Encryption with Associated Data (AEAD) construction, described in Section 2.8. This document does not introduce these new algorithms for the first time. They have been defined in scientific papers by D. J. Bernstein, which are referenced by this document. The purpose of this document is to serve as a stable reference for IETF documents making use of these algorithms. These algorithms have undergone rigorous analysis. Several papers discuss the security of Salsa and ChaCha ([LatinDances], [LatinDances2], [Zhenqing2012]). Nir & Langley Informational [Page 3]

RFC 7539 ChaCha20 & Poly1305 May 2015 1.1 . Conventions Used in This Document RFC2119]. The description of the ChaCha algorithm will at various time refer to the ChaCha state as a "vector" or as a "matrix". This follows the use of these terms in Professor Bernstein's paper. The matrix notation is more visually convenient and gives a better notion as to why some rounds are called "column rounds" while others are called "diagonal rounds". Here's a diagram of how the matrices relate to vectors (using the C language convention of zero being the index origin). 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 The elements in this vector or matrix are 32-bit unsigned integers. The algorithm name is "ChaCha". "ChaCha20" is a specific instance where 20 "rounds" (or 80 quarter rounds -- see Section 2.1) are used. Other variations are defined, with 8 or 12 rounds, but in this document we only describe the 20-round ChaCha, so the names "ChaCha" and "ChaCha20" will be used interchangeably. 2 . The Algorithms 2.1 . The ChaCha Quarter Round Nir & Langley Informational [Page 4]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.1.1 . Test Vector for the ChaCha Quarter Round 2.2 . A Quarter Round on the ChaCha State Nir & Langley Informational [Page 5]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.2.1 . Test Vector for the Quarter Round on the ChaCha State 2.3 . The ChaCha20 Block Function Nir & Langley Informational [Page 6]

RFC 7539 ChaCha20 & Poly1305 May 2015 Section 3.2 of [RFC5116]. This limits the use of a single (key,nonce) combination to 2^32 blocks, or 256 GB, but that is enough for most uses. In cases where a single key is used by multiple senders, it is important to make sure that they don't use the same nonces. This can be assured by partitioning the nonce space so that the first 32 bits are unique per sender, while the other 64 bits come from a counter. The ChaCha20 state is initialized as follows: o The first four words (0-3) are constants: 0x61707865, 0x3320646e, 0x79622d32, 0x6b206574. o The next eight words (4-11) are taken from the 256-bit key by reading the bytes in little-endian order, in 4-byte chunks. o Word 12 is a block counter. Since each block is 64-byte, a 32-bit word is enough for 256 gigabytes of data. o Words 13-15 are a nonce, which should not be repeated for the same key. The 13th word is the first 32 bits of the input nonce taken as a little-endian integer, while the 15th word is the last 32 bits. cccccccc cccccccc cccccccc cccccccc kkkkkkkk kkkkkkkk kkkkkkkk kkkkkkkk kkkkkkkk kkkkkkkk kkkkkkkk kkkkkkkk bbbbbbbb nnnnnnnn nnnnnnnn nnnnnnnn c=constant k=key b=blockcount n=nonce ChaCha20 runs 20 rounds, alternating between "column rounds" and "diagonal rounds". Each round consists of four quarter-rounds, and they are run as follows. Quarter rounds 1-4 are part of a "column" round, while 5-8 are part of a "diagonal" round: 1. QUARTERROUND ( 0, 4, 8,12) 2. QUARTERROUND ( 1, 5, 9,13) 3. QUARTERROUND ( 2, 6,10,14) 4. QUARTERROUND ( 3, 7,11,15) 5. QUARTERROUND ( 0, 5,10,15) Nir & Langley Informational [Page 7]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.3.1 . The ChaCha20 Block Function in Pseudocode Nir & Langley Informational [Page 8]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.3.2 . Test Vector for the ChaCha20 Block Function Nir & Langley Informational [Page 9]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.4 . The ChaCha20 Encryption Algorithm Nir & Langley Informational [Page 10]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.4.1 . The ChaCha20 Encryption Algorithm in Pseudocode 2.4.2 . Example and Test Vector for the ChaCha20 Cipher Nir & Langley Informational [Page 11]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 12]

RFC 7539 ChaCha20 & Poly1305 May 2015 080 52 bc 51 4d 16 cc f8 06 81 8c e9 1a b7 79 37 36 R.QM.........y76 096 5a f9 0b bf 74 a3 5b e6 b4 0b 8e ed f2 78 5e 42 Z...t.[......x^B 112 87 4d .M 2.5 . The Poly1305 Algorithm Poly1305]) is titled "The Poly1305-AES message-authentication code", and the MAC function there requires a 128-bit AES key, a 128-bit "additional key", and a 128-bit (non- secret) nonce. AES is used there for encrypting the nonce, so as to get a unique (and secret) 128-bit string, but as the paper states, "There is nothing special about AES here. One can replace AES with an arbitrary keyed function from an arbitrary set of nonces to 16-byte strings." Regardless of how the key is generated, the key is partitioned into two parts, called "r" and "s". The pair (r,s) should be unique, and MUST be unpredictable for each invocation (that is why it was originally obtained by encrypting a nonce), while "r" MAY be constant, but needs to be modified as follows before being used: ("r" is treated as a 16-octet little-endian number): o r[3], r[7], r[11], and r[15] are required to have their top four bits clear (be smaller than 16) o r[4], r[8], and r[12] are required to have their bottom two bits clear (be divisible by 4) Nir & Langley Informational [Page 13]

RFC 7539 ChaCha20 & Poly1305 May 2015 Section 2.6) is also acceptable. The inputs to Poly1305 are: o A 256-bit one-time key o An arbitrary length message The output is a 128-bit tag. First, the "r" value should be clamped. Next, set the constant prime "P" be 2^130-5: 3fffffffffffffffffffffffffffffffb. Also set a variable "accumulator" to zero. Next, divide the message into 16-byte blocks. The last one might be shorter: o Read the block as a little-endian number. Nir & Langley Informational [Page 14]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.5.1 . The Poly1305 Algorithms in Pseudocode 2.5.2 . Poly1305 Example and Test Vector Nir & Langley Informational [Page 15]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 16]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.6 . Generating the Poly1305 Key Using ChaCha20 Section 2.5, it is acceptable to generate the one-time Poly1305 pseudorandomly. This section defines such a method. To generate such a key pair (r,s), we will use the ChaCha20 block function described in Section 2.3. This assumes that we have a 256-bit session key for the Message Authentication Code (MAC) function, such as SK_ai and SK_ar in Internet Key Exchange Protocol version 2 (IKEv2) ([RFC7296]), the integrity key in the Encapsulating Security Payload (ESP) and Authentication Header (AH), or the client_write_MAC_key and server_write_MAC_key in TLS. Any document that specifies the use of Poly1305 as a MAC algorithm for some protocol must specify that 256 bits are allocated for the integrity key. Note that in the AEAD construction defined in Section 2.8, the same key is used for encryption and key generation, so the use of SK_a* or *_write_MAC_key is only for stand-alone Poly1305. The method is to call the block function with the following parameters: o The 256-bit session integrity key is used as the ChaCha20 key. o The block counter is set to zero. o The protocol will specify a 96-bit or 64-bit nonce. This MUST be unique per invocation with the same key, so it MUST NOT be randomly generated. A counter is a good way to implement this, but other methods, such as a Linear Feedback Shift Register (LFSR) are also acceptable. ChaCha20 as specified here requires a 96-bit nonce. So if the provided nonce is only 64-bit, then the first 32 bits of the nonce will be set to a constant number. This will usually be zero, but for protocols with multiple senders it may be different for each sender, but should be the same for all invocations of the function with the same key by a particular sender. After running the block function, we have a 512-bit state. We take the first 256 bits or the serialized state, and use those as the one- time Poly1305 key: the first 128 bits are clamped and form "r", while the next 128 bits become "s". The other 256 bits are discarded. Nir & Langley Informational [Page 17]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.6.1 . Poly1305 Key Generation in Pseudocode 2.6.2 . Poly1305 Key Generation Test Vector 2.7 . A Pseudorandom Function for Crypto Suites based on ChaCha/Poly1305 RFC7296]), require a Pseudorandom Function (PRF), mostly for key derivation. In the IKEv2 definition, a PRF is a function that accepts a variable-length key and a Nir & Langley Informational [Page 18]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 20]

RFC 7539 ChaCha20 & Poly1305 May 2015 Procter]. Here is a list of the parameters for this construction as defined in Section 4 of RFC 5116: o K_LEN (key length) is 32 octets. o P_MAX (maximum size of the plaintext) is 247,877,906,880 bytes, or nearly 256 GB. o A_MAX (maximum size of the associated data) is set to 2^64-1 octets by the length field for associated data. o N_MIN = N_MAX = 12 octets. o C_MAX = P_MAX + tag length = 247,877,906,896 octets. Distinct AAD inputs (as described in Section 3.3 of RFC 5116) shall be concatenated into a single input to AEAD_CHACHA20_POLY1305. It is up to the application to create a structure in the AAD input if it is needed. 2.8.1 . Pseudocode for the AEAD Construction Nir & Langley Informational [Page 21]

RFC 7539 ChaCha20 & Poly1305 May 2015 2.8.2 . Example and Test Vector for AEAD_CHACHA20_POLY1305 Nir & Langley Informational [Page 22]

RFC 7539 ChaCha20 & Poly1305 May 2015 048 1a 71 de 0a 9e 06 0b 29 05 d6 a5 b6 7e cd 3b 36 .q.....)....~.;6 064 92 dd bd 7f 2d 77 8b 8c 98 03 ae e3 28 09 1b 58 ....-w......(..X 080 fa b3 24 e4 fa d6 75 94 55 85 80 8b 48 31 d7 bc ..$...u.U...H1.. 096 3f f4 de f0 8e 4b 7a 9d e5 76 d2 65 86 ce c6 4b ?....Kz..v.e...K 112 61 16 a. AEAD Construction for Poly1305: 000 50 51 52 53 c0 c1 c2 c3 c4 c5 c6 c7 00 00 00 00 PQRS............ 016 d3 1a 8d 34 64 8e 60 db 7b 86 af bc 53 ef 7e c2 ...4d.`.{...S.~. 032 a4 ad ed 51 29 6e 08 fe a9 e2 b5 a7 36 ee 62 d6 ...Q)n......6.b. 048 3d be a4 5e 8c a9 67 12 82 fa fb 69 da 92 72 8b =..^..g....i..r. 064 1a 71 de 0a 9e 06 0b 29 05 d6 a5 b6 7e cd 3b 36 .q.....)....~.;6 080 92 dd bd 7f 2d 77 8b 8c 98 03 ae e3 28 09 1b 58 ....-w......(..X 096 fa b3 24 e4 fa d6 75 94 55 85 80 8b 48 31 d7 bc ..$...u.U...H1.. 112 3f f4 de f0 8e 4b 7a 9d e5 76 d2 65 86 ce c6 4b ?....Kz..v.e...K 128 61 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a............... 144 0c 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 ........r....... Note the four zero bytes in line 000 and the 14 zero bytes in line 128 Nir & Langley Informational [Page 23]

RFC 7539 ChaCha20 & Poly1305 May 2015 3 . Implementation Advice Section 2.3 describes the ChaCha block function as "adding the original input words". This implies that before starting the rounds on the ChaCha state, we copy it aside, only to add it in later. This is correct, but we can save a few operations if we instead copy the state and do the work on the copy. This way, for the next block you don't need to recreate the state, but only to increment the block counter. This saves approximately 5.5% of the cycles. It is not recommended to use a generic big number library such as the one in OpenSSL for the arithmetic operations in Poly1305. Such libraries use dynamic allocation to be able to handle an integer of any size, but that flexibility comes at the expense of performance as well as side-channel security. More efficient implementations that run in constant time are available, one of them in D. J. Bernstein's own library, NaCl ([NaCl]). A constant-time but not optimal approach would be to naively implement the arithmetic operations for 288-bit integers, because even a naive implementation will not exceed 2^288 in the multiplication of (acc+block) and r. An efficient constant- time implementation can be found in the public domain library poly1305-donna ([Poly1305_Donna]). 4 . Security Considerations AE]. Proving the security of either of these is beyond the scope of this document. Such proofs are available in the referenced academic papers ([ChaCha], [Poly1305], [LatinDances], [LatinDances2], and [Zhenqing2012]). The most important security consideration in implementing this document is the uniqueness of the nonce used in ChaCha20. Counters and LFSRs are both acceptable ways of generating unique nonces, as is Nir & Langley Informational [Page 24]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 25]

RFC 7539 ChaCha20 & Poly1305 May 2015 Standby-Cipher] McGrew, D., Grieco, A., and Y. Sheffer, "Selection of Future Cryptographic Standards", Work in Progress, draft-mcgrew-standby-cipher-00, January 2013. [Zhenqing2012] Zhenqing, S., Bin, Z., Dengguo, F., and W. Wenling, "Improved Key Recovery Attacks on Reduced-Round Salsa20 and ChaCha*", 2012. Nir & Langley Informational [Page 28]

RFC 7539 ChaCha20 & Poly1305 May 2015 Appendix A . Additional Test Vectors Section 2. A.1 . The ChaCha20 Block Functions 032 da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37 .AY|QWH.w$.?..J7 048 6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86 jC.........i..e. Nir & Langley Informational [Page 29]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 30]

RFC 7539 ChaCha20 & Poly1305 May 2015 000 72 d5 4d fb f1 2e c4 4b 36 26 92 df 94 13 7f 32 r.M....K6&.....2 016 8f ea 8d a7 39 90 26 5e c1 bb be a1 ae 9a f0 ca ....9.&^........ 032 13 b2 5a a2 6c b4 a6 48 cb 9b 9d 1b e6 5b 2c 09 ..Z.l..H.....[,. 048 24 a6 6c 54 d5 45 ec 1b 73 74 f4 87 2e 99 f0 96 $.lT.E..st...... Test Vector #5: ============== Key: 000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Nonce: 000 00 00 00 00 00 00 00 00 00 00 00 02 ............ Block Counter = 0 ChaCha state at the end 374dc6c2 3736d58c b904e24a cd3f93ef 88228b1a 96a4dfb3 5b76ab72 c727ee54 0e0e978a f3145c95 1b748ea8 f786c297 99c28f5f 628314e8 398a19fa 6ded1b53 Keystream: 000 c2 c6 4d 37 8c d5 36 37 4a e2 04 b9 ef 93 3f cd ..M7..67J.....?. 016 1a 8b 22 88 b3 df a4 96 72 ab 76 5b 54 ee 27 c7 ..".....r.v[T.'. 032 8a 97 0e 0e 95 5c 14 f3 a8 8e 74 1b 97 c2 86 f7 .....\....t..... 048 5f 8f c2 99 e8 14 83 62 fa 19 8a 39 53 1b ed 6d _......b...9S..m Nir & Langley Informational [Page 31]

RFC 7539 ChaCha20 & Poly1305 May 2015 A.2 . ChaCha20 Encryption 032 da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37 .AY|QWH.w$.?..J7 048 6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86 jC.........i..e. Test Vector #2: ============== Key: 000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................ Nonce: 000 00 00 00 00 00 00 00 00 00 00 00 02 ............ Initial Block Counter = 1 Plaintext: 000 41 6e 79 20 73 75 62 6d 69 73 73 69 6f 6e 20 74 Any submission t 016 6f 20 74 68 65 20 49 45 54 46 20 69 6e 74 65 6e o the IETF inten 032 64 65 64 20 62 79 20 74 68 65 20 43 6f 6e 74 72 ded by the Contr 048 69 62 75 74 6f 72 20 66 6f 72 20 70 75 62 6c 69 ibutor for publi 064 63 61 74 69 6f 6e 20 61 73 20 61 6c 6c 20 6f 72 cation as all or 080 20 70 61 72 74 20 6f 66 20 61 6e 20 49 45 54 46 part of an IETF 096 20 49 6e 74 65 72 6e 65 74 2d 44 72 61 66 74 20 Internet-Draft 112 6f 72 20 52 46 43 20 61 6e 64 20 61 6e 79 20 73 or RFC and any s 128 74 61 74 65 6d 65 6e 74 20 6d 61 64 65 20 77 69 tatement made wi Nir & Langley Informational [Page 32]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 33]

RFC 7539 ChaCha20 & Poly1305 May 2015 A.3 . Poly1305 Message Authentication Code Nir & Langley Informational [Page 34]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 35]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 36]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 37]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 38]

RFC 7539 ChaCha20 & Poly1305 May 2015 Nir & Langley Informational [Page 39]

RFC 7539 ChaCha20 & Poly1305 May 2015 A.4 . Poly1305 Key Generation Using ChaCha20 Nir & Langley Informational [Page 40]

RFC 7539 ChaCha20 & Poly1305 May 2015 v 016 06 cb 33 06 6c 44 7b 87 bc 26 66 dd e3 fb b7 39 ..3.lD{..&f....9 Test Vector #3: ============== The key: 000 1c 92 40 a5 eb 55 d3 8a f3 33 88 86 04 f6 b5 f0 ..@..U...3...... 016 47 39 17 c1 40 2b 80 09 9d ca 5c bc 20 70 75 c0 G9..@+....\. pu. The nonce: 000 00 00 00 00 00 00 00 00 00 00 00 02 ............ Poly1305 one-time key: 000 96 5e 3b c6 f9 ec 7e d9 56 08 08 f4 d2 29 f9 4b .^;...~.V....).K 016 13 7f f2 75 ca 9b 3f cb dd 59 de aa d2 33 10 ae ...u..?..Y...3.. A.5 . ChaCha20-Poly1305 AEAD Decryption Nir & Langley Informational [Page 41]

RFC 7539 ChaCha20 & Poly1305 May 2015 096 97 97 a0 6e f4 f0 ef 61 c1 86 32 4e 2b 35 06 38 ...n...a..2N+5.8 112 36 06 90 7b 6a 7c 02 b0 f9 f6 15 7b 53 c8 67 e4 6..{j|.....{S.g. 128 b9 16 6c 76 7b 80 4d 46 a5 9b 52 16 cd e7 a4 e9 ..lv{.MF..R..... 144 90 40 c5 a4 04 33 22 5e e2 82 a1 b0 a0 6c 52 3e .@...3"^.....lR> 160 af 45 34 d7 f8 3f a1 15 5b 00 47 71 8c bc 54 6a .E4..?..[.Gq..Tj 176 0d 07 2b 04 b3 56 4e ea 1b 42 22 73 f5 48 27 1a ..+..VN..B"s.H'. 192 0b b2 31 60 53 fa 76 99 19 55 eb d6 31 59 43 4e ..1`S.v..U..1YCN 208 ce bb 4e 46 6d ae 5a 10 73 a6 72 76 27 09 7a 10 ..NFm.Z.s.rv'.z. 224 49 e6 17 d9 1d 36 10 94 fa 68 f0 ff 77 98 71 30 I....6...h..w.q0 240 30 5b ea ba 2e da 04 df 99 7b 71 4d 6c 6f 2c 29 0[.......{qMlo,) 256 a6 ad 5c b4 02 2b 02 70 9b ..\..+.p. The nonce: 000 00 00 00 00 01 02 03 04 05 06 07 08 ............ The AAD: 000 f3 33 88 86 00 00 00 00 00 00 4e 91 .3........N. Received Tag: 000 ee ad 9d 67 89 0c bb 22 39 23 36 fe a1 85 1f 38 ...g..."9#6....8 Nir & Langley Informational [Page 42]

RFC 7539 ChaCha20 & Poly1305 May 2015 112 97 97 a0 6e f4 f0 ef 61 c1 86 32 4e 2b 35 06 38 ...n...a..2N+5.8 128 36 06 90 7b 6a 7c 02 b0 f9 f6 15 7b 53 c8 67 e4 6..{j|.....{S.g. 144 b9 16 6c 76 7b 80 4d 46 a5 9b 52 16 cd e7 a4 e9 ..lv{.MF..R..... 160 90 40 c5 a4 04 33 22 5e e2 82 a1 b0 a0 6c 52 3e .@...3"^.....lR> 176 af 45 34 d7 f8 3f a1 15 5b 00 47 71 8c bc 54 6a .E4..?..[.Gq..Tj 192 0d 07 2b 04 b3 56 4e ea 1b 42 22 73 f5 48 27 1a ..+..VN..B"s.H'. 208 0b b2 31 60 53 fa 76 99 19 55 eb d6 31 59 43 4e ..1`S.v..U..1YCN 224 ce bb 4e 46 6d ae 5a 10 73 a6 72 76 27 09 7a 10 ..NFm.Z.s.rv'.z. 240 49 e6 17 d9 1d 36 10 94 fa 68 f0 ff 77 98 71 30 I....6...h..w.q0 256 30 5b ea ba 2e da 04 df 99 7b 71 4d 6c 6f 2c 29 0[.......{qMlo,) 272 a6 ad 5c b4 02 2b 02 70 9b 00 00 00 00 00 00 00 ..\..+.p........ 288 0c 00 00 00 00 00 00 00 09 01 00 00 00 00 00 00 ................ Nir & Langley Informational [Page 43]

RFC 7539 ChaCha20 & Poly1305 May 2015 000 ee ad 9d 67 89 0c bb 22 39 23 36 fe a1 85 1f 38 ...g..."9#6....8 Finally, we decrypt the ciphertext Plaintext:: 000 49 6e 74 65 72 6e 65 74 2d 44 72 61 66 74 73 20 Internet-Drafts 016 61 72 65 20 64 72 61 66 74 20 64 6f 63 75 6d 65 are draft docume 032 6e 74 73 20 76 61 6c 69 64 20 66 6f 72 20 61 20 nts valid for a 048 6d 61 78 69 6d 75 6d 20 6f 66 20 73 69 78 20 6d maximum of six m 064 6f 6e 74 68 73 20 61 6e 64 20 6d 61 79 20 62 65 onths and may be 080 20 75 70 64 61 74 65 64 2c 20 72 65 70 6c 61 63 updated, replac 096 65 64 2c 20 6f 72 20 6f 62 73 6f 6c 65 74 65 64 ed, or obsoleted 112 20 62 79 20 6f 74 68 65 72 20 64 6f 63 75 6d 65 by other docume 128 6e 74 73 20 61 74 20 61 6e 79 20 74 69 6d 65 2e nts at any time. 144 20 49 74 20 69 73 20 69 6e 61 70 70 72 6f 70 72 It is inappropr 160 69 61 74 65 20 74 6f 20 75 73 65 20 49 6e 74 65 iate to use Inte 176 72 6e 65 74 2d 44 72 61 66 74 73 20 61 73 20 72 rnet-Drafts as r 192 65 66 65 72 65 6e 63 65 20 6d 61 74 65 72 69 61 eference materia 208 6c 20 6f 72 20 74 6f 20 63 69 74 65 20 74 68 65 l or to cite the 224 6d 20 6f 74 68 65 72 20 74 68 61 6e 20 61 73 20 m other than as 240 2f e2 80 9c 77 6f 72 6b 20 69 6e 20 70 72 6f 67 /...work in prog 256 72 65 73 73 2e 2f e2 80 9d ress./... Appendix B . Performance Measurements of ChaCha20 https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html>. +----------------------------+-------------+-------------------+ | Chip | AES-128-GCM | ChaCha20-Poly1305 | +----------------------------+-------------+-------------------+ | OMAP 4460 | 24.1 MB/s | 75.3 MB/s | | Snapdragon S4 Pro | 41.5 MB/s | 130.9 MB/s | | Sandy Bridge Xeon (AES-NI) | 900 MB/s | 500 MB/s | +----------------------------+-------------+-------------------+ Table 1: Speed Comparison Nir & Langley Informational [Page 44]

RFC 7539 ChaCha20 & Poly1305 May 2015 Procter]. Authors' Addresses Yoav Nir Check Point Software Technologies, Ltd. 5 Hasolelim St. Tel Aviv 6789735 Israel EMail: ynir.ietf@gmail.com Adam Langley Google, Inc. EMail: agl@google.com Nir & Langley Informational [Page 45]