idnits 2.17.1 draft-nir-ipsecme-chacha20-poly1305-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2014) is 3749 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Experimental January 21, 2014 5 Expires: July 25, 2014 7 ChaCha20 and Poly1305 and their use in IPsec 8 draft-nir-ipsecme-chacha20-poly1305-00 10 Abstract 12 This document describes the use of the ChaCha20 stream cipher in 13 IPsec, as well as the use of the Poly1305 authenticator, both as 14 stand-alone algorithms, and as a combined mode AEAD algorithm. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 25, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 52 2. The Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. The ChaCha20 block function . . . . . . . . . . . . . . . 3 54 2.2. The ChaCha20 encryption algorithm . . . . . . . . . . . . 4 55 2.3. The Poly1305 algorithm . . . . . . . . . . . . . . . . . . 5 56 2.4. AEAD Construction . . . . . . . . . . . . . . . . . . . . 5 57 3. Algorithms for ESP & AH . . . . . . . . . . . . . . . . . . . 6 58 3.1. ENCR_ChaCha20 for ESP . . . . . . . . . . . . . . . . . . 6 59 3.2. AUTH_Poly1305 for ESP and AH . . . . . . . . . . . . . . . 7 60 3.3. ESP_ChaCha20-Poly1305 for ESP . . . . . . . . . . . . . . 7 61 3.3.1. AAD Construction . . . . . . . . . . . . . . . . . . . 8 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Examples of the algorithms . . . . . . . . . . . . . 10 69 A.1. Example of the block function . . . . . . . . . . . . . . 10 70 A.2. Example of ChaCha20 Encryption in IPsec . . . . . . . . . 11 71 A.3. Example of the AUTH_Poly1305 . . . . . . . . . . . . . . . 12 72 A.4. Example of ESP_ChaCha20-Poly1305 in IPsec . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 The Advanced Encryption Standard (AES - [FIPS-197]) has become the 78 gold standard in encryption. Its efficient design, wide 79 implementation, and hardware support allow for high performance in 80 many areas, including IPsec VPNs. On most modern platforms, AES is 81 anywhere from 4x to 10x as fast as the previous most-used cipher, 82 3-key Data Encryption Standard (3DES - [FIPS-46]), which makes it not 83 only the best choice, but the only choice. 85 The problem is that if future advances in cryptanalysis reveal a 86 weakness in AES, VPN users will be in an unenviable position. With 87 the only other widely supported cipher being the much slower 3DES, it 88 is not feasible to re-configure IPsec implementations to use 3DES. 89 [standby-cipher] describes this issue and the need for a standby 90 cipher in greater detail. 92 This document proposes such a standby cipher for IPsec. We use 93 ChaCha20 ([chacha]) with or without the Poly1305 ([poly1305]) 94 authenticator. 96 1.1. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. The Algorithms 104 The subsections below describe the algorithms used and the AEAD 105 construction. 107 2.1. The ChaCha20 block function 109 The ChaCha20 block function is part of the ChaCha20 stream cipher 110 (Section 2.2). It uses a 256-bit key. There are some variations 111 defined, such as 128-bit keys, and 8- and 12-round variants, but this 112 document defines only a 256-bit key and a 20-round ChaCha. ChaCha20 113 works on 512-bit blocks (64 bytes, or 16 32-bit words). In this 114 section we will describe the ChaCha block function. 116 ChaCha maps an array of sixteen 32-bit input words to sixteen 32-bit 117 output words. The input words are partitioned as follows: 118 o The first 4 words (0-3) are constants: 0x61707865, 0x3320646e, 119 0x79622d32, 0x6b206574. 121 o The next 8 words (4-11) are taken from the 256-bit key by reading 122 the bytes in little-endian order, in 4-byte chunks. 123 o Word 12 is a block counter. Since each block is 64-byte, a 32-bit 124 word is enough for 256 Gigabytes of data. 125 o Word 13 is called Sender ID, or SID. Note that in the original 126 ChaCha20 word 13 is also part of the block count, in case the 127 encrypted data exceeds 256 gigabytes. That is not necessary for 128 IPsec. 129 o Words 14-15 are a nonce, which should not be repeated for the same 130 combination of key and sender ID. The 14th word is the least 131 significant 32 bits of the input nonce (nonce | 0xffffffff), while 132 the 15th word is the most significant 32 bits (nonce >> 32). 134 ChaCha20 runs 20 rounds, alternating between "column" and "diagonal" 135 rounds. At the end of 20 rounds, the original input words are added 136 to the output words, and the result is serialized by serializing the 137 numbers in order, with the most significant octet of every 32-bit 138 integer preceding the others. See Appendix A.1 for an example of 139 this serialization. 141 The inputs to ChaCha20 are: 142 o A 256-bit key 143 o A 32-bit sender ID 144 o A 64-bit nonce, treated as a number 145 o A 32-bit block count parameter 147 The output is 64 random-looking bytes. 149 2.2. The ChaCha20 encryption algorithm 151 ChaCha20 is a stream cipher designed by D. J. Bernstein. It is a 152 refinement of the Salsa20 algorithm, and uses a 256-bit key. There 153 are some variations defined, such as 128-bit keys, and 8- and 12- 154 round variants, but this document defines only a 256-bit key and a 155 20-round ChaCha. 157 ChaCha20 successively calls the ChaCha20 block function, with the 158 same key, sender ID and nonce, and with successively increasing block 159 counter parameters. Concatenating the results forms a key stream, 160 which is then XOR-ed with the plaintext. There is no requirement for 161 the plaintext to be an integral multiple of 512-bits. If there is 162 extra keystream from the last block, it is discarded. 164 The inputs to ChaCha20 are: 165 o A 256-bit key 166 o A 32-bit sender ID 167 o A 32-bit initial counter 168 o A 64-bit nonce 169 o an arbitrary-length plaintext 171 The output is an encrypted message of the same length. 173 2.3. The Poly1305 algorithm 175 Poly1305 is a one-time authenticator designed by D. J. Bernstein. 176 Poly1305 takes a 32-byte one-time key and a message and produces a 177 16-byte tag. 179 The key MUST NOT be re-used. 181 The inputs to Poly1305 are: 182 o A 256-bit one-time key 183 o An arbitrary length message 185 The output is a 128-bit tag. 187 2.4. AEAD Construction 189 Note: Much of the content of this document, including this AEAD 190 construction is taken from Adam Langley's draft ([agl-draft]) for the 191 use of these algorithms in TLS. The AEAD construction described here 192 is called CHACHA20-POLY1305-ESP. 194 The inputs to CHACHA20-POLY1305-ESP are: 195 o A 256-bit key 196 o A 32-bit sender ID 197 o A 64-bit nonce 198 o An arbitrary length plaintext 199 o Arbitrary length additional data 201 The ChaCha20 and Poly1305 primitives are combined into an AEAD that 202 takes a 256-bit key and 64-bit IV as follows: 203 o First the ChaCha20 block function with the key, sender ID, nonce, 204 and zero for the block counter. From the 64-byte output, the 205 first 32 bytes are kept as the Poly1305 256-bit key. 206 o The ChaCha20 encryption function is called to encrypt the 207 plaintext, using the same key, sender ID, nonce and plaintext, and 208 with the initial counter set to 1. 209 o The Poly1305 function is called with the Poly1305 key calculated 210 above, and a message constructed as a concatenation of the 211 following: 212 * The additional data 213 * The length of the additional data in octets (as a 32-bit 214 network order integer) 215 * The ciphertext 216 * The length of the ciphertext in octets (as a 32-bit network 217 order integer) 219 Decryption is pretty much the same, but will be expanded later on. 221 The output from the AEAD is twofold: 222 o A ciphertext of the same length as the plaintext. 223 o A 128-bit tag (the result of the Poly1305 function. 225 3. Algorithms for ESP & AH 227 This document defines three algorithms for use with the Encapsulated 228 Security Protocol (ESP - [RFC4303]) and Authentication Header (AH - 229 [RFC4302]): 230 o ChaCha20 for use as an encryption algorithms for ESP. 231 o Poly1305-MAC for use as a message authentication algorithm for ESP 232 and AH. 233 o ChaCha20-Poly1305-ESP as an AEAD algorithm for ESP. 235 3.1. ENCR_ChaCha20 for ESP 237 For ChaCha20 used in ESP, the following parameters are used: 238 o The IV is 64-bit. Since this is used as the nonce for the 239 ChaCha20 function, this IV MUST NOT repeat. The most natural way 240 to implement this is with a counter, but anything that guarantees 241 uniqueness can be used, such as a linear feedback shift register 242 (LFSR). Note that the encrypter can use any IV generation method 243 that meets the uniqueness requirement, without coordinating with 244 the decrypter. 245 o The Internet Key Exchange protocol (IKE - [RFC5996]) generates a 246 bitstring called KEYMAT that is generated from a PRF. That KEYMAT 247 is divided into keys for encryption, message authentication and 248 whatever else is needed. For the ChaCha20 algorithm, 256 bits are 249 used for the key. 250 o The ChaCha20 encryption algorithm is called with the 256-bit key, 251 one (1) for the initial counter, the packet IV as a nonce, and the 252 plaintext. For regular IPsec, the Sender ID is set to zero. For 253 multi-sender SAs, such as described in [RFC6054], there sender ID 254 can be set to a different value for each sender. The 64-bit IV is 255 treated as a 64-bit network order integer, and passed to the 256 ChaCha20 function as a number. The reason that one (1) is used 257 for the initial counter rather than zero is that one is used for 258 encryption in the AEAD algorithm (because zero is reserved for 259 generating the one-time Poly1305 key), so one was used here for 260 consistency. 261 o As ChaCha20 is not a block cipher, no padding should be necessary. 262 However, in keeping with the specification in RFC 4303, the ESP 263 does have padding, so as to align the buffer to an integral 264 multiple of 4 octets. 266 The encryption algorithm transform ID for negotiating this algorithm 267 in IKE is TBA by IANA. 269 3.2. AUTH_Poly1305 for ESP and AH 271 You cannot use a part of the keying material directly, because 272 Poly1305 requires a different key for each authenticated message. So 273 the Poly1305 key for each message is generated as follows: 274 o The key for AUTH_Poly1305 is 256-bits. 275 o To determine the per-packet Poly1305 key, the ChaCha20 block 276 function is called with the following parameters: 277 * The AUTH_Poly1305 256-bit key is used as the key. 278 * The sender ID is set to zero. 279 * The packet replay counter is used as the nonce. If Extended 280 Sequence Numbers (ESN) are employed, then the full 64-bit is 281 used for the nonce. 282 * Zero is used for the block counter. 283 o The 512-bit result is then truncated. The top 256 bits are used 284 as the one-time key for Poly1305 to calculate the message 285 authentication code (MAC). 286 o The 128-bit output serves as the MAC for the packet. All 16 bytes 287 are included in the packet. 289 The integrity algorithm transform ID for negotiating this algorithm 290 in IKE is TBA by IANA. 292 3.3. ESP_ChaCha20-Poly1305 for ESP 294 ESP_ChaCha20-Poly1305 is a combined mode algorithm, or AEAD. The 295 construction follows the AEAD construction in Section 2.4: 296 o As in Section 3.1, the IV is 64-bit, and is used as a nonce. 297 o Also as in Section 3.1, the encryption key is 256-bit. 298 o As in Section 3.2, the nonce, along with a block counter of zero 299 is passed to the ChaCha20 block function, and the top part of the 300 result used as the Poly1305 key. 301 o The ChaCha20 encryption function is then called with the nonce, 302 the key, and an initial counter of zero. 303 o Finally, the Poly1305 function is run on the data to be 304 authenticated, which is, as specified in Section 2.4 a 305 concatenation of the following: 307 * The Authenticated Additional Data (AAD) - see Section 3.3.1. 308 * The AAD length in bytes as a 32-bit network order quantity. 309 * The ciphertext 310 * The length of the ciphertext as a 32-bit network order 311 quantity. 312 o The 128-bit output of Poly1305 is used as the tag. All 16 bytes 313 are included in the packet. 315 The encryption algorithm transform ID for negotiating this algorithm 316 in IKE is TBA by IANA. 318 3.3.1. AAD Construction 320 The construction of the Additional Authenticated Data (AAD) is 321 similar to the one in [RFC4106]. For security associations (SAs) 322 with 32-bit sequence numbers the AAD is 8 bytes: 4-byte SPI followed 323 by 4-byte sequence number ordered exactly as it is in the packet. 324 For SAs with ESN the AAD is 12 bytes: 4-byte SPI followed by an 325 8-byte sequence number as a 64-bit network order integer. 327 4. Security Considerations 329 The ChaCha20 cipher is designed to provide 256-bit security. 331 The Poly1305 authenticator is designed to ensure that forged messages 332 are rejected with a probability of 1-(n/(2^102)) for a 16n-byte 333 message, even after sending 2^64 legitimate messages, so it is SUF- 334 CMA in the terminology of [AE]. 336 The most important security consideration in implementing this draft 337 is the uniqueness of the nonce used in ChaCha20. This is trivial in 338 AUTH_Poly1305, because the packet sequence number is used as a nonce, 339 but is required for ChaCha20 as well. As said in Section 3.1, the 340 nonce should be selected uniquely for a particular key. counters and 341 LFSRs are both acceptable ways of generating unique nonces, as is 342 encrypting a counter using a 64-bit cipher such as DES. Note that it 343 is not acceptable to use a truncation of a counter encrypted with a 344 128-bit or 256-bit cipher, because such a truncation may repeat after 345 a short time. 347 The same kind of collision risk as in the above paragraph also exists 348 in the selection of the Poly1305 key in both the AEAD construction 349 (Section 2.4) and in the AUTH_Poly1305 algorithm (Section 3.2). 350 ChaCha20 is used to generate a 512-bit value, which is unique to each 351 packet, but this uniqueness is not guaranteed for its 256-bit 352 truncation, which serves as the actual key for Poly1305. While 353 uniqueness is not guaranteed, it is still very likely. Birthday 354 paradox calculations show that generating Poly1305 keys needs to 355 happen over 2^101 times (way more than the 2^64 allowed by IPsec) to 356 drive the chances of collision up to 0.00000000000001%. This is why 357 we may safely ignore the possibility of collision. 359 5. IANA Considerations 361 IANA is requested to assign two values from the IKEv2 "Transform Type 362 1 - Encryption Algorithm Transform IDs" registry, as follows: 363 o ENCR_ChaCha20 364 o ESP_ChaCha20-Poly1305 366 IANA is also requested to assign one value from the IKEv2 "Transform 367 Type 3 - Integrity Algorithm Transform IDs" registry with name 368 "AUTH_Poly1305". 370 6. Acknowledgements 372 Much of the text in this document was inspired by Adam Langley's 373 draft for TLS, and by "inspired" I mean "shamelessly copied". The 374 author would also like to thank Adam, Watson Ladd and Dave McGrew for 375 allaying his fears about writing a document describing crypto. 377 7. References 379 7.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 385 December 2005. 387 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 388 RFC 4303, December 2005. 390 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 391 "Internet Key Exchange Protocol Version 2 (IKEv2)", 392 RFC 5996, September 2010. 394 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 395 Encapsulating Security Payload (ESP) and Authentication 396 Header (AH) to Protect Group Traffic", RFC 6054, 397 November 2010. 399 [chacha] Bernstein, D., "ChaCha, a variant of Salsa20", Jan 2008. 401 [poly1305] 402 Bernstein, D., "The Poly1305-AES message-authentication 403 code", Mar 2005. 405 7.2. Informative References 407 [AE] Bellare, M. and C. Namprempre, "Authenticated Encryption: 408 Relations among notions and analysis of the generic 409 composition paradigm", 410 . 412 [FIPS-197] 413 National Institute of Standards and Technology, "Advanced 414 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 415 http://csrc.nist.gov/publications/fips/fips197/ 416 fips-197.pdf>. 418 [FIPS-46] National Institute of Standards and Technology, "Data 419 Encryption Standard", FIPS PUB 46-2, December 1993, 420 . 422 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 423 (GCM) in IPsec Encapsulating Security Payload (ESP)", 424 RFC 4106, June 2005. 426 [agl-draft] 427 Langley, A. and W. Chang, "ChaCha20 and Poly1305 based 428 Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04 429 (work in progress), November 2013. 431 [standby-cipher] 432 McGrew, D., Grieco, A., and Y. Sheffer, "Selection of 433 Future Cryptographic Standards", 434 draft-mcgrew-standby-cipher (work in progress). 436 Appendix A. Examples of the algorithms 438 A.1. Example of the block function 440 In this example, we show a single run of the ChaCha20 block. For our 441 example, we choose 442 o Key: 443 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 445 o Sender ID: 0 446 o Nonce: fedcba9876543210 447 o Block Count: 5 449 The block is set up as follows: 451 61707865 3320646e 79622d32 6b206574 452 03020100 07060504 0b0a0908 0f0e0d0c 453 13121110 17161514 1b1a1918 1f1e1d1c 454 00000005 00000000 76543210 fedcba98 456 After running the block function, the result is as follows: 458 a435cd80 a16b9b89 9112c0a4 487b4230 459 0d98f8cf b5b59396 4cce17a6 d17db31a 460 6dd35e45 658dff64 52b615fb b3c17e96 461 31d2725f ecd5246f 739bdab7 07cf7593 463 The resulting octet string looks like this: 465 a435cd80a16b9b899112c0a4487b42300d98f8cfb5b593964cce17a6d17db31a 466 6dd35e45658dff6452b615fbb3c17e9631d2725fecd5246f739bdab707cf7593 468 A.2. Example of ChaCha20 Encryption in IPsec 470 In this example, we show a run of the ChaCha20 encryption function. 471 For our example, we chose some arbitrary data. Also, 472 o Key: 473 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 474 o Sender ID: 0 475 o IV: 0x000000000000004a (74) 476 o Message Length: 80 octets 477 o The message itself: 479 35:6f:16:49:d0:2a:7f:19:30:f1:8f:af:e6:d1:69:d3:22:12:1f:76:78:be:6c 480 af:90:17:f3:fb:8e:12:d3:f1:f7:dc:7c:31:02:70:36:54:0c:5a:37:aa:31:fd 481 8a:e2:31:73:8a:ff:cc:77:8c:ba:c4:7b:6b:d1:17:6c:ce:cc:90:56:ae:65:b9 482 c6:af:40:e6:9d:f4:37:8f:4a:a9:f3 484 First, we need to apply padding. We will use an ESP-style padding, 485 rounding up the length of the packet to 84 octets, with two padding 486 bytes, a pad length, and a Next Header field set to 0x04: 488 35:6f:16:49:d0:2a:7f:19:30:f1:8f:af:e6:d1:69:d3:22:12:1f:76:78:be:6c 489 af:90:17:f3:fb:8e:12:d3:f1:f7:dc:7c:31:02:70:36:54:0c:5a:37:aa:31:fd 490 8a:e2:31:73:8a:ff:cc:77:8c:ba:c4:7b:6b:d1:17:6c:ce:cc:90:56:ae:65:b9 491 c6:af:40:e6:9d:f4:37:8f:4a:a9:f3:01:02:02:04 492 For 84 octets, we need two blocks. We call the block function twice, 493 once with the block counter set to 1, and then again with the block 494 counter set to two. The results are as follows: 496 Block 1 before rounds: 497 61707865 3320646e 79622d32 6b206574 498 03020100 07060504 0b0a0908 0f0e0d0c 499 13121110 17161514 1b1a1918 1f1e1d1c 500 00000001 00000000 0000004a 00000000 502 Block 1 after rounds: 503 9944f9d8 0f69b9cc 9002b600 559b9586 504 04579a7b a9a146c0 a601d9dd 8a141b06 505 d08a69bb e737527d 0ee7970d ff8512d8 506 d959240f 0f09eb18 eb0f2a3a ee0fbcf2 508 Block 2 before rounds: 509 61707865 3320646e 79622d32 6b206574 510 03020100 07060504 0b0a0908 0f0e0d0c 511 13121110 17161514 1b1a1918 1f1e1d1c 512 00000002 00000000 0000004a 00000000 514 Block 2 after rounds: 515 213bebc0 720ce566 26195c71 84e2ee1d 516 511f64c2 b8ed11da ede4e571 d9b57c34 517 0aa05765 dd073b1c 22d7dc84 86c91bc0 518 a9b89717 dbf8c56f 5822cafd deec62ff 520 84 bytes of key stream: 521 99:44:f9:d8:0f:69:b9:cc:90:02:b6:00:55:9b:95:86:04:57:9a:7b:a9:a1:46 522 c0:a6:01:d9:dd:8a:14:1b:06:d0:8a:69:bb:e7:37:52:7d:0e:e7:97:0d:ff:85 523 12:d8:d9:59:24:0f:0f:09:eb:18:eb:0f:2a:3a:ee:0f:bc:f2:21:3b:eb:c0:72 524 0c:e5:66:26:19:5c:71:84:e2:ee:1d:51:1f:64:c2 526 XOR'd with the plaintext: 527 ac:2b:ef:91:df:43:c6:d5:a0:f3:39:af:b3:4a:fc:55:26:45:85:0d:d1:1f:2a 528 6f:36:16:2a:26:04:06:c8:f7:27:56:15:8a:e5:47:64:29:02:bd:a0:a7:ce:78 529 98:3a:e8:2a:ae:f0:c3:7e:67:a2:2f:74:41:eb:f9:63:72:3e:b1:6d:45:a5:cb 530 ca:4a:26:c0:84:a8:46:0b:a8:47:ee:50:1d:66:c6 532 A.3. Example of the AUTH_Poly1305 534 In this example, we show a run of the AUTH_Poly1305 message 535 authentication function. For our example, we choose some arbitrary 536 data - the same data as in the ENCH_ChaCha20 example above. Also, 537 o Key: 538 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 540 o Replay Counter: 0x0000004a (74) 541 o Message Length: 80 octets 542 o The message itself: 544 35:6f:16:49:d0:2a:7f:19:30:f1:8f:af:e6:d1:69:d3:22:12:1f:76:78:be:6c 545 af:90:17:f3:fb:8e:12:d3:f1:f7:dc:7c:31:02:70:36:54:0c:5a:37:aa:31:fd 546 8a:e2:31:73:8a:ff:cc:77:8c:ba:c4:7b:6b:d1:17:6c:ce:cc:90:56:ae:65:b9 547 c6:af:40:e6:9d:f4:37:8f:4a:a9:f3 549 First, we run the ChaCha20 algorithm to generate the one-time 550 Poly1305 key: 552 Key block before the rounds: 553 61707865 3320646e 79622d32 6b206574 554 03020100 07060504 0b0a0908 0f0e0d0c 555 13121110 17161514 1b1a1918 1f1e1d1c 556 00000000 00000000 0000004a 00000000 558 Key block after rounds: 559 64345099 66639817 2113da66 371489fa 560 091f5ff3 c681552b b0f0a4b5 d0d7e6dd 561 5401d1e1 b6ff30e5 25a5a57c b1af2f06 562 8a064ae1 39b28c25 9698451b c688b187 564 256-bit one-time Poly1305 key: 565 64345099666398172113da66371489fa091f5ff3c681552bb0f0a4b5d0d7e6dd 567 Tag: 43dc3ef779160bb54943a2279570d679 569 A.4. Example of ESP_ChaCha20-Poly1305 in IPsec 571 In this example, we encrypt the same data as in Appendix A.2, and 572 also authenticate it. For the purposes of this example, we will 573 assume that ESN is not used. 574 o Key: 575 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 576 o Sender ID: 0 577 o SPI: 0x7890abcd 578 o IV: 0x000000000000004a (74) 579 o Message Length: 80 octets 580 o The message itself: 582 35:6f:16:49:d0:2a:7f:19:30:f1:8f:af:e6:d1:69:d3:22:12:1f:76:78:be:6c 583 af:90:17:f3:fb:8e:12:d3:f1:f7:dc:7c:31:02:70:36:54:0c:5a:37:aa:31:fd 584 8a:e2:31:73:8a:ff:cc:77:8c:ba:c4:7b:6b:d1:17:6c:ce:cc:90:56:ae:65:b9 585 c6:af:40:e6:9d:f4:37:8f:4a:a9:f3 587 First, we repeat the calculations in Appendix A.3 to get the one-time 588 Poly1305 key: 590 Key block before the rounds: 591 61707865 3320646e 79622d32 6b206574 592 03020100 07060504 0b0a0908 0f0e0d0c 593 13121110 17161514 1b1a1918 1f1e1d1c 594 00000000 00000000 0000004a 00000000 596 Key block after rounds: 597 64345099 66639817 2113da66 371489fa 598 091f5ff3 c681552b b0f0a4b5 d0d7e6dd 599 5401d1e1 b6ff30e5 25a5a57c b1af2f06 600 8a064ae1 39b28c25 9698451b c688b187 602 256-bit one-time Poly1305 key: 603 64345099666398172113da66371489fa091f5ff3c681552bb0f0a4b5d0d7e6dd 605 Next, we need to apply padding. We will use an ESP-style padding, 606 rounding up the length of the packet to 84 octets, with two padding 607 bytes, a pad length, and a Next Header field set to 0x04: 609 35:6f:16:49:d0:2a:7f:19:30:f1:8f:af:e6:d1:69:d3:22:12:1f:76:78:be:6c 610 af:90:17:f3:fb:8e:12:d3:f1:f7:dc:7c:31:02:70:36:54:0c:5a:37:aa:31:fd 611 8a:e2:31:73:8a:ff:cc:77:8c:ba:c4:7b:6b:d1:17:6c:ce:cc:90:56:ae:65:b9 612 c6:af:40:e6:9d:f4:37:8f:4a:a9:f3:01:02:02:04 614 Step 3, we run the ChaCha20 block twice to create sufficient 615 keystream to XOR with all the (padded) plaintext. 617 Block 1 before rounds: 618 61707865 3320646e 79622d32 6b206574 619 03020100 07060504 0b0a0908 0f0e0d0c 620 13121110 17161514 1b1a1918 1f1e1d1c 621 00000001 00000000 0000004a 00000000 623 Block 1 after rounds: 624 9944f9d8 0f69b9cc 9002b600 559b9586 625 04579a7b a9a146c0 a601d9dd 8a141b06 626 d08a69bb e737527d 0ee7970d ff8512d8 627 d959240f 0f09eb18 eb0f2a3a ee0fbcf2 629 Block 2 before rounds: 630 61707865 3320646e 79622d32 6b206574 631 03020100 07060504 0b0a0908 0f0e0d0c 632 13121110 17161514 1b1a1918 1f1e1d1c 633 00000002 00000000 0000004a 00000000 635 Block 2 after rounds: 636 213bebc0 720ce566 26195c71 84e2ee1d 637 511f64c2 b8ed11da ede4e571 d9b57c34 638 0aa05765 dd073b1c 22d7dc84 86c91bc0 639 a9b89717 dbf8c56f 5822cafd deec62ff 641 84 bytes of key stream: 642 99:44:f9:d8:0f:69:b9:cc:90:02:b6:00:55:9b:95:86:04:57:9a:7b:a9:a1:46 643 c0:a6:01:d9:dd:8a:14:1b:06:d0:8a:69:bb:e7:37:52:7d:0e:e7:97:0d:ff:85 644 12:d8:d9:59:24:0f:0f:09:eb:18:eb:0f:2a:3a:ee:0f:bc:f2:21:3b:eb:c0:72 645 0c:e5:66:26:19:5c:71:84:e2:ee:1d:51:1f:64:c2 647 XOR'd with the plaintext: 648 ac:2b:ef:91:df:43:c6:d5:a0:f3:39:af:b3:4a:fc:55:26:45:85:0d:d1:1f:2a 649 6f:36:16:2a:26:04:06:c8:f7:27:56:15:8a:e5:47:64:29:02:bd:a0:a7:ce:78 650 98:3a:e8:2a:ae:f0:c3:7e:67:a2:2f:74:41:eb:f9:63:72:3e:b1:6d:45:a5:cb 651 ca:4a:26:c0:84:a8:46:0b:a8:47:ee:50:1d:66:c6 653 next, we construct the AEAD. As described in Section 3.3.1, the AAD 654 is a concatenation of the 4-byte SPI, followed by a 4-byte sequence 655 number. In this case: 78:90:ab:cd:00:00:00:4a. The Poly1305 656 function is run over a concatenation of the AAD, the length of the 657 AAD as a 32-bit integer (8), The ciphertext, and the length of the 658 ciphertext (84): 660 Buffer to be authenticated: 661 78:90:ab:cd:00:00:00:4a:00:00:00:08:ac:2b:ef:91:df:43:c6:d5:a0:f3:39 662 af:b3:4a:fc:55:26:45:85:0d:d1:1f:2a:6f:36:16:2a:26:04:06:c8:f7:27:56 663 15:8a:e5:47:64:29:02:bd:a0:a7:ce:78:98:3a:e8:2a:ae:f0:c3:7e:67:a2:2f 664 74:41:eb:f9:63:72:3e:b1:6d:45:a5:cb:ca:4a:26:c0:84:a8:46:0b:a8:47:ee 665 50:1d:66:c6:00:00:00:54 667 Tag: 7af839e8f4961cd99f0600dc7b8ad8d6 669 Author's Address 671 Yoav Nir 672 Check Point Software Technologies Ltd. 673 5 Hasolelim st. 674 Tel Aviv 6789735 675 Israel 677 Email: ynir@checkpoint.com