The three layers of VPN encryption
A working VPN connection involves three distinct cryptographic operations, each handled by different algorithms:
- Symmetric encryption β encrypts the actual data packets. Fast. Uses a session key shared between client and server.
- Key exchange β securely establishes that shared session key. Uses asymmetric crypto (public/private key pairs).
- Authentication β verifies that the packets weren't tampered with in transit, and that the other party is who they claim to be.
Each layer uses different algorithms with different trade-offs. The "AES-256" in marketing usually refers only to the first layer.
Symmetric encryption
AES-256-GCM
The default for OpenVPN and IPsec. AES (Advanced Encryption Standard) was selected by the US government in 2001 as a replacement for the older DES. AES-256 means 256-bit keys, which gives a key space of 2^256 β for context, the universe contains around 2^265 atoms. Brute-forcing a 256-bit key is not happening, ever, by any conceivable computer.
The "GCM" part stands for Galois/Counter Mode β a way of using AES that also provides authentication (so you don't need a separate authentication layer for packet integrity).
Performance: very fast on hardware with AES-NI instructions (most modern x86 CPUs and many ARM CPUs). Slower on older or smaller devices without acceleration.
ChaCha20-Poly1305
The default for WireGuard, and an alternative in modern OpenVPN. ChaCha20 is a stream cipher designed by Daniel Bernstein in 2008. Poly1305 is a matching authentication algorithm.
ChaCha20-Poly1305 is considered cryptographically equivalent to AES-256-GCM but performs differently:
- On devices without AES hardware acceleration (older phones, low-power embedded devices), ChaCha20 is significantly faster.
- On devices with AES-NI, AES is faster.
- The implementation is simpler β smaller attack surface for bugs.
Both ciphers are state-of-the-art. The choice between them is mostly about which performs better on your specific hardware.
Key exchange
Before symmetric encryption can happen, both sides need to agree on a session key β without anyone else being able to learn it. The solution is Diffie-Hellman key exchange (DH), which lets two parties derive a shared secret over an insecure channel.
Modern key exchange options
- X25519 β elliptic curve DH using Curve25519. Used by WireGuard, common in TLS 1.3. Fast and considered very secure.
- ECDH P-256 / P-384 β NIST-standard elliptic curves. Used by IPsec and OpenVPN. Some cryptographers prefer X25519 because the NIST curves have unexplained constants in their definition (mild ongoing skepticism); both are considered secure for practical use.
- Classical DH (large prime groups) β older, slower. Used by IPsec when configured for legacy compatibility. Should use 2048-bit groups or larger; 1024-bit groups (still seen in old setups) are considered weak.
Perfect forward secrecy
Forward secrecy means session keys are generated freshly for each connection and discarded afterward. If an attacker captures encrypted traffic and later compromises the long-term identity keys, they still can't decrypt the captured sessions β because the session keys came from the DH exchange, not from the identity keys.
All modern VPN protocols (WireGuard, OpenVPN with properly configured TLS 1.3, modern IKEv2) provide forward secrecy by default. Older configurations that used static keys did not β and any captured traffic from that era is potentially decryptable if the static key ever leaks.
Authentication
How do you know the VPN server you connected to is actually the VPN provider's server, and not an attacker impersonating it? Authentication.
- Certificate-based: the VPN server presents a certificate signed by a Certificate Authority. The client verifies the signature. Standard for OpenVPN and IKEv2.
- Public-key based: WireGuard uses a simpler model β each peer has a public key, and the handshake includes mutual signing. No CAs needed.
- Pre-shared key (PSK): both sides know a shared secret. Simple but the secret distribution is its own problem. Sometimes used as an extra layer alongside other auth.
- Username/password: in addition to cryptographic auth. Used by some providers for user management; doesn't affect the protocol's cryptographic security.
What "military-grade" actually means
AES-256 was approved by the NSA in 2003 for protecting US government classified information up to TOP SECRET. That's the basis for the "military-grade" claim.
The problem with the marketing: every reputable VPN uses AES-256 or equivalent. It's the baseline, not a competitive differentiator. When a VPN advertises "military-grade encryption," they're saying "we use what everyone uses." Take it as a sanity check, not a feature.
The differentiators are elsewhere β protocol choice, key-exchange strength, forward secrecy, implementation quality, no-log policy. Encryption strength is table stakes.
How encryption gets defeated in practice
Real attackers don't break AES-256. They:
- Compromise endpoints (malware on your device, on the VPN server).
- Steal or subpoena keys.
- Exploit implementation bugs (buffer overflows, padding oracle attacks).
- Side-channel attacks (timing, power consumption).
- Social engineering.
The strength of the cipher doesn't matter if the surrounding system is broken. This is why no-log architecture, audited implementations, and operational security matter more than which exact cipher is used.
Related reading
- /features/encryption/ β product page
- WireGuard (uses ChaCha20)
- OpenVPN (uses AES-256-GCM)