Every time you connect to a VPN, a quiet negotiation happens before a single byte of your traffic moves. Your device and the VPN server agree on a cipher, exchange keys, and build a tunnel that — in theory — turns your data into unreadable noise for anyone watching in between. But “encrypted” is not a single state. It is a stack of decisions, and the cipher named on a provider’s marketing page is only the most visible one.
In this guide we open up that stack layer by layer: the symmetric ciphers that scramble your actual traffic, the handshake mechanisms that establish trust, and the protocol choices that determine how all of it fits together. By the end, you’ll be able to read a VPN’s technical specification sheet the way an engineer does — and spot the difference between genuine security and encryption theater.
What Encryption Actually Does Inside a VPN Tunnel
A VPN tunnel performs two separate cryptographic jobs at once. First, a handshake establishes a shared secret between your device and the server without ever transmitting that secret in the clear — this is where key exchange algorithms like Elliptic-Curve Diffie-Hellman (ECDH) come in. Second, once that shared secret exists, a symmetric cipher uses it to encrypt and decrypt the actual stream of packets flowing through the tunnel. Symmetric ciphers are fast enough to handle real-time traffic; asymmetric cryptography is reserved for the handshake because it’s computationally heavier but doesn’t require a pre-shared secret.
Confusing these two jobs is the single most common mistake people make when comparing VPN providers. A provider can advertise “256-bit encryption” while using a weak or outdated handshake mechanism, and the marketing claim remains technically true while the real-world security is mediocre.
AES-256: The Industry Workhorse
The Advanced Encryption Standard with a 256-bit key (AES-256) is the cipher the U.S. government uses to protect classified information, and it has been the default choice for VPN providers for well over a decade. It operates as a block cipher, encrypting data in fixed 128-bit chunks, and when implemented in GCM (Galois/Counter Mode) it also provides authentication — meaning the receiving end can detect if traffic was tampered with in transit, not just decrypt it.
AES-256 has no known practical attack that reduces its effective security below brute force — and brute-forcing a 256-bit key would take longer than the current age of the universe with all of today’s computing power combined.
The catch with AES is that it’s computationally intensive unless the processor has dedicated hardware acceleration (AES-NI, present in nearly all modern CPUs). On hardware without that acceleration — some older routers, budget IoT devices, low-power ARM chips — AES-256 can visibly slow down a connection.
ChaCha20-Poly1305: Built for Speed and Mobile
ChaCha20, paired with the Poly1305 authenticator, was designed by cryptographer Daniel J. Bernstein specifically to perform well in software, without needing dedicated hardware support. That makes it the preferred cipher for mobile devices, older hardware, and any environment where AES-NI isn’t guaranteed to be present. It’s also the cipher used by default in the WireGuard protocol, which has become the backbone of most modern VPN apps.
| Property | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| Cipher type | Block cipher | Stream cipher |
| Key size | 256-bit | 256-bit |
| Needs hardware acceleration | Yes, for best performance | No |
| Best on mobile / ARM | Good with AES-NI | Excellent |
| Typical protocol pairing | OpenVPN, IKEv2 | WireGuard |
Neither cipher is objectively “more secure” than the other at 256-bit key length — both are considered unbroken and suitable for protecting highly sensitive data. The right choice depends on the hardware doing the encrypting, not on which name sounds more advanced.
The Handshake: Where Trust Is Actually Established
Older protocols like OpenVPN typically rely on RSA key exchange combined with TLS, often using 2048-bit or 4096-bit RSA keys. Modern protocols favor Elliptic-Curve Diffie-Hellman (ECDH), which achieves equivalent security with much smaller keys and faster computation. WireGuard goes a step further with its Noise Protocol Framework, which formalizes the handshake into a small, auditable sequence of cryptographic operations — one of the reasons WireGuard’s entire codebase can be reviewed in a fraction of the time OpenVPN’s can.
A property worth specifically checking for is Perfect Forward Secrecy (PFS): a fresh encryption key generated for every session, so that even if a single session key were somehow compromised, previously captured traffic would remain unreadable. We cover this in depth in a companion piece on Goliry, but it’s worth flagging here — a provider skipping PFS undermines the value of even the strongest symmetric cipher.
Why the Cipher Name Isn’t the Whole Story
Strong cryptography can be undermined by weak implementation. A few things matter as much as the cipher itself:
- Open-source, audited code — a correct algorithm implemented incorrectly is often worse than a slightly weaker algorithm implemented correctly.
- Key management — how often session keys rotate, and whether the provider can technically reconstruct them.
- DNS and IPv6 leak protection — encryption inside the tunnel means little if requests slip outside it.
- Jurisdiction and logging policy — the strongest cipher can’t protect you from a provider that keeps connection logs and is legally compelled to hand them over.
- Does the provider name both the cipher and the handshake mechanism, not just “256-bit encryption”?
- Is the client app’s source code published or independently audited?
- Does the protocol support Perfect Forward Secrecy?
- Is there a published, third-party-verified no-logs audit?
Real-World Performance: What Users Actually Notice
Cipher choice isn’t just an abstract security question — it shows up in day-to-day speed. On a modern laptop or phone with AES-NI hardware support, AES-256-GCM and ChaCha20-Poly1305 perform almost identically, and most people would never detect a difference in a blind test. The gap opens up on lower-power devices: budget routers, older smart TVs, some IoT hubs, and a handful of ARM-based single-board computers that lack AES acceleration entirely. On that class of hardware, forcing AES-256 can cut throughput noticeably, sometimes by half or more, simply because the processor has to fall back to slower software-only AES routines.
This is part of why WireGuard’s default use of ChaCha20 was a deliberate design decision rather than an arbitrary one. The protocol’s authors wanted consistent performance across the widest possible range of devices — from a flagship phone to a cheap travel router — without needing to detect hardware capabilities and switch ciphers on the fly. If you’ve noticed a VPN app run faster on one device and slower on another despite an identical subscription and server location, mismatched hardware acceleration for the underlying cipher is one of the more common, least-discussed explanations.
Reading a Provider’s Technical Page Like an Engineer
Most VPN comparison content stops at “uses AES-256,” treating that as the end of the investigation. A more useful habit is to look for the full sentence structure a provider uses to describe its cryptography. A page that reads “AES-256-GCM with ECDHE key exchange over TLS 1.3, forward secrecy enabled by default” is describing an actual, checkable system. A page that reads only “military-grade 256-bit encryption” is describing a feeling. Neither statement is necessarily false, but only one gives you something concrete enough to verify against the app’s actual configuration, a third-party audit, or the open-source code repository if one is published.
It’s also worth checking whether the cipher and handshake details are consistent across the provider’s website, app settings, and any published transparency or audit documentation. Inconsistency between these three sources — for example, a website claiming ChaCha20 while the app’s advanced settings only expose AES — is a useful, if unglamorous, signal about how carefully the rest of the product has been maintained.
Frequently Asked Questions
Is 256-bit encryption ever actually necessary, or is 128-bit enough?
AES-128 is not considered broken and remains secure against any known classical attack. The move to 256-bit keys across the VPN industry is largely a margin-of-safety decision — it provides headroom against future advances in cryptanalysis and, to some degree, against theoretical quantum attacks that would effectively halve a key’s strength. For a consumer VPN, either key length is defensible; 256-bit has simply become the de facto baseline.
Can a VPN use two different ciphers for different parts of the connection?
Yes. It’s common for the handshake (establishing the shared secret) to use one type of cryptography — typically elliptic-curve Diffie-Hellman — while the ongoing data transfer uses a separate symmetric cipher like AES-256 or ChaCha20. This is normal, expected design, not a red flag.
Does a faster cipher mean weaker security?
Not necessarily. ChaCha20 was designed to be fast specifically in software while maintaining the same 256-bit security margin as AES-256. Speed differences here largely reflect how well-suited each algorithm is to specific hardware, not a trade-off between speed and safety.
How can I check which cipher my VPN is actually using right now?
Most VPN apps expose this under an “advanced” or “protocol” settings menu. If a provider doesn’t disclose this anywhere in the app or documentation, that itself is worth treating as a gap when comparing providers.
Looking Ahead
AES-256 and ChaCha20-Poly1305 are expected to remain secure against classical computing attacks for the foreseeable future. The more interesting question — one we explore in a separate deep dive on Goliry — is how the VPN industry is beginning to prepare for cryptographically relevant quantum computers, which pose a very different kind of threat to the key exchange mechanisms discussed above.
For now, the practical takeaway is simple: don’t choose a VPN because a page mentions “military-grade encryption.” Look for named ciphers, named handshake protocols, Perfect Forward Secrecy, and independent audits. That combination — not a single buzzword — is what separates real protection from marketing.
Leave a Reply