AES vs ChaCha20: Which Symmetric Encryption Algorithm Should You Use

The Highway and the City Street

Imagine you need to move goods between two warehouses every day. Two routes are available.

The first is a motorway. Wide, straight, purpose-built for speed. There is one catch: it requires a special electronic toll pass that only works on this road. If you have the pass, you fly — nothing moves faster. If you do not have it, you crawl behind barriers while the system tries to process you manually.

The second is a city street. More turns, more traffic lights, never quite as fast as the motorway at its theoretical best. But it accepts every vehicle, needs no special pass, and keeps flowing even when the motorway toll systems are down.

This is the difference between AES and ChaCha20.

AES is the motorway. When running on modern hardware with dedicated AES acceleration — built into virtually every server and desktop processor made in the last decade — it is extraordinarily fast. Nothing encrypts bulk data faster when the conditions are right.

ChaCha20 is the city street. Not quite as fast as AES on ideal hardware, but fast and consistent everywhere: older phones, embedded controllers, devices that never received hardware crypto support. And it is simpler to implement securely, which is why it became the cipher of choice for Signal, WhatsApp, and WireGuard.

Both are gold-standard symmetric encryption algorithms. Both are considered secure against all known practical attacks. Neither is a wrong choice from a security standpoint. But one will be a better fit for your specific deployment — and understanding why requires understanding the hardware underneath.

Quick Decision Snapshot

Not sure which to pick? Start here. The rest of the article explains the reasoning in full — but if you need a fast orientation before diving in:

1. Building for servers or cloud infrastructure? → Use AES-256-GCM
2. Building for mobile, or supporting a wide range of devices? → Use ChaCha20-Poly1305
3. Building a web server that serves all kinds of clients? → Support both and let TLS negotiate automatically
4. Subject to compliance rules (FIPS, PCI DSS, government standards)? → AES-256-GCM is likely mandated

Keep this in mind as you read. Every detail that follows is in service of one of these four decisions.

A Quick Refresher on Symmetric Encryption

Symmetric encryption uses the same secret key to both encrypt and decrypt data.

Here's the key idea: think of it like a lockbox where the same physical key both locks and unlocks it. It is fast, computationally efficient, and well-suited to encrypting large volumes of data. The challenge with symmetric encryption has never been speed or security — it is key distribution. How do you get the same secret key to both parties without an attacker intercepting it along the way?

AES and ChaCha20 solve the encryption half of that problem. Key distribution is handled elsewhere — typically by a key exchange protocol like Diffie-Hellman, which lets two parties agree on a shared secret over a public channel without ever transmitting the secret itself. Once that shared secret is established, a key derivation function (think of it as a recipe that turns raw secret material into a properly formatted encryption key) produces the symmetric keys used for actual data encryption.

What this means in practice: AES and ChaCha20 are the engines at the end of that chain. They do the heavy lifting of encrypting the actual bytes — but they do not work alone, and they do not handle the problem of getting keys to both sides.

AES: The Established Standard

AES — the Advanced Encryption Standard — was selected by the US government in 2001 following a rigorous open competition and has been the worldwide default for symmetric encryption ever since. Its longevity is not inertia. It reflects twenty-five years of sustained cryptanalysis that has found no practical weakness in the full algorithm.

The basics: AES encrypts data in fixed 128-bit blocks — chunks of 16 bytes at a time. It supports key sizes of 128, 192, or 256 bits. AES-256 is the standard choice for high-security applications and is mandatory in many regulated environments. AES-128 is also fully secure against all known attacks and is slightly faster, though the difference is rarely the deciding factor for most applications.

What Makes AES Fast

The short answer: dedicated silicon.

Modern server and desktop CPUs include a set of hardware instructions called AES-NI (AES New Instructions), introduced around 2010. When these are present, AES operations are handed off to specialised circuits built directly into the processor — bypassing the general-purpose execution units entirely. The result is encryption speeds measured in gigabytes per second per core.

What this means in practice: software alone cannot get close to that speed. AES-NI is what separates AES on a server from AES on a cheap IoT device — and it is why the same algorithm behaves so differently in different environments.

Most modern ARM processors (ARMv8 and later, including all recent iPhone chips and high-end Android processors) include equivalent AES acceleration, so this hardware advantage is no longer limited to data centres.

Where AES Appears

AES is essentially everywhere symmetric encryption is used at scale: full-disk encryption (BitLocker on Windows, FileVault on macOS, LUKS on Linux), Wi-Fi security (WPA2, WPA3), TLS connections, database encryption, VPN tunnels, and compressed archive formats. If a system was built in the last decade and needs symmetric encryption, it almost certainly uses AES.

Modes of Operation — Why They Matter

Here's a concept that trips up many beginners, so read this carefully.

AES in its raw form only encrypts a single 16-byte block at a time. To encrypt anything longer — a file, a web request, a database record — you need a mode of operation that defines how multiple blocks are chained together. The mode you choose is just as important as the algorithm itself.

GCM (Galois/Counter Mode) is the mode you should use for all new systems. AES-GCM does two things at once: it encrypts the data and generates an authentication tag that proves the data has not been tampered with. In plain terms: it hides the data and guarantees no one has changed it — in a single pass. This property has a formal name: Authenticated Encryption with Associated Data, or AEAD. Think of AEAD as a sealed envelope that is both locked and tamper-evident. If anyone opens it en route, you will know.

CBC (Cipher Block Chaining) is an older mode that provides encryption only — no tamper detection. Without a separate authentication mechanism bolted on, an attacker can modify CBC ciphertext in transit and produce predictable changes in the decrypted output. CBC is still found in legacy systems, but it should not appear in new code.

ECB (Electronic Codebook) should never be used. It encrypts every block independently, which means identical chunks of data always produce identical ciphertext. Patterns in the original data remain visible through the encryption. There is a well-known demonstration of this flaw: a bitmap image of the Linux Tux mascot, when encrypted with ECB, remains perfectly recognisable in the ciphertext. The outline is still there. Avoid ECB entirely.

The One Rule You Must Not Break

Never reuse an initialisation vector (IV) with the same key.

An IV is a random value mixed into the encryption to ensure that encrypting the same data twice produces different ciphertext. For AES-GCM, reusing an IV with the same key is catastrophic — it allows an attacker to recover the authentication key, which means they can both decrypt messages and forge new ones. Use randomly generated 96-bit IVs, or use a counter-based scheme designed to guarantee uniqueness.

ChaCha20: The Modern Contender

ChaCha20 was designed by cryptographer Daniel Bernstein in 2008 to solve a specific problem: AES is only fast when hardware acceleration is present. On devices without AES-NI, AES runs entirely in software and becomes significantly slower. ChaCha20 was built to be fast in software on any processor, without needing special hardware.

The key design choice: instead of the block-based structure AES uses, ChaCha20 is a stream cipher. Here is how it works in plain terms: it takes your key and a unique number (called a nonce), and uses them to generate a long stream of random-looking bytes. It then combines that stream with your data byte-by-byte to scramble it. Think of it as producing a one-time mask the exact length of your message and laying it over the plaintext to hide it. The receiver, who has the same key and nonce, generates the identical mask and removes it to reveal the original data.

Why this matters for performance: the operations involved — additions, bitwise rotations, and XOR — are available and fast on every CPU ever made. There are no special circuits required. ChaCha20 is fast everywhere, not just on hardware built for it.

ChaCha20 uses 256-bit keys only. There is no smaller variant.

ChaCha20-Poly1305: The Complete Package

ChaCha20 on its own only encrypts — it does not verify integrity. So it is almost always paired with Poly1305, a fast authentication code. Together they form an AEAD scheme, providing the same guarantee as AES-GCM: the data is both encrypted and protected against tampering. In plain terms: ChaCha20-Poly1305 hides your data and tells you immediately if anyone has touched it in transit.

When you see ChaCha20-Poly1305 in a library or TLS configuration, that is the complete, production-ready form. You rarely need to think about ChaCha20 and Poly1305 separately.

Where ChaCha20 Appears

ChaCha20-Poly1305 is the cipher used by Signal and WhatsApp for message encryption. WireGuard, the modern VPN protocol, uses it exclusively. Modern web browsers support it as a TLS cipher suite and prefer it automatically when connecting from devices that lack hardware AES acceleration.

What this means in practice: if you send a message on Signal, it is encrypted with ChaCha20. If you connect to a VPN via WireGuard, all traffic is encrypted with ChaCha20. It is not an obscure or experimental algorithm — it is battle-hardened and deployed at massive scale.

A Note on Nonce Misuse Resistance

The same rule that applies to AES-GCM applies here: never reuse a nonce with the same key. If you are generating nonces randomly rather than with a reliable counter, consider XChaCha20-Poly1305 instead — it uses a 192-bit nonce, large enough that random generation is safe even across billions of messages. The equivalent for AES users is AES-GCM-SIV, which tolerates accidental nonce reuse without catastrophic failure.

The Performance Picture

Performance comparisons between AES and ChaCha20 depend almost entirely on one question: is hardware acceleration present?

On server hardware — which describes virtually every cloud instance and data centre machine — AES-256-GCM is substantially faster than ChaCha20. The dedicated silicon is that effective. For bulk data encryption, disk encryption, or any server-side workload, AES is the clear performance winner in this environment.

On devices without hardware AES support — older smartphones, low-power IoT devices, microcontrollers — ChaCha20 can be significantly faster. It was designed for exactly this environment. On such devices, choosing AES means paying a software performance cost on every encrypted byte, which translates directly into slower responses.

On modern mobile devices the picture blurs. iPhones from the A7 chip (2013) onward and most flagship Android devices include hardware AES acceleration — so on these devices, AES and ChaCha20 perform comparably. The problem is that "modern mobile devices" is not a uniform category. A developer supporting Android back to version 8 will encounter a wide range of hardware. ChaCha20 provides consistent performance across all of it; AES does not.

The practical guidance, simply stated: for servers, use AES — the hardware is there. For mobile with broad device support, use ChaCha20 — the consistency is worth more than the peak speed AES offers on high-end devices. For systems serving both, support both and let TLS handle the decision automatically.

Security: Both Are Excellent — and That Is Not a Cliché

This is the most important section in the article, so read it carefully.

The choice between AES and ChaCha20 is not a security choice. Both AES-256 and ChaCha20 are considered cryptographically secure. Neither has any known practical attack against the full algorithm.

Here's the key idea: you are choosing between two equally strong locks. The question is which lock is easier for you to install correctly in your specific situation.

AES has twenty-five years of public cryptanalysis behind it. The best-known theoretical attacks against AES-128 require computational resources so large they will never be practical. AES-256 provides an even larger security margin and is the mandated choice in frameworks including FIPS 140-3, PCI DSS, and numerous government standards. If compliance is a constraint in your environment, AES-256 is likely not optional.

ChaCha20 descends from Salsa20, which has been publicly analysed since 2005 with no practical weaknesses found. ChaCha20 improves on it. Its simpler structure means there is less surface area for implementation errors — writing correct, constant-time code (code that does not leak information through how long it takes to execute) is more straightforward for ChaCha20 than for AES. Some cryptographers express a preference for ChaCha20 precisely because its simplicity makes implementations easier to verify.

Other Symmetric Algorithms You May Encounter

AES and ChaCha20 are the only symmetric algorithms you should consider for new systems. Others appear in legacy code — here is what to know about them.

RC4 was once widely used in WEP and early TLS. It is broken. Statistical biases in its output allow attackers to recover plaintext from sufficient ciphertext. Do not use it under any circumstances, and treat any codebase that still uses it as a security liability.

DES and 3DES date from the 1970s. DES has a 56-bit key that can be brute-forced in hours on modern hardware. 3DES applies DES three times for better security, but it is slow and uses 64-bit blocks — too small for modern data volumes. Both are formally deprecated. Treat them as you would RC4.

Blowfish and Twofish come from the 1990s. Blowfish uses 64-bit blocks, which create statistical collision problems at data volumes that are routine today. Twofish was an AES competition finalist but lost. Neither should appear in new code.

Salsa20 is ChaCha20's predecessor. ChaCha20 is strictly better. If you encounter Salsa20 in a codebase, treat it as a migration candidate.

SM4 is China's national symmetric encryption standard and is mandatory for certain products sold in Chinese markets. If your deployment includes Chinese regulatory requirements, SM4 may be a requirement rather than a choice.

How to Choose: The Full Decision Framework

The quick snapshot at the top of this article gave you the fast answer. Here is the reasoning behind it.

The choice comes down to four factors: your deployment environment, your hardware assumptions, your compliance requirements, and your implementation context.

Use AES-256-GCM when your application runs on server or cloud infrastructure where hardware AES acceleration is universally present. Use it for bulk data encryption — disk encryption, database encryption, large file storage — where throughput matters and the hardware is controlled. Use it when you must satisfy FIPS 140-3, PCI DSS, or government standards that explicitly mandate AES. And use it as a sensible default when you have no strong reason to do otherwise — AES on modern server hardware is extensively audited, widely understood, and supported everywhere.

Use ChaCha20-Poly1305 when your primary platform is mobile and you need consistent performance across a wide range of devices, including older hardware without AES acceleration. Use it when you are building messaging or real-time communication applications. Use it when you are implementing encryption in an environment where hardware acceleration cannot be guaranteed. Use it when you want implementation simplicity and side-channel resistance to be properties of the algorithm rather than something you have to engineer separately.

Support both when you are building a web server with a diverse client base. Modern TLS libraries handle cipher suite negotiation automatically: the client sends a list of what it supports, the server selects the best mutually supported option, and each client gets the cipher suited to its hardware. There is no performance or security cost to supporting both.

Where These Algorithms Fit in the Broader Security Stack

AES and ChaCha20 encrypt actual data. To understand their role, it helps to see the full chain they sit at the end of.

In TLS (the protocol behind HTTPS): when your browser connects to a website, a handshake happens first. Asymmetric cryptography (RSA or elliptic curve keys) verifies the server's identity. A key exchange protocol (Diffie-Hellman) allows both sides to agree on a shared secret without ever sending it across the network. A key derivation function turns that secret into usable symmetric keys. Then — and only then — AES-GCM or ChaCha20-Poly1305 encrypts the actual traffic: the web page, the API response, the authentication token. The symmetric cipher is the last step, but it handles the vast majority of the data volume.

In disk encryption: your laptop's drive is encrypted with AES. The key is derived from your login password using a password-based key derivation function (PBKDF2 or Argon2) designed to be deliberately slow — making brute-force attacks expensive. Every file read and write passes through AES transparently. You never notice it happening, but it is happening constantly.

In messaging apps: Signal and WhatsApp use ChaCha20-Poly1305 within a protocol that continuously generates new keys — one per message. Each message is encrypted with a key that has never been used before and will never be used again. If an attacker somehow obtained one message key, they could decrypt only that single message. No past messages, no future ones.

In VPNs: WireGuard uses ChaCha20-Poly1305 exclusively. OpenVPN and IPsec support both, with AES being more common in enterprise configurations partly because of compliance requirements.

In hardware security modules (HSMs): these are tamper-resistant devices used in enterprise and payment systems to store keys securely. AES dominates here, both because HSMs are built around hardware AES acceleration and because most HSM-relevant regulatory frameworks mandate AES explicitly.

What to Take Away

After working through this article, you should be able to make a clear, reasoned choice between these two algorithms for any deployment you encounter.

The core insight is this: the choice is about hardware environment and implementation context, not about which algorithm is safer. Both AES-256 and ChaCha20 are secure. Both are actively maintained. Both are trusted by the organisations with the most to lose from getting encryption wrong.

AES-256-GCM is the right default for server and cloud workloads where hardware acceleration is present and compliance requirements may mandate AES. ChaCha20-Poly1305 is the right choice for mobile applications, messaging systems, and any context where consistent performance across diverse hardware matters more than peak throughput. For systems serving both, support both cipher suites and let TLS negotiation handle the decision.

Neither algorithm is going away. Choosing between them is an engineering optimisation — not a gamble.

The Highway and the City Street, Revisited

The motorway — AES — is exceptional when the conditions are right. On a modern server with hardware acceleration, encrypting data with AES-GCM is one of the most efficient operations a CPU performs. Your cloud infrastructure, your data centre, your development laptop — these are the motorway. Use it.

The city street — ChaCha20 — is never quite as fast as the motorway at its absolute best. But it works reliably everywhere, on every device, without any special pass. Your users' ageing Android phones, your IoT sensor nodes, the embedded controller in a piece of industrial equipment — these are the city street. ChaCha20 keeps them moving when AES would crawl.

The best-engineered systems support both and route automatically based on what each client brings to the connection. The motorway is faster when the conditions are right. The city street is more reliable when they are not. Your job is to build a system that reads the conditions correctly — and chooses accordingly.