idnits 2.17.1 

draft-irtf-cfrg-chacha20-poly1305-04.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == Line 246 has weird spacing: '...db886dc  c9a62...'

  == Line 298 has weird spacing: '...ccccccc  ccccc...'

  == Line 299 has weird spacing: '...kkkkkkk  kkkkk...'

  == Line 300 has weird spacing: '...kkkkkkk  kkkkk...'

  == Line 301 has weird spacing: '...bbbbbbb  nnnnn...'

  == (9 more instances...)

  -- The document date (January 3, 2015) is 3401 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  -- Looks like a reference, but probably isn't: '3' on line 577

  -- Looks like a reference, but probably isn't: '7' on line 578

  -- Looks like a reference, but probably isn't: '11' on line 579

  -- Looks like a reference, but probably isn't: '15' on line 580

  -- Looks like a reference, but probably isn't: '4' on line 581

  -- Looks like a reference, but probably isn't: '8' on line 582

  -- Looks like a reference, but probably isn't: '12' on line 583

  -- Looks like a reference, but probably isn't: '16' on line 575

  == Missing Reference: '0x01' is mentioned on line 635, but not defined

  -- Obsolete informational reference (is this intentional?): RFC 5996
     (Obsoleted by RFC 7296)


     Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                                             Y. Nir
3	Internet-Draft                                               Check Point
4	Intended status: Informational                                A. Langley
5	Expires: July 7, 2015                                         Google Inc
6	                                                         January 3, 2015

8	                ChaCha20 and Poly1305 for IETF protocols
9	                  draft-irtf-cfrg-chacha20-poly1305-04

11	Abstract

13	   This document defines the ChaCha20 stream cipher, as well as the use
14	   of the Poly1305 authenticator, both as stand-alone algorithms, and as
15	   a "combined mode", or Authenticated Encryption with Additional Data
16	   (AEAD) algorithm.

18	   This document does not introduce any new crypto, but is meant to
19	   serve as a stable reference and an implementation guide.  It is a
20	   product of the Crypto Forum Research Group (CFRG)

22	Status of This Memo

24	   This Internet-Draft is submitted in full conformance with the
25	   provisions of BCP 78 and BCP 79.

27	   Internet-Drafts are working documents of the Internet Engineering
28	   Task Force (IETF).  Note that other groups may also distribute
29	   working documents as Internet-Drafts.  The list of current Internet-
30	   Drafts is at http://datatracker.ietf.org/drafts/current/.

32	   Internet-Drafts are draft documents valid for a maximum of six months
33	   and may be updated, replaced, or obsoleted by other documents at any
34	   time.  It is inappropriate to use Internet-Drafts as reference
35	   material or to cite them other than as "work in progress."

37	   This Internet-Draft will expire on July 7, 2015.

39	Copyright Notice

41	   Copyright (c) 2015 IETF Trust and the persons identified as the
42	   document authors.  All rights reserved.

44	   This document is subject to BCP 78 and the IETF Trust's Legal
45	   Provisions Relating to IETF Documents
46	   (http://trustee.ietf.org/license-info) in effect on the date of
47	   publication of this document.  Please review these documents
48	   carefully, as they describe your rights and restrictions with respect
49	   to this document.

51	Table of Contents

53	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
54	     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
55	   2.  The Algorithms  . . . . . . . . . . . . . . . . . . . . . . .   4
56	     2.1.  The ChaCha Quarter Round  . . . . . . . . . . . . . . . .   4
57	       2.1.1.  Test Vector for the ChaCha Quarter Round  . . . . . .   5
58	     2.2.  A Quarter Round on the ChaCha State . . . . . . . . . . .   5
59	       2.2.1.  Test Vector for the Quarter Round on the ChaCha state   5
60	     2.3.  The ChaCha20 block Function . . . . . . . . . . . . . . .   6
61	       2.3.1.  The ChaCha20 Block Function in Pseudo-Code  . . . . .   7
62	       2.3.2.  Test Vector for the ChaCha20 Block Function . . . . .   8
63	     2.4.  The ChaCha20 encryption algorithm . . . . . . . . . . . .   9
64	       2.4.1.  The ChaCha20 encryption algorithm in Pseudo-Code  . .  10
65	       2.4.2.  Example and Test Vector for the ChaCha20 Cipher . . .  10
66	     2.5.  The Poly1305 algorithm  . . . . . . . . . . . . . . . . .  12
67	       2.5.1.  The Poly1305 Algorithms in Pseudo-Code  . . . . . . .  14
68	       2.5.2.  Poly1305 Example and Test Vector  . . . . . . . . . .  14
69	     2.6.  Generating the Poly1305 key using ChaCha20  . . . . . . .  15
70	       2.6.1.  Poly1305 Key Generation in Pseudo-Code  . . . . . . .  16
71	       2.6.2.  Poly1305 Key Generation Test Vector . . . . . . . . .  17
72	     2.7.  A Pseudo-Random Function for ChaCha/Poly-1305 based
73	           Crypto Suites . . . . . . . . . . . . . . . . . . . . . .  17
74	     2.8.  AEAD Construction . . . . . . . . . . . . . . . . . . . .  18
75	       2.8.1.  Pseudo-Code for the AEAD Construction . . . . . . . .  20
76	       2.8.2.  Example and Test Vector for AEAD_CHACHA20-POLY1305  .  20
77	   3.  Implementation Advice . . . . . . . . . . . . . . . . . . . .  22
78	   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
79	   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
80	   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
81	   7.  Changes from Previous Versions  . . . . . . . . . . . . . . .  24
82	     7.1.  Changes from version -01 to version -02 . . . . . . . . .  24
83	     7.2.  Changes from version -00 to version -01 . . . . . . . . .  24
84	     7.3.  Changes from draft-nir-cfrg to draft-irtf-cfrg  . . . . .  25
85	   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
86	     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
87	     8.2.  Informative References  . . . . . . . . . . . . . . . . .  25
88	   Appendix A.  Additional Test Vectors  . . . . . . . . . . . . . .  26
89	     A.1.  The ChaCha20 Block Functions  . . . . . . . . . . . . . .  26
90	     A.2.  ChaCha20 Encryption . . . . . . . . . . . . . . . . . . .  29
91	     A.3.  Poly1305 Message Authentication Code  . . . . . . . . . .  32
92	     A.4.  Poly1305 Key Generation Using ChaCha20  . . . . . . . . .  38
93	     A.5.  ChaCha20-Poly1305 AEAD Decryption . . . . . . . . . . . .  39
94	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  42

96	1.  Introduction

98	   The Advanced Encryption Standard (AES - [FIPS-197]) has become the
99	   gold standard in encryption.  Its efficient design, widespread
100	   implementation, and hardware support allow for high performance in
101	   many areas.  On most modern platforms, AES is anywhere from 4x to 10x
102	   as fast as the previous most-used cipher, 3-key Data Encryption
103	   Standard (3DES - [FIPS-46]), which makes it not only the best choice,
104	   but the only practical choice.

106	   The problem is that if future advances in cryptanalysis reveal a
107	   weakness in AES, users will be in an unenviable position.  With the
108	   only other widely supported cipher being the much slower 3DES, it is
109	   not feasible to re-configure implementations to use 3DES.
110	   [standby-cipher] describes this issue and the need for a standby
111	   cipher in greater detail.

113	   This document defines such a standby cipher.  We use ChaCha20
114	   ([chacha]) with or without the Poly1305 ([poly1305]) authenticator.
115	   These algorithms are not just fast, they are fast even in software-
116	   only C-language implementations, allowing for much quicker deployment
117	   when compared with algorithms such as AES that are significantly
118	   accelerated by hardware implementations.

120	   This document does not introduce these new algorithms.  They have
121	   been defined in scientific papers by D.  J.  Bernstein, which are
122	   referenced by this document.  The purpose of this document is to
123	   serve as a stable reference for IETF documents making use of these
124	   algorithms.

126	   These algorithms have undergone rigorous analysis.  Several papers
127	   discuss the security of Salsa and ChaCha ([LatinDances],
128	   [LatinDances2], [Zhenqing2012]).

130	   This document represents the consensus of the Crypto Forum Research
131	   Group (CFRG).

133	1.1.  Conventions Used in This Document

135	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137	   document are to be interpreted as described in [RFC2119].

139	   The description of the ChaCha algorithm will at various time refer to
140	   the ChaCha state as a "vector" or as a "matrix".  This follows the
141	   use of these terms in Prof. Bernstein's paper.  The matrix notation
142	   is more visually convenient, and gives a better notion as to why some
143	   rounds are called "column rounds" while others are called "diagonal
144	   rounds".  Here's a diagram of how the matrices relate to vectors
145	   (using the C language convention of zero being the index origin).

147	      0   1   2   3
148	      4   5   6   7
149	      8   9  10  11
150	     12  13  14  15

152	   The elements in this vector or matrix are 32-bit unsigned integers.

154	   The algorithm name is "ChaCha".  "ChaCha20" is a specific instance
155	   where 20 "rounds" (or 80 quarter rounds - see Section 2.1) are used.
156	   Other variations are defined, with 8 or 12 rounds, but in this
157	   document we only describe the 20-round ChaCha, so the names "ChaCha"
158	   and "ChaCha20" will be used interchangeably.

160	2.  The Algorithms

162	   The subsections below describe the algorithms used and the AEAD
163	   construction.

165	2.1.  The ChaCha Quarter Round

167	   The basic operation of the ChaCha algorithm is the quarter round.  It
168	   operates on four 32-bit unsigned integers, denoted a, b, c, and d.
169	   The operation is as follows (in C-like notation):

171	   1.  a += b; d ^= a; d <<<= 16;
172	   2.  c += d; b ^= c; b <<<= 12;
173	   3.  a += b; d ^= a; d <<<= 8;
174	   4.  c += d; b ^= c; b <<<= 7;

176	   Where "+" denotes integer addition modulo 2^32, "^" denotes a bitwise
177	   Exclusive OR (XOR), and "<<< n" denotes an n-bit left rotation
178	   (towards the high bits).

180	   For example, let's see the add, XOR and roll operations from the
181	   fourth line with sample numbers:

183	   o  a = 0x11111111
184	   o  b = 0x01020304
185	   o  c = 0x77777777
186	   o  d = 0x01234567
187	   o  c = c + d = 0x77777777 + 0x01234567 = 0x789abcde
188	   o  b = b ^ c = 0x01020304 ^ 0x789abcde = 0x7998bfda
189	   o  b = b <<< 7 = 0x7998bfda <<< 7 = 0xcc5fed3c

191	2.1.1.  Test Vector for the ChaCha Quarter Round

193	   For a test vector, we will use the same numbers as in the example,
194	   adding something random for c.

196	   o  a = 0x11111111
197	   o  b = 0x01020304
198	   o  c = 0x9b8d6f43
199	   o  d = 0x01234567

201	   After running a Quarter Round on these 4 numbers, we get these:

203	   o  a = 0xea2a92f4
204	   o  b = 0xcb1cf8ce
205	   o  c = 0x4581472e
206	   o  d = 0x5881c4bb

208	2.2.  A Quarter Round on the ChaCha State

210	   The ChaCha state does not have 4 integer numbers, but 16.  So the
211	   quarter round operation works on only 4 of them - hence the name.
212	   Each quarter round operates on 4 pre-determined numbers in the ChaCha
213	   state.  We will denote by QUARTERROUND(x,y,z,w) a quarter-round
214	   operation on the numbers at indexes x, y, z, and w of the ChaCha
215	   state when viewed as a vector.  For example, if we apply
216	   QUARTERROUND(1,5,9,13) to a state, this means running the quarter
217	   round operation on the elements marked with an asterisk, while
218	   leaving the others alone:

220	      0  *a   2   3
221	      4  *b   6   7
222	      8  *c  10  11
223	     12  *d  14  15

225	   Note that this run of quarter round is part of what is called a
226	   "column round".

228	2.2.1.  Test Vector for the Quarter Round on the ChaCha state

230	   For a test vector, we will use a ChaCha state that was generated
231	   randomly:

233	   Sample ChaCha State

235	       879531e0  c5ecf37d  516461b1  c9a62f8a
236	       44c20ef3  3390af7f  d9fc690b  2a5f714c
237	       53372767  b00a5631  974c541a  359e9963
238	       5c971061  3d631689  2098d9d6  91dbd320

240	   We will apply the QUARTERROUND(2,7,8,13) operation to this state.
241	   For obvious reasons, this one is part of what is called a "diagonal
242	   round":

244	   After applying QUARTERROUND(2,7,8,13)

246	       879531e0  c5ecf37d *bdb886dc  c9a62f8a
247	       44c20ef3  3390af7f  d9fc690b *cfacafd2
248	      *e46bea80  b00a5631  974c541a  359e9963
249	       5c971061 *ccc07c79  2098d9d6  91dbd320

251	   Note that only the numbers in positions 2, 7, 8, and 13 changed.

253	2.3.  The ChaCha20 block Function

255	   The ChaCha block function transforms a ChaCha state by running
256	   multiple quarter rounds.

258	   The inputs to ChaCha20 are:

260	   o  A 256-bit key, treated as a concatenation of 8 32-bit little-
261	      endian integers.
262	   o  A 96-bit nonce, treated as a concatenation of 3 32-bit little-
263	      endian integers.
264	   o  A 32-bit block count parameter, treated as a 32-bit little-endian
265	      integer.

267	   The output is 64 random-looking bytes.

269	   The ChaCha algorithm described here uses a 256-bit key.  The original
270	   algorithm also specified 128-bit keys and 8- and 12-round variants,
271	   but these are out of scope for this document.  In this section we
272	   describe the ChaCha block function.

274	   Note also that the original ChaCha had a 64-bit nonce and 64-bit
275	   block count.  We have modified this here to be more consistent with
276	   recommendations in section 3.2 of [RFC5116].  This limits the use of
277	   a single (key,nonce) combination to 2^32 blocks, or 256 GB, but that
278	   is enough for most uses.  In cases where a single key is used by
279	   multiple senders, it is important to make sure that they don't use
280	   the same nonces.  This can be assured by partitioning the nonce space
281	   so that the first 32 bits are unique per sender, while the other 64
282	   bits come from a counter.

284	   The ChaCha20 state is initialized as follows:

286	   o  The first 4 words (0-3) are constants: 0x61707865, 0x3320646e,
287	      0x79622d32, 0x6b206574.

289	   o  The next 8 words (4-11) are taken from the 256-bit key by reading
290	      the bytes in little-endian order, in 4-byte chunks.
291	   o  Word 12 is a block counter.  Since each block is 64-byte, a 32-bit
292	      word is enough for 256 gigabytes of data.
293	   o  Words 13-15 are a nonce, which should not be repeated for the same
294	      key.  The 13th word is the first 32 bits of the input nonce taken
295	      as a little-endian integer, while the 15th word is the last 32
296	      bits.

298	       cccccccc  cccccccc  cccccccc  cccccccc
299	       kkkkkkkk  kkkkkkkk  kkkkkkkk  kkkkkkkk
300	       kkkkkkkk  kkkkkkkk  kkkkkkkk  kkkkkkkk
301	       bbbbbbbb  nnnnnnnn  nnnnnnnn  nnnnnnnn

303	   c=constant k=key b=blockcount n=nonce

305	   ChaCha20 runs 20 rounds, alternating between "column" and "diagonal"
306	   rounds.  Each round is 4 quarter-rounds, and they are run as follows.
307	   Quarter-rounds 1-4 are part of a "column" round, while 5-8 are part
308	   of a "diagonal" round:

310	   1.  QUARTERROUND ( 0, 4, 8,12)
311	   2.  QUARTERROUND ( 1, 5, 9,13)
312	   3.  QUARTERROUND ( 2, 6,10,14)
313	   4.  QUARTERROUND ( 3, 7,11,15)
314	   5.  QUARTERROUND ( 0, 5,10,15)
315	   6.  QUARTERROUND ( 1, 6,11,12)
316	   7.  QUARTERROUND ( 2, 7, 8,13)
317	   8.  QUARTERROUND ( 3, 4, 9,14)

319	   At the end of 20 rounds (or 10 iterations of the above list), we add
320	   the original input words to the output words, and serialize the
321	   result by sequencing the words one-by-one in little-endian order.

323	   Note: "addition" in the above paragraph is done modulo 2^32.  In some
324	   machine languages this is called carryless addition on a 32-bit word.

326	2.3.1.  The ChaCha20 Block Function in Pseudo-Code

328	   Note: This section and a few others contain pseudo-code for the
329	   algorithm explained in a previous section.  Every effort was made for
330	   the pseudo-code to accurately reflect the algorithm as described in
331	   the preceding section.  If a conflict is still present, the textual
332	   explanation and the test vectors are normative.

334	      inner_block (state):
335	         Qround(state, 0, 4, 8,12)
336	         Qround(state, 1, 5, 9,13)
337	         Qround(state, 2, 6,10,14)
338	         Qround(state, 3, 7,11,15)
339	         Qround(state, 0, 5,10,15)
340	         Qround(state, 1, 6,11,12)
341	         Qround(state, 2, 7, 8,13)
342	         Qround(state, 3, 4, 9,14)
343	         end

345	      chacha20_block(key, counter, nonce):
346	         state = constants | key | counter | nonce
347	         working_state = state
348	         for i=1 upto 10
349	            inner_block(working_state)
350	            end
351	         state += working_state
352	         return serialize(state)
353	         end

355	2.3.2.  Test Vector for the ChaCha20 Block Function

357	   For a test vector, we will use the following inputs to the ChaCha20
358	   block function:

360	   o  Key = 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:10:11:12:13:
361	      14:15:16:17:18:19:1a:1b:1c:1d:1e:1f.  The key is a sequence of
362	      octets with no particular structure before we copy it into the
363	      ChaCha state.
364	   o  Nonce = (00:00:00:09:00:00:00:4a:00:00:00:00)
365	   o  Block Count = 1.

367	   After setting up the ChaCha state, it looks like this:

369	   ChaCha State with the key set up.

371	       61707865  3320646e  79622d32  6b206574
372	       03020100  07060504  0b0a0908  0f0e0d0c
373	       13121110  17161514  1b1a1918  1f1e1d1c
374	       00000001  09000000  4a000000  00000000

376	   After running 20 rounds (10 column rounds interleaved with 10
377	   diagonal rounds), the ChaCha state looks like this:

379	   ChaCha State after 20 rounds

381	       837778ab  e238d763  a67ae21e  5950bb2f
382	       c4f2d0c7  fc62bb2f  8fa018fc  3f5ec7b7
383	       335271c2  f29489f3  eabda8fc  82e46ebd
384	       d19c12b4  b04e16de  9e83d0cb  4e3c50a2

386	   Finally we add the original state to the result (simple vector or
387	   matrix addition), giving this:

389	   ChaCha State at the end of the ChaCha20 operation

391	       e4e7f110  15593bd1  1fdd0f50  c47120a3
392	       c7f4d1c7  0368c033  9aaa2204  4e6cd4c3
393	       466482d2  09aa9f07  05d7c214  a2028bd9
394	       d19c12b5  b94e16de  e883d0cb  4e3c50a2

396	   After we serialize the state, we get this:

398	  Serialized Block:
399	  000  10 f1 e7 e4 d1 3b 59 15 50 0f dd 1f a3 20 71 c4  .....;Y.P.... q.
400	  016  c7 d1 f4 c7 33 c0 68 03 04 22 aa 9a c3 d4 6c 4e  ....3.h.."....lN
401	  032  d2 82 64 46 07 9f aa 09 14 c2 d7 05 d9 8b 02 a2  ..dF............
402	  048  b5 12 9c d1 de 16 4e b9 cb d0 83 e8 a2 50 3c 4e  ......N......P<N

404	2.4.  The ChaCha20 encryption algorithm

406	   ChaCha20 is a stream cipher designed by D.  J.  Bernstein.  It is a
407	   refinement of the Salsa20 algorithm, and uses a 256-bit key.

409	   ChaCha20 successively calls the ChaCha20 block function, with the
410	   same key and nonce, and with successively increasing block counter
411	   parameters.  ChaCha20 then serializes the resulting state by writing
412	   the numbers in little-endian order, creating a key-stream block.
413	   Concatenating the key-stream blocks from the successive blocks forms
414	   a key stream.  The ChaCha20 function then performs a XOR of this
415	   keystream with the plaintext.  Alternatively, each key-stream block
416	   can be XOR-ed with a plaintext block before proceeding to create the
417	   next block, saving some memory.  There is no requirement for the
418	   plaintext to be an integral multiple of 512-bits.  If there is extra
419	   keystream from the last block, it is discarded.  Specific protocols
420	   MAY require that the plaintext and ciphertext have certain length.
421	   Such protocols need to specify how the plaintext is padded, and how
422	   much padding it receives.

424	   The inputs to ChaCha20 are:

426	   o  A 256-bit key
427	   o  A 32-bit initial counter.  This can be set to any number, but will
428	      usually be zero or one.  It makes sense to use 1 if we use the
429	      zero block for something else, such as generating a one-time
430	      authenticator key as part of an AEAD algorithm.
431	   o  A 96-bit nonce.  In some protocols, this is known as the
432	      Initialization Vector.
433	   o  An arbitrary-length plaintext

435	   The output is an encrypted message, or "ciphertext" of the same
436	   length.

438	   Decryption is done in the same way.  The ChaCha20 block function is
439	   used to expand the key into a key stream, which is XOR-ed with the
440	   ciphertext giving back the plaintext.

442	2.4.1.  The ChaCha20 encryption algorithm in Pseudo-Code

444	     chacha20_encrypt(key, counter, nonce, plaintext):
445	        for counter=1 upto ceil(len(plaintext) / 64)
446	           key_stream = chacha20_block(key, counter, nonce)
447	           block = plaintext[((counter-1)*64)..(counter*64-1)]
448	           encrypted_message +=  block ^ key_stream
449	           end
450	        if ((len(plaintext) % 64) != 0)
451	           key_stream = chacha20_block(key, counter, nonce)
452	           block = plaintext[(counter*64)..len(plaintext)-1]
453	           encrypted_message += (block^key_stream)[0..len(plaintext)%64]
454	           end
455	        return encrypted_mesage
456	        end

458	2.4.2.  Example and Test Vector for the ChaCha20 Cipher

460	   For a test vector, we will use the following inputs to the ChaCha20
461	   block function:

463	   o  Key = 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:10:11:12:13:
464	      14:15:16:17:18:19:1a:1b:1c:1d:1e:1f.
465	   o  Nonce = (00:00:00:00:00:00:00:4a:00:00:00:00).
466	   o  Initial Counter = 1.

468	   We use the following for the plaintext.  It was chosen to be long
469	   enough to require more than one block, but not so long that it would
470	   make this example cumbersome (so, less than 3 blocks):

472	  Plaintext Sunscreen:
473	  000  4c 61 64 69 65 73 20 61 6e 64 20 47 65 6e 74 6c  Ladies and Gentl
474	  016  65 6d 65 6e 20 6f 66 20 74 68 65 20 63 6c 61 73  emen of the clas
475	  032  73 20 6f 66 20 27 39 39 3a 20 49 66 20 49 20 63  s of '99: If I c
476	  048  6f 75 6c 64 20 6f 66 66 65 72 20 79 6f 75 20 6f  ould offer you o
477	  064  6e 6c 79 20 6f 6e 65 20 74 69 70 20 66 6f 72 20  nly one tip for
478	  080  74 68 65 20 66 75 74 75 72 65 2c 20 73 75 6e 73  the future, suns
479	  096  63 72 65 65 6e 20 77 6f 75 6c 64 20 62 65 20 69  creen would be i
480	  112  74 2e                                            t.

482	   The following figure shows 4 ChaCha state matrices:

484	   1.  First block as it is set up.
485	   2.  Second block as it is set up.  Note that these blocks are only
486	       two bits apart - only the counter in position 12 is different.
487	   3.  Third block is the first block after the ChaCha20 block
488	       operation.
489	   4.  Final block is the second block after the ChaCha20 block
490	       operation was applied.

492	   After that, we show the keystream.

494	   First block setup:
495	       61707865  3320646e  79622d32  6b206574
496	       03020100  07060504  0b0a0908  0f0e0d0c
497	       13121110  17161514  1b1a1918  1f1e1d1c
498	       00000001  00000000  4a000000  00000000

500	   Second block setup:
501	       61707865  3320646e  79622d32  6b206574
502	       03020100  07060504  0b0a0908  0f0e0d0c
503	       13121110  17161514  1b1a1918  1f1e1d1c
504	       00000002  00000000  4a000000  00000000

506	   First block after block operation:
507	       f3514f22  e1d91b40  6f27de2f  ed1d63b8
508	       821f138c  e2062c3d  ecca4f7e  78cff39e
509	       a30a3b8a  920a6072  cd7479b5  34932bed
510	       40ba4c79  cd343ec6  4c2c21ea  b7417df0

512	   Second block after block operation:
513	       9f74a669  410f633f  28feca22  7ec44dec
514	       6d34d426  738cb970  3ac5e9f3  45590cc4
515	       da6e8b39  892c831a  cdea67c1  2b7e1d90
516	       037463f3  a11a2073  e8bcfb88  edc49139

518	   Keystream:
519	   22:4f:51:f3:40:1b:d9:e1:2f:de:27:6f:b8:63:1d:ed:8c:13:1f:82:3d:2c:06
520	   e2:7e:4f:ca:ec:9e:f3:cf:78:8a:3b:0a:a3:72:60:0a:92:b5:79:74:cd:ed:2b
521	   93:34:79:4c:ba:40:c6:3e:34:cd:ea:21:2c:4c:f0:7d:41:b7:69:a6:74:9f:3f
522	   63:0f:41:22:ca:fe:28:ec:4d:c4:7e:26:d4:34:6d:70:b9:8c:73:f3:e9:c5:3a
523	   c4:0c:59:45:39:8b:6e:da:1a:83:2c:89:c1:67:ea:cd:90:1d:7e:2b:f3:63

525	   Finally, we XOR the Keystream with the plaintext, yielding the
526	   Ciphertext:

528	  Ciphertext Sunscreen:
529	  000  6e 2e 35 9a 25 68 f9 80 41 ba 07 28 dd 0d 69 81  n.5.%h..A..(..i.
530	  016  e9 7e 7a ec 1d 43 60 c2 0a 27 af cc fd 9f ae 0b  .~z..C`..'......
531	  032  f9 1b 65 c5 52 47 33 ab 8f 59 3d ab cd 62 b3 57  ..e.RG3..Y=..b.W
532	  048  16 39 d6 24 e6 51 52 ab 8f 53 0c 35 9f 08 61 d8  .9.$.QR..S.5..a.
533	  064  07 ca 0d bf 50 0d 6a 61 56 a3 8e 08 8a 22 b6 5e  ....P.jaV....".^
534	  080  52 bc 51 4d 16 cc f8 06 81 8c e9 1a b7 79 37 36  R.QM.........y76
535	  096  5a f9 0b bf 74 a3 5b e6 b4 0b 8e ed f2 78 5e 42  Z...t.[......x^B
536	  112  87 4d                                            .M

538	2.5.  The Poly1305 algorithm

540	   Poly1305 is a one-time authenticator designed by D.  J.  Bernstein.
541	   Poly1305 takes a 32-byte one-time key and a message and produces a
542	   16-byte tag.  This tag is used to authenticate the message.

544	   The original article ([poly1305]) is entitled "The Poly1305-AES
545	   message-authentication code", and the MAC function there requires a
546	   128-bit AES key, a 128-bit "additional key", and a 128-bit (non-
547	   secret) nonce.  AES is used there for encrypting the nonce, so as to
548	   get a unique (and secret) 128-bit string, but as the paper states,
549	   "There is nothing special about AES here.  One can replace AES with
550	   an arbitrary keyed function from an arbitrary set of nonces to
551	   16-byte strings."

553	   Regardless of how the key is generated, the key is partitioned into
554	   two parts, called "r" and "s".  The pair (r,s) should be unique, and
555	   MUST be unpredictable for each invocation (that is why it was
556	   originally obtained by encrypting a nonce), while "r" MAY be
557	   constant, but needs to be modified as follows before being used: ("r"
558	   is treated as a 16-octet little-endian number):

560	   o  r[3], r[7], r[11], and r[15] are required to have their top four
561	      bits clear (be smaller than 16)
562	   o  r[4], r[8], and r[12] are required to have their bottom two bits
563	      clear (be divisible by 4)

565	   The following sample code clamps "r" to be appropriate:

567	   /*
568	   Adapted from poly1305aes_test_clamp.c version 20050207
569	   D. J. Bernstein
570	   Public domain.
571	   */

573	   #include "poly1305aes_test.h"

575	   void poly1305aes_test_clamp(unsigned char r[16])
576	   {
577	     r[3] &= 15;
578	     r[7] &= 15;
579	     r[11] &= 15;
580	     r[15] &= 15;
581	     r[4] &= 252;
582	     r[8] &= 252;
583	     r[12] &= 252;
584	   }

586	   The "s" should be unpredictable, but it is perfectly acceptable to
587	   generate both "r" and "s" uniquely each time.  Because each of them
588	   is 128-bit, pseudo-randomly generating them (see Section 2.6) is also
589	   acceptable.

591	   The inputs to Poly1305 are:

593	   o  A 256-bit one-time key
594	   o  An arbitrary length message

596	   The output is a 128-bit tag.

598	   First, the "r" value should be clamped.

600	   Next, set the constant prime "P" be 2^130-5:
601	   3fffffffffffffffffffffffffffffffb.  Also set a variable "accumulator"
602	   to zero.

604	   Next, divide the message into 16-byte blocks.  The last one might be
605	   shorter:

607	   o  Read the block as a little-endian number.
608	   o  Add one bit beyond the number of octets.  For a 16-byte block this
609	      is equivalent to adding 2^128 to the number.  For the shorter
610	      block it can be 2^120, 2^112, or any power of two that is evenly
611	      divisible by 8, all the way down to 2^8.
612	   o  If the block is not 17 bytes long (the last block), pad it with
613	      zeros.  This is meaningless if you are treating the blocks as
614	      numbers.

616	   o  Add this number to the accumulator.
617	   o  Multiply by "r"
618	   o  Set the accumulator to the result modulo p.  To summarize: Acc =
619	      ((Acc+block)*r) % p.

621	   Finally, the value of the secret key "s" is added to the accumulator,
622	   and the 128 least significant bits are serialized in little-endian
623	   order to form the tag.

625	2.5.1.  The Poly1305 Algorithms in Pseudo-Code

627	      clamp(r): r &= 0x0fffff0c0ffffffc0ffffffcffffffff
628	      poly1305_mac(msg, key):
629	         r = (le_bytes_to_num(key[0..15])
630	         clamp(r)
631	         s = le_num(key[16..31])
632	         accumulator = 0
633	         p = (1<<130)-5
634	         for i=1 upto ceil(msg length in bytes / 16)
635	            n = le_bytes_to_num([0x01] | msg[((i-1)*16)..(i*16)])
636	            a += n
637	            a = (r * a) % p
638	            end
639	         a += s
640	         return num_to_16_le_bytes(a)
641	         end

643	2.5.2.  Poly1305 Example and Test Vector

645	   For our example, we will dispense with generating the one-time key
646	   using AES, and assume that we got the following keying material:

648	   o  Key Material: 85:d6:be:78:57:55:6d:33:7f:44:52:fe:42:d5:06:a8:01:0
649	      3:80:8a:fb:0d:b2:fd:4a:bf:f6:af:41:49:f5:1b
650	   o  s as an octet string:
651	      01:03:80:8a:fb:0d:b2:fd:4a:bf:f6:af:41:49:f5:1b
652	   o  s as a 128-bit number: 1bf54941aff6bf4afdb20dfb8a800301
653	   o  r before clamping: 85:d6:be:78:57:55:6d:33:7f:44:52:fe:42:d5:06:a8
654	   o  Clamped r as a number: 806d5400e52447c036d555408bed685.

656	   For our message, we'll use a short text:

658	  Message to be Authenticated:
659	  000  43 72 79 70 74 6f 67 72 61 70 68 69 63 20 46 6f  Cryptographic Fo
660	  016  72 75 6d 20 52 65 73 65 61 72 63 68 20 47 72 6f  rum Research Gro
661	  032  75 70                                            up
662	   Since Poly1305 works in 16-byte chunks, the 34-byte message divides
663	   into 3 blocks.  In the following calculation, "Acc" denotes the
664	   accumulator and "Block" the current block:

666	   Block #1

668	   Acc = 00
669	   Block = 6f4620636968706172676f7470797243
670	   Block with 0x01 byte = 016f4620636968706172676f7470797243
671	   Acc + block = 016f4620636968706172676f7470797243
672	   (Acc+Block) * r =
673	        b83fe991ca66800489155dcd69e8426ba2779453994ac90ed284034da565ecf
674	   Acc = ((Acc+Block)*r) % P = 2c88c77849d64ae9147ddeb88e69c83fc

676	   Block #2

678	   Acc = 2c88c77849d64ae9147ddeb88e69c83fc
679	   Block = 6f7247206863726165736552206d7572
680	   Block with 0x01 byte = 016f7247206863726165736552206d7572
681	   Acc + block = 437febea505c820f2ad5150db0709f96e
682	   (Acc+Block) * r =
683	        21dcc992d0c659ba4036f65bb7f88562ae59b32c2b3b8f7efc8b00f78e548a26
684	   Acc = ((Acc+Block)*r) % P = 2d8adaf23b0337fa7cccfb4ea344b30de

686	   Last Block

688	   Acc = 2d8adaf23b0337fa7cccfb4ea344b30de
689	   Block = 7075
690	   Block with 0x01 byte = 017075
691	   Acc + block = 2d8adaf23b0337fa7cccfb4ea344ca153
692	   (Acc + Block) * r =
693	        16d8e08a0f3fe1de4fe4a15486aca7a270a29f1e6c849221e4a6798b8e45321f
694	   ((Acc + Block) * r) % P = 28d31b7caff946c77c8844335369d03a7

696	   Adding s we get this number, and serialize if to get the tag:

698	   Acc + s = 2a927010caf8b2bc2c6365130c11d06a8

700	   Tag: a8:06:1d:c1:30:51:36:c6:c2:2b:8b:af:0c:01:27:a9

702	2.6.  Generating the Poly1305 key using ChaCha20

704	   As said in Section 2.5, it is acceptable to generate the one-time
705	   Poly1305 pseudo-randomly.  This section proposes such a method.

707	   To generate such a key pair (r,s), we will use the ChaCha20 block
708	   function described in Section 2.3.  This assumes that we have a
709	   256-bit session key for the MAC function, such as SK_ai and SK_ar in
710	   IKEv2 ([RFC5996]), the integrity key in ESP and AH, or the
711	   client_write_MAC_key and server_write_MAC_key in TLS.  Any document
712	   that specifies the use of Poly1305 as a MAC algorithm for some
713	   protocol must specify that 256 bits are allocated for the integrity
714	   key.  Note that in the AEAD construction defined in Section 2.8, the
715	   same key is used for encryption and key generation, so the use of
716	   SK_a* or *_write_MAC_key is only for stand-alone Poly1305.

718	   The method is to call the block function with the following
719	   parameters:

721	   o  The 256-bit session integrity key is used as the ChaCha20 key.
722	   o  The block counter is set to zero.
723	   o  The protocol will specify a 96-bit or 64-bit nonce.  This MUST be
724	      unique per invocation with the same key, so it MUST NOT be
725	      randomly generated.  A counter is a good way to implement this,
726	      but other methods, such as a Linear Feedback Shift Register (LFSR)
727	      are also acceptable.  ChaCha20 as specified here requires a 96-bit
728	      nonce.  So if the provided nonce is only 64-bit, then the first 32
729	      bits of the nonce will be set to a constant number.  This will
730	      usually be zero, but for protocols with multiple senders it may be
731	      different for each sender, but should be the same for all
732	      invocations of the function with the same key by a particular
733	      sender.

735	   After running the block function, we have a 512-bit state.  We take
736	   the first 256 bits or the serialized state, and use those as the one-
737	   time Poly1305 key: The first 128 bits are clamped, and form "r",
738	   while the next 128 bits become "s".  The other 256 bits are
739	   discarded.

741	   Note that while many protocols have provisions for a nonce for
742	   encryption algorithms (often called Initialization Vectors, or IVs),
743	   they usually don't have such a provision for the MAC function.  In
744	   that case the per-invocation nonce will have to come from somewhere
745	   else, such as a message counter.

747	2.6.1.  Poly1305 Key Generation in Pseudo-Code

749	      poly1305_key_gen(key,iv,constant):
750	         nonce = constant | iv
751	         counter = 0
752	         block = chacha20_block(key,counter,nonce)
753	         return block[0..31]
754	         end

756	2.6.2.  Poly1305 Key Generation Test Vector

758	   For this example, we'll set:

760	  Key:
761	  000  80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f  ................
762	  016  90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f  ................

764	   Nonce:
765	   000  00 00 00 00 00 01 02 03 04 05 06 07              ............

767	   The ChaCha state set up with key, nonce, and block counter zero:
768	         61707865  3320646e  79622d32  6b206574
769	         83828180  87868584  8b8a8988  8f8e8d8c
770	         93929190  97969594  9b9a9998  9f9e9d9c
771	         00000000  00000000  03020100  07060504

773	   The ChaCha state after 20 rounds:
774	         8ba0d58a  cc815f90  27405081  7194b24a
775	         37b633a8  a50dfde3  e2b8db08  46a6d1fd
776	         7da03782  9183a233  148ad271  b46773d1
777	         3cc1875a  8607def1  ca5c3086  7085eb87

779	  Output bytes:
780	  000  8a d5 a0 8b 90 5f 81 cc 81 50 40 27 4a b2 94 71  ....._...P@'J..q
781	  016  a8 33 b6 37 e3 fd 0d a5 08 db b8 e2 fd d1 a6 46  .3.7...........F

783	   And that output is also the 32-byte one-time key used for Poly1305.

785	2.7.  A Pseudo-Random Function for ChaCha/Poly-1305 based Crypto Suites

787	   Some protocols such as IKEv2([RFC5996]) require a Pseudo-Random
788	   Function (PRF), mostly for key derivation.  In the IKEv2 definition,
789	   a PRF is a function that accepts a variable-length key and a
790	   variable-length input, and returns a fixed-length output.  Most
791	   commonly, HMAC constructions are used for this purpose, and often the
792	   same function is used for both message authentication and PRF.

794	   Poly-1305 is not a suitable choice for a PRF.  Poly-1305 prohibits
795	   using the same key twice, whereas the PRF in IKEv2 is used multiple
796	   times with the same key.  Additionally, unlike HMAC, Poly-1305 is
797	   biased, so using it for key derivation would reduce the security of
798	   the symmetric encryption.

800	   Chacha20 could be used as a key-derivation function, by generating an
801	   arbitrarily long keystream.  However, that is not what protocols such
802	   as IKEv2 require.

804	   For this reason, this document does not specify a PRF, and recommends
805	   that crypto suites use some other PRF such as PRF_HMAC_SHA2_256
806	   (section 2.1.2 of [RFC4868])

808	2.8.  AEAD Construction

810	   AEAD_CHACHA20-POLY1305 is an authenticated encryption with additional
811	   data algorithm.  The inputs to AEAD_CHACHA20-POLY1305 are:

813	   o  A 256-bit key
814	   o  A 96-bit nonce - different for each invocation with the same key.
815	   o  An arbitrary length plaintext
816	   o  Arbitrary length additional authenticated data (AAD)

818	   Some protocols may have unique per-invocation inputs that are not
819	   96-bit in length.  For example, IPsec may specify a 64-bit nonce.  In
820	   such a case, it is up to the protocol document to define how to
821	   transform the protocol nonce into a 96-bit nonce, for example by
822	   concatenating a constant value.

824	   The ChaCha20 and Poly1305 primitives are combined into an AEAD that
825	   takes a 256-bit key and 96-bit nonce as follows:

827	   o  First, a Poly1305 one-time key is generated from the 256-bit key
828	      and nonce using the procedure described in Section 2.6.
829	   o  Next, the ChaCha20 encryption function is called to encrypt the
830	      plaintext, using the same key and nonce, and with the initial
831	      counter set to 1.
832	   o  Finally, the Poly1305 function is called with the Poly1305 key
833	      calculated above, and a message constructed as a concatenation of
834	      the following:

836	      *  The AAD
837	      *  padding1 - the padding is up to 15 zero bytes, and it brings
838	         the total length so far to an integral multiple of 16.  If the
839	         length of the AAD was already an integral multiple of 16 bytes,
840	         this field is zero-length.
841	      *  The ciphertext
842	      *  padding2 - the padding is up to 15 zero bytes, and it brings
843	         the total length so far to an integral multiple of 16.  If the
844	         length of the ciphertext was already an integral multiple of 16
845	         bytes, this field is zero-length.
846	      *  The length of the additional data in octets (as a 64-bit
847	         little-endian integer).
848	      *  The length of the ciphertext in octets (as a 64-bit little-
849	         endian integer).

851	   Decryption is pretty much the same thing.

853	   The output from the AEAD is twofold:

855	   o  A ciphertext of the same length as the plaintext.
856	   o  A 128-bit tag, which is the output of the Poly1305 function.

858	   A few notes about this design:

860	   1.  The amount of encrypted data possible in a single invocation is
861	       2^32-1 blocks of 64 bytes each, because of the size of the block
862	       counter field in the ChaCha20 block function.  This gives a total
863	       of 247,877,906,880 bytes, or nearly 256 GB.  This should be
864	       enough for traffic protocols such as IPsec and TLS, but may be
865	       too small for file and/or disk encryption.  For such uses, we can
866	       return to the original design, reduce the nonce to 64 bits, and
867	       use the integer at position 13 as the top 32 bits of a 64-bit
868	       block counter, increasing the total message size to over a
869	       million petabytes (1,180,591,620,717,411,303,360 bytes to be
870	       exact).
871	   2.  Despite the previous item, the ciphertext length field in the
872	       construction of the buffer on which Poly1305 runs limits the
873	       ciphertext (and hence, the plaintext) size to 2^64 bytes, or
874	       sixteen thousand petabytes (18,446,744,073,709,551,616 bytes to
875	       be exact).

877	   The AEAD construction in this section is a novel composition of
878	   ChaCha20 and Poly1305.  A security analysis of this composition is
879	   given in [Procter].

881	   Here is a list of the parameters for this construction as defined in
882	   Section 4 of RFC 5116:

884	   o  K_LEN (key length) is 32 octets.
885	   o  P_MAX (maximum size of the plaintext) is 247,877,906,880 bytes, or
886	      nearly 256 GB.
887	   o  A_MAX (maximum size of the associated data) is set to 2^64-1
888	      octets by the length field for associated data.
889	   o  N_MIN = N_MAX = 12 octets.
890	   o  C_MAX = P_MAX + tag length = 247,877,906,896 octets.

892	   Distinct AAD inputs (as described in section 3.3 of RFC 5116) shall
893	   be concatenated into a single input to AEAD_CHACHA20-POLY1305.  It is
894	   up to the application to create a structure in the AAD input if it is
895	   needed.

897	2.8.1.  Pseudo-Code for the AEAD Construction

899	      pad16(x):
900	         if (len(x) % 16)==0
901	            then return NULL
902	            else return copies(0, 16-(len(x)%16))
903	         end

905	      chacha20_aead_encrypt(aad, key, iv, constant, plaintext):
906	         otk = poly1305_key_gen(key, iv, constant)
907	         nonce = constant | iv
908	         ciphertext = chacha_encrypt(key, 1, nonce, plaintext)
909	         mac_data = aad | pad16(aad)
910	         mac_data |= ciphertext | pad16(ciphertext)
911	         mac_data |= num_to_4_le_bytes(aad.length)
912	         mac_data |= num_to_4_le_bytes(ciphertext.length)
913	         tag = poly1305_mac(mac_data, otk)
914	         return (ciphertext, tag)

916	2.8.2.  Example and Test Vector for AEAD_CHACHA20-POLY1305

918	   For a test vector, we will use the following inputs to the
919	   AEAD_CHACHA20-POLY1305 function:

921	  Plaintext:
922	  000  4c 61 64 69 65 73 20 61 6e 64 20 47 65 6e 74 6c  Ladies and Gentl
923	  016  65 6d 65 6e 20 6f 66 20 74 68 65 20 63 6c 61 73  emen of the clas
924	  032  73 20 6f 66 20 27 39 39 3a 20 49 66 20 49 20 63  s of '99: If I c
925	  048  6f 75 6c 64 20 6f 66 66 65 72 20 79 6f 75 20 6f  ould offer you o
926	  064  6e 6c 79 20 6f 6e 65 20 74 69 70 20 66 6f 72 20  nly one tip for
927	  080  74 68 65 20 66 75 74 75 72 65 2c 20 73 75 6e 73  the future, suns
928	  096  63 72 65 65 6e 20 77 6f 75 6c 64 20 62 65 20 69  creen would be i
929	  112  74 2e                                            t.

931	   AAD:
932	   000  50 51 52 53 c0 c1 c2 c3 c4 c5 c6 c7              PQRS........

934	  Key:
935	  000  80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f  ................
936	  016  90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f  ................

938	   IV:
939	   000  40 41 42 43 44 45 46 47                          @ABCDEFG

941	   32-bit fixed-common part:
942	   000  07 00 00 00                                      ....

944	   Set up for generating poly1305 one-time key (sender id=7):
945	       61707865  3320646e  79622d32  6b206574
946	       83828180  87868584  8b8a8988  8f8e8d8c
947	       93929190  97969594  9b9a9998  9f9e9d9c
948	       00000000  00000007  43424140  47464544

950	   After generating Poly1305 one-time key:
951	       252bac7b  af47b42d  557ab609  8455e9a4
952	       73d6e10a  ebd97510  7875932a  ff53d53e
953	       decc7ea2  b44ddbad  e49c17d1  d8430bc9
954	       8c94b7bc  8b7d4b4b  3927f67d  1669a432

956	  Poly1305 Key:
957	  000  7b ac 2b 25 2d b4 47 af 09 b6 7a 55 a4 e9 55 84  {.+%-.G...zU..U.
958	  016  0a e1 d6 73 10 75 d9 eb 2a 93 75 78 3e d5 53 ff  ...s.u..*.ux>.S.

960	  Poly1305 r =  455e9a4057ab6080f47b42c052bac7b
961	  Poly1305 s = ff53d53e7875932aebd9751073d6e10a

963	   Keystream bytes:
964	   9f:7b:e9:5d:01:fd:40:ba:15:e2:8f:fb:36:81:0a:ae:
965	   c1:c0:88:3f:09:01:6e:de:dd:8a:d0:87:55:82:03:a5:
966	   4e:9e:cb:38:ac:8e:5e:2b:b8:da:b2:0f:fa:db:52:e8:
967	   75:04:b2:6e:be:69:6d:4f:60:a4:85:cf:11:b8:1b:59:
968	   fc:b1:c4:5f:42:19:ee:ac:ec:6a:de:c3:4e:66:69:78:
969	   8e:db:41:c4:9c:a3:01:e1:27:e0:ac:ab:3b:44:b9:cf:
970	   5c:86:bb:95:e0:6b:0d:f2:90:1a:b6:45:e4:ab:e6:22:
971	   15:38

973	  Ciphertext:
974	  000  d3 1a 8d 34 64 8e 60 db 7b 86 af bc 53 ef 7e c2  ...4d.`.{...S.~.
975	  016  a4 ad ed 51 29 6e 08 fe a9 e2 b5 a7 36 ee 62 d6  ...Q)n......6.b.
976	  032  3d be a4 5e 8c a9 67 12 82 fa fb 69 da 92 72 8b  =..^..g....i..r.
977	  048  1a 71 de 0a 9e 06 0b 29 05 d6 a5 b6 7e cd 3b 36  .q.....)....~.;6
978	  064  92 dd bd 7f 2d 77 8b 8c 98 03 ae e3 28 09 1b 58  ....-w......(..X
979	  080  fa b3 24 e4 fa d6 75 94 55 85 80 8b 48 31 d7 bc  ..$...u.U...H1..
980	  096  3f f4 de f0 8e 4b 7a 9d e5 76 d2 65 86 ce c6 4b  ?....Kz..v.e...K
981	  112  61 16                                            a.

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

995	   Note the 4 zero bytes in line 000 and the 14 zero bytes in line 128

997	   Tag:
998	   1a:e1:0b:59:4f:09:e2:6a:7e:90:2e:cb:d0:60:06:91

1000	3.  Implementation Advice

1002	   Each block of ChaCha20 involves 16 move operations and one increment
1003	   operation for loading the state, 80 each of XOR, addition and Roll
1004	   operations for the rounds, 16 more add operations and 16 XOR
1005	   operations for protecting the plaintext.  Section 2.3 describes the
1006	   ChaCha block function as "adding the original input words".  This
1007	   implies that before starting the rounds on the ChaCha state, we copy
1008	   it aside, only to add it in later.  This is correct, but we can save
1009	   a few operations if we instead copy the state and do the work on the
1010	   copy.  This way, for the next block you don't need to recreate the
1011	   state, but only to increment the block counter.  This saves
1012	   approximately 5.5% of the cycles.

1014	   It is not recommended to use a generic big number library such as the
1015	   one in OpenSSL for the arithmetic operations in Poly1305.  Such
1016	   libraries use dynamic allocation to be able to handle any-sized
1017	   integer, but that flexibility comes at the expense of performance as
1018	   well as side-channel security.  More efficient implementations that
1019	   run in constant time are available, one of them in D.  J.
1020	   Bernstein's own library, NaCl ([NaCl]).  A constant-time but not
1021	   optimal approach would be to naively implement the arithmetic
1022	   operations for a 288-bit integers, because even a naive
1023	   implementation will not exceed 2^288 in the multiplication of
1024	   (acc+block) and r.  An efficient constant-time implementation can be
1025	   found in the public domain library poly1305-donna ([poly1305_donna]).

1027	4.  Security Considerations

1029	   The ChaCha20 cipher is designed to provide 256-bit security.

1031	   The Poly1305 authenticator is designed to ensure that forged messages
1032	   are rejected with a probability of 1-(n/(2^102)) for a 16n-byte
1033	   message, even after sending 2^64 legitimate messages, so it is SUF-
1034	   CMA in the terminology of [AE].

1036	   Proving the security of either of these is beyond the scope of this
1037	   document.  Such proofs are available in the referenced academic
1038	   papers ([chacha],[poly1305],[LatinDances], [LatinDances2], and
1039	   [Zhenqing2012])

1041	   The most important security consideration in implementing this draft
1042	   is the uniqueness of the nonce used in ChaCha20.  Counters and LFSRs
1043	   are both acceptable ways of generating unique nonces, as is
1044	   encrypting a counter using a 64-bit cipher such as DES.  Note that it
1045	   is not acceptable to use a truncation of a counter encrypted with a
1046	   128-bit or 256-bit cipher, because such a truncation may repeat after
1047	   a short time.

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

1054	   The Poly1305 key MUST be unpredictable to an attacker.  Randomly
1055	   generating the key would fulfill this requirement, except that
1056	   Poly1305 is often used in communications protocols, so the receiver
1057	   should know the key.  Pseudo-random number generation such as by
1058	   encrypting a counter is acceptable.  Using ChaCha with a secret key
1059	   and a nonce is also acceptable.

1061	   The algorithms presented here were designed to be easy to implement
1062	   in constant time to avoid side-channel vulnerabilities.  The
1063	   operations used in ChaCha20 are all additions, XORs, and fixed
1064	   rotations.  All of these can and should be implemented in constant
1065	   time.  Access to offsets into the ChaCha state and the number of
1066	   operations do not depend on any property of the key, eliminating the
1067	   chance of information about the key leaking through the timing of
1068	   cache misses.

1070	   For Poly1305, the operations are addition, multiplication and
1071	   modulus, all on >128-bit numbers.  This can be done in constant time,
1072	   but a naive implementation (such as using some generic big number
1073	   library) will not be constant time.  For example, if the
1074	   multiplication is performed as a separate operation from the modulus,
1075	   the result will sometimes be under 2^256 and some times be above
1076	   2^256.  Implementers should be careful about timing side-channels for
1077	   Poly1305 by using the appropriate implementation of these operations.

1079	5.  IANA Considerations

1081	   IANA is requested to assign an entry in the "Authenticated Encryption
1082	   with Associated Data (AEAD) Parameters" registry with
1083	   "AEAD_CHACHA20-POLY1305" as the name and this document as reference.

1085	6.  Acknowledgements

1087	   ChaCha20 and Poly1305 were invented by Daniel J.  Bernstein.  The
1088	   AEAD construction and the method of creating the one-time poly1305
1089	   key were invented by Adam Langley.

1091	   Thanks to Robert Ransom, Watson Ladd, Stefan Buhler, Dan Harkins, and
1092	   Kenny Paterson for their helpful comments and explanations.  Thanks
1093	   to Niels Moeller for suggesting the more efficient AEAD construction
1094	   in this document.  Special thanks to Ilari Liusvaara for providing
1095	   extra test vectors, helpful comments, and for being the first to
1096	   attempt an implementation from this draft.  And thanks to Sean
1097	   Parkinson for suggesting improvements to the examples and the pseudo-
1098	   code.

1100	   Special thanks goes to Gordon Procter for performing a security
1101	   analysis of the composition and publishing [Procter].

1103	7.  Changes from Previous Versions

1105	   NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION BEFORE PUBLICATION

1107	7.1.  Changes from version -01 to version -02

1109	   Added IANA considerations and a paragraph in the security
1110	   considerations detailing the consequences of repeating a nonce.

1112	   Added the pseudo-code.

1114	   Replaced the example of a quarterround in section 2.1

1116	7.2.  Changes from version -00 to version -01

1118	   Added references to [LatinDances2] and [Procter].

1120	   Added this section.

1122	7.3.  Changes from draft-nir-cfrg to draft-irtf-cfrg

1124	   Added references to [Zhenqing2012] and [LatinDances].

1126	   Many clarifications and improved terminology.

1128	   More test vectors from Illari.

1130	8.  References

1132	8.1.  Normative References

1134	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1135	              Requirement Levels", BCP 14, RFC 2119, March 1997.

1137	   [chacha]   Bernstein, D., "ChaCha, a variant of Salsa20", January
1138	              2008.

1140	   [poly1305]
1141	              Bernstein, D., "The Poly1305-AES message-authentication
1142	              code", March 2005.

1144	8.2.  Informative References

1146	   [AE]       Bellare, M. and C. Namprempre, "Authenticated Encryption:
1147	              Relations among notions and analysis of the generic
1148	              composition paradigm", December 2000,
1149	              <http://cseweb.ucsd.edu/~mihir/papers/oem.html>.

1151	   [FIPS-197]
1152	              National Institute of Standards and Technology, "Advanced
1153	              Encryption Standard (AES)", FIPS PUB 197, November 2001.

1155	   [FIPS-46]  National Institute of Standards and Technology, "Data
1156	              Encryption Standard", FIPS PUB 46-2, December 1993,
1157	              <http://www.itl.nist.gov/fipspubs/fip46-2.htm>.

1159	   [LatinDances]
1160	              Aumasson, J., Fischer, S., Khazaei, S., Meier, W., and C.
1161	              Rechberger, "New Features of Latin Dances: Analysis of
1162	              Salsa, ChaCha, and Rumba", December 2007.

1164	   [LatinDances2]
1165	              Ishiguro, T., Kiyomoto, S., and Y. Miyake, "Latin Dances
1166	              Revisited: New Analytic Results of Salsa20 and ChaCha",
1167	              February 2012.

1169	   [NaCl]     Bernstein, D., Lange, T., and P. Schwabe, "NaCl:
1170	              Networking and Cryptography library", July 2012,
1171	              <http://nacl.cace-project.eu/index.html>.

1173	   [Procter]  Procter, G., "A Security Analysis of the Composition of
1174	              ChaCha20 and Poly1305", August 2014.

1176	   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
1177	              384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.

1179	   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
1180	              Encryption", RFC 5116, January 2008.

1182	   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
1183	              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
1184	              5996, September 2010.

1186	   [Zhenqing2012]
1187	              Zhenqing, S., Bin, Z., Dengguo, F., and W. Wenling,
1188	              "Improved key recovery attacks on reduced-round salsa20
1189	              and chacha", 2012.

1191	   [poly1305_donna]
1192	              Floodyberry, A., "Poly1305-donna", February 2014,
1193	              <https://github.com/floodyberry/poly1305-donna>.

1195	   [standby-cipher]
1196	              McGrew, D., Grieco, A., and Y. Sheffer, "Selection of
1197	              Future Cryptographic Standards", draft-mcgrew-standby-
1198	              cipher (work in progress), January 2013.

1200	Appendix A.  Additional Test Vectors

1202	   The sub-sections of this appendix contain more test vectors for the
1203	   algorithms in the sub-sections of Section 2.

1205	A.1.  The ChaCha20 Block Functions
1206	  Test Vector #1:
1207	  ==============

1209	  Key:
1210	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1211	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1213	  Nonce:
1214	  000  00 00 00 00 00 00 00 00 00 00 00 00              ............

1216	  Block Counter = 0

1218	    ChaCha State at the end
1219	        ade0b876  903df1a0  e56a5d40  28bd8653
1220	        b819d2bd  1aed8da0  ccef36a8  c70d778b
1221	        7c5941da  8d485751  3fe02477  374ad8b8
1222	        f4b8436a  1ca11815  69b687c3  8665eeb2

1224	  Keystream:
1225	  000  76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28  v.....=.@]j.S..(
1226	  016  bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7  .........6...w..
1227	  032  da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37  .AY|QWH.w$.?..J7
1228	  048  6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86  jC.........i..e.

1230	  Test Vector #2:
1231	  ==============

1233	  Key:
1234	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1235	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1237	  Nonce:
1238	  000  00 00 00 00 00 00 00 00 00 00 00 00              ............

1240	  Block Counter = 1

1242	    ChaCha State at the end
1243	        bee7079f  7a385155  7c97ba98  0d082d73
1244	        a0290fcb  6965e348  3e53c612  ed7aee32
1245	        7621b729  434ee69c  b03371d5  d539d874
1246	        281fed31  45fb0a51  1f0ae1ac  6f4d794b

1248	  Keystream:
1249	  000  9f 07 e7 be 55 51 38 7a 98 ba 97 7c 73 2d 08 0d  ....UQ8z...|s-..
1250	  016  cb 0f 29 a0 48 e3 65 69 12 c6 53 3e 32 ee 7a ed  ..).H.ei..S>2.z.
1251	  032  29 b7 21 76 9c e6 4e 43 d5 71 33 b0 74 d8 39 d5  ).!v..NC.q3.t.9.
1252	  048  31 ed 1f 28 51 0a fb 45 ac e1 0a 1f 4b 79 4d 6f  1..(Q..E....KyMo
1253	  Test Vector #3:
1254	  ==============

1256	  Key:
1257	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1258	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  ................

1260	  Nonce:
1261	  000  00 00 00 00 00 00 00 00 00 00 00 00              ............

1263	  Block Counter = 1

1265	    ChaCha State at the end
1266	        2452eb3a  9249f8ec  8d829d9b  ddd4ceb1
1267	        e8252083  60818b01  f38422b8  5aaa49c9
1268	        bb00ca8e  da3ba7b4  c4b592d1  fdf2732f
1269	        4436274e  2561b3c8  ebdd4aa6  a0136c00

1271	  Keystream:
1272	  000  3a eb 52 24 ec f8 49 92 9b 9d 82 8d b1 ce d4 dd  :.R$..I.........
1273	  016  83 20 25 e8 01 8b 81 60 b8 22 84 f3 c9 49 aa 5a  . %....`."...I.Z
1274	  032  8e ca 00 bb b4 a7 3b da d1 92 b5 c4 2f 73 f2 fd  ......;...../s..
1275	  048  4e 27 36 44 c8 b3 61 25 a6 4a dd eb 00 6c 13 a0  N'6D..a%.J...l..

1277	  Test Vector #4:
1278	  ==============

1280	  Key:
1281	  000  00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1282	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1284	  Nonce:
1285	  000  00 00 00 00 00 00 00 00 00 00 00 00              ............

1287	  Block Counter = 2

1289	    ChaCha State at the end
1290	        fb4dd572  4bc42ef1  df922636  327f1394
1291	        a78dea8f  5e269039  a1bebbc1  caf09aae
1292	        a25ab213  48a6b46c  1b9d9bcb  092c5be6
1293	        546ca624  1bec45d5  87f47473  96f0992e

1295	  Keystream:
1296	  000  72 d5 4d fb f1 2e c4 4b 36 26 92 df 94 13 7f 32  r.M....K6&.....2
1297	  016  8f ea 8d a7 39 90 26 5e c1 bb be a1 ae 9a f0 ca  ....9.&^........
1298	  032  13 b2 5a a2 6c b4 a6 48 cb 9b 9d 1b e6 5b 2c 09  ..Z.l..H.....[,.
1299	  048  24 a6 6c 54 d5 45 ec 1b 73 74 f4 87 2e 99 f0 96  $.lT.E..st......

1301	  Test Vector #5:
1302	  ==============

1304	  Key:
1305	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1306	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1308	  Nonce:
1309	  000  00 00 00 00 00 00 00 00 00 00 00 02              ............

1311	  Block Counter = 0

1313	    ChaCha State at the end
1314	        374dc6c2  3736d58c  b904e24a  cd3f93ef
1315	        88228b1a  96a4dfb3  5b76ab72  c727ee54
1316	        0e0e978a  f3145c95  1b748ea8  f786c297
1317	        99c28f5f  628314e8  398a19fa  6ded1b53

1319	  Keystream:
1320	  000  c2 c6 4d 37 8c d5 36 37 4a e2 04 b9 ef 93 3f cd  ..M7..67J.....?.
1321	  016  1a 8b 22 88 b3 df a4 96 72 ab 76 5b 54 ee 27 c7  ..".....r.v[T.'.
1322	  032  8a 97 0e 0e 95 5c 14 f3 a8 8e 74 1b 97 c2 86 f7  .....\....t.....
1323	  048  5f 8f c2 99 e8 14 83 62 fa 19 8a 39 53 1b ed 6d  _......b...9S..m

1325	A.2.  ChaCha20 Encryption
1326	  Test Vector #1:
1327	  ==============

1329	  Key:
1330	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1331	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1333	  Nonce:
1334	  000  00 00 00 00 00 00 00 00 00 00 00 00              ............

1336	  Initial Block Counter = 0

1338	  Plaintext:
1339	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1340	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1341	  032  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1342	  048  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1344	  Ciphertext:
1345	  000  76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28  v.....=.@]j.S..(
1346	  016  bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7  .........6...w..
1347	  032  da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37  .AY|QWH.w$.?..J7
1348	  048  6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86  jC.........i..e.

1350	  Test Vector #2:
1351	  ==============

1353	  Key:
1354	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1355	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  ................

1357	  Nonce:
1358	  000  00 00 00 00 00 00 00 00 00 00 00 02              ............

1360	  Initial Block Counter = 1

1362	  Plaintext:
1363	  000  41 6e 79 20 73 75 62 6d 69 73 73 69 6f 6e 20 74  Any submission t
1364	  016  6f 20 74 68 65 20 49 45 54 46 20 69 6e 74 65 6e  o the IETF inten
1365	  032  64 65 64 20 62 79 20 74 68 65 20 43 6f 6e 74 72  ded by the Contr
1366	  048  69 62 75 74 6f 72 20 66 6f 72 20 70 75 62 6c 69  ibutor for publi
1367	  064  63 61 74 69 6f 6e 20 61 73 20 61 6c 6c 20 6f 72  cation as all or
1368	  080  20 70 61 72 74 20 6f 66 20 61 6e 20 49 45 54 46   part of an IETF
1369	  096  20 49 6e 74 65 72 6e 65 74 2d 44 72 61 66 74 20   Internet-Draft
1370	  112  6f 72 20 52 46 43 20 61 6e 64 20 61 6e 79 20 73  or RFC and any s
1371	  128  74 61 74 65 6d 65 6e 74 20 6d 61 64 65 20 77 69  tatement made wi
1372	  144  74 68 69 6e 20 74 68 65 20 63 6f 6e 74 65 78 74  thin the context
1373	  160  20 6f 66 20 61 6e 20 49 45 54 46 20 61 63 74 69   of an IETF acti
1374	  176  76 69 74 79 20 69 73 20 63 6f 6e 73 69 64 65 72  vity is consider
1375	  192  65 64 20 61 6e 20 22 49 45 54 46 20 43 6f 6e 74  ed an "IETF Cont
1376	  208  72 69 62 75 74 69 6f 6e 22 2e 20 53 75 63 68 20  ribution". Such
1377	  224  73 74 61 74 65 6d 65 6e 74 73 20 69 6e 63 6c 75  statements inclu
1378	  240  64 65 20 6f 72 61 6c 20 73 74 61 74 65 6d 65 6e  de oral statemen
1379	  256  74 73 20 69 6e 20 49 45 54 46 20 73 65 73 73 69  ts in IETF sessi
1380	  272  6f 6e 73 2c 20 61 73 20 77 65 6c 6c 20 61 73 20  ons, as well as
1381	  288  77 72 69 74 74 65 6e 20 61 6e 64 20 65 6c 65 63  written and elec
1382	  304  74 72 6f 6e 69 63 20 63 6f 6d 6d 75 6e 69 63 61  tronic communica
1383	  320  74 69 6f 6e 73 20 6d 61 64 65 20 61 74 20 61 6e  tions made at an
1384	  336  79 20 74 69 6d 65 20 6f 72 20 70 6c 61 63 65 2c  y time or place,
1385	  352  20 77 68 69 63 68 20 61 72 65 20 61 64 64 72 65   which are addre
1386	  368  73 73 65 64 20 74 6f                             ssed to

1388	  Ciphertext:
1389	  000  a3 fb f0 7d f3 fa 2f de 4f 37 6c a2 3e 82 73 70  ...}../.O7l.>.sp
1390	  016  41 60 5d 9f 4f 4f 57 bd 8c ff 2c 1d 4b 79 55 ec  A`].OOW...,.KyU.
1391	  032  2a 97 94 8b d3 72 29 15 c8 f3 d3 37 f7 d3 70 05  *....r)....7..p.
1392	  048  0e 9e 96 d6 47 b7 c3 9f 56 e0 31 ca 5e b6 25 0d  ....G...V.1.^.%.
1393	  064  40 42 e0 27 85 ec ec fa 4b 4b b5 e8 ea d0 44 0e  @B.'....KK....D.
1394	  080  20 b6 e8 db 09 d8 81 a7 c6 13 2f 42 0e 52 79 50   ........./B.RyP
1395	  096  42 bd fa 77 73 d8 a9 05 14 47 b3 29 1c e1 41 1c  B..ws....G.)..A.
1396	  112  68 04 65 55 2a a6 c4 05 b7 76 4d 5e 87 be a8 5a  h.eU*....vM^...Z
1397	  128  d0 0f 84 49 ed 8f 72 d0 d6 62 ab 05 26 91 ca 66  ...I..r..b..&..f
1398	  144  42 4b c8 6d 2d f8 0e a4 1f 43 ab f9 37 d3 25 9d  BK.m-....C..7.%.
1399	  160  c4 b2 d0 df b4 8a 6c 91 39 dd d7 f7 69 66 e9 28  ......l.9...if.(
1400	  176  e6 35 55 3b a7 6c 5c 87 9d 7b 35 d4 9e b2 e6 2b  .5U;.l\..{5....+
1401	  192  08 71 cd ac 63 89 39 e2 5e 8a 1e 0e f9 d5 28 0f  .q..c.9.^.....(.
1402	  208  a8 ca 32 8b 35 1c 3c 76 59 89 cb cf 3d aa 8b 6c  ..2.5.<vY...=..l
1403	  224  cc 3a af 9f 39 79 c9 2b 37 20 fc 88 dc 95 ed 84  .:..9y.+7 ......
1404	  240  a1 be 05 9c 64 99 b9 fd a2 36 e7 e8 18 b0 4b 0b  ....d....6....K.
1405	  256  c3 9c 1e 87 6b 19 3b fe 55 69 75 3f 88 12 8c c0  ....k.;.Uiu?....
1406	  272  8a aa 9b 63 d1 a1 6f 80 ef 25 54 d7 18 9c 41 1f  ...c..o..%T...A.
1407	  288  58 69 ca 52 c5 b8 3f a3 6f f2 16 b9 c1 d3 00 62  Xi.R..?.o......b
1408	  304  be bc fd 2d c5 bc e0 91 19 34 fd a7 9a 86 f6 e6  ...-.....4......
1409	  320  98 ce d7 59 c3 ff 9b 64 77 33 8f 3d a4 f9 cd 85  ...Y...dw3.=....
1410	  336  14 ea 99 82 cc af b3 41 b2 38 4d d9 02 f3 d1 ab  .......A.8M.....
1411	  352  7a c6 1d d2 9c 6f 21 ba 5b 86 2f 37 30 e3 7c fd  z....o!.[./70.|.
1412	  368  c4 fd 80 6c 22 f2 21                             ...l".!
1413	  Test Vector #3:
1414	  ==============

1416	  Key:
1417	  000  1c 92 40 a5 eb 55 d3 8a f3 33 88 86 04 f6 b5 f0  ..@..U...3......
1418	  016  47 39 17 c1 40 2b 80 09 9d ca 5c bc 20 70 75 c0  G9..@+....\. pu.

1420	  Nonce:
1421	  000  00 00 00 00 00 00 00 00 00 00 00 02              ............

1423	  Initial Block Counter = 42

1425	  Plaintext:
1426	  000  27 54 77 61 73 20 62 72 69 6c 6c 69 67 2c 20 61  'Twas brillig, a
1427	  016  6e 64 20 74 68 65 20 73 6c 69 74 68 79 20 74 6f  nd the slithy to
1428	  032  76 65 73 0a 44 69 64 20 67 79 72 65 20 61 6e 64  ves.Did gyre and
1429	  048  20 67 69 6d 62 6c 65 20 69 6e 20 74 68 65 20 77   gimble in the w
1430	  064  61 62 65 3a 0a 41 6c 6c 20 6d 69 6d 73 79 20 77  abe:.All mimsy w
1431	  080  65 72 65 20 74 68 65 20 62 6f 72 6f 67 6f 76 65  ere the borogove
1432	  096  73 2c 0a 41 6e 64 20 74 68 65 20 6d 6f 6d 65 20  s,.And the mome
1433	  112  72 61 74 68 73 20 6f 75 74 67 72 61 62 65 2e     raths outgrabe.

1435	  Ciphertext:
1436	  000  62 e6 34 7f 95 ed 87 a4 5f fa e7 42 6f 27 a1 df  b.4....._..Bo'..
1437	  016  5f b6 91 10 04 4c 0d 73 11 8e ff a9 5b 01 e5 cf  _....L.s....[...
1438	  032  16 6d 3d f2 d7 21 ca f9 b2 1e 5f b1 4c 61 68 71  .m=..!...._.Lahq
1439	  048  fd 84 c5 4f 9d 65 b2 83 19 6c 7f e4 f6 05 53 eb  ...O.e...l....S.
1440	  064  f3 9c 64 02 c4 22 34 e3 2a 35 6b 3e 76 43 12 a6  ..d.."4.*5k>vC..
1441	  080  1a 55 32 05 57 16 ea d6 96 25 68 f8 7d 3f 3f 77  .U2.W....%h.}??w
1442	  096  04 c6 a8 d1 bc d1 bf 4d 50 d6 15 4b 6d a7 31 b1  .......MP..Km.1.
1443	  112  87 b5 8d fd 72 8a fa 36 75 7a 79 7a c1 88 d1     ....r..6uzyz...

1445	A.3.  Poly1305 Message Authentication Code

1447	   Notice how in test vector #2 r is equal to zero.  The part of the
1448	   Poly1305 algorithm where the accumulator is multiplied by r means
1449	   that with r equal zero, the tag will be equal to s regardless of the
1450	   content of the Text.  Fortunately, all the proposed methods of
1451	   generating r are such that getting this particular weak key is very
1452	   unlikely.

1454	  Test Vector #1:
1455	  ==============

1457	  One-time Poly1305 Key:
1458	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1459	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1461	  Text to MAC:
1462	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1463	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1464	  032  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1465	  048  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1467	  Tag:
1468	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1470	  Test Vector #2:
1471	  ==============

1473	  One-time Poly1305 Key:
1474	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1475	  016  36 e5 f6 b5 c5 e0 60 70 f0 ef ca 96 22 7a 86 3e  6.....`p...."z.>

1477	  Text to MAC:
1478	  000  41 6e 79 20 73 75 62 6d 69 73 73 69 6f 6e 20 74  Any submission t
1479	  016  6f 20 74 68 65 20 49 45 54 46 20 69 6e 74 65 6e  o the IETF inten
1480	  032  64 65 64 20 62 79 20 74 68 65 20 43 6f 6e 74 72  ded by the Contr
1481	  048  69 62 75 74 6f 72 20 66 6f 72 20 70 75 62 6c 69  ibutor for publi
1482	  064  63 61 74 69 6f 6e 20 61 73 20 61 6c 6c 20 6f 72  cation as all or
1483	  080  20 70 61 72 74 20 6f 66 20 61 6e 20 49 45 54 46   part of an IETF
1484	  096  20 49 6e 74 65 72 6e 65 74 2d 44 72 61 66 74 20   Internet-Draft
1485	  112  6f 72 20 52 46 43 20 61 6e 64 20 61 6e 79 20 73  or RFC and any s
1486	  128  74 61 74 65 6d 65 6e 74 20 6d 61 64 65 20 77 69  tatement made wi
1487	  144  74 68 69 6e 20 74 68 65 20 63 6f 6e 74 65 78 74  thin the context
1488	  160  20 6f 66 20 61 6e 20 49 45 54 46 20 61 63 74 69   of an IETF acti
1489	  176  76 69 74 79 20 69 73 20 63 6f 6e 73 69 64 65 72  vity is consider
1490	  192  65 64 20 61 6e 20 22 49 45 54 46 20 43 6f 6e 74  ed an "IETF Cont
1491	  208  72 69 62 75 74 69 6f 6e 22 2e 20 53 75 63 68 20  ribution". Such
1492	  224  73 74 61 74 65 6d 65 6e 74 73 20 69 6e 63 6c 75  statements inclu
1493	  240  64 65 20 6f 72 61 6c 20 73 74 61 74 65 6d 65 6e  de oral statemen
1494	  256  74 73 20 69 6e 20 49 45 54 46 20 73 65 73 73 69  ts in IETF sessi
1495	  272  6f 6e 73 2c 20 61 73 20 77 65 6c 6c 20 61 73 20  ons, as well as
1496	  288  77 72 69 74 74 65 6e 20 61 6e 64 20 65 6c 65 63  written and elec
1497	  304  74 72 6f 6e 69 63 20 63 6f 6d 6d 75 6e 69 63 61  tronic communica
1498	  320  74 69 6f 6e 73 20 6d 61 64 65 20 61 74 20 61 6e  tions made at an
1499	  336  79 20 74 69 6d 65 20 6f 72 20 70 6c 61 63 65 2c  y time or place,
1500	  352  20 77 68 69 63 68 20 61 72 65 20 61 64 64 72 65   which are addre
1501	  368  73 73 65 64 20 74 6f                             ssed to

1503	  Tag:
1504	  000  36 e5 f6 b5 c5 e0 60 70 f0 ef ca 96 22 7a 86 3e  6.....`p...."z.>
1505	  Test Vector #3:
1506	  ==============

1508	  One-time Poly1305 Key:
1509	  000  36 e5 f6 b5 c5 e0 60 70 f0 ef ca 96 22 7a 86 3e  6.....`p...."z.>
1510	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1512	  Text to MAC:
1513	  000  41 6e 79 20 73 75 62 6d 69 73 73 69 6f 6e 20 74  Any submission t
1514	  016  6f 20 74 68 65 20 49 45 54 46 20 69 6e 74 65 6e  o the IETF inten
1515	  032  64 65 64 20 62 79 20 74 68 65 20 43 6f 6e 74 72  ded by the Contr
1516	  048  69 62 75 74 6f 72 20 66 6f 72 20 70 75 62 6c 69  ibutor for publi
1517	  064  63 61 74 69 6f 6e 20 61 73 20 61 6c 6c 20 6f 72  cation as all or
1518	  080  20 70 61 72 74 20 6f 66 20 61 6e 20 49 45 54 46   part of an IETF
1519	  096  20 49 6e 74 65 72 6e 65 74 2d 44 72 61 66 74 20   Internet-Draft
1520	  112  6f 72 20 52 46 43 20 61 6e 64 20 61 6e 79 20 73  or RFC and any s
1521	  128  74 61 74 65 6d 65 6e 74 20 6d 61 64 65 20 77 69  tatement made wi
1522	  144  74 68 69 6e 20 74 68 65 20 63 6f 6e 74 65 78 74  thin the context
1523	  160  20 6f 66 20 61 6e 20 49 45 54 46 20 61 63 74 69   of an IETF acti
1524	  176  76 69 74 79 20 69 73 20 63 6f 6e 73 69 64 65 72  vity is consider
1525	  192  65 64 20 61 6e 20 22 49 45 54 46 20 43 6f 6e 74  ed an "IETF Cont
1526	  208  72 69 62 75 74 69 6f 6e 22 2e 20 53 75 63 68 20  ribution". Such
1527	  224  73 74 61 74 65 6d 65 6e 74 73 20 69 6e 63 6c 75  statements inclu
1528	  240  64 65 20 6f 72 61 6c 20 73 74 61 74 65 6d 65 6e  de oral statemen
1529	  256  74 73 20 69 6e 20 49 45 54 46 20 73 65 73 73 69  ts in IETF sessi
1530	  272  6f 6e 73 2c 20 61 73 20 77 65 6c 6c 20 61 73 20  ons, as well as
1531	  288  77 72 69 74 74 65 6e 20 61 6e 64 20 65 6c 65 63  written and elec
1532	  304  74 72 6f 6e 69 63 20 63 6f 6d 6d 75 6e 69 63 61  tronic communica
1533	  320  74 69 6f 6e 73 20 6d 61 64 65 20 61 74 20 61 6e  tions made at an
1534	  336  79 20 74 69 6d 65 20 6f 72 20 70 6c 61 63 65 2c  y time or place,
1535	  352  20 77 68 69 63 68 20 61 72 65 20 61 64 64 72 65   which are addre
1536	  368  73 73 65 64 20 74 6f                             ssed to

1538	  Tag:
1539	  000  f3 47 7e 7c d9 54 17 af 89 a6 b8 79 4c 31 0c f0  .G~|.T.....yL1..

1541	  Test Vector #4:
1542	  ==============

1544	  One-time Poly1305 Key:
1545	  000  1c 92 40 a5 eb 55 d3 8a f3 33 88 86 04 f6 b5 f0  ..@..U...3......
1546	  016  47 39 17 c1 40 2b 80 09 9d ca 5c bc 20 70 75 c0  G9..@+....\. pu.

1548	  Text to MAC:
1549	  000  27 54 77 61 73 20 62 72 69 6c 6c 69 67 2c 20 61  'Twas brillig, a
1550	  016  6e 64 20 74 68 65 20 73 6c 69 74 68 79 20 74 6f  nd the slithy to
1551	  032  76 65 73 0a 44 69 64 20 67 79 72 65 20 61 6e 64  ves.Did gyre and
1552	  048  20 67 69 6d 62 6c 65 20 69 6e 20 74 68 65 20 77   gimble in the w
1553	  064  61 62 65 3a 0a 41 6c 6c 20 6d 69 6d 73 79 20 77  abe:.All mimsy w
1554	  080  65 72 65 20 74 68 65 20 62 6f 72 6f 67 6f 76 65  ere the borogove
1555	  096  73 2c 0a 41 6e 64 20 74 68 65 20 6d 6f 6d 65 20  s,.And the mome
1556	  112  72 61 74 68 73 20 6f 75 74 67 72 61 62 65 2e     raths outgrabe.

1558	  Tag:
1559	  000  45 41 66 9a 7e aa ee 61 e7 08 dc 7c bc c5 eb 62  EAf.~..a...|...b

1561	   Test Vector #5: If one uses 130-bit partial reduction, does the code
1562	   handle the case where partially reduced final result is not fully
1563	   reduced?

1565	   R:
1566	   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1567	   S:
1568	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1569	   data:
1570	   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1571	   tag:
1572	   03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

1574	   Test Vector #6: What happens if addition of s overflows modulo 2^128?

1576	   R:
1577	   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1578	   S:
1579	   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1580	   data:
1581	   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1582	   tag:
1583	   03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1584	   Test Vector #7: What happens if data limb is all ones and there is
1585	   carry from lower limb?

1587	   R:
1588	   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1589	   S:
1590	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1591	   data:
1592	   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1593	   F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1594	   11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1595	   tag:
1596	   05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

1598	   Test Vector #8: What happens if final result from polynomial part is
1599	   exactly 2^130-5?

1601	   R:
1602	   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1603	   S:
1604	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1605	   data:
1606	   FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1607	   FB FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE
1608	   01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
1609	   tag:
1610	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

1612	   Test Vector #9: What happens if final result from polynomial part is
1613	   exactly 2^130-6?

1615	   R:
1616	   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1617	   S:
1618	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1619	   data:
1620	   FD FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1621	   tag:
1622	   FA FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1623	   Test Vector #10: What happens if 5*H+L-type reduction produces
1624	   131-bit intermediate result?

1626	   R:
1627	   01 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
1628	   S:
1629	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1630	   data:
1631	   E3 35 94 D7 50 5E 43 B9 00 00 00 00 00 00 00 00
1632	   33 94 D7 50 5E 43 79 CD 01 00 00 00 00 00 00 00
1633	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1634	   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1635	   tag:
1636	   14 00 00 00 00 00 00 00 55 00 00 00 00 00 00 00

1638	   Test Vector #11: What happens if 5*H+L-type reduction produces
1639	   131-bit final result?

1641	   R:
1642	   01 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
1643	   S:
1644	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1645	   data:
1646	   E3 35 94 D7 50 5E 43 B9 00 00 00 00 00 00 00 00
1647	   33 94 D7 50 5E 43 79 CD 01 00 00 00 00 00 00 00
1648	   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1649	   tag:
1650	   13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

1652	A.4.  Poly1305 Key Generation Using ChaCha20

1654	  Test Vector #1:
1655	  ==============

1657	  The key:
1658	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1659	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

1661	  The nonce:
1662	  000  00 00 00 00 00 00 00 00 00 00 00 00              ............

1664	  Poly1305 one-time key:
1665	  000  76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28  v.....=.@]j.S..(
1666	  016  bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7  .........6...w..

1668	  Test Vector #2:
1669	  ==============

1671	  The key:
1672	  000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
1673	  016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  ................

1675	  The nonce:
1676	  000  00 00 00 00 00 00 00 00 00 00 00 02              ............

1678	  Poly1305 one-time key:
1679	  000  ec fa 25 4f 84 5f 64 74 73 d3 cb 14 0d a9 e8 76  ..%O._dts......v
1680	  016  06 cb 33 06 6c 44 7b 87 bc 26 66 dd e3 fb b7 39  ..3.lD{..&f....9

1682	  Test Vector #3:
1683	  ==============

1685	  The key:
1686	  000  1c 92 40 a5 eb 55 d3 8a f3 33 88 86 04 f6 b5 f0  ..@..U...3......
1687	  016  47 39 17 c1 40 2b 80 09 9d ca 5c bc 20 70 75 c0  G9..@+....\. pu.

1689	  The nonce:
1690	  000  00 00 00 00 00 00 00 00 00 00 00 02              ............

1692	  Poly1305 one-time key:
1693	  000  96 5e 3b c6 f9 ec 7e d9 56 08 08 f4 d2 29 f9 4b  .^;...~.V....).K
1694	  016  13 7f f2 75 ca 9b 3f cb dd 59 de aa d2 33 10 ae  ...u..?..Y...3..

1696	A.5.  ChaCha20-Poly1305 AEAD Decryption

1698	   Below we'll see decrypting a message.  We receive a ciphertext, a
1699	   nonce, and a tag.  We know the key.  We will check the tag, and then
1700	   (assuming that it validates) decrypt the ciphertext.  In this
1701	   particular protocol, we'll assume that there is no padding of the
1702	   plaintext.

1704	  The key:
1705	  000  1c 92 40 a5 eb 55 d3 8a f3 33 88 86 04 f6 b5 f0  ..@..U...3......
1706	  016  47 39 17 c1 40 2b 80 09 9d ca 5c bc 20 70 75 c0  G9..@+....\. pu.

1708	  Ciphertext:
1709	  000  64 a0 86 15 75 86 1a f4 60 f0 62 c7 9b e6 43 bd  d...u...`.b...C.
1710	  016  5e 80 5c fd 34 5c f3 89 f1 08 67 0a c7 6c 8c b2  ^.\.4\....g..l..
1711	  032  4c 6c fc 18 75 5d 43 ee a0 9e e9 4e 38 2d 26 b0  Ll..u]C....N8-&.
1712	  048  bd b7 b7 3c 32 1b 01 00 d4 f0 3b 7f 35 58 94 cf  ...<2.....;.5X..
1713	  064  33 2f 83 0e 71 0b 97 ce 98 c8 a8 4a bd 0b 94 81  3/..q......J....
1714	  080  14 ad 17 6e 00 8d 33 bd 60 f9 82 b1 ff 37 c8 55  ...n..3.`....7.U
1715	  096  97 97 a0 6e f4 f0 ef 61 c1 86 32 4e 2b 35 06 38  ...n...a..2N+5.8
1716	  112  36 06 90 7b 6a 7c 02 b0 f9 f6 15 7b 53 c8 67 e4  6..{j|.....{S.g.
1717	  128  b9 16 6c 76 7b 80 4d 46 a5 9b 52 16 cd e7 a4 e9  ..lv{.MF..R.....
1718	  144  90 40 c5 a4 04 33 22 5e e2 82 a1 b0 a0 6c 52 3e  .@...3"^.....lR>
1719	  160  af 45 34 d7 f8 3f a1 15 5b 00 47 71 8c bc 54 6a  .E4..?..[.Gq..Tj
1720	  176  0d 07 2b 04 b3 56 4e ea 1b 42 22 73 f5 48 27 1a  ..+..VN..B"s.H'.
1721	  192  0b b2 31 60 53 fa 76 99 19 55 eb d6 31 59 43 4e  ..1`S.v..U..1YCN
1722	  208  ce bb 4e 46 6d ae 5a 10 73 a6 72 76 27 09 7a 10  ..NFm.Z.s.rv'.z.
1723	  224  49 e6 17 d9 1d 36 10 94 fa 68 f0 ff 77 98 71 30  I....6...h..w.q0
1724	  240  30 5b ea ba 2e da 04 df 99 7b 71 4d 6c 6f 2c 29  0[.......{qMlo,)
1725	  256  a6 ad 5c b4 02 2b 02 70 9b                       ..\..+.p.

1727	  The nonce:
1728	  000  00 00 00 00 01 02 03 04 05 06 07 08              ............

1730	  The AAD:
1731	  000  f3 33 88 86 00 00 00 00 00 00 4e 91              .3........N.

1733	  Received Tag:
1734	  000  ee ad 9d 67 89 0c bb 22 39 23 36 fe a1 85 1f 38  ...g..."9#6....8
1735	   First, we calculate the one-time Poly1305 key

1737	  @@@  ChaCha state with key set up
1738	        61707865  3320646e  79622d32  6b206574
1739	        a540921c  8ad355eb  868833f3  f0b5f604
1740	        c1173947  09802b40  bc5cca9d  c0757020
1741	        00000000  00000000  04030201  08070605

1743	  @@@  ChaCha state after 20 rounds
1744	        a94af0bd  89dee45c  b64bb195  afec8fa1
1745	        508f4726  63f554c0  1ea2c0db  aa721526
1746	        11b1e514  a0bacc0f  828a6015  d7825481
1747	        e8a4a850  d9dcbbd6  4c2de33a  f8ccd912

1749	  @@@ out bytes:
1750	  bd:f0:4a:a9:5c:e4:de:89:95:b1:4b:b6:a1:8f:ec:af:
1751	  26:47:8f:50:c0:54:f5:63:db:c0:a2:1e:26:15:72:aa

1753	  Poly1305 one-time key:
1754	  000  bd f0 4a a9 5c e4 de 89 95 b1 4b b6 a1 8f ec af  ..J.\.....K.....
1755	  016  26 47 8f 50 c0 54 f5 63 db c0 a2 1e 26 15 72 aa  &G.P.T.c....&.r.

1757	   Next, we construct the AEAD buffer

1759	  Poly1305 Input:
1760	  000  f3 33 88 86 00 00 00 00 00 00 4e 91 00 00 00 00  .3........N.....
1761	  016  64 a0 86 15 75 86 1a f4 60 f0 62 c7 9b e6 43 bd  d...u...`.b...C.
1762	  032  5e 80 5c fd 34 5c f3 89 f1 08 67 0a c7 6c 8c b2  ^.\.4\....g..l..
1763	  048  4c 6c fc 18 75 5d 43 ee a0 9e e9 4e 38 2d 26 b0  Ll..u]C....N8-&.
1764	  064  bd b7 b7 3c 32 1b 01 00 d4 f0 3b 7f 35 58 94 cf  ...<2.....;.5X..
1765	  080  33 2f 83 0e 71 0b 97 ce 98 c8 a8 4a bd 0b 94 81  3/..q......J....
1766	  096  14 ad 17 6e 00 8d 33 bd 60 f9 82 b1 ff 37 c8 55  ...n..3.`....7.U
1767	  112  97 97 a0 6e f4 f0 ef 61 c1 86 32 4e 2b 35 06 38  ...n...a..2N+5.8
1768	  128  36 06 90 7b 6a 7c 02 b0 f9 f6 15 7b 53 c8 67 e4  6..{j|.....{S.g.
1769	  144  b9 16 6c 76 7b 80 4d 46 a5 9b 52 16 cd e7 a4 e9  ..lv{.MF..R.....
1770	  160  90 40 c5 a4 04 33 22 5e e2 82 a1 b0 a0 6c 52 3e  .@...3"^.....lR>
1771	  176  af 45 34 d7 f8 3f a1 15 5b 00 47 71 8c bc 54 6a  .E4..?..[.Gq..Tj
1772	  192  0d 07 2b 04 b3 56 4e ea 1b 42 22 73 f5 48 27 1a  ..+..VN..B"s.H'.
1773	  208  0b b2 31 60 53 fa 76 99 19 55 eb d6 31 59 43 4e  ..1`S.v..U..1YCN
1774	  224  ce bb 4e 46 6d ae 5a 10 73 a6 72 76 27 09 7a 10  ..NFm.Z.s.rv'.z.
1775	  240  49 e6 17 d9 1d 36 10 94 fa 68 f0 ff 77 98 71 30  I....6...h..w.q0
1776	  256  30 5b ea ba 2e da 04 df 99 7b 71 4d 6c 6f 2c 29  0[.......{qMlo,)
1777	  272  a6 ad 5c b4 02 2b 02 70 9b 00 00 00 00 00 00 00  ..\..+.p........
1778	  288  0c 00 00 00 00 00 00 00 09 01 00 00 00 00 00 00  ................

1780	   We calculate the Poly1305 tag and find that it matches

1782	  Calculated Tag:
1783	  000  ee ad 9d 67 89 0c bb 22 39 23 36 fe a1 85 1f 38  ...g..."9#6....8

1785	   Finally, we decrypt the ciphertext

1787	  Plaintext::
1788	  000  49 6e 74 65 72 6e 65 74 2d 44 72 61 66 74 73 20  Internet-Drafts
1789	  016  61 72 65 20 64 72 61 66 74 20 64 6f 63 75 6d 65  are draft docume
1790	  032  6e 74 73 20 76 61 6c 69 64 20 66 6f 72 20 61 20  nts valid for a
1791	  048  6d 61 78 69 6d 75 6d 20 6f 66 20 73 69 78 20 6d  maximum of six m
1792	  064  6f 6e 74 68 73 20 61 6e 64 20 6d 61 79 20 62 65  onths and may be
1793	  080  20 75 70 64 61 74 65 64 2c 20 72 65 70 6c 61 63   updated, replac
1794	  096  65 64 2c 20 6f 72 20 6f 62 73 6f 6c 65 74 65 64  ed, or obsoleted
1795	  112  20 62 79 20 6f 74 68 65 72 20 64 6f 63 75 6d 65   by other docume
1796	  128  6e 74 73 20 61 74 20 61 6e 79 20 74 69 6d 65 2e  nts at any time.
1797	  144  20 49 74 20 69 73 20 69 6e 61 70 70 72 6f 70 72   It is inappropr
1798	  160  69 61 74 65 20 74 6f 20 75 73 65 20 49 6e 74 65  iate to use Inte
1799	  176  72 6e 65 74 2d 44 72 61 66 74 73 20 61 73 20 72  rnet-Drafts as r
1800	  192  65 66 65 72 65 6e 63 65 20 6d 61 74 65 72 69 61  eference materia
1801	  208  6c 20 6f 72 20 74 6f 20 63 69 74 65 20 74 68 65  l or to cite the
1802	  224  6d 20 6f 74 68 65 72 20 74 68 61 6e 20 61 73 20  m other than as
1803	  240  2f e2 80 9c 77 6f 72 6b 20 69 6e 20 70 72 6f 67  /...work in prog
1804	  256  72 65 73 73 2e 2f e2 80 9d                       ress./...

1806	Authors' Addresses

1808	   Yoav Nir
1809	   Check Point Software Technologies Ltd.
1810	   5 Hasolelim st.
1811	   Tel Aviv  6789735
1812	   Israel

1814	   Email: ynir.ietf@gmail.com

1816	   Adam Langley
1817	   Google Inc

1819	   Email: agl@google.com