AES-GCM or ChaCha20-Poly1305: choosing a VPN data cipher

Both names are AEAD constructions, both are standardised, and on a current x86 server either one will saturate a gigabit link without visible effort. The choice stops being arbitrary when you leave that server: cheap routers, older phones and virtual appliances often lack AES acceleration, and there the difference is large. So the comparison is not "which cipher is faster" but "which cipher does this endpoint set run well, and does the protocol even offer a choice".

Same job, different cores

Both constructions give confidentiality and integrity in one pass and authenticate associated data, which is why VPN protocols use them for the data channel. The difference is inside: AES-GCM is the AES block cipher in a counter mode with a polynomial authenticator over GF(2^128), while ChaCha20-Poly1305 is a 256-bit-key stream cipher with a separate one-time authenticator.

What matters operationally is shared: both fail catastrophically on nonce reuse, both need the nonce space managed per key, and neither fixes a peer that authenticates the wrong thing. A profile that says AES-256-GCM is not more secure than one that says CHACHA20-POLY1305; both are strong when the implementation is correct.

Where AES-GCM wins

AES has dedicated instructions on most modern CPUs: AES-NI on x86, the crypto extensions on ARMv8, and equivalents on recent POWER and RISC-V designs. When those are present, GCM runs several blocks in parallel per cycle-class and the software implementation is irrelevant. This is the common case for servers, desktops and current phones, and it is why "use AES" is decent default advice in a data centre.

The problem is the second-order case. Without dedicated instructions, AES in software is slow, and table-driven software implementations are the ones with a long history of cache-timing problems. A VPN concentrator running in a virtual machine whose host does not expose AES flags to the guest is exactly this case, and it is easy to miss because the host CPU does have the feature.

Check what the process actually sees rather than what the CPU supports: grep -o aes /proc/cpuinfo | head -1 on Linux, or the equivalent feature flag in the hypervisor's CPU model.

Where ChaCha20-Poly1305 wins

ChaCha20 is fast in portable software because it uses only addition, rotation and XOR, and its implementations avoid secret-dependent table lookups by design. On a device without AES acceleration that is a material advantage, and it is the reason WireGuard chose it — the WireGuard protocol description lists ChaCha20-Poly1305 as its data cipher with no alternative.

That single choice tells you something useful: on hardware where AES is accelerated, WireGuard gives up some throughput compared to AES-GCM, and its authors accepted that in exchange for predictable behaviour across phones, home routers and container hosts. If your fleet is mostly small ARM boxes, that trade is in your favour.

The counter-case is a busy x86 concentrator, where AES-GCM with AES-NI is the faster and better-supported path, and where ChaCha20 costs measurable CPU per gigabit. Neither construction is a weakness; the question is which one your hardware executes cheaply.

What your protocol actually lets you choose

Note the split in OpenVPN: the control channel and the data channel are negotiated separately, so the suite you see for TLS says nothing about the cipher protecting your payload. The session summary reports both, and reading only one of the two is a common source of confusion.

In OpenVPN the data channel cipher comes from the data-ciphers list on both ends. If the server's list and the client's list do not intersect, the connection either falls back to whatever data-ciphers-fallback allows or fails outright, and that failure is usually blamed on the wrong layer. Set the same list on both sides, then confirm the negotiated result in the log rather than assuming the order of the list was honoured.

Decide from three facts about the deployment

First, do the endpoints have AES acceleration? If every peer does, AES-GCM is the cheaper choice and the default in most maintained configurations. If a meaningful share are small routers or older phones, ChaCha20-Poly1305 keeps the tail of the fleet from becoming the capacity limit.

Second, does the protocol offer a choice at all? With WireGuard the decision was made for you, and the useful work is verifying that the tooling around it is not silently substituting something else. With OpenVPN and IPsec, the answer is a configuration line and a negotiated result to record.

Third, can both ends agree? A cipher that one peer does not implement is not a performance decision, it is an outage. That is why the peer list matters more than any benchmark: a mixed fleet needs the intersection of capabilities, not the preference of the fastest machine.

If you do measure, keep the device, the endpoint and the workload identical and change one thing. A test that compares two servers in different regions measures the route, not the cipher, and a laptop benchmark tells you nothing about a container host whose CPU flags are masked. Compare, then write down which cipher was actually negotiated — that record is worth more than the benchmark.