One document matched: draft-nir-cfrg-chacha20-poly1305-03.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-nir-cfrg-chacha20-poly1305-03" category="info" submissionType="IRTF">
<front>
<title abbrev="ChaCha20 & Poly1305">ChaCha20 and Poly1305 for IETF protocols</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>6789735</code>
<country>Israel</country>
</postal>
<email>ynir.ietf@gmail.com</email>
</address>
</author>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization>Google Inc</organization>
<address>
<email>agl@google.com</email>
</address>
</author>
<date year="2014"/>
<keyword>Internet-Draft</keyword>
<abstract>
<t> 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 Additional Data (AEAD) algorithm.</t>
<t> This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> The Advanced Encryption Standard (AES - <xref target="FIPS-197"/>) has become the gold standard in encryption. Its efficient design, wide implementation, and hardware support allow for high performance in many areas. On most modern platforms, AES is anywhere from 4x to 10x as fast as the previous most-used cipher, 3-key Data Encryption Standard (3DES - <xref target="FIPS-46"/>), which makes it not only the best choice, but the only practical choice.</t>
<t> The problem is that 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 re-configure implementations to use 3DES. <xref target="standby-cipher"/> describes this issue and the need for a standby cipher in greater detail.</t>
<t> This document defines such a standby cipher. We use ChaCha20 (<xref target="chacha"/>) with or without the Poly1305 (<xref target="poly1305"/>) authenticator. These algorithms are not just fast and secure. They are fast even in software-only C-language implementations, allowing for much quicker deployment when compared with algorithms such as AES that are significantly accelerated by hardware implementations.</t>
<t> These document does not introduce these new algorithms. 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.</t>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<t>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 <xref target="RFC2119"/>.</t>
<t> 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 DJB'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 to martices relate to vectors (using the C language convention of zero being the index origin).<figure>
<artwork><![CDATA[
0 1 2 3
4 5 6 7
8 9 10 11
12 13 14 15
]]></artwork>
</figure>The elements in this vector or matrix are 32-bit unsigned integers.</t>
<t> The algorithm name is "ChaCha". "ChaCha20" is a specific instance where 20 "rounds" (or 80 quarter rounds - see <xref target="qround"/>) 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.</t>
</section>
</section>
<section anchor="algs" title="The Algorithms">
<t> The subsections below describe the algorithms used and the AEAD construction.</t>
<section anchor="qround" title="The ChaCha Quarter Round">
<t> 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): <list style="symbols">
<t>a += b; d ^= a; d <<<= 16;</t>
<t>c += d; b ^= c; b <<<= 12;</t>
<t>a += b; d ^= a; d <<<= 8;</t>
<t>c += d; b ^= c; b <<<= 7;</t></list>Where "+" denotes integer addition without carry, "^" denotes a bitwise XOR, and "<<< n" denotes an n-bit left rotation (towards the high bits).</t>
<t> For example, let's see the add, XOR and roll operations from the first line with sample numbers: <list style="symbols">
<t> b = 0x01020304</t>
<t> a = 0x11111111</t>
<t> d = 0x01234567 </t>
<t> a = a + b = 0x11111111 + 0x01020304 = 0x12131415</t>
<t> d = d ^ a = 0x01234567 ^ 0x12131415 = 0x13305172</t>
<t> d = d<<<16 = 0x51721330</t></list></t>
<section anchor="qround_tv" title="Test Vector for the ChaCha Quarter Round">
<t> For a test vector, we will use the same numbers as in the example, adding something random for c.<list style="symbols">
<t> a = 0x11111111</t>
<t> b = 0x01020304</t>
<t> c = 0x9b8d6f43</t>
<t> d = 0x01234567</t></list></t>
<t> After running a Quarter Round on these 4 numbers, we get these:<list style="symbols">
<t> a = 0xea2a92f4</t>
<t> b = 0xcb1cf8ce</t>
<t> c = 0x4581472e</t>
<t> d = 0x5881c4bb</t></list></t>
</section>
</section>
<section anchor="qround_chacha" title="A Quarter Round on the ChaCha State">
<t>The ChaCha state does not have 4 integer numbers, but 16. So the quarter round operation works on only 4 of them - hence the name. Each quarter round operates on 4 pre-determined numbers in the ChaCha state. We will denote by QUATERROUND(x,y,z,w) a quarter-round operation on the numbers at indexes 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:<figure>
<artwork><![CDATA[
0 *a 2 3
4 *b 6 7
8 *c 10 11
12 *d 14 15
]]></artwork>
</figure>Note that this run of quarter round is part of what is called a "column round".</t>
<section anchor="qround_chacha_tv" title="Test Vector for the Quarter Round on the ChaCha state">
<t> For a test vector, we will use a ChaCha state that was generated randomly:<figure>
<preamble>Sample ChaCha State</preamble><artwork><![CDATA[
879531e0 c5ecf37d 516461b1 c9a62f8a
44c20ef3 3390af7f d9fc690b 2a5f714c
53372767 b00a5631 974c541a 359e9963
5c971061 3d631689 2098d9d6 91dbd320
]]></artwork>
</figure></t>
<t> 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":<figure>
<preamble>After applying QUARTERROUND(2,7,8,13)</preamble><artwork><![CDATA[
879531e0 c5ecf37d bdb886dc c9a62f8a
44c20ef3 3390af7f d9fc690b cfacafd2
e46bea80 b00a5631 974c541a 359e9963
5c971061 ccc07c79 2098d9d6 91dbd320
]]></artwork><postamble>Note that only the numbers in positions 2, 7, 8, and 13 changed.</postamble>
</figure></t>
</section>
</section>
<section anchor="chacha_block" title="The ChaCha20 block Function">
<t> The ChaCha block function transforms a ChaCha state by running multiple quarter rounds.</t>
<t> The inputs to ChaCha20 are: <list style="symbols">
<t> A 256-bit key, treated as a concatenation of 8 32-bit little-endian integers.</t>
<t> A 96-bit nonce, treated as a concatenation of 3 32-bit little-endian integers.</t>
<t> A 32-bit block count parameter, treated as a 32-bit little-endian integer.</t></list></t>
<t> The output is 64 random-looking bytes.</t>
<t> 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.</t>
<t> 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 <xref target="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.</t>
<t> The ChaCha20 state is initialized as follows: <list style="symbols">
<t> The first 4 words (0-3) are constants: 0x61707865, 0x3320646e, 0x79622d32, 0x6b206574.</t>
<t> The next 8 words (4-11) are taken from the 256-bit key by reading the bytes in little-endian order, in 4-byte chunks.</t>
<t> Word 12 is a block counter. Since each block is 64-byte, a 32-bit word is enough for 256 Gigabytes of data.</t>
<t> 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.</t></list><figure>
<artwork><![CDATA[
cccccccc cccccccc cccccccc cccccccc
kkkkkkkk kkkkkkkk kkkkkkkk kkkkkkkk
kkkkkkkk kkkkkkkk kkkkkkkk kkkkkkkk
bbbbbbbb nnnnnnnn nnnnnnnn nnnnnnnn
]]></artwork><postamble>c=constant k=key b=blockcount n=nonce</postamble></figure></t>
<t> ChaCha20 runs 20 rounds, alternating between "column" and "diagonal" rounds. Each round is 4 quarter-rounds, and they are run as follows. Rounds 1-4 are part of the "column" round, while 5-8 are part of the "diagonal" round:<list style="numbers">
<t> QUARTERROUND ( 0, 4, 8,12)</t>
<t> QUARTERROUND ( 1, 5, 9,13)</t>
<t> QUARTERROUND ( 2, 6,10,14)</t>
<t> QUARTERROUND ( 3, 7,11,15)</t>
<t> QUARTERROUND ( 0, 5,10,15)</t>
<t> QUARTERROUND ( 1, 6,11,12)</t>
<t> QUARTERROUND ( 2, 7, 8,13)</t>
<t> QUARTERROUND ( 3, 4, 9,14)</t></list></t>
<t> At the end of 20 rounds, the original input words are added to the output words, and the result is serialized by sequencing the words one-by-one in little-endian order.</t>
<section anchor="chacha_block_tv" title="Test Vector for the ChaCha20 Block Function">
<t> For a test vector, we will use the following inputs to the ChaCha20 block function:<list style="symbols">
<t> 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.</t>
<t> Nonce = (00:00:00:09:00:00:00:4a:00:00:00:00)</t>
<t> Block Count = 1.</t></list></t>
<t> After setting up the ChaCha state, it looks like this:<figure>
<preamble>ChaCha State with the key set up.</preamble><artwork><![CDATA[
61707865 3320646e 79622d32 6b206574
03020100 07060504 0b0a0908 0f0e0d0c
13121110 17161514 1b1a1918 1f1e1d1c
00000001 09000000 4a000000 00000000
]]></artwork>
</figure></t>
<t> After running 20 rounds (10 column rounds interleaved with 10 diagonal rounds), the ChaCha state looks like this:<figure>
<preamble>ChaCha State after 20 rounds</preamble><artwork><![CDATA[
837778ab e238d763 a67ae21e 5950bb2f
c4f2d0c7 fc62bb2f 8fa018fc 3f5ec7b7
335271c2 f29489f3 eabda8fc 82e46ebd
d19c12b4 b04e16de 9e83d0cb 4e3c50a2
]]></artwork>
</figure></t>
<t> Finally we add the original state to the result (simple vector or matrix addition), giving this:<figure>
<preamble>ChaCha State at the end of the ChaCha20 operation</preamble><artwork><![CDATA[
e4e7f110 15593bd1 1fdd0f50 c47120a3
c7f4d1c7 0368c033 9aaa2204 4e6cd4c3
466482d2 09aa9f07 05d7c214 a2028bd9
d19c12b5 b94e16de e883d0cb 4e3c50a2
]]></artwork>
</figure></t>
<t> After we serialize the state, we get this:<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="chacha20" title="The ChaCha20 encryption algorithm">
<t> ChaCha20 is a stream cipher designed by D. J. Bernstein. It is a refinement of the Salsa20 algorithm, and uses a 256-bit key.</t>
<t> ChaCha20 successively calls the ChaCha20 block function, with the same key and nonce, and with successively increasing block counter parameters. The resulting state is then serialized by writing the numbers in little-endian order, creating a key-stream block. Concatenating the key-stream blocks from the successive blocks forms a key stream, which is then XOR-ed with the plaintext. Alternatively, each key-stream block can be XOR-ed 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.</t>
<t> The inputs to ChaCha20 are: <list style="symbols">
<t> A 256-bit key</t>
<t> A 32-bit initial counter. This can be set to any number, but will usually be zero or one. It makes sense to use 1 if we use the zero block for something else, such as generating a one-time authenticator key as part of an AEAD algorithm.</t>
<t> A 96-bit nonce. In some protocols, this is known as the Initialization Vector.</t>
<t> an arbitrary-length plaintext</t></list></t>
<t> The output is an encrypted message of the same length.</t>
<t> Decryption is done in the same way. The ChaCha20 block function is used to expand the key into a key stream, which is XOR-ed with the ciphertext giving back the plaintext.</t>
<section anchor="chacha20_tv" title="Example and Test Vector for the ChaCha20 Cipher">
<t> For a test vector, we will use the following inputs to the ChaCha20 block function:<list style="symbols">
<t> 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.</t>
<t> Nonce = (00:00:00:00:00:00:00:4a:00:00:00:00).</t>
<t> Initial Counter = 1.</t></list></t>
<t> 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):<figure>
<artwork><![CDATA[
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.
]]></artwork>
</figure></t>
<t> The following figure shows 4 ChaCha state matrices:<list style="numbers">
<t> First block as it is set up.</t>
<t> Second block as it is set up. Note that these blocks are only two bits apart - only the counter in position 12 is different.</t>
<t> Third block is the first block after the ChaCha20 block operation.</t>
<t> Final block is the second block after the ChaCha20 block operation was applied.</t></list>After that, we show the keystream.<figure>
<artwork><![CDATA[
First block setup:
61707865 3320646e 79622d32 6b206574
03020100 07060504 0b0a0908 0f0e0d0c
13121110 17161514 1b1a1918 1f1e1d1c
00000001 00000000 4a000000 00000000
]]></artwork>
</figure><figure>
<artwork><![CDATA[
Second block setup:
61707865 3320646e 79622d32 6b206574
03020100 07060504 0b0a0908 0f0e0d0c
13121110 17161514 1b1a1918 1f1e1d1c
00000002 00000000 4a000000 00000000
]]></artwork>
</figure><figure>
<artwork><![CDATA[
First block after block operation:
f3514f22 e1d91b40 6f27de2f ed1d63b8
821f138c e2062c3d ecca4f7e 78cff39e
a30a3b8a 920a6072 cd7479b5 34932bed
40ba4c79 cd343ec6 4c2c21ea b7417df0
]]></artwork>
</figure><figure>
<artwork><![CDATA[
Second block after block operation:
9f74a669 410f633f 28feca22 7ec44dec
6d34d426 738cb970 3ac5e9f3 45590cc4
da6e8b39 892c831a cdea67c1 2b7e1d90
037463f3 a11a2073 e8bcfb88 edc49139
]]></artwork>
</figure><figure>
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
<t> Finally, we XOR the Keystream with the plaintext, yielding the Ciphertext:<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="_poly1305" title="The Poly1305 algorithm">
<t> 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.</t>
<t> The original article (<xref target="poly1305"/>) is entitled "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.". </t>
<t> 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):<list style="symbols">
<t> r[3], r[7], r[11], and r[15] are required to have their top four bits clear (be smaller than 16)</t>
<t> r[4], r[8], and r[12] are required to have their bottom two bits clear (be divisible by 4)</t></list></t>
<t> The following sample code clamps "r" to be appropriate:<figure>
<artwork><![CDATA[
/*
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;
}
]]></artwork>
</figure></t>
<t> 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-bit, pseudo-randomly generating them (see <xref target="poly_key_chacha"/>) is also acceptable.</t>
<t> The inputs to Poly1305 are:<list style="symbols">
<t> A 256-bit one-time key</t>
<t> An arbitrary length message </t></list></t>
<t> The output is a 128-bit tag.</t>
<t> First, the "r" value should be clamped.</t>
<t> Next, set the constant prime "P" be 2^130-5: 3fffffffffffffffffffffffffffffffb. Also set a variable "accumulator" to zero.</t>
<t> Next, divide the message into 16-byte blocks. The last one might be shorter:<list style="symbols">
<t>Read the block as a little-endian number.</t>
<t>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.</t>
<t>If the block is not 17 bytes long (the last block), pad it with zeros. This is meaningless if you're treating it them as numbers.</t>
<t>Add this number to the accumulator.</t>
<t>Multiply by "r"</t>
<t>Set the accumulator to the result modulo p. To summarize: Acc = ((Acc+block)*r) % p.</t></list></t>
<t>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.</t>
<section anchor="poly1305_tv" title="Poly1305 Example and Test Vector">
<t> For our example, we will dispense with generating the one-time key using AES, and assume that we got the following keying material:<list style="symbols">
<t> Key Material: 85:d6:be:78:57:55:6d:33:7f:44:52:fe:42:d5:06:a8:01:03:80:8a:fb:0d:b2:fd:4a:bf:f6:af:41:49:f5:1b</t>
<t> s as an octet string: 01:03:80:8a:fb:0d:b2:fd:4a:bf:f6:af:41:49:f5:1b</t>
<t> s as a 128-bit number: 1bf54941aff6bf4afdb20dfb8a800301</t>
<t> r before clamping: 85:d6:be:78:57:55:6d:33:7f:44:52:fe:42:d5:06:a8</t>
<t> Clamped r as a number: 806d5400e52447c036d555408bed685.</t></list></t>
<t> For our message, we'll use a short text:<figure>
<artwork><![CDATA[
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
]]></artwork></figure></t>
<t>Since Poly1305 works in 16-byte chunks, the 34-byte message divides into 3 blocks. In the following calculation, "Acc" denotes the accumulator and "Block" the current block:<figure>
<preamble>Block #1</preamble><artwork><![CDATA[
Acc = 00
Block = 6f4620636968706172676f7470797243
Block with 0x01 byte = 016f4620636968706172676f7470797243
Acc + block = 016f4620636968706172676f7470797243
(Acc+Block) * r =
b83fe991ca66800489155dcd69e8426ba2779453994ac90ed284034da565ecf
Acc = ((Acc+Block)*r) % P = 2c88c77849d64ae9147ddeb88e69c83fc
]]></artwork>
</figure><figure>
<preamble>Block #2</preamble><artwork><![CDATA[
Acc = 2c88c77849d64ae9147ddeb88e69c83fc
Block = 6f7247206863726165736552206d7572
Block with 0x01 byte = 016f7247206863726165736552206d7572
Acc + block = 437febea505c820f2ad5150db0709f96e
(Acc+Block) * r =
21dcc992d0c659ba4036f65bb7f88562ae59b32c2b3b8f7efc8b00f78e548a26
Acc = ((Acc+Block)*r) % P = 2d8adaf23b0337fa7cccfb4ea344b30de
]]></artwork>
</figure><figure>
<preamble>Last Block</preamble><artwork><![CDATA[
Acc = 2d8adaf23b0337fa7cccfb4ea344b30de
Block = 7075
Block with 0x01 byte = 017075
Acc + block = 2d8adaf23b0337fa7cccfb4ea344ca153
(Acc + Block) * r =
16d8e08a0f3fe1de4fe4a15486aca7a270a29f1e6c849221e4a6798b8e45321f
((Acc + Block) * r) % P = 28d31b7caff946c77c8844335369d03a7
]]></artwork>
</figure></t>
<t>Adding s we get this number, and serialize if to get the tag:<figure>
<artwork><![CDATA[
Acc + s = 2a927010caf8b2bc2c6365130c11d06a8
Tag: a8:06:1d:c1:30:51:36:c6:c2:2b:8b:af:0c:01:27:a9
]]></artwork></figure></t>
</section>
</section>
<section anchor="poly_key_chacha" title="Generating the Poly1305 key using ChaCha20">
<t> As said in <xref target="_poly1305"/>, it is acceptable to generate the one-time Poly1305 pseudo-randomly. This section proposes such a method.</t>
<t> To generate such a key pair (r,s), we will use the ChaCha20 block function described in <xref target="chacha_block"/>. This assumes that we have a 256-bit session key for the MAC function, such as SK_ai and SK_ar in IKEv2 (<xref target="RFC5996"/>), the integrity key in ESP and 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.</t>
<t> The method is to call the block function with the following parameters:<list style="symbols">
<t> The 256-bit session integrity key is used as the ChaCha20 key.</t>
<t> The block counter is set to zero.</t>
<t> 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 an 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 sender, 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.</t></list></t>
<t> 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.</t>
<t> 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.</t>
<section anchor="poly_key_chacha_tv" title="Poly1305 Key Generation Test Vector">
<t> For this example, we'll set: </t>
<figure>
<artwork><![CDATA[
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 ................
]]></artwork></figure><figure>
<artwork><![CDATA[
Nonce:
000 00 00 00 00 00 01 02 03 04 05 06 07 ............
]]></artwork></figure><figure>
<artwork><![CDATA[
The ChaCha state set up with key, nonce, and block counter zero:
61707865 3320646e 79622d32 6b206574
83828180 87868584 8b8a8988 8f8e8d8c
93929190 97969594 9b9a9998 9f9e9d9c
00000000 00000000 03020100 07060504
]]></artwork></figure><figure>
<artwork><![CDATA[
The ChaCha state after 20 rounds:
8ba0d58a cc815f90 27405081 7194b24a
37b633a8 a50dfde3 e2b8db08 46a6d1fd
7da03782 9183a233 148ad271 b46773d1
3cc1875a 8607def1 ca5c3086 7085eb87
]]></artwork></figure><figure>
<artwork><![CDATA[
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
]]></artwork></figure>
<t> And that output is also the 32-byte one-time key used for Poly1305.</t>
</section>
</section>
<section anchor="polyprf" title="A Pseudo-Random Function for ChaCha/Poly-1305 based Crypto Suites">
<t> Some protocols such as IKEv2(<xref target="RFC5996"/>) require a Pseudo-Random Function (PRF), mostly for key derivation. In the IKEv2 definition, a PRF is a function that accepts a variable-length key and a variable-length input, and returns a fixed-length output. This section does not specify such a function.</t>
<t> Poly-1305 is an obvious choice, because MAC functions are often used as PRFs. However, Poly-1305 prohibits using the same key twice, whereas the PRF in IKEv2 is used multiple times with the same key. This issue can be solved by adding a nonce or a counter to Poly-1305, much as we do when using this function as a MAC, but that would require changing the interface for the PRF function.</t>
<t> 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.</t>
<t> 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 (section 2.1.2 of <xref target="RFC4868"/>)</t>
</section>
<section anchor="aead" title="AEAD Construction">
<t> Note: Much of the content of this document, including this AEAD construction is taken from Adam Langley's draft (<xref target="agl-draft"/>) for the use of these algorithms in TLS. The AEAD construction described here is called AEAD_CHACHA20-POLY1305.</t>
<t> AEAD_CHACHA20-POLY1305 is an authenticated encryption with additional data algorithm. The inputs to AEAD_CHACHA20-POLY1305 are:<list style="symbols">
<t> A 256-bit key </t>
<t> A 96-bit nonce - different for each invocation with the same key.</t>
<t> An arbitrary length plaintext</t>
<t> Arbitrary length additional data</t></list></t>
<t> The ChaCha20 and Poly1305 primitives are combined into an AEAD that takes a 256-bit key and 64-bit IV as follows:<list style="symbols">
<t> First the 96-bit nonce is constructed by prepending a 32-bit constant value to the IV. This could be set to zero, or could be derived from keying material, or could be assigned to a sender. It is up to the specific protocol to define the source for that 32-bit value.</t>
<t> Next, a Poly1305 one-time key is generated from the 256-bit key and nonce using the procedure described in <xref target="poly_key_chacha"/>.</t>
<t> The ChaCha20 encryption function is called to encrypt the plaintext, using the same key and nonce, and with the initial counter set to 1.</t>
<t> The Poly1305 function is called with the Poly1305 key calculated above, and a message constructed as a concatenation of the following:<list>
<t> The additional data</t>
<t> The length of the additional data in octets (as a 64-bit little-endian integer). TBD: bit count rather than octets? network order?</t>
<t> The ciphertext</t>
<t> The length of the ciphertext in octets (as a 64-bit little-endian integer). TBD: bit count rather than octets? network order?</t></list></t> </list></t>
<t> Decryption is pretty much the same thing.</t>
<t>The output from the AEAD is twofold:<list style="symbols">
<t> A ciphertext of the same length as the plaintext.</t>
<t> A 128-bit tag, which is the output of the Poly1305 function.</t></list></t>
<t> A few notes about this design:<list style="numbers">
<t> The amount of encrypted data possible in a single invocation is 2^32-1 blocks of 64 bytes each, for a total of 247,877,906,880 bytes, or nearly 256 GB. This should be 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).</t>
<t> 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).</t></list></t>
<section anchor="aead_tv" title="Example and Test Vector for AEAD_CHACHA20-POLY1305">
<t> For a test vector, we will use the following inputs to the AEAD_CHACHA20-POLY1305 function:<figure>
<artwork><![CDATA[
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.
]]></artwork></figure><figure>
<artwork><![CDATA[
AAD:
000 50 51 52 53 c0 c1 c2 c3 c4 c5 c6 c7 PQRS........
]]></artwork></figure><figure>
<artwork><![CDATA[
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|................
]]></artwork></figure><figure>
<artwork><![CDATA[
IV:
000 40 41 42 43 44 45 46 47 @ABCDEFG
]]></artwork></figure><figure>
<artwork><![CDATA[
32-bit fixed-common part:
000 07 00 00 00 ....
]]></artwork></figure><figure>
<artwork><![CDATA[
Set up 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
]]></artwork></figure><figure>
<artwork><![CDATA[
After generating Poly1305 one-time key:
252bac7b af47b42d 557ab609 8455e9a4
73d6e10a ebd97510 7875932a ff53d53e
decc7ea2 b44ddbad e49c17d1 d8430bc9
8c94b7bc 8b7d4b4b 3927f67d 1669a432
]]></artwork></figure><figure>
<artwork><![CDATA[
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
]]></artwork></figure><figure>
<artwork><![CDATA[
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
]]></artwork></figure><figure>
<artwork><![CDATA[
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.
]]></artwork></figure><figure>
<artwork><![CDATA[
AEAD Construction for Poly1305:
000 50 51 52 53 c0 c1 c2 c3 c4 c5 c6 c7 0c 00 00 00|PQRS............
016 00 00 00 00 d3 1a 8d 34 64 8e 60 db 7b 86 af bc|.......4d.`.{...
032 53 ef 7e c2 a4 ad ed 51 29 6e 08 fe a9 e2 b5 a7|S.~....Q)n......
048 36 ee 62 d6 3d be a4 5e 8c a9 67 12 82 fa fb 69|6.b.=..^..g....i
064 da 92 72 8b 1a 71 de 0a 9e 06 0b 29 05 d6 a5 b6|..r..q.....)....
080 7e cd 3b 36 92 dd bd 7f 2d 77 8b 8c 98 03 ae e3|~.;6...-w......
096 28 09 1b 58 fa b3 24 e4 fa d6 75 94 55 85 80 8b|(..X..$...u.U...
112 48 31 d7 bc 3f f4 de f0 8e 4b 7a 9d e5 76 d2 65|H1..?....Kz..v.e
128 86 ce c6 4b 61 16 72 00 00 00 00 00 00 00 |...Ka.r.......
]]></artwork></figure><figure>
<artwork><![CDATA[
Tag:
18:fb:11:a5:03:1a:d1:3a:7e:3b:03:d4:6e:e3:a6:a7
]]></artwork></figure></t>
</section>
</section>
</section>
<section anchor="advice" title="Implementation Advice">
<t> 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. <xref target="chacha_block"/> describes the ChaCha block function as "adding the original input words". This implies that before starting the rounds on the ChaCha state, it is copied aside only to be added in later. This would be correct, but it saves a few operations to 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.</t>
<t> 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 any-sized integer, 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 DJB's own library, NaCl (<xref target="NaCl"/>). A constant-time but not optimal approach would be to naively implement the arithmetic operations for a 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 (<xref target="poly1305_donna"/>).</t>
</section>
<section anchor="security" title="Security Considerations">
<t> The ChaCha20 cipher is designed to provide 256-bit security.</t>
<t> 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 in the terminology of <xref target="AE"/>.</t>
<t> Proving the security of either of these is beyond the scope of this document. Such proofs are available in the referenced academic papers.</t>
<t> The most important security consideration in implementing this draft is the uniqueness of the nonce used in ChaCha20. Counters and LFSRs are both acceptable ways of generating unique nonces, as is 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.</t>
<t> 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. Pseudo-random number generation such as by encrypting a counter is acceptable. Using ChaCha with a secret key and a nonce is also acceptable.</t>
<t> 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.</t>
<t> For Poly1305, the operations are addition, multiplication and modulus, all on >128-bit numbers. 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 some times be under 2^256 and some times be above 2^256. Implementers should be careful about timing side-channels for Poly1305 by using the appropriate implementation of these operations.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> There are no IANA considerations for this document.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t> 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.</t>
<t> Thanks to Robert Ransom and Ilari Liusvaara for their helpful comments and explanations.</t>
</section>
<!-- ======================= TODOs ==========================================
Here are things we need to do:
* If we want this to be used in IKE (as opposed to ESP) we'll need a PRF.
ChaCha20 would be a great PRF, but what RFC 5996 requires is something
with a fixed-length output, so basically a MAC. However, RFC 5996
requires that the key be variable-length. One way is to use Poly1305
and preferring a 256-bit key. If the key is not 256-bit, we SHA2-256 it
into 256 bits. I'm not so happy about adding SHA2-256 into this.
-->
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='16553' target='http://tools.ietf.org/html/rfc2119' />
</reference>
<reference anchor='chacha'>
<front>
<title>ChaCha, a variant of Salsa20</title>
<author initials='D.J' surname='Bernstein' fullname='Daniel J Bernstein'>
<organization>The University of Illinois at Chicago</organization>
</author>
<date month='Jan' day='28' year='2008' />
</front>
<format type='PDF' target='http://cr.yp.to/chacha/chacha-20080128.pdf' />
</reference>
<reference anchor='poly1305'>
<front>
<title>The Poly1305-AES message-authentication code</title>
<author initials='D.J' surname='Bernstein' fullname='Daniel J Bernstein'>
<organization>The University of Illinois at Chicago</organization>
</author>
<date month='Mar' day='29' year='2005' />
</front>
<format type='PDF' target='http://cr.yp.to/mac/poly1305-20050329.pdf' />
</reference>
</references>
<references title="Informative References">
<reference anchor="FIPS-197">
<front>
<title>Advanced Encryption Standard (AES)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="November" year="2001" />
</front>
<seriesInfo name="FIPS" value="PUB 197" />
<format type='PDF' target='http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf' />
</reference>
<reference anchor="FIPS-46" target="http://www.itl.nist.gov/fipspubs/fip46-2.htm">
<front>
<title>Data Encryption Standard</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="December" year="1993" />
</front>
<seriesInfo name="FIPS" value="PUB 46-2" />
</reference>
<reference anchor="standby-cipher">
<front>
<title>Selection of Future Cryptographic Standards</title>
<author initials='D' surname='McGrew' fullname='David McGrew'>
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials='A' surname='Grieco' fullname='Anthony Grieco'>
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials='Y' surname='Sheffer' fullname='Yaron Sheffer'>
<organization>Porticor</organization>
</author>
</front>
<seriesInfo name="Internet-Draft" value="draft-mcgrew-standby-cipher" />
<format type="HTML" target="http://tools.ietf.org/html/draft-mcgrew-standby-cipher-00" />
</reference>
<reference anchor="agl-draft">
<front>
<title>ChaCha20 and Poly1305 based Cipher Suites for TLS</title>
<author initials="A" surname="Langley" fullname="Adam Langley">
<organization/>
</author>
<author initials="W" surname="Chang" fullname="Wan-Teh Chang">
<organization/>
</author>
<date month="November" day="22" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-agl-tls-chacha20poly1305-04"/>
<format type="HTML" target="http://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.html"/>
</reference>
<reference anchor="AE" target="http://cseweb.ucsd.edu/~mihir/papers/oem.html">
<front>
<title>Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm</title>
<author initials="M." surname="Bellare"/>
<author initials="C." surname="Namprempre"/>
</front>
</reference>
<reference anchor="NaCl" target="http://nacl.cace-project.eu/index.html">
<front>
<title>NaCl: Networking and Cryptography library</title>
<author initials="D.J" surname="Bernstein" fullname="Daniel J. Bernstein"/>
<author initials="T" surname="Lange" fullname="Tanja Lange"/>
<author initials="P" surname="Schwabe" fullname="Peter Schwabe"/>
</front>
</reference>
<reference anchor="poly1305_donna" target="https://github.com/floodyberry/poly1305-donna">
<front>
<title>Poly1305-donna</title>
<author initials="A.M" surname="Floodyberry" fullname="Andrew M. Floodyberry"/>
</front>
</reference>
<reference anchor="RFC5116">
<front>
<title>An Interface and Algorithms for Authenticated Encryption</title>
<author initials='D' surname='McGrew' fullname='David McGrew'>
<organization>Cisco Systems, Inc.</organization>
</author>
<date year="2008" month="January"/>
</front>
<seriesInfo name="RFC" value="5116"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc5116.txt"/>
<format type="HTML" target="http://tools.ietf.org/html/rfc5116"/>
</reference>
<reference anchor="RFC4868">
<front>
<title>Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec</title>
<author initials="S." surname="Kelly" fullname="Scott G. Kelly">
<organization>Aruba Networks</organization>
</author>
<author initials="S." surname="Frankel" fullname="Sheila Frankel">
<organization>NIST</organization>
</author>
<date year="2007" month="May"/>
</front>
<seriesInfo name="RFC" value="4868"/>
<format type="HTML" target="http://tools.ietf.org/html/rfc4868"/>
</reference>
<reference anchor="RFC5996">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author initials="C." surname="Kaufman" fullname="C. Kaufman">
<organization/>
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization/>
</author>
<author initials="Y." surname="Nir" fullname="Y. Nir">
<organization/>
</author>
<author initials="P." surname="Eronen" fullname="P. Eronen">
<organization/>
</author>
<date year="2010" month="September"/>
</front>
<seriesInfo name="RFC" value="5996"/>
<format type="TXT" octets="346466" target="http://www.rfc-editor.org/rfc/rfc5996.txt"/>
</reference>
</references>
<!-- ====================================================================== -->
<section anchor="test_vectors" title="Additional Test Vectors">
<t> The sub-sections of this appendix contain more test vectors for the algorithms in the sub-sections of <xref target="algs"/>. </t>
<section anchor="appAblock" title="The ChaCha20 Block Functions">
<t><figure>
<artwork><![CDATA[
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.
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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..
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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......
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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
]]></artwork></figure></t>
</section>
<section anchor="testv_chacha" title="ChaCha20 Encryption">
<t><figure>
<artwork><![CDATA[
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.
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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
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".!
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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...
]]></artwork></figure></t>
</section>
<section anchor="testv_poly1305" title="Poly1305 Message Authentication Code">
<t> 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.</t>
<t><figure>
<artwork><![CDATA[
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 ................
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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.>
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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..
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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
]]></artwork></figure></t>
</section>
<section anchor="testv_poly_keygen" title="Poly1305 Key Generation Using ChaCha20">
<t><figure>
<artwork><![CDATA[
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..
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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
]]></artwork></figure></t>
<t><figure>
<artwork><![CDATA[
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..
]]></artwork></figure></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:42:19 |