# ChaCha20 vs AES-GCM: When to Pick Which **Source**: https://quantumsequrity.com/blog/chacha20-vs-aes **Category**: Cryptography Foundations --- [← Back to Blog](../../blog.html) Cryptography Foundations # ChaCha20 vs AES-GCM: When to Pick Which 11 min read When you connect to a website over HTTPS, send a message on Signal, or open a WireGuard VPN tunnel, one of two stream ciphers is doing the heavy lifting: AES-GCM or ChaCha20-Poly1305. Both are considered safe by NIST and by every serious cryptographer in the world. Both protect billions of connections every day. So why do we still have two of them, and how does an engineer pick one over the other? The short answer is that AES-GCM is faster on modern desktop and server processors thanks to dedicated hardware, while ChaCha20 is faster and safer on phones, embedded devices, and any chip that does not have AES instructions. The longer answer involves side-channel resistance, software simplicity, and a famous design philosophy from cryptographer Daniel J. Bernstein. ## Where AES Came From AES, the Advanced Encryption Standard, was selected by the US National Institute of Standards and Technology in 2001 after a five-year open competition. The winning design was Rijndael, created by Belgian cryptographers Vincent Rijmen and Joan Daemen. NIST published it as FIPS 197. AES is a block cipher. It takes a fixed 128-bit chunk of plaintext and a key, and produces a 128-bit chunk of ciphertext. To encrypt files or network traffic that are longer than 128 bits, you wrap AES in a "mode" such as GCM (Galois/Counter Mode) or CTR (Counter mode). GCM is the default authenticated mode used in TLS, IPsec, and most modern protocols. In 2008 and 2010, Intel and AMD started shipping a special instruction set called AES-NI directly inside their CPUs. Instead of running roughly 200 software operations per AES block, the chip can execute one round in a single clock cycle. AES-NI made AES the fastest cipher on any laptop, desktop, or server made in the last fifteen years. ## Where ChaCha20 Came From ChaCha20 was published in 2008 by Daniel J. Bernstein as a refinement of his earlier Salsa20 cipher (2005). Salsa20 was a finalist in the European eSTREAM project, which ran from 2004 to 2008 and selected stream ciphers suitable for software and hardware. ChaCha20 is a stream cipher built around an "ARX" design: it only uses three operations on 32-bit words, namely Add, Rotate, and XOR. There are no S-boxes, no lookup tables, no modular multiplication. The whole cipher is twenty rounds of mixing eight 32-bit words. The simplicity is the point. ChaCha20 was designed to run quickly in pure software, on any CPU, without leaking timing information through cache hits and misses. In 2013 and 2014, Google adopted ChaCha20-Poly1305 for TLS connections from Android phones and Chrome browsers, especially when the device did not have AES hardware acceleration. The IETF formally standardized it as RFC 7539 in 2015 and updated it as RFC 8439 in 2018. ## How Both Ciphers Actually Work AES-GCM combines two pieces. First, AES in counter mode (AES-CTR) generates a keystream by encrypting an incrementing counter. The keystream is XORed with the plaintext to produce ciphertext. Second, GCM uses a GHASH function over GF(2 to the 128) to produce a 128-bit authentication tag that detects tampering. ChaCha20-Poly1305 follows the same idea. ChaCha20 generates a keystream by repeatedly running its 20-round permutation on a 512-bit state and incrementing a counter. The keystream is XORed with the plaintext. Then Poly1305, a one-time MAC invented by Bernstein in 2005, produces a 128-bit tag. Both schemes give you confidentiality (nobody can read your plaintext) and integrity (nobody can tamper with the ciphertext without the receiver noticing). Both are AEAD, which stands for Authenticated Encryption with Associated Data. Read more in [AES-256-GCM Explained](aes-256-gcm-explained). ## Performance: The Numbers That Matter On a modern Intel or AMD desktop CPU with AES-NI and PCLMULQDQ instructions, AES-GCM is dramatically faster than ChaCha20. Benchmarks routinely show AES-GCM hitting 5 to 7 GB/second on a single core, while ChaCha20-Poly1305 reaches 2 to 3 GB/second. On a low-end ARM smartphone or microcontroller without AES hardware, the picture flips. AES becomes a software bit-slicing exercise that runs at 100 to 300 MB/second, while ChaCha20 still runs at 800 MB/second to 1.5 GB/second. ChaCha20 can be 3 to 5 times faster than AES on hardware that has no AES extension. Modern ARM chips since the ARMv8 generation include the AES extension as well, which closes the gap. Apple Silicon, recent Snapdragon, and most flagship Android SoCs all support AES in hardware. But not everything is a flagship. Many IoT chips, low-cost laptops from a decade ago, and embedded controllers still have no AES instruction. ## Side-Channel Resistance: The Quieter Question Performance gets the headlines. Side channels deserve more attention. A side-channel attack does not break the math of the cipher. It steals information from how the cipher is executed: timing, power use, electromagnetic emissions, or cache access patterns. AES has had a long history of cache-timing attacks against software implementations because the most natural code uses lookup tables. The keys leak through which cache lines are touched. Constant-time AES implementations exist, but they require either AES-NI hardware or expensive bit-slicing tricks. Without AES-NI, "fast software AES" and "constant-time AES" are mostly different goals. ChaCha20 was designed from day one to run in constant time on any architecture. Add, Rotate, and XOR all take the same number of cycles regardless of operand values. There are no data-dependent branches and no lookup tables. The cipher leaks nothing through cache or branch behavior. This matters for cloud, mobile, and shared-tenant environments where an attacker might run code on the same physical CPU as the victim. ChaCha20 has fewer historical CVEs in this category, and the ones that exist are usually about misuse rather than the cipher itself. ## Nonce Misuse: Both Sides Are Brittle AES-GCM and ChaCha20-Poly1305 share one dangerous property: if you ever reuse a nonce with the same key, security collapses. Reusing a nonce with AES-GCM lets an attacker recover the GHASH key and forge arbitrary messages. Reusing a nonce with ChaCha20-Poly1305 is just as bad and reveals the XOR of two plaintexts. For both, the standard nonce length is 96 bits in AES-GCM (12 bytes) and 96 bits in ChaCha20-Poly1305 (RFC 8439). The total number of distinct nonces under one key must stay below about 2 to the 32 to keep the collision probability low when you generate them randomly. That is why long-lived keys must use a counter-based nonce, not a random one. Read more in [AES-256-GCM Explained](aes-256-gcm-explained). XChaCha20-Poly1305 fixes this by using a 192-bit nonce, which is large enough to pick at random for 2 to the 80 messages without worry. AES-GCM has no comparable extension in the standard. ## How TLS Actually Decides In the TLS 1.3 handshake (RFC 8446), the client offers a list of cipher suites in order of preference. The server picks one and tells the client. The decision usually follows this rule: - If both client and server have AES-NI hardware, both prefer AES-GCM. - If either side lacks AES-NI, both prefer ChaCha20-Poly1305. Google Chrome includes a feature called the "equal preference cipher suite" mechanism, where Chrome on Android offers ChaCha20 first if the device does not have AES hardware. Most Android devices below the flagship tier still rely on ChaCha20 for HTTPS as of 2026. ## What QNSQY Uses QNSQY's hybrid encryption pipeline uses AES-256-GCM as the default symmetric layer because the binary runs primarily on x86_64 desktops, servers, and modern laptops where AES-NI is universal. The symmetric data-encryption key is wrapped by a hybrid post-quantum KEM, namely ML-KEM combined with X25519 (read more in [ML-KEM Explained](ml-kem-explained) and [Hybrid Encryption](hybrid-encryption)). For specific use cases, particularly mobile chat clients and embedded sensor networks where AES-NI is not guaranteed, ChaCha20-Poly1305 remains a viable alternative. The QNSQY file format reserves AEAD identifier bytes so future builds can negotiate ChaCha20 without breaking compatibility. ## Quantum Resistance: Same Story for Both Grover's algorithm reduces the effective brute-force complexity of any symmetric cipher by half. AES-256 drops from 256 bits of classical security to 128 bits of quantum security. ChaCha20 drops from 256 to 128 bits as well. Both numbers are still considered safe. NIST's recommendations for post-quantum readiness call for using 256-bit symmetric keys as the lower bound. Both AES-256-GCM and ChaCha20-Poly1305 meet this requirement. Read more in [Grover's Algorithm Explained for Layman](grover-algorithm-explained-layman). ## When to Pick Which The 2026 picture is simpler than it used to be: - Servers and desktops with AES-NI: AES-256-GCM. It is faster, well audited, and the IANA-default in TLS 1.3. - Phones and laptops without AES-NI: ChaCha20-Poly1305. It is faster and resists cache timing without effort. - Embedded systems and IoT: ChaCha20-Poly1305 unless you have hardware AES. The smaller code footprint and constant-time behavior matter more than peak throughput. - Cloud workloads on shared CPU silicon: ChaCha20-Poly1305 if you are concerned about cross-VM cache attacks. AES-NI mitigates this in practice, but ChaCha20 mitigates it by design. - Long-lived secrets where nonce reuse is a real risk: XChaCha20-Poly1305 with its 192-bit nonce. ## Implementation Surface and Auditability A subtler difference: ChaCha20 implementations tend to be much shorter than AES implementations. A complete ChaCha20-Poly1305 in clean C fits in roughly 300 to 500 lines. A complete AES-GCM with hardware acceleration paths and software fallback paths runs to 2000 lines or more. The size difference matters for audited code where every line must be reviewed. This is part of why projects like WireGuard, Monocypher, and the Noise Protocol Framework chose ChaCha20-Poly1305 as their default AEAD. The smaller surface makes the code easier to audit, easier to formally verify, and easier to port to new platforms. For software running on millions of devices, the auditability and portability advantages can outweigh raw throughput. AES wins benchmarks; ChaCha20 wins clean review. ## The Long Lifecycle Both AES and ChaCha20 are expected to remain safe for decades against classical adversaries. NIST has shown no intention to deprecate AES. The IETF has no plans to remove ChaCha20-Poly1305 from TLS 1.3 or QUIC. Both algorithms have been hammered on by academic researchers, intelligence agencies, and bug bounty hunters for over fifteen years without a meaningful break. The next pivot for both is the post-quantum migration of the surrounding key exchange. Symmetric encryption itself stays roughly the same: AES-256 and ChaCha20 with 256-bit keys remain safe under quantum attack thanks to Grover's modest speedup. What changes is the layer above: instead of an X25519 or RSA key delivering the AEAD key, an ML-KEM hybrid delivers it. The cipher choice for 2030 is not "AES or ChaCha20" but "what hybrid post-quantum primitive delivers the AEAD key." Both AES-GCM and ChaCha20-Poly1305 will be at the bottom of the stack regardless. ## FAQ **Is one cipher really more secure than the other?** No serious cryptographer rates one above the other for security. Both have endured 15+ years of public scrutiny without a meaningful break. The real differences are speed and side-channel surface area. **Why does TLS still negotiate AES-GCM by default?** Because IANA's cipher suite registry lists AES-128-GCM-SHA256 as the mandatory baseline for TLS 1.3 (RFC 8446 Section 9.1). Servers must support it. ChaCha20-Poly1305 is recommended but optional. **Will quantum computers break AES or ChaCha20?** No, not in any practical sense. Grover's algorithm halves brute-force time, but breaking AES-256 still requires roughly 2 to the 128 quantum operations, which is far beyond any imaginable quantum machine. **Should I use AES-128 or AES-256?** For long-term confidentiality, use AES-256. For most TLS connections, AES-128-GCM is faster and still gives 128-bit classical security. NIST recommends 256-bit keys for data that must remain confidential after large quantum computers exist. **What about AES-OCB or AES-CCM?** OCB is patent-encumbered until recently and was never widely deployed in TLS. CCM is used in constrained environments like Bluetooth Low Energy and IEEE 802.15.4. GCM beats both for general-purpose performance on modern hardware. ## Sources 1. NIST FIPS 197: Advanced Encryption Standard (AES). https://csrc.nist.gov/pubs/fips/197/final 2. NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. https://csrc.nist.gov/pubs/sp/800/38/d/final 3. IETF RFC 8439: ChaCha20 and Poly1305 for IETF Protocols. https://www.rfc-editor.org/rfc/rfc8439 4. IETF RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. https://www.rfc-editor.org/rfc/rfc8446 5. Daniel J. Bernstein, "ChaCha, a variant of Salsa20" (2008). https://cr.yp.to/chacha/chacha-20080128.pdf 6. eSTREAM Project Final Report. https://www.ecrypt.eu.org/stream/ ## Related Articles - [AES-256-GCM Explained](aes-256-gcm-explained) - [Hybrid Encryption](hybrid-encryption) - [ML-KEM Explained](ml-kem-explained) - [Grover's Algorithm Explained for Layman](grover-algorithm-explained-layman) - [What Is Post-Quantum Cryptography](what-is-post-quantum-cryptography) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)