From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc7539.txt | 2523 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2523 insertions(+)
 create mode 100644 doc/rfc/rfc7539.txt

(limited to 'doc/rfc/rfc7539.txt')

diff --git a/doc/rfc/rfc7539.txt b/doc/rfc/rfc7539.txt
new file mode 100644
index 0000000..46d0ffc
--- /dev/null
+++ b/doc/rfc/rfc7539.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+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
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................4
+   2. The Algorithms ..................................................4
+      2.1. The ChaCha Quarter Round ...................................4
+           2.1.1. Test Vector for the ChaCha Quarter Round ............5
+      2.2. A Quarter Round on the ChaCha State ........................5
+           2.2.1. Test Vector for the Quarter Round on the
+                  ChaCha State ........................................6
+      2.3. The ChaCha20 Block Function ................................6
+           2.3.1. The ChaCha20 Block Function in Pseudocode ...........8
+           2.3.2. Test Vector for the ChaCha20 Block Function .........9
+      2.4. The ChaCha20 Encryption Algorithm .........................10
+           2.4.1. The ChaCha20 Encryption Algorithm in Pseudocode ....11
+           2.4.2. Example and Test Vector for the ChaCha20 Cipher ....11
+      2.5. The Poly1305 Algorithm ....................................13
+           2.5.1. The Poly1305 Algorithms in Pseudocode ..............15
+           2.5.2. Poly1305 Example and Test Vector ...................15
+      2.6. Generating the Poly1305 Key Using ChaCha20 ................17
+           2.6.1. Poly1305 Key Generation in Pseudocode ..............18
+           2.6.2. Poly1305 Key Generation Test Vector ................18
+      2.7. A Pseudorandom Function for Crypto Suites based on
+           ChaCha/Poly1305 ...........................................18
+      2.8. AEAD Construction .........................................19
+           2.8.1. Pseudocode for the AEAD Construction ...............21
+           2.8.2. Example and Test Vector for
+                  AEAD_CHACHA20_POLY1305 .............................22
+   3. Implementation Advice ..........................................24
+   4. Security Considerations ........................................24
+   5. IANA Considerations ............................................26
+   6. References .....................................................26
+      6.1. Normative References ......................................26
+      6.2. Informative References ....................................26
+   Appendix A. Additional Test Vectors ...............................29
+     A.1. The ChaCha20 Block Functions ...............................29
+     A.2. ChaCha20 Encryption ........................................32
+     A.3. Poly1305 Message Authentication Code .......................34
+     A.4. Poly1305 Key Generation Using ChaCha20 .....................40
+     A.5. ChaCha20-Poly1305 AEAD Decryption ..........................41
+   Appendix B. Performance Measurements of ChaCha20 ..................44
+   Acknowledgements ..................................................45
+   Authors' Addresses ................................................45
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                     [Page 2]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+1.  Introduction
+
+   The Advanced Encryption Standard (AES -- [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
+
+
+   This document represents the consensus of the Crypto Forum Research
+   Group (CFRG).
+
+1.1.  Conventions Used in This Document
+
+   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 [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
+
+   The subsections below describe the algorithms used and the AEAD
+   construction.
+
+2.1.  The ChaCha Quarter Round
+
+   The basic operation of the ChaCha algorithm is the quarter round.  It
+   operates on four 32-bit unsigned integers, denoted a, b, c, and d.
+   The operation is as follows (in C-like notation):
+
+   1.  a += b; d ^= a; d <<<= 16;
+   2.  c += d; b ^= c; b <<<= 12;
+   3.  a += b; d ^= a; d <<<= 8;
+   4.  c += d; b ^= c; b <<<= 7;
+
+
+
+
+
+Nir & Langley                 Informational                     [Page 4]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   Where "+" denotes integer addition modulo 2^32, "^" denotes a bitwise
+   Exclusive OR (XOR), and "<<< n" denotes an n-bit left rotation
+   (towards the high bits).
+
+   For example, let's see the add, XOR, and roll operations from the
+   fourth line with sample numbers:
+
+   o  a = 0x11111111
+   o  b = 0x01020304
+   o  c = 0x77777777
+   o  d = 0x01234567
+   o  c = c + d = 0x77777777 + 0x01234567 = 0x789abcde
+   o  b = b ^ c = 0x01020304 ^ 0x789abcde = 0x7998bfda
+   o  b = b <<< 7 = 0x7998bfda <<< 7 = 0xcc5fed3c
+
+2.1.1.  Test Vector for the ChaCha Quarter Round
+
+   For a test vector, we will use the same numbers as in the example,
+   adding something random for c.
+
+   o  a = 0x11111111
+   o  b = 0x01020304
+   o  c = 0x9b8d6f43
+   o  d = 0x01234567
+
+   After running a Quarter Round on these four numbers, we get these:
+
+   o  a = 0xea2a92f4
+   o  b = 0xcb1cf8ce
+   o  c = 0x4581472e
+   o  d = 0x5881c4bb
+
+2.2.  A Quarter Round on the ChaCha State
+
+   The ChaCha state does not have four integer numbers: it has 16.  So
+   the quarter-round operation works on only four of them -- hence the
+   name.  Each quarter round operates on four predetermined numbers in
+   the ChaCha state.  We will denote by QUARTERROUND(x,y,z,w) a quarter-
+   round operation on the numbers at indices x, y, z, and w of the
+   ChaCha state when viewed as a vector.  For example, if we apply
+   QUARTERROUND(1,5,9,13) to a state, this means running the quarter-
+   round operation on the elements marked with an asterisk, while
+   leaving the others alone:
+
+      0  *a   2   3
+      4  *b   6   7
+      8  *c  10  11
+     12  *d  14  15
+
+
+
+Nir & Langley                 Informational                     [Page 5]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   Note that this run of quarter round is part of what is called a
+   "column round".
+
+2.2.1.  Test Vector for the Quarter Round on the ChaCha State
+
+   For a test vector, we will use a ChaCha state that was generated
+   randomly:
+
+   Sample ChaCha State
+
+       879531e0  c5ecf37d  516461b1  c9a62f8a
+       44c20ef3  3390af7f  d9fc690b  2a5f714c
+       53372767  b00a5631  974c541a  359e9963
+       5c971061  3d631689  2098d9d6  91dbd320
+
+   We will apply the QUARTERROUND(2,7,8,13) operation to this state.
+   For obvious reasons, this one is part of what is called a "diagonal
+   round":
+
+   After applying QUARTERROUND(2,7,8,13)
+
+       879531e0  c5ecf37d *bdb886dc  c9a62f8a
+       44c20ef3  3390af7f  d9fc690b *cfacafd2
+      *e46bea80  b00a5631  974c541a  359e9963
+       5c971061 *ccc07c79  2098d9d6  91dbd320
+
+   Note that only the numbers in positions 2, 7, 8, and 13 changed.
+
+2.3.  The ChaCha20 Block Function
+
+   The ChaCha block function transforms a ChaCha state by running
+   multiple quarter rounds.
+
+   The inputs to ChaCha20 are:
+
+   o  A 256-bit key, treated as a concatenation of eight 32-bit little-
+      endian integers.
+
+   o  A 96-bit nonce, treated as a concatenation of three 32-bit little-
+      endian integers.
+
+   o  A 32-bit block count parameter, treated as a 32-bit little-endian
+      integer.
+
+   The output is 64 random-looking bytes.
+
+
+
+
+
+
+Nir & Langley                 Informational                     [Page 6]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   The ChaCha algorithm described here uses a 256-bit key.  The original
+   algorithm also specified 128-bit keys and 8- and 12-round variants,
+   but these are out of scope for this document.  In this section, we
+   describe the ChaCha block function.
+
+   Note also that the original ChaCha had a 64-bit nonce and 64-bit
+   block count.  We have modified this here to be more consistent with
+   recommendations in 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
+
+
+   6.  QUARTERROUND ( 1, 6,11,12)
+   7.  QUARTERROUND ( 2, 7, 8,13)
+   8.  QUARTERROUND ( 3, 4, 9,14)
+
+   At the end of 20 rounds (or 10 iterations of the above list), we add
+   the original input words to the output words, and serialize the
+   result by sequencing the words one-by-one in little-endian order.
+
+   Note: "addition" in the above paragraph is done modulo 2^32.  In some
+   machine languages, this is called carryless addition on a 32-bit
+   word.
+
+2.3.1.  The ChaCha20 Block Function in Pseudocode
+
+   Note: This section and a few others contain pseudocode for the
+   algorithm explained in a previous section.  Every effort was made for
+   the pseudocode to accurately reflect the algorithm as described in
+   the preceding section.  If a conflict is still present, the textual
+   explanation and the test vectors are normative.
+
+      inner_block (state):
+         Qround(state, 0, 4, 8,12)
+         Qround(state, 1, 5, 9,13)
+         Qround(state, 2, 6,10,14)
+         Qround(state, 3, 7,11,15)
+         Qround(state, 0, 5,10,15)
+         Qround(state, 1, 6,11,12)
+         Qround(state, 2, 7, 8,13)
+         Qround(state, 3, 4, 9,14)
+         end
+
+      chacha20_block(key, counter, nonce):
+         state = constants | key | counter | nonce
+         working_state = state
+         for i=1 upto 10
+            inner_block(working_state)
+            end
+         state += working_state
+         return serialize(state)
+         end
+
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                     [Page 8]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+2.3.2.  Test Vector for the ChaCha20 Block Function
+
+   For a test vector, we will use the following inputs to the ChaCha20
+   block function:
+
+   o  Key = 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:10:11:12:13:
+      14:15:16:17:18:19:1a:1b:1c:1d:1e:1f.  The key is a sequence of
+      octets with no particular structure before we copy it into the
+      ChaCha state.
+
+   o  Nonce = (00:00:00:09:00:00:00:4a:00:00:00:00)
+
+   o  Block Count = 1.
+
+   After setting up the ChaCha state, it looks like this:
+
+   ChaCha state with the key setup.
+
+       61707865  3320646e  79622d32  6b206574
+       03020100  07060504  0b0a0908  0f0e0d0c
+       13121110  17161514  1b1a1918  1f1e1d1c
+       00000001  09000000  4a000000  00000000
+
+   After running 20 rounds (10 column rounds interleaved with 10
+   "diagonal rounds"), the ChaCha state looks like this:
+
+   ChaCha state after 20 rounds
+
+       837778ab  e238d763  a67ae21e  5950bb2f
+       c4f2d0c7  fc62bb2f  8fa018fc  3f5ec7b7
+       335271c2  f29489f3  eabda8fc  82e46ebd
+       d19c12b4  b04e16de  9e83d0cb  4e3c50a2
+
+   Finally, we add the original state to the result (simple vector or
+   matrix addition), giving this:
+
+   ChaCha state at the end of the ChaCha20 operation
+
+       e4e7f110  15593bd1  1fdd0f50  c47120a3
+       c7f4d1c7  0368c033  9aaa2204  4e6cd4c3
+       466482d2  09aa9f07  05d7c214  a2028bd9
+       d19c12b5  b94e16de  e883d0cb  4e3c50a2
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                     [Page 9]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   After we serialize the state, we get this:
+
+  Serialized Block:
+  000  10 f1 e7 e4 d1 3b 59 15 50 0f dd 1f a3 20 71 c4  .....;Y.P.... q.
+  016  c7 d1 f4 c7 33 c0 68 03 04 22 aa 9a c3 d4 6c 4e  ....3.h.."....lN
+  032  d2 82 64 46 07 9f aa 09 14 c2 d7 05 d9 8b 02 a2  ..dF............
+  048  b5 12 9c d1 de 16 4e b9 cb d0 83 e8 a2 50 3c 4e  ......N......P<N
+
+2.4.  The ChaCha20 Encryption Algorithm
+
+   ChaCha20 is a stream cipher designed by D. J. Bernstein.  It is a
+   refinement of the Salsa20 algorithm, and it uses a 256-bit key.
+
+   ChaCha20 successively calls the ChaCha20 block function, with the
+   same key and nonce, and with successively increasing block counter
+   parameters.  ChaCha20 then serializes the resulting state by writing
+   the numbers in little-endian order, creating a keystream block.
+
+   Concatenating the keystream blocks from the successive blocks forms a
+   keystream.  The ChaCha20 function then performs an XOR of this
+   keystream with the plaintext.  Alternatively, each keystream block
+   can be XORed with a plaintext block before proceeding to create the
+   next block, saving some memory.  There is no requirement for the
+   plaintext to be an integral multiple of 512 bits.  If there is extra
+   keystream from the last block, it is discarded.  Specific protocols
+   MAY require that the plaintext and ciphertext have certain length.
+   Such protocols need to specify how the plaintext is padded and how
+   much padding it receives.
+
+   The inputs to ChaCha20 are:
+
+   o  A 256-bit key
+
+   o  A 32-bit initial counter.  This can be set to any number, but will
+      usually be zero or one.  It makes sense to use one if we use the
+      zero block for something else, such as generating a one-time
+      authenticator key as part of an AEAD algorithm.
+
+   o  A 96-bit nonce.  In some protocols, this is known as the
+      Initialization Vector.
+
+   o  An arbitrary-length plaintext
+
+   The output is an encrypted message, or "ciphertext", of the same
+   length.
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 10]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   Decryption is done in the same way.  The ChaCha20 block function is
+   used to expand the key into a keystream, which is XORed with the
+   ciphertext giving back the plaintext.
+
+2.4.1.  The ChaCha20 Encryption Algorithm in Pseudocode
+
+     chacha20_encrypt(key, counter, nonce, plaintext):
+        for j = 0 upto floor(len(plaintext)/64)-1
+           key_stream = chacha20_block(key, counter+j, nonce)
+           block = plaintext[(j*64)..(j*64+63)]
+           encrypted_message +=  block ^ key_stream
+           end
+        if ((len(plaintext) % 64) != 0)
+           j = floor(len(plaintext)/64)
+           key_stream = chacha20_block(key, counter+j, nonce)
+           block = plaintext[(j*64)..len(plaintext)-1]
+           encrypted_message += (block^key_stream)[0..len(plaintext)%64]
+           end
+        return encrypted_message
+        end
+
+2.4.2.  Example and Test Vector for the ChaCha20 Cipher
+
+   For a test vector, we will use the following inputs to the ChaCha20
+   block function:
+
+   o  Key = 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:10:11:12:13:
+      14:15:16:17:18:19:1a:1b:1c:1d:1e:1f.
+
+   o  Nonce = (00:00:00:00:00:00:00:4a:00:00:00:00).
+
+   o  Initial Counter = 1.
+
+   We use the following for the plaintext.  It was chosen to be long
+   enough to require more than one block, but not so long that it would
+   make this example cumbersome (so, less than 3 blocks):
+
+  Plaintext Sunscreen:
+  000  4c 61 64 69 65 73 20 61 6e 64 20 47 65 6e 74 6c  Ladies and Gentl
+  016  65 6d 65 6e 20 6f 66 20 74 68 65 20 63 6c 61 73  emen of the clas
+  032  73 20 6f 66 20 27 39 39 3a 20 49 66 20 49 20 63  s of '99: If I c
+  048  6f 75 6c 64 20 6f 66 66 65 72 20 79 6f 75 20 6f  ould offer you o
+  064  6e 6c 79 20 6f 6e 65 20 74 69 70 20 66 6f 72 20  nly one tip for
+  080  74 68 65 20 66 75 74 75 72 65 2c 20 73 75 6e 73  the future, suns
+  096  63 72 65 65 6e 20 77 6f 75 6c 64 20 62 65 20 69  creen would be i
+  112  74 2e                                            t.
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 11]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   The following figure shows four ChaCha state matrices:
+
+   1.  First block as it is set up.
+
+   2.  Second block as it is set up.  Note that these blocks are only
+       two bits apart -- only the counter in position 12 is different.
+
+   3.  Third block is the first block after the ChaCha20 block
+       operation.
+
+   4.  Final block is the second block after the ChaCha20 block
+       operation was applied.
+
+   After that, we show the keystream.
+
+   First block setup:
+       61707865  3320646e  79622d32  6b206574
+       03020100  07060504  0b0a0908  0f0e0d0c
+       13121110  17161514  1b1a1918  1f1e1d1c
+       00000001  00000000  4a000000  00000000
+
+   Second block setup:
+       61707865  3320646e  79622d32  6b206574
+       03020100  07060504  0b0a0908  0f0e0d0c
+       13121110  17161514  1b1a1918  1f1e1d1c
+       00000002  00000000  4a000000  00000000
+
+   First block after block operation:
+       f3514f22  e1d91b40  6f27de2f  ed1d63b8
+       821f138c  e2062c3d  ecca4f7e  78cff39e
+       a30a3b8a  920a6072  cd7479b5  34932bed
+       40ba4c79  cd343ec6  4c2c21ea  b7417df0
+
+   Second block after block operation:
+       9f74a669  410f633f  28feca22  7ec44dec
+       6d34d426  738cb970  3ac5e9f3  45590cc4
+       da6e8b39  892c831a  cdea67c1  2b7e1d90
+       037463f3  a11a2073  e8bcfb88  edc49139
+
+   Keystream:
+   22:4f:51:f3:40:1b:d9:e1:2f:de:27:6f:b8:63:1d:ed:8c:13:1f:82:3d:2c:06
+   e2:7e:4f:ca:ec:9e:f3:cf:78:8a:3b:0a:a3:72:60:0a:92:b5:79:74:cd:ed:2b
+   93:34:79:4c:ba:40:c6:3e:34:cd:ea:21:2c:4c:f0:7d:41:b7:69:a6:74:9f:3f
+   63:0f:41:22:ca:fe:28:ec:4d:c4:7e:26:d4:34:6d:70:b9:8c:73:f3:e9:c5:3a
+   c4:0c:59:45:39:8b:6e:da:1a:83:2c:89:c1:67:ea:cd:90:1d:7e:2b:f3:63
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 12]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   Finally, we XOR the keystream with the plaintext, yielding the
+   ciphertext:
+
+  Ciphertext Sunscreen:
+  000  6e 2e 35 9a 25 68 f9 80 41 ba 07 28 dd 0d 69 81  n.5.%h..A..(..i.
+  016  e9 7e 7a ec 1d 43 60 c2 0a 27 af cc fd 9f ae 0b  .~z..C`..'......
+  032  f9 1b 65 c5 52 47 33 ab 8f 59 3d ab cd 62 b3 57  ..e.RG3..Y=..b.W
+  048  16 39 d6 24 e6 51 52 ab 8f 53 0c 35 9f 08 61 d8  .9.$.QR..S.5..a.
+  064  07 ca 0d bf 50 0d 6a 61 56 a3 8e 08 8a 22 b6 5e  ....P.jaV....".^
+  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 a one-time authenticator designed by D. J. Bernstein.
+   Poly1305 takes a 32-byte one-time key and a message and produces a
+   16-byte tag.  This tag is used to authenticate the message.
+
+   The original article ([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
+
+
+   The following sample code clamps "r" to be appropriate:
+
+   /*
+   Adapted from poly1305aes_test_clamp.c version 20050207
+   D. J. Bernstein
+   Public domain.
+   */
+
+   #include "poly1305aes_test.h"
+
+   void poly1305aes_test_clamp(unsigned char r[16])
+   {
+     r[3] &= 15;
+     r[7] &= 15;
+     r[11] &= 15;
+     r[15] &= 15;
+     r[4] &= 252;
+     r[8] &= 252;
+     r[12] &= 252;
+   }
+
+   The "s" should be unpredictable, but it is perfectly acceptable to
+   generate both "r" and "s" uniquely each time.  Because each of them
+   is 128 bits, pseudorandomly generating them (see 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
+
+
+   o  Add one bit beyond the number of octets.  For a 16-byte block,
+      this is equivalent to adding 2^128 to the number.  For the shorter
+      block, it can be 2^120, 2^112, or any power of two that is evenly
+      divisible by 8, all the way down to 2^8.
+
+   o  If the block is not 17 bytes long (the last block), pad it with
+      zeros.  This is meaningless if you are treating the blocks as
+      numbers.
+
+   o  Add this number to the accumulator.
+
+   o  Multiply by "r".
+
+   o  Set the accumulator to the result modulo p.  To summarize: Acc =
+      ((Acc+block)*r) % p.
+
+   Finally, the value of the secret key "s" is added to the accumulator,
+   and the 128 least significant bits are serialized in little-endian
+   order to form the tag.
+
+2.5.1.  The Poly1305 Algorithms in Pseudocode
+
+      clamp(r): r &= 0x0ffffffc0ffffffc0ffffffc0fffffff
+      poly1305_mac(msg, key):
+         r = (le_bytes_to_num(key[0..15])
+         clamp(r)
+         s = le_num(key[16..31])
+         accumulator = 0
+         p = (1<<130)-5
+         for i=1 upto ceil(msg length in bytes / 16)
+            n = le_bytes_to_num(msg[((i-1)*16)..(i*16)] | [0x01])
+            a += n
+            a = (r * a) % p
+            end
+         a += s
+         return num_to_16_le_bytes(a)
+         end
+
+2.5.2.  Poly1305 Example and Test Vector
+
+   For our example, we will dispense with generating the one-time key
+   using AES, and assume that we got the following keying material:
+
+   o  Key Material: 85:d6:be:78:57:55:6d:33:7f:44:52:fe:42:d5:06:a8:01:0
+      3:80:8a:fb:0d:b2:fd:4a:bf:f6:af:41:49:f5:1b
+
+   o  s as an octet string:
+      01:03:80:8a:fb:0d:b2:fd:4a:bf:f6:af:41:49:f5:1b
+
+
+
+Nir & Langley                 Informational                    [Page 15]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   o  s as a 128-bit number: 1bf54941aff6bf4afdb20dfb8a800301
+
+   o  r before clamping: 85:d6:be:78:57:55:6d:33:7f:44:52:fe:42:d5:06:a8
+
+   o  Clamped r as a number: 806d5400e52447c036d555408bed685
+
+   For our message, we'll use a short text:
+
+  Message to be Authenticated:
+  000  43 72 79 70 74 6f 67 72 61 70 68 69 63 20 46 6f  Cryptographic Fo
+  016  72 75 6d 20 52 65 73 65 61 72 63 68 20 47 72 6f  rum Research Gro
+  032  75 70                                            up
+
+   Since Poly1305 works in 16-byte chunks, the 34-byte message divides
+   into three blocks.  In the following calculation, "Acc" denotes the
+   accumulator and "Block" the current block:
+
+   Block #1
+
+   Acc = 00
+   Block = 6f4620636968706172676f7470797243
+   Block with 0x01 byte = 016f4620636968706172676f7470797243
+   Acc + block = 016f4620636968706172676f7470797243
+   (Acc+Block) * r =
+        b83fe991ca66800489155dcd69e8426ba2779453994ac90ed284034da565ecf
+   Acc = ((Acc+Block)*r) % P = 2c88c77849d64ae9147ddeb88e69c83fc
+
+   Block #2
+
+   Acc = 2c88c77849d64ae9147ddeb88e69c83fc
+   Block = 6f7247206863726165736552206d7572
+   Block with 0x01 byte = 016f7247206863726165736552206d7572
+   Acc + block = 437febea505c820f2ad5150db0709f96e
+   (Acc+Block) * r =
+        21dcc992d0c659ba4036f65bb7f88562ae59b32c2b3b8f7efc8b00f78e548a26
+   Acc = ((Acc+Block)*r) % P = 2d8adaf23b0337fa7cccfb4ea344b30de
+
+   Last Block
+
+   Acc = 2d8adaf23b0337fa7cccfb4ea344b30de
+   Block = 7075
+   Block with 0x01 byte = 017075
+   Acc + block = 2d8adaf23b0337fa7cccfb4ea344ca153
+   (Acc + Block) * r =
+        16d8e08a0f3fe1de4fe4a15486aca7a270a29f1e6c849221e4a6798b8e45321f
+   ((Acc + Block) * r) % P = 28d31b7caff946c77c8844335369d03a7
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 16]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   Adding s, we get this number, and serialize if to get the tag:
+
+   Acc + s = 2a927010caf8b2bc2c6365130c11d06a8
+
+   Tag: a8:06:1d:c1:30:51:36:c6:c2:2b:8b:af:0c:01:27:a9
+
+2.6.  Generating the Poly1305 Key Using ChaCha20
+
+   As said in 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
+
+
+   Note that while many protocols have provisions for a nonce for
+   encryption algorithms (often called Initialization Vectors, or IVs),
+   they usually don't have such a provision for the MAC function.  In
+   that case, the per-invocation nonce will have to come from somewhere
+   else, such as a message counter.
+
+2.6.1.  Poly1305 Key Generation in Pseudocode
+
+      poly1305_key_gen(key,nonce):
+         counter = 0
+         block = chacha20_block(key,counter,nonce)
+         return block[0..31]
+         end
+
+2.6.2.  Poly1305 Key Generation Test Vector
+
+   For this example, we'll set:
+
+  Key:
+  000  80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f  ................
+  016  90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f  ................
+
+   Nonce:
+   000  00 00 00 00 00 01 02 03 04 05 06 07              ............
+
+   The ChaCha state setup with key, nonce, and block counter zero:
+         61707865  3320646e  79622d32  6b206574
+         83828180  87868584  8b8a8988  8f8e8d8c
+         93929190  97969594  9b9a9998  9f9e9d9c
+         00000000  00000000  03020100  07060504
+
+   The ChaCha state after 20 rounds:
+         8ba0d58a  cc815f90  27405081  7194b24a
+         37b633a8  a50dfde3  e2b8db08  46a6d1fd
+         7da03782  9183a233  148ad271  b46773d1
+         3cc1875a  8607def1  ca5c3086  7085eb87
+
+  Output bytes:
+  000  8a d5 a0 8b 90 5f 81 cc 81 50 40 27 4a b2 94 71  ....._...P@'J..q
+  016  a8 33 b6 37 e3 fd 0d a5 08 db b8 e2 fd d1 a6 46  .3.7...........F
+
+   And that output is also the 32-byte one-time key used for Poly1305.
+
+2.7.  A Pseudorandom Function for Crypto Suites based on ChaCha/Poly1305
+
+   Some protocols, such as IKEv2 ([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
+
+
+   variable-length input, and returns a fixed-length output.  Most
+   commonly, Hashed MAC (HMAC) constructions are used for this purpose,
+   and often the same function is used for both message authentication
+   and PRF.
+
+   Poly1305 is not a suitable choice for a PRF.  Poly1305 prohibits
+   using the same key twice, whereas the PRF in IKEv2 is used multiple
+   times with the same key.  Additionally, unlike HMAC, Poly1305 is
+   biased, so using it for key derivation would reduce the security of
+   the symmetric encryption.
+
+   Chacha20 could be used as a key-derivation function, by generating an
+   arbitrarily long keystream.  However, that is not what protocols such
+   as IKEv2 require.
+
+   For this reason, this document does not specify a PRF and recommends
+   that crypto suites use some other PRF such as PRF_HMAC_SHA2_256 (see
+   Section 2.1.2 of [RFC4868]).
+
+2.8.  AEAD Construction
+
+   AEAD_CHACHA20_POLY1305 is an authenticated encryption with additional
+   data algorithm.  The inputs to AEAD_CHACHA20_POLY1305 are:
+
+   o  A 256-bit key
+
+   o  A 96-bit nonce -- different for each invocation with the same key
+
+   o  An arbitrary length plaintext
+
+   o  Arbitrary length additional authenticated data (AAD)
+
+   Some protocols may have unique per-invocation inputs that are not 96
+   bits in length.  For example, IPsec may specify a 64-bit nonce.  In
+   such a case, it is up to the protocol document to define how to
+   transform the protocol nonce into a 96-bit nonce, for example, by
+   concatenating a constant value.
+
+   The ChaCha20 and Poly1305 primitives are combined into an AEAD that
+   takes a 256-bit key and 96-bit nonce as follows:
+
+   o  First, a Poly1305 one-time key is generated from the 256-bit key
+      and nonce using the procedure described in Section 2.6.
+
+   o  Next, the ChaCha20 encryption function is called to encrypt the
+      plaintext, using the same key and nonce, and with the initial
+      counter set to 1.
+
+
+
+
+Nir & Langley                 Informational                    [Page 19]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   o  Finally, the Poly1305 function is called with the Poly1305 key
+      calculated above, and a message constructed as a concatenation of
+      the following:
+
+      *  The AAD
+
+      *  padding1 -- the padding is up to 15 zero bytes, and it brings
+         the total length so far to an integral multiple of 16.  If the
+         length of the AAD was already an integral multiple of 16 bytes,
+         this field is zero-length.
+
+      *  The ciphertext
+
+      *  padding2 -- the padding is up to 15 zero bytes, and it brings
+         the total length so far to an integral multiple of 16.  If the
+         length of the ciphertext was already an integral multiple of 16
+         bytes, this field is zero-length.
+
+      *  The length of the additional data in octets (as a 64-bit
+         little-endian integer).
+
+      *  The length of the ciphertext in octets (as a 64-bit little-
+         endian integer).
+
+   The output from the AEAD is twofold:
+
+   o  A ciphertext of the same length as the plaintext.
+
+   o  A 128-bit tag, which is the output of the Poly1305 function.
+
+   Decryption is similar with the following differences:
+
+   o  The roles of ciphertext and plaintext are reversed, so the
+      ChaCha20 encryption function is applied to the ciphertext,
+      producing the plaintext.
+
+   o  The Poly1305 function is still run on the AAD and the ciphertext,
+      not the plaintext.
+
+   o  The calculated tag is bitwise compared to the received tag.  The
+      message is authenticated if and only if the tags match.
+
+   A few notes about this design:
+
+   1.  The amount of encrypted data possible in a single invocation is
+       2^32-1 blocks of 64 bytes each, because of the size of the block
+       counter field in the ChaCha20 block function.  This gives a total
+       of 247,877,906,880 bytes, or nearly 256 GB.  This should be
+
+
+
+Nir & Langley                 Informational                    [Page 20]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+       enough for traffic protocols such as IPsec and TLS, but may be
+       too small for file and/or disk encryption.  For such uses, we can
+       return to the original design, reduce the nonce to 64 bits, and
+       use the integer at position 13 as the top 32 bits of a 64-bit
+       block counter, increasing the total message size to over a
+       million petabytes (1,180,591,620,717,411,303,360 bytes to be
+       exact).
+
+   2.  Despite the previous item, the ciphertext length field in the
+       construction of the buffer on which Poly1305 runs limits the
+       ciphertext (and hence, the plaintext) size to 2^64 bytes, or
+       sixteen thousand petabytes (18,446,744,073,709,551,616 bytes to
+       be exact).
+
+   The AEAD construction in this section is a novel composition of
+   ChaCha20 and Poly1305.  A security analysis of this composition is
+   given in [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
+
+      pad16(x):
+         if (len(x) % 16)==0
+            then return NULL
+            else return copies(0, 16-(len(x)%16))
+         end
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 21]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+      chacha20_aead_encrypt(aad, key, iv, constant, plaintext):
+         nonce = constant | iv
+         otk = poly1305_key_gen(key, nonce)
+         ciphertext = chacha20_encrypt(key, 1, nonce, plaintext)
+         mac_data = aad | pad16(aad)
+         mac_data |= ciphertext | pad16(ciphertext)
+         mac_data |= num_to_4_le_bytes(aad.length)
+         mac_data |= num_to_4_le_bytes(ciphertext.length)
+         tag = poly1305_mac(mac_data, otk)
+         return (ciphertext, tag)
+
+2.8.2.  Example and Test Vector for AEAD_CHACHA20_POLY1305
+
+   For a test vector, we will use the following inputs to the
+   AEAD_CHACHA20_POLY1305 function:
+
+  Plaintext:
+  000  4c 61 64 69 65 73 20 61 6e 64 20 47 65 6e 74 6c  Ladies and Gentl
+  016  65 6d 65 6e 20 6f 66 20 74 68 65 20 63 6c 61 73  emen of the clas
+  032  73 20 6f 66 20 27 39 39 3a 20 49 66 20 49 20 63  s of '99: If I c
+  048  6f 75 6c 64 20 6f 66 66 65 72 20 79 6f 75 20 6f  ould offer you o
+  064  6e 6c 79 20 6f 6e 65 20 74 69 70 20 66 6f 72 20  nly one tip for
+  080  74 68 65 20 66 75 74 75 72 65 2c 20 73 75 6e 73  the future, suns
+  096  63 72 65 65 6e 20 77 6f 75 6c 64 20 62 65 20 69  creen would be i
+  112  74 2e                                            t.
+
+   AAD:
+   000  50 51 52 53 c0 c1 c2 c3 c4 c5 c6 c7              PQRS........
+
+  Key:
+  000  80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f  ................
+  016  90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f  ................
+
+   IV:
+   000  40 41 42 43 44 45 46 47                          @ABCDEFG
+
+   32-bit fixed-common part:
+   000  07 00 00 00                                      ....
+
+   Setup for generating Poly1305 one-time key (sender id=7):
+       61707865  3320646e  79622d32  6b206574
+       83828180  87868584  8b8a8988  8f8e8d8c
+       93929190  97969594  9b9a9998  9f9e9d9c
+       00000000  00000007  43424140  47464544
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 22]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   After generating Poly1305 one-time key:
+       252bac7b  af47b42d  557ab609  8455e9a4
+       73d6e10a  ebd97510  7875932a  ff53d53e
+       decc7ea2  b44ddbad  e49c17d1  d8430bc9
+       8c94b7bc  8b7d4b4b  3927f67d  1669a432
+
+  Poly1305 Key:
+  000  7b ac 2b 25 2d b4 47 af 09 b6 7a 55 a4 e9 55 84  {.+%-.G...zU..U.
+  016  0a e1 d6 73 10 75 d9 eb 2a 93 75 78 3e d5 53 ff  ...s.u..*.ux>.S.
+
+  Poly1305 r =  455e9a4057ab6080f47b42c052bac7b
+  Poly1305 s = ff53d53e7875932aebd9751073d6e10a
+
+   keystream bytes:
+   9f:7b:e9:5d:01:fd:40:ba:15:e2:8f:fb:36:81:0a:ae:
+   c1:c0:88:3f:09:01:6e:de:dd:8a:d0:87:55:82:03:a5:
+   4e:9e:cb:38:ac:8e:5e:2b:b8:da:b2:0f:fa:db:52:e8:
+   75:04:b2:6e:be:69:6d:4f:60:a4:85:cf:11:b8:1b:59:
+   fc:b1:c4:5f:42:19:ee:ac:ec:6a:de:c3:4e:66:69:78:
+   8e:db:41:c4:9c:a3:01:e1:27:e0:ac:ab:3b:44:b9:cf:
+   5c:86:bb:95:e0:6b:0d:f2:90:1a:b6:45:e4:ab:e6:22:
+   15:38
+
+  Ciphertext:
+  000  d3 1a 8d 34 64 8e 60 db 7b 86 af bc 53 ef 7e c2  ...4d.`.{...S.~.
+  016  a4 ad ed 51 29 6e 08 fe a9 e2 b5 a7 36 ee 62 d6  ...Q)n......6.b.
+  032  3d be a4 5e 8c a9 67 12 82 fa fb 69 da 92 72 8b  =..^..g....i..r.
+  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
+
+
+   Tag:
+   1a:e1:0b:59:4f:09:e2:6a:7e:90:2e:cb:d0:60:06:91
+
+3.  Implementation Advice
+
+   Each block of ChaCha20 involves 16 move operations and one increment
+   operation for loading the state, 80 each of XOR, addition and Roll
+   operations for the rounds, 16 more add operations and 16 XOR
+   operations for protecting the plaintext.  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
+
+   The ChaCha20 cipher is designed to provide 256-bit security.
+
+   The Poly1305 authenticator is designed to ensure that forged messages
+   are rejected with a probability of 1-(n/(2^102)) for a 16n-byte
+   message, even after sending 2^64 legitimate messages, so it is
+   SUF-CMA (strong unforgeability against chosen-message attacks) in the
+   terminology of [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
+
+
+   encrypting a counter using a 64-bit cipher such as DES.  Note that it
+   is not acceptable to use a truncation of a counter encrypted with a
+   128-bit or 256-bit cipher, because such a truncation may repeat after
+   a short time.
+
+   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.
+
+   The Poly1305 key MUST be unpredictable to an attacker.  Randomly
+   generating the key would fulfill this requirement, except that
+   Poly1305 is often used in communications protocols, so the receiver
+   should know the key.  Pseudorandom number generation such as by
+   encrypting a counter is acceptable.  Using ChaCha with a secret key
+   and a nonce is also acceptable.
+
+   The algorithms presented here were designed to be easy to implement
+   in constant time to avoid side-channel vulnerabilities.  The
+   operations used in ChaCha20 are all additions, XORs, and fixed
+   rotations.  All of these can and should be implemented in constant
+   time.  Access to offsets into the ChaCha state and the number of
+   operations do not depend on any property of the key, eliminating the
+   chance of information about the key leaking through the timing of
+   cache misses.
+
+   For Poly1305, the operations are addition, multiplication. and
+   modulus, all on numbers with greater than 128 bits.  This can be done
+   in constant time, but a naive implementation (such as using some
+   generic big number library) will not be constant time.  For example,
+   if the multiplication is performed as a separate operation from the
+   modulus, the result will sometimes be under 2^256 and sometimes be
+   above 2^256.  Implementers should be careful about timing side-
+   channels for Poly1305 by using the appropriate implementation of
+   these operations.
+
+   Validating the authenticity of a message involves a bitwise
+   comparison of the calculated tag with the received tag.  In most use
+   cases, nonces and AAD contents are not "used up" until a valid
+   message is received.  This allows an attacker to send multiple
+   identical messages with different tags until one passes the tag
+   comparison.  This is hard if the attacker has to try all 2^128
+   possible tags one by one.  However, if the timing of the tag
+   comparison operation reveals how long a prefix of the calculated and
+   received tags is identical, the number of messages can be reduced
+   significantly.  For this reason, with online protocols,
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 25]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   implementation MUST use a constant-time comparison function rather
+   than relying on optimized but insecure library functions such as the
+   C language's memcmp().
+
+5.  IANA Considerations
+
+   IANA has assigned an entry in the "Authenticated Encryption with
+   Associated Data (AEAD) Parameters" registry with 29 as the Numeric
+   ID, "AEAD_CHACHA20_POLY1305" as the name, and this document as
+   reference.
+
+6.  References
+
+6.1.  Normative References
+
+   [ChaCha]   Bernstein, D., "ChaCha, a variant of Salsa20", January
+              2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>.
+
+   [Poly1305] Bernstein, D., "The Poly1305-AES message-authentication
+              code", March 2005,
+              <http://cr.yp.to/mac/poly1305-20050329.pdf>.
+
+   [RFC2119]  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>.
+
+6.2.  Informative References
+
+   [AE]       Bellare, M. and C. Namprempre, "Authenticated Encryption:
+              Relations among notions and analysis of the generic
+              composition paradigm", September 2008,
+              <http://dl.acm.org/citation.cfm?id=1410269>.
+
+   [Cache-Collisions]
+              Bonneau, J. and I. Mironov, "Cache-Collision Timing
+              Attacks Against AES", 2006,
+              <http://research.microsoft.com/pubs/64024/aes-timing.pdf>.
+
+   [FIPS-197] National Institute of Standards and Technology, "Advanced
+              Encryption Standard (AES)", FIPS PUB 197, November 2001,
+              <http://csrc.nist.gov/publications/fips/fips197/
+              fips-197.pdf>.
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 26]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   [LatinDances]
+              Aumasson, J., Fischer, S., Khazaei, S., Meier, W., and C.
+              Rechberger, "New Features of Latin Dances: Analysis of
+              Salsa, ChaCha, and Rumba", December 2007,
+              <http://cr.yp.to/rumba20/newfeatures-20071218.pdf>.
+
+   [LatinDances2]
+              Ishiguro, T., Kiyomoto, S., and Y. Miyake, "Modified
+              version of 'Latin Dances Revisited: New Analytic Results
+              of Salsa20 and ChaCha'", February 2012,
+              <https://eprint.iacr.org/2012/065.pdf>.
+
+   [NaCl]     Bernstein, D., Lange, T., and P. Schwabe, "NaCl:
+              Networking and Cryptography library", July 2012,
+              <http://nacl.cr.yp.to>.
+
+   [Poly1305_Donna]
+              Floodyberry, A., "poly1305-donna", February 2014,
+              <https://github.com/floodyberry/poly1305-donna>.
+
+   [Procter]  Procter, G., "A Security Analysis of the Composition of
+              ChaCha20 and Poly1305", August 2014,
+              <http://eprint.iacr.org/2014/613.pdf>.
+
+   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
+              384, and HMAC-SHA-512 with IPsec", RFC 4868,
+              DOI 10.17487/RFC4868, May 2007,
+              <http://www.rfc-editor.org/info/rfc4868>.
+
+   [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>.
+
+   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+              Kivinen, "Internet Key Exchange Protocol Version 2
+              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+              2014, <http://www.rfc-editor.org/info/rfc7296>.
+
+   [SP800-67] National Institute of Standards and Technology,
+              "Recommendation for the Triple Data Encryption Algorithm
+              (TDEA) Block Cipher", NIST 800-67, January 2012,
+              <http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/
+              SP-800-67-Rev1.pdf>.
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 27]
+
+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
+
+   The subsections of this appendix contain more test vectors for the
+   algorithms in the sub-sections of Section 2.
+
+A.1.  The ChaCha20 Block Functions
+
+  Test Vector #1:
+  ==============
+
+  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 00              ............
+
+  Block Counter = 0
+
+    ChaCha state at the end
+        ade0b876  903df1a0  e56a5d40  28bd8653
+        b819d2bd  1aed8da0  ccef36a8  c70d778b
+        7c5941da  8d485751  3fe02477  374ad8b8
+        f4b8436a  1ca11815  69b687c3  8665eeb2
+
+  Keystream:
+  000  76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28  v.....=.@]j.S..(
+  016  bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7  .........6...w..
+  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
+
+
+  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 00  ................
+
+  Nonce:
+  000  00 00 00 00 00 00 00 00 00 00 00 00              ............
+
+  Block Counter = 1
+
+    ChaCha state at the end
+        bee7079f  7a385155  7c97ba98  0d082d73
+        a0290fcb  6965e348  3e53c612  ed7aee32
+        7621b729  434ee69c  b03371d5  d539d874
+        281fed31  45fb0a51  1f0ae1ac  6f4d794b
+
+  Keystream:
+  000  9f 07 e7 be 55 51 38 7a 98 ba 97 7c 73 2d 08 0d  ....UQ8z...|s-..
+  016  cb 0f 29 a0 48 e3 65 69 12 c6 53 3e 32 ee 7a ed  ..).H.ei..S>2.z.
+  032  29 b7 21 76 9c e6 4e 43 d5 71 33 b0 74 d8 39 d5  ).!v..NC.q3.t.9.
+  048  31 ed 1f 28 51 0a fb 45 ac e1 0a 1f 4b 79 4d 6f  1..(Q..E....KyMo
+
+  Test Vector #3:
+  ==============
+
+  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 00              ............
+
+  Block Counter = 1
+
+    ChaCha state at the end
+        2452eb3a  9249f8ec  8d829d9b  ddd4ceb1
+        e8252083  60818b01  f38422b8  5aaa49c9
+        bb00ca8e  da3ba7b4  c4b592d1  fdf2732f
+        4436274e  2561b3c8  ebdd4aa6  a0136c00
+
+  Keystream:
+  000  3a eb 52 24 ec f8 49 92 9b 9d 82 8d b1 ce d4 dd  :.R$..I.........
+  016  83 20 25 e8 01 8b 81 60 b8 22 84 f3 c9 49 aa 5a  . %....`."...I.Z
+  032  8e ca 00 bb b4 a7 3b da d1 92 b5 c4 2f 73 f2 fd  ......;...../s..
+  048  4e 27 36 44 c8 b3 61 25 a6 4a dd eb 00 6c 13 a0  N'6D..a%.J...l..
+
+
+
+
+Nir & Langley                 Informational                    [Page 30]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  Test Vector #4:
+  ==============
+
+  Key:
+  000  00 ff 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 00              ............
+
+  Block Counter = 2
+
+    ChaCha state at the end
+        fb4dd572  4bc42ef1  df922636  327f1394
+        a78dea8f  5e269039  a1bebbc1  caf09aae
+        a25ab213  48a6b46c  1b9d9bcb  092c5be6
+        546ca624  1bec45d5  87f47473  96f0992e
+
+  Keystream:
+  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
+
+  Test Vector #1:
+  ==============
+
+  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 00              ............
+
+  Initial Block Counter = 0
+
+  Plaintext:
+  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  ................
+  032  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+  048  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+
+  Ciphertext:
+  000  76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28  v.....=.@]j.S..(
+  016  bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7  .........6...w..
+  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
+
+
+  144  74 68 69 6e 20 74 68 65 20 63 6f 6e 74 65 78 74  thin the context
+  160  20 6f 66 20 61 6e 20 49 45 54 46 20 61 63 74 69   of an IETF acti
+  176  76 69 74 79 20 69 73 20 63 6f 6e 73 69 64 65 72  vity is consider
+  192  65 64 20 61 6e 20 22 49 45 54 46 20 43 6f 6e 74  ed an "IETF Cont
+  208  72 69 62 75 74 69 6f 6e 22 2e 20 53 75 63 68 20  ribution". Such
+  224  73 74 61 74 65 6d 65 6e 74 73 20 69 6e 63 6c 75  statements inclu
+  240  64 65 20 6f 72 61 6c 20 73 74 61 74 65 6d 65 6e  de oral statemen
+  256  74 73 20 69 6e 20 49 45 54 46 20 73 65 73 73 69  ts in IETF sessi
+  272  6f 6e 73 2c 20 61 73 20 77 65 6c 6c 20 61 73 20  ons, as well as
+  288  77 72 69 74 74 65 6e 20 61 6e 64 20 65 6c 65 63  written and elec
+  304  74 72 6f 6e 69 63 20 63 6f 6d 6d 75 6e 69 63 61  tronic communica
+  320  74 69 6f 6e 73 20 6d 61 64 65 20 61 74 20 61 6e  tions made at an
+  336  79 20 74 69 6d 65 20 6f 72 20 70 6c 61 63 65 2c  y time or place,
+  352  20 77 68 69 63 68 20 61 72 65 20 61 64 64 72 65   which are addre
+  368  73 73 65 64 20 74 6f                             ssed to
+
+  Ciphertext:
+  000  a3 fb f0 7d f3 fa 2f de 4f 37 6c a2 3e 82 73 70  ...}../.O7l.>.sp
+  016  41 60 5d 9f 4f 4f 57 bd 8c ff 2c 1d 4b 79 55 ec  A`].OOW...,.KyU.
+  032  2a 97 94 8b d3 72 29 15 c8 f3 d3 37 f7 d3 70 05  *....r)....7..p.
+  048  0e 9e 96 d6 47 b7 c3 9f 56 e0 31 ca 5e b6 25 0d  ....G...V.1.^.%.
+  064  40 42 e0 27 85 ec ec fa 4b 4b b5 e8 ea d0 44 0e  @B.'....KK....D.
+  080  20 b6 e8 db 09 d8 81 a7 c6 13 2f 42 0e 52 79 50   ........./B.RyP
+  096  42 bd fa 77 73 d8 a9 05 14 47 b3 29 1c e1 41 1c  B..ws....G.)..A.
+  112  68 04 65 55 2a a6 c4 05 b7 76 4d 5e 87 be a8 5a  h.eU*....vM^...Z
+  128  d0 0f 84 49 ed 8f 72 d0 d6 62 ab 05 26 91 ca 66  ...I..r..b..&..f
+  144  42 4b c8 6d 2d f8 0e a4 1f 43 ab f9 37 d3 25 9d  BK.m-....C..7.%.
+  160  c4 b2 d0 df b4 8a 6c 91 39 dd d7 f7 69 66 e9 28  ......l.9...if.(
+  176  e6 35 55 3b a7 6c 5c 87 9d 7b 35 d4 9e b2 e6 2b  .5U;.l\..{5....+
+  192  08 71 cd ac 63 89 39 e2 5e 8a 1e 0e f9 d5 28 0f  .q..c.9.^.....(.
+  208  a8 ca 32 8b 35 1c 3c 76 59 89 cb cf 3d aa 8b 6c  ..2.5.<vY...=..l
+  224  cc 3a af 9f 39 79 c9 2b 37 20 fc 88 dc 95 ed 84  .:..9y.+7 ......
+  240  a1 be 05 9c 64 99 b9 fd a2 36 e7 e8 18 b0 4b 0b  ....d....6....K.
+  256  c3 9c 1e 87 6b 19 3b fe 55 69 75 3f 88 12 8c c0  ....k.;.Uiu?....
+  272  8a aa 9b 63 d1 a1 6f 80 ef 25 54 d7 18 9c 41 1f  ...c..o..%T...A.
+  288  58 69 ca 52 c5 b8 3f a3 6f f2 16 b9 c1 d3 00 62  Xi.R..?.o......b
+  304  be bc fd 2d c5 bc e0 91 19 34 fd a7 9a 86 f6 e6  ...-.....4......
+  320  98 ce d7 59 c3 ff 9b 64 77 33 8f 3d a4 f9 cd 85  ...Y...dw3.=....
+  336  14 ea 99 82 cc af b3 41 b2 38 4d d9 02 f3 d1 ab  .......A.8M.....
+  352  7a c6 1d d2 9c 6f 21 ba 5b 86 2f 37 30 e3 7c fd  z....o!.[./70.|.
+  368  c4 fd 80 6c 22 f2 21                             ...l".!
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 33]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  Test Vector #3:
+  ==============
+
+  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.
+
+  Nonce:
+  000  00 00 00 00 00 00 00 00 00 00 00 02              ............
+
+  Initial Block Counter = 42
+
+  Plaintext:
+  000  27 54 77 61 73 20 62 72 69 6c 6c 69 67 2c 20 61  'Twas brillig, a
+  016  6e 64 20 74 68 65 20 73 6c 69 74 68 79 20 74 6f  nd the slithy to
+  032  76 65 73 0a 44 69 64 20 67 79 72 65 20 61 6e 64  ves.Did gyre and
+  048  20 67 69 6d 62 6c 65 20 69 6e 20 74 68 65 20 77   gimble in the w
+  064  61 62 65 3a 0a 41 6c 6c 20 6d 69 6d 73 79 20 77  abe:.All mimsy w
+  080  65 72 65 20 74 68 65 20 62 6f 72 6f 67 6f 76 65  ere the borogove
+  096  73 2c 0a 41 6e 64 20 74 68 65 20 6d 6f 6d 65 20  s,.And the mome
+  112  72 61 74 68 73 20 6f 75 74 67 72 61 62 65 2e     raths outgrabe.
+
+  Ciphertext:
+  000  62 e6 34 7f 95 ed 87 a4 5f fa e7 42 6f 27 a1 df  b.4....._..Bo'..
+  016  5f b6 91 10 04 4c 0d 73 11 8e ff a9 5b 01 e5 cf  _....L.s....[...
+  032  16 6d 3d f2 d7 21 ca f9 b2 1e 5f b1 4c 61 68 71  .m=..!...._.Lahq
+  048  fd 84 c5 4f 9d 65 b2 83 19 6c 7f e4 f6 05 53 eb  ...O.e...l....S.
+  064  f3 9c 64 02 c4 22 34 e3 2a 35 6b 3e 76 43 12 a6  ..d.."4.*5k>vC..
+  080  1a 55 32 05 57 16 ea d6 96 25 68 f8 7d 3f 3f 77  .U2.W....%h.}??w
+  096  04 c6 a8 d1 bc d1 bf 4d 50 d6 15 4b 6d a7 31 b1  .......MP..Km.1.
+  112  87 b5 8d fd 72 8a fa 36 75 7a 79 7a c1 88 d1     ....r..6uzyz...
+
+A.3.  Poly1305 Message Authentication Code
+
+   Notice how, in test vector #2, r is equal to zero.  The part of the
+   Poly1305 algorithm where the accumulator is multiplied by r means
+   that with r equal zero, the tag will be equal to s regardless of the
+   content of the text.  Fortunately, all the proposed methods of
+   generating r are such that getting this particular weak key is very
+   unlikely.
+
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 34]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  Test Vector #1:
+  ==============
+
+  One-time Poly1305 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  ................
+
+  Text to MAC:
+  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  ................
+  032  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+  048  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+
+  Tag:
+  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 35]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  Test Vector #2:
+  ==============
+
+  One-time Poly1305 Key:
+  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+  016  36 e5 f6 b5 c5 e0 60 70 f0 ef ca 96 22 7a 86 3e  6.....`p...."z.>
+
+  Text to MAC:
+  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
+  144  74 68 69 6e 20 74 68 65 20 63 6f 6e 74 65 78 74  thin the context
+  160  20 6f 66 20 61 6e 20 49 45 54 46 20 61 63 74 69   of an IETF acti
+  176  76 69 74 79 20 69 73 20 63 6f 6e 73 69 64 65 72  vity is consider
+  192  65 64 20 61 6e 20 22 49 45 54 46 20 43 6f 6e 74  ed an "IETF Cont
+  208  72 69 62 75 74 69 6f 6e 22 2e 20 53 75 63 68 20  ribution". Such
+  224  73 74 61 74 65 6d 65 6e 74 73 20 69 6e 63 6c 75  statements inclu
+  240  64 65 20 6f 72 61 6c 20 73 74 61 74 65 6d 65 6e  de oral statemen
+  256  74 73 20 69 6e 20 49 45 54 46 20 73 65 73 73 69  ts in IETF sessi
+  272  6f 6e 73 2c 20 61 73 20 77 65 6c 6c 20 61 73 20  ons, as well as
+  288  77 72 69 74 74 65 6e 20 61 6e 64 20 65 6c 65 63  written and elec
+  304  74 72 6f 6e 69 63 20 63 6f 6d 6d 75 6e 69 63 61  tronic communica
+  320  74 69 6f 6e 73 20 6d 61 64 65 20 61 74 20 61 6e  tions made at an
+  336  79 20 74 69 6d 65 20 6f 72 20 70 6c 61 63 65 2c  y time or place,
+  352  20 77 68 69 63 68 20 61 72 65 20 61 64 64 72 65   which are addre
+  368  73 73 65 64 20 74 6f                             ssed to
+
+  Tag:
+  000  36 e5 f6 b5 c5 e0 60 70 f0 ef ca 96 22 7a 86 3e  6.....`p...."z.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 36]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  Test Vector #3:
+  ==============
+
+  One-time Poly1305 Key:
+  000  36 e5 f6 b5 c5 e0 60 70 f0 ef ca 96 22 7a 86 3e  6.....`p...."z.>
+  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+
+  Text to MAC:
+  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
+  144  74 68 69 6e 20 74 68 65 20 63 6f 6e 74 65 78 74  thin the context
+  160  20 6f 66 20 61 6e 20 49 45 54 46 20 61 63 74 69   of an IETF acti
+  176  76 69 74 79 20 69 73 20 63 6f 6e 73 69 64 65 72  vity is consider
+  192  65 64 20 61 6e 20 22 49 45 54 46 20 43 6f 6e 74  ed an "IETF Cont
+  208  72 69 62 75 74 69 6f 6e 22 2e 20 53 75 63 68 20  ribution". Such
+  224  73 74 61 74 65 6d 65 6e 74 73 20 69 6e 63 6c 75  statements inclu
+  240  64 65 20 6f 72 61 6c 20 73 74 61 74 65 6d 65 6e  de oral statemen
+  256  74 73 20 69 6e 20 49 45 54 46 20 73 65 73 73 69  ts in IETF sessi
+  272  6f 6e 73 2c 20 61 73 20 77 65 6c 6c 20 61 73 20  ons, as well as
+  288  77 72 69 74 74 65 6e 20 61 6e 64 20 65 6c 65 63  written and elec
+  304  74 72 6f 6e 69 63 20 63 6f 6d 6d 75 6e 69 63 61  tronic communica
+  320  74 69 6f 6e 73 20 6d 61 64 65 20 61 74 20 61 6e  tions made at an
+  336  79 20 74 69 6d 65 20 6f 72 20 70 6c 61 63 65 2c  y time or place,
+  352  20 77 68 69 63 68 20 61 72 65 20 61 64 64 72 65   which are addre
+  368  73 73 65 64 20 74 6f                             ssed to
+
+  Tag:
+  000  f3 47 7e 7c d9 54 17 af 89 a6 b8 79 4c 31 0c f0  .G~|.T.....yL1..
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 37]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  Test Vector #4:
+  ==============
+
+  One-time Poly1305 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.
+
+  Text to MAC:
+  000  27 54 77 61 73 20 62 72 69 6c 6c 69 67 2c 20 61  'Twas brillig, a
+  016  6e 64 20 74 68 65 20 73 6c 69 74 68 79 20 74 6f  nd the slithy to
+  032  76 65 73 0a 44 69 64 20 67 79 72 65 20 61 6e 64  ves.Did gyre and
+  048  20 67 69 6d 62 6c 65 20 69 6e 20 74 68 65 20 77   gimble in the w
+  064  61 62 65 3a 0a 41 6c 6c 20 6d 69 6d 73 79 20 77  abe:.All mimsy w
+  080  65 72 65 20 74 68 65 20 62 6f 72 6f 67 6f 76 65  ere the borogove
+  096  73 2c 0a 41 6e 64 20 74 68 65 20 6d 6f 6d 65 20  s,.And the mome
+  112  72 61 74 68 73 20 6f 75 74 67 72 61 62 65 2e     raths outgrabe.
+
+  Tag:
+  000  45 41 66 9a 7e aa ee 61 e7 08 dc 7c bc c5 eb 62  EAf.~..a...|...b
+
+   Test Vector #5: If one uses 130-bit partial reduction, does the code
+   handle the case where partially reduced final result is not fully
+   reduced?
+
+   R:
+   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   S:
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   data:
+   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+   tag:
+   03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Test Vector #6: What happens if addition of s overflows modulo 2^128?
+
+   R:
+   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   S:
+   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+   data:
+   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   tag:
+   03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 38]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   Test Vector #7: What happens if data limb is all ones and there is
+   carry from lower limb?
+
+   R:
+   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   S:
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   data:
+   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+   F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+   11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   tag:
+   05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Test Vector #8: What happens if final result from polynomial part is
+   exactly 2^130-5?
+
+   R:
+   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   S:
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   data:
+   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+   FB FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE
+   01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
+   tag:
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Test Vector #9: What happens if final result from polynomial part is
+   exactly 2^130-6?
+
+   R:
+   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   S:
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   data:
+   FD FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+   tag:
+   FA FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+
+
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 39]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+   Test Vector #10: What happens if 5*H+L-type reduction produces
+   131-bit intermediate result?
+
+   R:
+   01 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
+   S:
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   data:
+   E3 35 94 D7 50 5E 43 B9 00 00 00 00 00 00 00 00
+   33 94 D7 50 5E 43 79 CD 01 00 00 00 00 00 00 00
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   tag:
+   14 00 00 00 00 00 00 00 55 00 00 00 00 00 00 00
+
+   Test Vector #11: What happens if 5*H+L-type reduction produces
+   131-bit final result?
+
+   R:
+   01 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
+   S:
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   data:
+   E3 35 94 D7 50 5E 43 B9 00 00 00 00 00 00 00 00
+   33 94 D7 50 5E 43 79 CD 01 00 00 00 00 00 00 00
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   tag:
+   13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+A.4.  Poly1305 Key Generation Using ChaCha20
+
+  Test Vector #1:
+  ==============
+
+  The 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  ................
+
+  The nonce:
+  000  00 00 00 00 00 00 00 00 00 00 00 00              ............
+
+  Poly1305 one-time key:
+  000  76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28  v.....=.@]j.S..(
+  016  bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7  .........6...w..
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 40]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  Test Vector #2:
+  ==============
+
+  The 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  ................
+
+  The nonce:
+  000  00 00 00 00 00 00 00 00 00 00 00 02              ............
+
+  Poly1305 one-time key:
+  000  ec fa 25 4f 84 5f 64 74 73 d3 cb 14 0d a9 e8 76  ..%O._dts......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
+
+   Below we see decrypting a message.  We receive a ciphertext, a nonce,
+   and a tag.  We know the key.  We will check the tag and then
+   (assuming that it validates) decrypt the ciphertext.  In this
+   particular protocol, we'll assume that there is no padding of the
+   plaintext.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir & Langley                 Informational                    [Page 41]
+
+RFC 7539                   ChaCha20 & Poly1305                  May 2015
+
+
+  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.
+
+  Ciphertext:
+  000  64 a0 86 15 75 86 1a f4 60 f0 62 c7 9b e6 43 bd  d...u...`.b...C.
+  016  5e 80 5c fd 34 5c f3 89 f1 08 67 0a c7 6c 8c b2  ^.\.4\....g..l..
+  032  4c 6c fc 18 75 5d 43 ee a0 9e e9 4e 38 2d 26 b0  Ll..u]C....N8-&.
+  048  bd b7 b7 3c 32 1b 01 00 d4 f0 3b 7f 35 58 94 cf  ...<2.....;.5X..
+  064  33 2f 83 0e 71 0b 97 ce 98 c8 a8 4a bd 0b 94 81  3/..q......J....
+  080  14 ad 17 6e 00 8d 33 bd 60 f9 82 b1 ff 37 c8 55  ...n..3.`....7.U
+  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
+
+
+   First, we calculate the one-time Poly1305 key
+
+  @@@  ChaCha state with key setup
+        61707865  3320646e  79622d32  6b206574
+        a540921c  8ad355eb  868833f3  f0b5f604
+        c1173947  09802b40  bc5cca9d  c0757020
+        00000000  00000000  04030201  08070605
+
+  @@@  ChaCha state after 20 rounds
+        a94af0bd  89dee45c  b64bb195  afec8fa1
+        508f4726  63f554c0  1ea2c0db  aa721526
+        11b1e514  a0bacc0f  828a6015  d7825481
+        e8a4a850  d9dcbbd6  4c2de33a  f8ccd912
+
+  @@@ out bytes:
+  bd:f0:4a:a9:5c:e4:de:89:95:b1:4b:b6:a1:8f:ec:af:
+  26:47:8f:50:c0:54:f5:63:db:c0:a2:1e:26:15:72:aa
+
+  Poly1305 one-time key:
+  000  bd f0 4a a9 5c e4 de 89 95 b1 4b b6 a1 8f ec af  ..J.\.....K.....
+  016  26 47 8f 50 c0 54 f5 63 db c0 a2 1e 26 15 72 aa  &G.P.T.c....&.r.
+
+   Next, we construct the AEAD buffer
+
+  Poly1305 Input:
+  000  f3 33 88 86 00 00 00 00 00 00 4e 91 00 00 00 00  .3........N.....
+  016  64 a0 86 15 75 86 1a f4 60 f0 62 c7 9b e6 43 bd  d...u...`.b...C.
+  032  5e 80 5c fd 34 5c f3 89 f1 08 67 0a c7 6c 8c b2  ^.\.4\....g..l..
+  048  4c 6c fc 18 75 5d 43 ee a0 9e e9 4e 38 2d 26 b0  Ll..u]C....N8-&.
+  064  bd b7 b7 3c 32 1b 01 00 d4 f0 3b 7f 35 58 94 cf  ...<2.....;.5X..
+  080  33 2f 83 0e 71 0b 97 ce 98 c8 a8 4a bd 0b 94 81  3/..q......J....
+  096  14 ad 17 6e 00 8d 33 bd 60 f9 82 b1 ff 37 c8 55  ...n..3.`....7.U
+  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
+
+
+   We calculate the Poly1305 tag and find that it matches
+
+  Calculated Tag:
+  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
+
+   The following measurements were made by Adam Langley for a blog post
+   published on February 27th, 2014.  The original blog post was
+   available at the time of this writing at
+   <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
+
+
+Acknowledgements
+
+   ChaCha20 and Poly1305 were invented by Daniel J. Bernstein.  The AEAD
+   construction and the method of creating the one-time Poly1305 key
+   were invented by Adam Langley.
+
+   Thanks to Robert Ransom, Watson Ladd, Stefan Buhler, Dan Harkins, and
+   Kenny Paterson for their helpful comments and explanations.  Thanks
+   to Niels Moller for suggesting the more efficient AEAD construction
+   in this document.  Special thanks to Ilari Liusvaara for providing
+   extra test vectors, helpful comments, and for being the first to
+   attempt an implementation from this document.  Thanks to Sean
+   Parkinson for suggesting improvements to the examples and the
+   pseudocode.  Thanks to David Ireland for pointing out a bug in the
+   pseudocode, and to Stephen Farrell and Alyssa Rowan for pointing out
+   missing advise in the security considerations.
+
+   Special thanks goes to Gordon Procter for performing a security
+   analysis of the composition and publishing [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]
+
-- 
cgit v1.2.3