Check Point Software Technologies Ltd.

5 Hasolelim st. Tel Aviv 6789735 Israel ynir@checkpoint.com

Security Area Internet-Draft This document describes the use of the ChaCha20 stream cipher in IPsec, as well as the use of the Poly1305 authenticator, both as stand-alone algorithms, and as a combined mode AEAD algorithm.

The Advanced Encryption Standard (AES - ) has become the gold standard in encryption. Its efficient design, wide implementation, and hardware support allow for high performance in many areas, including IPsec VPNs. 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 - ), which makes it not only the best choice, but the only choice. 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 being the much slower 3DES, it is not feasible to re-configure IPsec implementations to use 3DES. describes this issue and the need for a standby cipher in greater detail. This document proposes such a standby cipher for IPsec. We use ChaCha20 () with or without the Poly1305 () authenticator.

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 .

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

The ChaCha20 block function is part of the ChaCha20 stream cipher (). It uses a 256-bit key. There are some variations defined, such as 128-bit keys, and 8- and 12-round variants, but this document defines only a 256-bit key and a 20-round ChaCha. ChaCha20 works on 512-bit blocks (64 bytes, or 16 32-bit words). In this section we will describe the ChaCha block function. ChaCha maps an array of sixteen 32-bit input words to sixteen 32-bit output words. The input words are partitioned as follows: The first 4 words (0-3) are constants: 0x61707865, 0x3320646e, 0x79622d32, 0x6b206574. 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. Word 12 is a block counter. Since each block is 64-byte, a 32-bit word is enough for 256 Gigabytes of data. Word 13 is called Sender ID, or SID. Note that in the original ChaCha20 word 13 is also part of the block count, in case the encrypted data exceeds 256 gigabytes. That is not necessary for IPsec. Words 14-15 are a nonce, which should not be repeated for the same combination of key and sender ID. The 14th word is the least significant 32 bits of the input nonce (nonce | 0xffffffff), while the 15th word is the most significant 32 bits (nonce >> 32). ChaCha20 runs 20 rounds, alternating between "column" and "diagonal" rounds. At the end of 20 rounds, the original input words are added to the output words, and the result is serialized by serializing the numbers in order, with the most significant octet of every 32-bit integer preceding the others. See for an example of this serialization. The inputs to ChaCha20 are: A 256-bit key A 32-bit sender ID A 64-bit nonce, treated as a number A 32-bit block count parameter The output is 64 random-looking bytes.

ChaCha20 is a stream cipher designed by D. J. Bernstein. It is a refinement of the Salsa20 algorithm, and uses a 256-bit key. There are some variations defined, such as 128-bit keys, and 8- and 12-round variants, but this document defines only a 256-bit key and a 20-round ChaCha. ChaCha20 successively calls the ChaCha20 block function, with the same key, sender ID and nonce, and with successively increasing block counter parameters. Concatenating the results forms a key stream, which is then XOR-ed with the plaintext. 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. The inputs to ChaCha20 are: A 256-bit key A 32-bit sender ID A 32-bit initial counter A 64-bit nonce an arbitrary-length plaintext The output is an encrypted message of the same length.

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. The key MUST NOT be re-used. The inputs to Poly1305 are: A 256-bit one-time key An arbitrary length message The output is a 128-bit tag.

Note: Much of the content of this document, including this AEAD construction is taken from Adam Langley's draft () for the use of these algorithms in TLS. The AEAD construction described here is called CHACHA20-POLY1305-ESP. The inputs to CHACHA20-POLY1305-ESP are: A 256-bit key A 32-bit sender ID A 64-bit nonce An arbitrary length plaintext Arbitrary length additional data The ChaCha20 and Poly1305 primitives are combined into an AEAD that takes a 256-bit key and 64-bit IV as follows: First the ChaCha20 block function with the key, sender ID, nonce, and zero for the block counter. From the 64-byte output, the first 32 bytes are kept as the Poly1305 256-bit key. The ChaCha20 encryption function is called to encrypt the plaintext, using the same key, sender ID, nonce and plaintext, and with the initial counter set to 1. The Poly1305 function is called with the Poly1305 key calculated above, and a message constructed as a concatenation of the following: The additional data The length of the additional data in octets (as a 32-bit network order integer) The ciphertext The length of the ciphertext in octets (as a 32-bit network order integer) Decryption is pretty much the same, but will be expanded later on. The output from the AEAD is twofold: A ciphertext of the same length as the plaintext. A 128-bit tag (the result of the Poly1305 function.

This document defines three algorithms for use with the Encapsulated Security Protocol (ESP - ) and Authentication Header (AH - ): ChaCha20 for use as an encryption algorithms for ESP. Poly1305-MAC for use as a message authentication algorithm for ESP and AH. ChaCha20-Poly1305-ESP as an AEAD algorithm for ESP.

For ChaCha20 used in ESP, the following parameters are used: The IV is 64-bit. Since this is used as the nonce for the ChaCha20 function, this IV MUST NOT repeat. The most natural way to implement this is with a counter, but anything that guarantees uniqueness can be used, such as a linear feedback shift register (LFSR). Note that the encrypter can use any IV generation method that meets the uniqueness requirement, without coordinating with the decrypter. The Internet Key Exchange protocol (IKE - ) generates a bitstring called KEYMAT that is generated from a PRF. That KEYMAT is divided into keys for encryption, message authentication and whatever else is needed. For the ChaCha20 algorithm, 256 bits are used for the key. The ChaCha20 encryption algorithm is called with the 256-bit key, one (1) for the initial counter, the packet IV as a nonce, and the plaintext. For regular IPsec, the Sender ID is set to zero. For multi-sender SAs, such as described in , there sender ID can be set to a different value for each sender. The 64-bit IV is treated as a 64-bit network order integer, and passed to the ChaCha20 function as a number. The reason that one (1) is used for the initial counter rather than zero is that one is used for encryption in the AEAD algorithm (because zero is reserved for generating the one-time Poly1305 key), so one was used here for consistency. As ChaCha20 is not a block cipher, no padding should be necessary. However, in keeping with the specification in RFC 4303, the ESP does have padding, so as to align the buffer to an integral multiple of 4 octets. The encryption algorithm transform ID for negotiating this algorithm in IKE is TBA by IANA.

You cannot use a part of the keying material directly, because Poly1305 requires a different key for each authenticated message. So the Poly1305 key for each message is generated as follows: The key for AUTH_Poly1305 is 256-bits. To determine the per-packet Poly1305 key, the ChaCha20 block function is called with the following parameters: The AUTH_Poly1305 256-bit key is used as the key. The sender ID is set to zero. The packet replay counter is used as the nonce. If Extended Sequence Numbers (ESN) are employed, then the full 64-bit is used for the nonce. Zero is used for the block counter. The 512-bit result is then truncated. The top 256 bits are used as the one-time key for Poly1305 to calculate the message authentication code (MAC). The 128-bit output serves as the MAC for the packet. All 16 bytes are included in the packet. The integrity algorithm transform ID for negotiating this algorithm in IKE is TBA by IANA.

ESP_ChaCha20-Poly1305 is a combined mode algorithm, or AEAD. The construction follows the AEAD construction in : As in , the IV is 64-bit, and is used as a nonce. Also as in , the encryption key is 256-bit. As in , the nonce, along with a block counter of zero is passed to the ChaCha20 block function, and the top part of the result used as the Poly1305 key. The ChaCha20 encryption function is then called with the nonce, the key, and an initial counter of zero. Finally, the Poly1305 function is run on the data to be authenticated, which is, as specified in a concatenation of the following: The Authenticated Additional Data (AAD) - see . The AAD length in bytes as a 32-bit network order quantity. The ciphertext The length of the ciphertext as a 32-bit network order quantity. The 128-bit output of Poly1305 is used as the tag. All 16 bytes are included in the packet. The encryption algorithm transform ID for negotiating this algorithm in IKE is TBA by IANA.

The construction of the Additional Authenticated Data (AAD) is similar to the one in . For security associations (SAs) with 32-bit sequence numbers the AAD is 8 bytes: 4-byte SPI followed by 4-byte sequence number ordered exactly as it is in the packet. For SAs with ESN the AAD is 12 bytes: 4-byte SPI followed by an 8-byte sequence number as a 64-bit network order integer.

The ChaCha20 cipher is designed to provide 256-bit security. The Poly1305 authenticator is designed to ensure that forged messages are rejected with a probability of 1-(n/(2^102)) for a 16n-byte message, even after sending 2^64 legitimate messages, so it is SUF-CMA in the terminology of . The most important security consideration in implementing this draft is the uniqueness of the nonce used in ChaCha20. This is trivial in AUTH_Poly1305, because the packet sequence number is used as a nonce, but is required for ChaCha20 as well. As said in , the nonce should be selected uniquely for a particular key. 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. The same kind of collision risk as in the above paragraph also exists in the selection of the Poly1305 key in both the AEAD construction () and in the AUTH_Poly1305 algorithm (). ChaCha20 is used to generate a 512-bit value, which is unique to each packet, but this uniqueness is not guaranteed for its 256-bit truncation, which serves as the actual key for Poly1305. While uniqueness is not guaranteed, it is still very likely. Birthday paradox calculations show that generating Poly1305 keys needs to happen over 2^101 times (way more than the 2^64 allowed by IPsec) to drive the chances of collision up to 0.00000000000001%. This is why we may safely ignore the possibility of collision.

IANA is requested to assign two values from the IKEv2 "Transform Type 1 - Encryption Algorithm Transform IDs" registry, as follows: ENCR_ChaCha20 ESP_ChaCha20-Poly1305 IANA is also requested to assign one value from the IKEv2 "Transform Type 3 - Integrity Algorithm Transform IDs" registry with name "AUTH_Poly1305".

Much of the text in this document was inspired by Adam Langley's draft for TLS, and by "inspired" I mean "shamelessly copied". The author would also like to thank Adam, Watson Ladd and Dave McGrew for allaying his fears about writing a document describing crypto.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword The University of Illinois at Chicago The University of Illinois at Chicago National Institute of Standards and Technology National Institute of Standards and Technology Cisco Systems, Inc. Cisco Systems, Inc. Porticor

In this example, we show a single run of the ChaCha20 block. For our example, we choose Key: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Sender ID: 0 Nonce: fedcba9876543210 Block Count: 5 The block is set up as follows:

After running the block function, the result is as follows:

The resulting octet string looks like this:

In this example, we show a run of the ChaCha20 encryption function. For our example, we chose some arbitrary data. Also, Key: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Sender ID: 0 IV: 0x000000000000004a (74) Message Length: 80 octets The message itself:

First, we need to apply padding. We will use an ESP-style padding, rounding up the length of the packet to 84 octets, with two padding bytes, a pad length, and a Next Header field set to 0x04:

For 84 octets, we need two blocks. We call the block function twice, once with the block counter set to 1, and then again with the block counter set to two. The results are as follows:

In this example, we show a run of the AUTH_Poly1305 message authentication function. For our example, we choose some arbitrary data - the same data as in the ENCH_ChaCha20 example above. Also, Key: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Replay Counter: 0x0000004a (74) Message Length: 80 octets The message itself:

First, we run the ChaCha20 algorithm to generate the one-time Poly1305 key:

In this example, we encrypt the same data as in , and also authenticate it. For the purposes of this example, we will assume that ESN is not used. Key: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Sender ID: 0 SPI: 0x7890abcd IV: 0x000000000000004a (74) Message Length: 80 octets The message itself:

First, we repeat the calculations in to get the one-time Poly1305 key:

Next, we need to apply padding. We will use an ESP-style padding, rounding up the length of the packet to 84 octets, with two padding bytes, a pad length, and a Next Header field set to 0x04:

Step 3, we run the ChaCha20 block twice to create sufficient keystream to XOR with all the (padded) plaintext.

next, we construct the AEAD. As described in , the AAD is a concatenation of the 4-byte SPI, followed by a 4-byte sequence number. In this case: 78:90:ab:cd:00:00:00:4a. The Poly1305 function is run over a concatenation of the AAD, the length of the AAD as a 32-bit integer (8), The ciphertext, and the length of the ciphertext (84):