From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7634.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc7634.txt (limited to 'doc/rfc/rfc7634.txt') diff --git a/doc/rfc/rfc7634.txt b/doc/rfc/rfc7634.txt new file mode 100644 index 0000000..253c70f --- /dev/null +++ b/doc/rfc/rfc7634.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Nir +Request for Comments: 7634 Check Point +Category: Standards Track August 2015 +ISSN: 2070-1721 + + + ChaCha20, Poly1305, and Their Use + in the Internet Key Exchange Protocol (IKE) and IPsec + +Abstract + + This document describes the use of the ChaCha20 stream cipher along + with the Poly1305 authenticator, combined into an AEAD algorithm for + the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7634. + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + +Nir Standards Track [Page 1] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 + 2. ChaCha20 and Poly1305 for ESP . . . . . . . . . . . . . . . . 3 + 2.1. AAD Construction . . . . . . . . . . . . . . . . . . . . 5 + 3. Use in IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Negotiation in IKEv2 . . . . . . . . . . . . . . . . . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 7.2. Informative References . . . . . . . . . . . . . . . . . 8 + Appendix A. ESP Example . . . . . . . . . . . . . . . . . . . . 9 + Appendix B. IKEv2 Example . . . . . . . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 + +1. Introduction + + The Advanced Encryption Standard (AES) [FIPS-197] has become the go- + to algorithm for encryption. It is now the most commonly used + algorithm in many areas, including IPsec Virtual Private Networks + (VPNs). On most modern platforms, AES is anywhere from four to ten + times as fast as the previously popular cipher, Triple Data + Encryption Standard (3DES) [SP800-67]. 3DES also uses a 64-bit + block; this means that the amount of data that can be encrypted + before rekeying is required is limited. These reasons make AES not + only the best choice, but the only viable choice for IPsec. + + The problem is that if future advances in cryptanalysis reveal a + weakness in AES, VPN users will be in an unenviable position. With + the only other widely supported cipher for IPsec implementations + being the much slower 3DES, it is not feasible to reconfigure IPsec + installations away from AES. [Standby-Cipher] describes this issue + and the need for a standby cipher in greater detail. + + This document proposes the fast and secure ChaCha20 stream cipher as + such a standby cipher in an Authenticated Encryption with Associated + Data (AEAD) construction with the Poly1305 authenticator for use with + the Encapsulated Security Protocol (ESP) [RFC4303] and the Internet + Key Exchange Protocol version 2 (IKEv2) [RFC7296]. The algorithms + are described in a separate document ([RFC7539]). This document only + describes the IPsec-specific things. + + + + + + + +Nir Standards Track [Page 2] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. ChaCha20 and Poly1305 for ESP + + AEAD_CHACHA20_POLY1305 ([RFC7539]) is a combined mode algorithm, or + AEAD. Usage follows the AEAD construction in Section 2.8 of RFC + 7539: + + o The Initialization Vector (IV) is 64 bits and is used as part of + the nonce. The IV MUST be unique for each invocation for a + particular security association (SA) but does not need to be + unpredictable. The use of a counter or a linear feedback shift + register (LFSR) is RECOMMENDED. + + o A 32-bit Salt is prepended to the 64-bit IV to form the 96-bit + nonce. The salt is fixed per SA, and it is not transmitted as + part of the ESP packet. + + o The encryption key is 256 bits. + + o The Internet Key Exchange Protocol generates a bitstring called + KEYMAT using a pseudorandom function (PRF). That KEYMAT is + divided into keys for encryption, message authentication, and + whatever else is needed. The KEYMAT requested for each + ChaCha20-Poly1305 key is 36 octets. The first 32 octets are the + 256-bit ChaCha20 key, and the remaining 4 octets are used as the + Salt value in the nonce. + + The ChaCha20 encryption algorithm requires the following parameters: + a 256-bit key, a 96-bit nonce, and a 32-bit Initial Block Counter. + For ESP, we set these as follows: + + o The key is set as mentioned above. + + o The 96-bit nonce is formed from a concatenation of the 32-bit Salt + and the 64-bit IV, as described above. + + o The Initial Block Counter is set to one (1). The reason that one + is used for the initial counter rather than zero is that zero is + reserved for generating the one-time Poly1305 key (see below). + + + + + + + +Nir Standards Track [Page 3] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + As the ChaCha20 block function is not applied directly to the + plaintext, no padding should be necessary. However, in keeping with + the specification in RFC 4303, the plaintext always has a pad length + octet and a Next Header octet, and it may require padding octets so + as to align the buffer to an integral multiple of 4 octets. + + The same key and nonce, along with a block counter of zero, are + passed to the ChaCha20 block function, and the top 256 bits of the + result are used as the Poly1305 key. + + Finally, the Poly1305 function is run on the data to be + authenticated, which is, as specified in Section 2.8 of [RFC7539], a + concatenation of the following in the order below: + + o The Authenticated Additional Data (AAD); see Section 2.1. + + o Zero-octet padding that rounds the length up to 16 octets. This + is 4 or 8 octets depending on the length of the AAD. + + o The ciphertext. + + o Zero-octet padding that rounds the total length up to an integral + multiple of 16 octets. + + o The length of the AAD in octets (as a 64-bit integer encoded in + little-endian byte order). + + o The length of the ciphertext in octets (as a 64-bit integer + encoded in little-endian byte order). + + The 128-bit output of Poly1305 is used as the tag. All 16 octets are + included in the packet. + + + + + + + + + + + + + + + + + + + +Nir Standards Track [Page 4] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + The figure below is a copy of Figure 2 in RFC 4303: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Security Parameters Index (SPI) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- + | IV (optional) | ^ p + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a + | Rest of Payload Data (variable) | | y + ~ ~ | l + | | | o + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a + | | TFC Padding * (optional, variable) | v d + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- + | | Padding (0-255 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Pad Length | Next Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Integrity Check Value-ICV (variable) | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o The IV field is 64 bits. It is the final 64 bits of the 96-bit + nonce. If the counter method is used for generating unique IVs, + then the final 32 bits of the IV will be equal to the Sequence + Number field. + + o The length of the Padding field need not exceed 4 octets. + However, neither RFC 4303 nor this specification require using the + minimal padding length. + + o The Integrity Check Value field contains the 16-octet tag. + +2.1. AAD Construction + + The construction of the Additional Authenticated Data (AAD) is + similar to the one in [RFC4106]. For security associations (SAs) + with 32-bit sequence numbers, the AAD is 8 octets: a 4-octet SPI + followed by a 4-octet sequence number ordered exactly as it is in the + packet. For SAs with an Extended Sequence Number (ESN), the AAD is + 12 octets: a 4-octet SPI followed by an 8-octet sequence number as a + 64-bit integer in big-endian byte order. + + + + + +Nir Standards Track [Page 5] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + +3. Use in IKEv2 + + AEAD algorithms can be used in IKE, as described in [RFC5282]. More + specifically: + + o The Encrypted Payload is as described in Section 3 of RFC 5282. + + o The ChaCha20-Poly1305 keying material is derived similarly to ESP: + 36 octets are requested for each of SK_ei and SK_er, of which the + first 32 form the key and the last 4 form the salt. No octets are + requested for SK_ai and SK_ar. + + o The IV is 64 bits, as described in Section 2, and is included + explicitly in the Encrypted payload. + + o The sender SHOULD include no padding and set the Pad Length field + to zero. The receiver MUST accept any length of padding. + + o The AAD is as described in Section 5.1 of RFC 5282, so it is 32 + octets (28 for the IKEv2 header plus 4 octets for the encrypted + payload header), assuming no unencrypted payloads. + +4. Negotiation in IKEv2 + + When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or + IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the + transform substructure of the SA payload as the ENCR (type 1) + transform ID. As with other AEAD algorithms, INTEG (type 3) + transform substructures MUST NOT be specified, or just one INTEG + transform MAY be included with value NONE (0). + +5. Security Considerations + + The ChaCha20 cipher is designed to provide 256-bit security. + + The Poly1305 authenticator is designed to ensure that forged messages + are rejected with a probability of 1-(n/(2^102)) for a 16n-octet + message, even after sending 2^64 legitimate messages, so it is + SUF-CMA (strong unforgeability against chosen-message attacks) in the + terminology of [AE]. + + The most important security consideration in implementing this + document is the uniqueness of the nonce used in ChaCha20. The nonce + should be selected uniquely for a particular key, but + unpredictability of the nonce is not required. Counters and LFSRs + are both acceptable ways of generating unique nonces. + + + + + +Nir Standards Track [Page 6] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + Another issue with implementing these algorithms is avoiding side + channels. This is trivial for ChaCha20, but requires some care for + Poly1305. Considerations for implementations of these algorithms are + in [RFC7539]. + + The Salt value in used nonce construction in ESP and IKEv2 is derived + from the keystream, same as the encryption key. It is never + transmitted on the wire, but the security of the algorithm does not + depend on its secrecy. Thus, implementations that keep keys and + other secret material within some security boundary MAY export the + Salt from the security boundary. This may be useful if the API + provided by the library accepts the nonce as a parameter rather than + the IV. + +6. IANA Considerations + + IANA has assigned the value 28 as a transform identifier for the + algorithm described in this document in the "Transform Type 1 - + Encryption Algorithm Transform IDs" registry with name + ENCR_CHACHA20_POLY1305 and this document as reference for both ESP + and IKEv2. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + . + + [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption + Algorithms with the Encrypted Payload of the Internet Key + Exchange version 2 (IKEv2) Protocol", RFC 5282, + DOI 10.17487/RFC5282, August 2008, + . + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October + 2014, . + + + + + + +Nir Standards Track [Page 7] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF + Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, + . + +7.2. Informative References + + [AE] Bellare, M. and C. Namprempre, "Authenticated Encryption: + Relations among notions and analysis of the generic + composition paradigm", DOI 10.1007/s00145-008-9026-x, + September 2008, + . + + [FIPS-197] + National Institute of Standards and Technology, "Advanced + Encryption Standard (AES)", FIPS PUB 197, November 2001, + . + + [RFC1761] Callaghan, B. and R. Gilligan, "Snoop Version 2 Packet + Capture File Format", RFC 1761, DOI 10.17487/RFC1761, + February 1995, . + + [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode + (GCM) in IPsec Encapsulating Security Payload (ESP)", + RFC 4106, DOI 10.17487/RFC4106, June 2005, + . + + [SP800-67] + National Institute of Standards and Technology, + "Recommendation for the Triple Data Encryption Algorithm + (TDEA) Block Cipher", FIPS SP800-67, January 2012, + . + + [Standby-Cipher] + McGrew, D., Grieco, A., and Y. Sheffer, "Selection of + Future Cryptographic Standards", Work in Progress + draft-mcgrew-standby-cipher-00, January 2013. + + + + + + + + + + + + + +Nir Standards Track [Page 8] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + +Appendix A. ESP Example + + For this example, we will use a tunnel-mode ESP SA using the + ChaCha20-Poly1305 algorithm. The keying material is as follows: + + KEYMAT: + 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 ................ + 032 a0 a1 a2 a3 .... + + Obviously not a great PRF. The first 32 octets are the key and the + final 4 octets (0xa0 0xa1 0xa2 0xa3) are the salt. For the packet, + we will use an ICMP packet from 198.51.100.5 to 192.0.2.5: + + Source Packet: + 000 45 00 00 54 a6 f2 00 00 40 01 e7 78 c6 33 64 05 E..T....@..x.3d. + 016 c0 00 02 05 08 00 5b 7a 3a 08 00 00 55 3b ec 10 ......[z:...U;.. + 032 00 07 36 27 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ..6'............ + 048 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# + 064 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 + 080 34 35 36 37 4567 + + The SA details are as follows: + + o The key and Salt are as above. + + o The SPI is 0x01 0x02 0x03 0x04. + + o The next sequence number is 5; ESN is not enabled. + + o The gateway IP address for this side is 203.0.113.153; The peer + address is 203.0.113.5. + + o NAT was not detected. + + The 64-bit IV is 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17. Putting + together the salt and IV we get the nonce: + + The nonce: + 000 a0 a1 a2 a3 10 11 12 13 14 15 16 17 ............ + + + + + + + + + + + +Nir Standards Track [Page 9] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + The plaintext to encrypt consists of the source IP packet plus the + padding: + + Plaintext (includes padding and pad length): + 000 45 00 00 54 a6 f2 00 00 40 01 e7 78 c6 33 64 05 E..T....@..x.3d. + 016 c0 00 02 05 08 00 5b 7a 3a 08 00 00 55 3b ec 10 ......[z:...U;.. + 032 00 07 36 27 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ..6'............ + 048 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# + 064 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 + 080 34 35 36 37 01 02 02 04 4567.... + + With the key, nonce, and plaintext available, we can call the + ChaCha20 function and encrypt the packet, producing the ciphertext: + + Ciphertext: + 000 24 03 94 28 b9 7f 41 7e 3c 13 75 3a 4f 05 08 7b $..(..A~<.u:O..{ + 016 67 c3 52 e6 a7 fa b1 b9 82 d4 66 ef 40 7a e5 c6 g.R.......f.@z.. + 032 14 ee 80 99 d5 28 44 eb 61 aa 95 df ab 4c 02 f7 .....(D.a....L.. + 048 2a a7 1e 7c 4c 4f 64 c9 be fe 2f ac c6 38 e8 f3 *..|LOd.../..8.. + 064 cb ec 16 3f ac 46 9b 50 27 73 f6 fb 94 e6 64 da ...?.F.P's....d. + 080 91 65 b8 28 29 f6 41 e0 .e.().A. + + To calculate the tag, we need a one-time Poly1305 key, which we + calculate by calling the ChaCha20 function again with the same key + and nonce, but a block count of zero. + + Poly1305 one-time key: + 000 af 1f 41 2c c1 15 ad ce 5e 4d 0e 29 d5 c1 30 bf ..A,....^M.)..0. + 016 46 31 21 0e 0f ef 74 31 c0 45 4f e7 0f d7 c2 d1 F1!...t1.EO..... + + The AAD is constructed by concatenating the SPI to the sequence + number: + + 000 01 02 03 04 00 00 00 05 ........ + + The input to the Poly1305 function is constructed by concatenating + and padding the AAD and ciphertext: + + Poly1305 Input: + 000 01 02 03 04 00 00 00 05 00 00 00 00 00 00 00 00 ................ + 016 24 03 94 28 b9 7f 41 7e 3c 13 75 3a 4f 05 08 7b $..(..A~<.u:O..{ + 032 67 c3 52 e6 a7 fa b1 b9 82 d4 66 ef 40 7a e5 c6 g.R.......f.@z.. + 048 14 ee 80 99 d5 28 44 eb 61 aa 95 df ab 4c 02 f7 .....(D.a....L.. + 064 2a a7 1e 7c 4c 4f 64 c9 be fe 2f ac c6 38 e8 f3 *..|LOd.../..8.. + 080 cb ec 16 3f ac 46 9b 50 27 73 f6 fb 94 e6 64 da ...?.F.P's....d. + 096 91 65 b8 28 29 f6 41 e0 00 00 00 00 00 00 00 00 .e.().A......... + 112 08 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 ........X....... + + + + +Nir Standards Track [Page 10] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + The resulting tag is: + + Tag: + 000 76 aa a8 26 6b 7f b0 f7 b1 1b 36 99 07 e1 ad 43 v..&k.....6....C + + Putting it all together, the resulting packet is as follows: + + ESP packet: + 000 45 00 00 8c 23 45 00 00 40 32 de 5b cb 00 71 99 E...#E..@2.[..q. + 016 cb 00 71 05 01 02 03 04 00 00 00 05 10 11 12 13 ..q............. + 032 14 15 16 17 24 03 94 28 b9 7f 41 7e 3c 13 75 3a ....$..(..A~<.u: + 048 4f 05 08 7b 67 c3 52 e6 a7 fa b1 b9 82 d4 66 ef O..{g.R.......f. + 064 40 7a e5 c6 14 ee 80 99 d5 28 44 eb 61 aa 95 df @z.......(D.a... + 080 ab 4c 02 f7 2a a7 1e 7c 4c 4f 64 c9 be fe 2f ac .L..*..|LOd.../. + 096 c6 38 e8 f3 cb ec 16 3f ac 46 9b 50 27 73 f6 fb .8.....?.F.P's.. + 112 94 e6 64 da 91 65 b8 28 29 f6 41 e0 76 aa a8 26 ..d..e.().A.v..& + 128 6b 7f b0 f7 b1 1b 36 99 07 e1 ad 43 k.....6....C + +Appendix B. IKEv2 Example + + For the IKEv2 example, we'll use the following: + + o The key is 0x80..0x9f, the same as in Appendix A. + + o The Salt is 0xa0 0xa1 0xa2 0xa3. + + o The IV will also be the same as in the previous example. The fact + that the IV and Salt are both the same means that the nonce is + also the same. + + o Because the key and nonce are the same, so is the one-time + Poly1305 key. + + o The packet will be an INFORMATIONAL request carrying a single + payload: a Notify payload with type SET_WINDOW_SIZE, setting the + window size to 10. + + o iSPI = 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7. + + o rSPI = 0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7. + + o Message ID shall be 9. + + The Notify Payload: + 000 00 00 00 0c 00 00 40 01 00 00 00 0a ......@..... + + Plaintext (with no padding and a zero pad length): + 000 00 00 00 0c 00 00 40 01 00 00 00 0a 00 ......@...... + + + +Nir Standards Track [Page 11] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + Ciphertext: + 000 61 03 94 70 1f 8d 01 7f 7c 12 92 48 89 a..p....|..H. + + The AAD is constructed by appending the IKE header to the encrypted + payload header. Note that the length field in the IKE header and the + length field in the encrypted payload header have to be calculated + before constructing the AAD: + + AAD: + 000 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7 ................ + 016 2e 20 25 00 00 00 00 09 00 00 00 45 29 00 00 29 . %........E)..) + + In this case, the length of the AAD is an integral multiple of 16, so + when constructing the input to Poly1305 there was no need for + padding. The ciphertext is 13 octets long, so it is followed by 3 + zero octets. The input to Poly1305 is 32 octets of AAD, 13 octets of + ciphertext, 3 octets of zero padding, and two 8-octet length fields + in little-endian byte order. + + Poly1305 Input: + 000 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7 ................ + 016 2e 20 25 00 00 00 00 09 00 00 00 45 29 00 00 29 . %........E)..) + 032 61 03 94 70 1f 8d 01 7f 7c 12 92 48 89 00 00 00 a..p....|..H.... + 048 20 00 00 00 00 00 00 00 0d 00 00 00 00 00 00 00 ............... + + Tag: + 000 6b 71 bf e2 52 36 ef d7 cd c6 70 66 90 63 15 b2 kq..R6....pf.c.. + + Encrypted Payload: + 000 29 00 00 29 10 11 12 13 14 15 16 17 61 03 94 70 )..)........a..p + 016 1f 8d 01 7f 7c 12 92 48 89 6b 71 bf e2 52 36 ef ....|..H.kq..R6. + 032 d7 cd c6 70 66 90 63 15 b2 ...pf.c.. + + The IKE Message: + 000 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7 ................ + 016 2e 20 25 00 00 00 00 09 00 00 00 45 29 00 00 29 . %........E)..) + 032 10 11 12 13 14 15 16 17 61 03 94 70 1f 8d 01 7f ........a..p.... + 048 7c 12 92 48 89 6b 71 bf e2 52 36 ef d7 cd c6 70 |..H.kq..R6....p + 064 66 90 63 15 b2 f.c.. + + + + + + + + + + + + +Nir Standards Track [Page 12] + +RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015 + + + The below file in the snoop format [RFC1761] contains three packets: + The first is the ICMP packet from the example in Appendix A, the + second is the ESP packet from the same appendix, and the third is the + IKEv2 packet from this appendix. To convert this text back into a + file, you can use a Unix command line tool such as + "openssl enc -d -a": + + c25vb3AAAAAAAAACAAAABAAAAGIAAABiAAAAegAAAABVPq8PAAADVdhs6fUQBHgx + wbcpwggARQAAVKbyAABAAed4xjNkBcAAAgUIAFt6OggAAFU77BAABzYnCAkKCwwN + Dg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3AAAAmgAA + AJoAAACyAAAAAFU+rw8AAAo62Gzp9RAEeDHBtynCCABFAACMI0UAAEAy3lvLAHGZ + ywBxBQECAwQAAAAFEBESExQVFhckA5QouX9BfjwTdTpPBQh7Z8NS5qf6sbmC1Gbv + QHrlxhTugJnVKETrYaqV36tMAvcqpx58TE9kyb7+L6zGOOjzy+wWP6xGm1Anc/b7 + lOZk2pFluCgp9kHgdqqoJmt/sPexGzaZB+GtQwAAAG8AAABvAAAAhwAAAABVPq8P + AAARH9hs6fUQBHgxwbcpwggARQAAYSNFAABAEd6nywBxmcsAcQUB9AH0AE0IUcDB + wsPExcbH0NHS09TV1tcuICUAAAAACQAAAEUpAAApEBESExQVFhdhA5RwH40Bf3wS + kkiJa3G/4lI279fNxnBmkGMVsg== + +Acknowledgements + + All of the algorithms in this document were designed by D. J. + Bernstein. The AEAD construction was designed by Adam Langley. The + author would also like to thank Adam for helpful comments, as well as + Yaron Sheffer for telling me to write the algorithms document. + Thanks also to Martin Willi for pointing out the discrepancy with the + final version of the algorithm document, and to Valery Smyslov and + Tero Kivinen for helpful comments on this document. Thanks to Steve + Doyle and Martin Willi for pointing out mistakes in my examples. + +Author's Address + + Yoav Nir + Check Point Software Technologies Ltd. + 5 Hasolelim St. + Tel Aviv 6789735 + Israel + + Email: ynir.ietf@gmail.com + + + + + + + + + + + + + +Nir Standards Track [Page 13] + -- cgit v1.2.3