ChaCha20-Poly1305

ChaCha20-Poly1305. It is a high-performance authenticated encryption with associated data (AEAD) cipher combining the ChaCha20 stream cipher and the Poly1305 message authentication code (MAC). Designed by Daniel J. Bernstein, it was created as a secure and efficient alternative to AES-GCM, particularly for software implementations on devices without dedicated hardware acceleration. The algorithm is widely standardized and deployed in major Internet protocols, including TLS 1.2, TLS 1.3, and WireGuard.

Overview

The construction follows the Encrypt-then-MAC paradigm, where ChaCha20 performs the encryption and Poly1305 computes an authentication tag over the resulting ciphertext and any associated data. This design provides both confidentiality and integrity in a single, efficient operation. Its development was motivated by perceived weaknesses and performance limitations in existing ciphers like RC4 and certain block cipher modes of operation. The combination was formally specified in RFC 7539 by the Internet Engineering Task Force (IETF), cementing its role in modern cryptographic protocols.

Algorithm components

The ChaCha20 component is a stream cipher derived from Salsa20, using a 256-bit key, a 96-bit nonce, and a 32-bit block counter to generate a keystream via a quarter-round function applied over a 4x4 matrix of 32-bit words. The core operation involves 20 rounds of alternating column and diagonal rounds, a refinement from the original Salsa20 design proposed by Daniel J. Bernstein. The Poly1305 component is a one-time MAC that uses a 256-bit one-time key, derived from the same master key as ChaCha20, to produce a 128-bit tag. It operates in the finite field modulo \(2^{130}-5\), offering high speed and security guarantees.

Security and performance

The security of the algorithm relies on the robustness of its components: ChaCha20 is considered secure against differential cryptanalysis and linear cryptanalysis, while Poly1305 provides strong guarantees against forgery under a chosen-ciphertext attack. A significant advantage is its consistent, high-speed performance in software across various central processing unit (CPU) architectures, including those without AES-NI instructions, such as many ARM-based systems found in mobile devices and the Internet of Things. This makes it a preferred choice in protocols like WireGuard and QUIC, where latency and throughput are critical. It is also designed to be resistant to timing attacks due to its constant-time operations.

Standardization and deployment

Formal standardization began with its adoption by the IETF in RFC 7539, which defined its use for IPsec and TLS. It later became a mandatory-to-implement cipher suite in TLS 1.3, as specified in RFC 8446, replacing older algorithms like RC4 and CBC mode ciphers. Major deployments include its use as the default encryption mechanism in the WireGuard VPN protocol, within Google's QUIC protocol, and in various libraries like OpenSSL and BoringSSL. It has also received attention from standards bodies like the National Institute of Standards and Technology (NIST) in post-quantum cryptography discussions.

Implementations

Optimized implementations are available in numerous cryptographic libraries and operating systems. Notable software libraries include OpenSSL (as of version 1.1.0), LibreSSL, BoringSSL, and the NaCl library by Daniel J. Bernstein. Language-specific implementations exist for Python (via the cryptography library), Go (in its standard library), and Rust (through crates like `chacha20poly1305`). Hardware support, while less common than for AES, is emerging in some cryptographic accelerators and secure element chips. Its inclusion in the Linux kernel for WireGuard and its use in major projects like OpenSSH underscore its widespread adoption.

Category:Cryptographic algorithms Category:Internet standards