ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec
Extracted elements (20)
ChaCha20-Poly1305 is proposed as a standby cipher for IPsec because AES dominates VPN deployments, and if AES is broken, the only alternative (3DES) is too slow and uses a 64-bit block that limits the data encrypted before rekeying. A fast, secure alternative cipher should be available before such a crisis occurs.
The Initial Block Counter for ChaCha20 encryption is set to 1 rather than 0. Block counter 0 is reserved for generating the one-time Poly1305 key by running the ChaCha20 block function with the same key and nonce at counter zero and taking the top 256 bits.
The AAD construction for ChaCha20-Poly1305 in ESP follows the same pattern as RFC 4106 (GCM in IPsec): SPI concatenated with the sequence number, with the ESN variant using a full 64-bit integer.
In IKEv2, the sender SHOULD include no padding and set the Pad Length field to zero. The receiver MUST accept any length of padding.
The 64-bit IV MUST be unique for each invocation under a particular SA, but does not need to be unpredictable. Use of a counter or LFSR is RECOMMENDED.
When negotiating ChaCha20-Poly1305 as an AEAD in IKEv2, INTEG (type 3) transform substructures MUST NOT be specified, or at most one INTEG transform MAY be included with value NONE (0).
AEAD_CHACHA20_POLY1305 is used for ESP and IKEv2 with a 256-bit encryption key, a 96-bit nonce formed by prepending a 32-bit Salt to a 64-bit IV, and an initial block counter of 1. The 128-bit Poly1305 tag is used as the Integrity Check Value.
For IKEv2, 36 octets of KEYMAT are requested for each of SK_ei and SK_er (first 32 = key, last 4 = salt); no octets are requested for SK_ai or SK_ar. The 64-bit IV is included explicitly in the Encrypted Payload. The AAD is 32 octets: 28-octet IKEv2 header plus 4-octet encrypted payload header.
For SAs with 32-bit sequence numbers, the AAD is 8 octets: a 4-octet SPI followed by a 4-octet sequence number in network byte order. For SAs with Extended Sequence Numbers (ESN), the AAD is 12 octets: a 4-octet SPI followed by an 8-octet sequence number in big-endian order.
IKE KEYMAT for ChaCha20-Poly1305 is 36 octets per direction: the first 32 octets are the 256-bit ChaCha20 encryption key and the remaining 4 octets are the Salt used in nonce construction.
The 96-bit ChaCha20 nonce is constructed by concatenating a 32-bit Salt (fixed per SA, derived from KEYMAT, not transmitted) with the 64-bit IV (transmitted in the ESP packet). The Salt occupies the high-order 32 bits.
The Poly1305 authenticator input is the concatenation of: AAD, zero-padding to 16-octet boundary, ciphertext, zero-padding to 16-octet boundary, AAD length as a 64-bit little-endian integer, and ciphertext length as a 64-bit little-endian integer.
The Poly1305 one-time key is derived by invoking the ChaCha20 block function with the same key and nonce as encryption but with block counter zero; the top 256 bits of the output are used as the Poly1305 key.
The transform ID ENCR_CHACHA20_POLY1305 (value 28) is used in the ENCR (type 1) transform substructure of the IKEv2 SA payload to negotiate ChaCha20-Poly1305 for both ESP and IKEv2.
IANA assigned transform identifier value 28 as ENCR_CHACHA20_POLY1305 in the 'Transform Type 1 - Encryption Algorithm Transform IDs' registry, applicable to both ESP and IKEv2.
ChaCha20 is designed to provide 256-bit security. Poly1305 is SUF-CMA (strongly unforgeable under chosen-message attacks), rejecting forged messages with probability 1-(n/2^102) for 16n-octet messages even after 2^64 legitimate messages.
Implementations must avoid side channels; this is trivial for ChaCha20 but requires care for Poly1305. Implementers should consult RFC 7539 for algorithm-level implementation considerations.
The most critical security requirement is nonce uniqueness: the nonce must be unique for each invocation under a given key. Unpredictability is not required; counters and LFSRs are both acceptable. Nonce reuse breaks confidentiality for ChaCha20.
The Salt used in nonce construction is derived from the keystream (same as the encryption key) and is never transmitted on the wire. The algorithm's security does not depend on Salt secrecy, so implementations MAY export the Salt from a security boundary, which is useful when a crypto library API accepts the nonce rather than the IV directly.
In the ESP packet, the IV field is 64 bits (the low-order 64 bits of the 96-bit nonce). The Integrity Check Value (ICV) field contains the 16-octet Poly1305 tag. Padding need not exceed 4 octets for ChaCha20, though RFC 4303 requirements still apply.