VPN Encryption Explained

Your VPN app shows a cipher in its settings: AES-256-GCM, or ChaCha20-Poly1305. You know these mean your traffic is encrypted. What they actually mean is something most guides never explain — what AES-256-GCM is, what the GCM part does, why that suffix matters more than the “256,” and why modern VPN ciphers not only encrypt your data but also authenticate every packet, in a single operation.

Most explanations stop at the brute-force argument: AES-256 uses a 256-bit key, so 2²⁵⁶ possible combinations, so brute-force is computationally impossible. That is true. It is also about a tenth of the story. The cipher name tells you the algorithm and the key length. It does not tell you whether the mode of operation provides integrity, whether the cipher is AEAD or legacy CBC, or whether your past sessions remain protected if a key is later compromised.

The guides to how a VPN actually works and what a VPN is cover the operational flow. This article goes one layer deeper: the cryptographic mechanisms that make that encryption real.

If you only read one paragraph: A VPN uses two types of encryption in sequence. Asymmetric cryptography is used once at the start of each session to let two parties agree on a shared secret without transmitting it over an open network. A symmetric cipher then encrypts all your data using keys derived from that shared secret. The critical detail most guides skip: modern VPN ciphers are AEAD — Authenticated Encryption with Associated Data. Every packet is both encrypted and cryptographically authenticated in the same operation. The GCM in AES-256-GCM is what provides the authentication. Without it, encryption alone does not detect tampering.

VPN encryption in plain English

Think of a modern VPN cipher as a lockbox with a tamper-evident seal. When you send data through a VPN, the cipher locks the contents so that nobody who intercepts the box can read what is inside. That is confidentiality. But the cipher also applies a cryptographic seal — a short tag — that is mathematically tied to every byte of the contents. If anyone alters anything inside the box, the seal breaks. The recipient checks the seal first, before opening the box at all. If the seal is broken, the box is discarded without the contents ever being seen. That combined lock-and-seal is what AEAD means: Authenticated Encryption with Associated Data.

What makes modern VPN encryption different from older approaches is that the lock and the seal are applied in the same operation. Legacy configurations used two separate steps — a padlock applied first, a wax seal applied after — which created a gap where a tampered box could produce a detectable error before the seal was checked. Real attacks exploited that gap. Today’s AEAD ciphers close it by making the lock and the seal a single inseparable thing. The technical names for the two cipher recipes that achieve this are AES-256-GCM and ChaCha20-Poly1305.

What VPN encryption actually is (and what it isn’t)

Encryption is often described as if its only job is keeping data unreadable. Strong encryption actually provides two distinct properties simultaneously: confidentiality, meaning an interceptor cannot read the data, and integrity, meaning an interceptor cannot alter the data without that alteration being detected. Modern VPN ciphers deliver both in a single operation.

Does VPN encryption hide that you’re using a VPN?

No. Encryption makes your traffic unreadable; it does not make it invisible. The contents of your data packets are sealed against interception, but the observable characteristics of the connection — the fact that you are connected to a VPN server, the timing and volume of packets, the protocol signature on the wire — remain visible to anyone monitoring your network traffic. Your ISP can see that encrypted data is flowing to a VPN server’s IP address. What they cannot see is what that traffic contains or which websites you are visiting beyond it. Encryption solves the content-visibility problem. It does not touch the connection-visibility problem.

Hiding the fact that a VPN is in use at all requires a separate layer: obfuscation. An obfuscated VPN transforms your traffic’s observable characteristics so that deep packet inspection systems cannot classify it as VPN traffic. Encryption and obfuscation are independent — a VPN can have one without the other, and most consumer VPNs provide encryption without obfuscation by default. Obfuscation is relevant only on networks that actively detect and block VPN traffic: censorship infrastructure in certain countries, or some aggressive institutional networks. For the full explanation of what obfuscation does and when you need it, see what an obfuscated VPN actually does.

This article covers the cryptographic mechanisms: what AES-256-GCM and ChaCha20-Poly1305 actually are and do. It does not cover the operational VPN flow — how traffic is tunneled, how packets are encapsulated, or how the VPN server decrypts and forwards your requests. That process is covered in full in the guide to how a VPN actually works.

Four mechanisms work together in every modern VPN session: a key exchange that lets two parties agree on a shared secret over an open network; a key derivation step that converts that shared secret into usable encryption keys; a symmetric cipher that encrypts the data; and an authentication mechanism that proves the data was not tampered with in transit.

VPN encryption operates across two distinct phases. The control plane handles negotiation — authentication and asymmetric key exchange — establishing the shared secret from which session keys are derived. The data plane handles transmission: symmetric AEAD encryption of all actual traffic using those session keys. The two planes use different algorithms because they solve different problems.

The two-key problem — why VPNs use hybrid encryption

Symmetric encryption uses the same key to encrypt and decrypt. It is fast, efficient, and scales to continuous high-throughput data without meaningful overhead, which makes it the right tool for protecting a VPN data stream. The problem is fundamental: how do two parties, communicating over an untrusted network where an adversary may be watching, agree on that shared key in the first place? Transmitting it in the clear exposes it to any observer on the network.

Asymmetric encryption, also called public-key cryptography, provides a mathematical solution. Each party holds a key pair: a public key they share freely, and a private key they never share. Data encrypted with a public key can only be decrypted with the corresponding private key. This means you can send an encrypted message to someone using only their public key, without any prior shared secret between you. The key distribution problem is solved. The limitation is speed: asymmetric operations are orders of magnitude slower than symmetric ones, making them impractical for encrypting a continuous data stream. A VPN connection moving megabytes of traffic per second cannot afford asymmetric computation on every packet.

Modern VPNs resolve this tension with a hybrid approach. Asymmetric cryptography is used exactly once at the start of each session: to perform a key exchange that allows both parties to independently derive the same shared secret without transmitting it. From that shared secret, a symmetric session key is derived. All actual data then travels under symmetric encryption using that session key. Asymmetric cryptography solves the key distribution problem; symmetric cryptography handles the data.

The asymmetric phase — key exchange — is where the handshake mechanism and perfect forward secrecy operate. The symmetric phase — data encryption — is where AES-256-GCM and ChaCha20-Poly1305 do their work.

Key exchange — how two parties agree on a secret over an open network

Diffie-Hellman key exchange is a cryptographic protocol that allows two parties to derive a shared secret over a public channel without ever transmitting the secret itself. Published by Whitfield Diffie and Martin Hellman in 1976, it solved what had been considered an impossible problem: establishing a shared encryption key across a network where an adversary can observe every message. The core insight: two parties can each combine a shared public value with their own private value to arrive at the same result, while a passive observer who sees only the public values cannot reproduce it. The mechanism can be illustrated with paint: both parties start with the same publicly known base colour. Each privately mixes in their own secret colour, then exchanges their mixed result with the other party. Each then adds the other’s mixture to their own private secret, and both arrive at the same final colour — because the total set of combined components is identical on both sides. An eavesdropper who sees only the exchanged mixtures cannot reconstruct the final colour without knowing at least one of the private secrets.

The raw output of a Diffie-Hellman exchange has algebraic structure that makes it unsuitable for direct use as an encryption key. A key derivation function (HKDF) processes it, extracting the entropy and expanding it into cryptographically strong, uniformly random key material that both parties can use as their symmetric session key.

Classical Diffie-Hellman operates over large prime fields and requires large key sizes for adequate security. Modern VPNs use elliptic-curve variants that achieve equivalent security with smaller keys and faster computation. WireGuard uses Curve25519; IKEv2 supports Curve25519 (DH Group 31) alongside NIST curves P-256 and P-384. For the design rationale behind Curve25519 specifically, see the WireGuard Explained article. For IKEv2’s DH group configuration and security recommendations, see the IKEv2/IPsec Explained guide.

The key pair used for this exchange is not the VPN server’s permanent identity key. It is an ephemeral pair, generated fresh for this session and discarded the moment the session key is derived. The long-term key authenticates the handshake — it proves the server is genuine — but it never encrypts the session data directly. The session key comes from ephemeral material. This distinction is the foundation of perfect forward secrecy, introduced briefly in a later section.

For protocol-specific handshake depth, see WireGuard Explained, OpenVPN Explained, and IKEv2/IPsec Explained. The full mechanics of how each implements the exchange — authentication differences, DH group selection, and key derivation — are covered in the forthcoming VPN Handshake and Key Exchange guide.

AES-256-GCM

AES-256-GCM is the most widely used cipher in consumer VPNs. The name encodes three decisions: the cipher (AES), the key length (256 bits), and the mode of operation (GCM). Of these, the mode is the most important and the least explained. Understanding what “-GCM” actually contributes requires understanding AES first, and then understanding why AES alone is not enough.

AES — the block cipher underneath

AES, the Advanced Encryption Standard, was standardised by the National Institute of Standards and Technology in 2001 as FIPS 197, following a public competition that began in 1997. AES is a block cipher: it operates on fixed-size chunks of data rather than on a continuous stream. Every AES operation, regardless of key length, works on blocks of exactly 128 bits — 16 bytes at a time. AES-128, AES-192, and AES-256 differ in key size, not block size.

The key length determines how many rounds of processing the cipher applies: 10 rounds for AES-128, 12 for AES-192, 14 for AES-256. VPNs use AES-256.

Each round applies a sequence of operations to the 128-bit block. SubBytes replaces each byte using a fixed substitution table, introducing non-linearity so the output has no simple mathematical relationship to the input. ShiftRows rotates the rows of the block, spreading bytes across different column positions. MixColumns multiplies each column by a fixed matrix over a Galois field, thoroughly mixing the bytes within each column. AddRoundKey XORs the block with a subkey derived from the original key through a key schedule. After 14 rounds of this, the relationship between the original plaintext and the ciphertext is so thoroughly diffused that no pattern in the plaintext survives in the output. (The very last round skips the MixColumns step — a detail that matters for the mathematics but not for the intuition.)

A 256-bit key has 2²⁵⁶ possible values. To illustrate the scale: the estimated number of atoms in the observable universe is approximately 10⁸⁰, roughly 2²⁶⁶. A brute-force search through the AES-256 key space would require examining more combinations than there are atoms in the universe. AES-256 has been subjected to intense public cryptanalysis since its standardisation. The best known theoretical attacks require computational resources so far beyond practical that they are not a meaningful concern.

This is where most guides stop, treating AES-256 as the complete answer. But AES as described above is just a block transformation — it encrypts exactly 128 bits at a time. Real VPN traffic is continuous and variable in length. The mode of operation defines how the cipher handles a stream of data, and whether it also provides integrity.

GCM mode — the critical suffix

A block cipher alone transforms one block of data. A mode of operation defines how the cipher is applied repeatedly across a message of arbitrary length, and whether it does anything beyond encrypting. AES has been used in many modes over the years: ECB, CBC, CTR, GCM, and others. The mode matters as much as the cipher. GCM is the one that makes AES-256 suitable for modern VPN use.

GCM (Galois/Counter Mode) does two things simultaneously in a single pass over your data. The first is Counter Mode encryption. Rather than encrypting your plaintext directly, CTR mode uses AES as a pseudo-random number generator: a counter value, unique for each block position, is encrypted by AES to produce a block of pseudo-random output. That output is XORed with the plaintext to produce ciphertext. The counter increments for each block. This construction behaves like a stream cipher, handling data of any length. Crucially, because each block’s keystream depends only on its counter value and not on any previous ciphertext block, the computation is fully parallelisable. Modern CPUs can process multiple counter blocks simultaneously, which is why AES-256-GCM can saturate a gigabit connection with negligible overhead on hardware equipped with AES-NI acceleration.

The second component is GHASH, a polynomial hash function operating over the Galois field GF(2¹²⁸). It processes the ciphertext, along with any additional authenticated data, to produce a fixed-size authentication tag — typically 128 bits. The tag is computed over the ciphertext using the session key material and is appended to the ciphertext. The receiver recomputes the tag independently; if it does not match — because even a single bit was modified anywhere in the ciphertext — the packet is rejected and no plaintext is ever released to the application.

The result is that AES-256-GCM is an AEAD cipher: a single cryptographic operation produces both the ciphertext and a cryptographic proof of integrity. The “-GCM” suffix is not optional decoration. It is what separates a cipher that provides confidentiality alone from one that provides both confidentiality and integrity. Two configurations can both describe themselves as “AES-256” and have entirely different security properties depending on whether GCM follows the hyphen.

The ordering matters: the authentication tag is verified before any plaintext is released. If a received packet’s tag verification fails — because the ciphertext was forged, modified in transit, or replayed — the receiver produces no output. No error message, no timing signal, no decrypted content. This ordering eliminates the padding oracle attack surface that plagued CBC-mode deployments.

AES-GCM is hardware-accelerated on virtually every mainstream processor manufactured in the last decade, making it essentially free in CPU cost on any modern device.

A note on nonces

GCM requires one additional input alongside the key and the data: a nonce. “Nonce” is short for “number used once,” though the precise requirement is uniqueness rather than randomness — a nonce can be a simple incrementing counter, it just must never repeat under the same key. The recommended and near-universal size for an AES-GCM nonce is 96 bits (12 bytes). The nonce is not secret: in many protocols it is transmitted alongside the ciphertext, though some implementations (TLS 1.3, WireGuard) derive the nonce from a shared counter that both parties maintain independently and never transmit.

Reusing a nonce with the same key in GCM is a catastrophic failure on two fronts. First, two ciphertexts produced from different plaintexts under the same key and nonce share an identical keystream. XORing those two ciphertexts together cancels the keystream and leaves the XOR of the two plaintexts directly visible. With any known content in either message, both plaintexts become recoverable. Second, GCM’s authentication relies on a single hidden key, H, that is fixed per long-term key (H = AES_k(0¹²⁸)). From two messages that share a nonce, an attacker can solve for H. Once H is known, the attacker can forge valid authentication tags for any message they observed under that key, collapsing the integrity guarantee entirely. This is Joux’s “forbidden attack,” first documented in 2006 and demonstrated at scale against TLS by Böck, Zauner, Devlin, Somorovsky, and Jovanovic in 2016.

In practice, this is not a concern for users: VPN stacks manage nonces automatically. WireGuard, for example, constructs its per-packet nonce from 32 zero bits followed by an incrementing 64-bit counter, and forces a new session key after 2⁶⁰ messages or 120 seconds, whichever comes first. Nonce reuse in ChaCha20-Poly1305 is equally catastrophic for confidentiality, since it is also a stream cipher and the same XOR-of-plaintexts exposure applies. There is one structural difference in authentication: because ChaCha20-Poly1305 derives a fresh Poly1305 authentication key for each (key, nonce) pair, a nonce reuse compromises authentication only for that specific nonce rather than across all traffic under the long-term key. On confidentiality, both ciphers fail equally. Nonce management is automatic in all major VPN stacks and is not something a user configures.

ChaCha20-Poly1305

AES-256-GCM is not the only AEAD cipher used in VPNs. ChaCha20-Poly1305 is the alternative, and it is not a weaker or stronger option but an equivalent one built from different components. It provides the same security model — ciphertext plus authentication tag in a single operation — while reaching that model through a different architecture.

ChaCha20 is a stream cipher. Rather than processing data in fixed 128-bit blocks, it generates a continuous pseudo-random keystream directly from a 256-bit key, a 96-bit nonce, and a 32-bit block counter. That keystream is XORed with the plaintext byte by byte. No block boundaries, no padding, no mode of operation required on top — the cipher itself is designed for variable-length data. ChaCha20 is built from simple arithmetic operations applied across a 512-bit internal state, operations efficient on any processor without requiring dedicated hardware acceleration.

Poly1305 is the authentication component: a one-time message authentication code that generates a 128-bit authentication tag over the ciphertext. Critically, the Poly1305 key is not a separate long-term secret. It is generated on the fly: ChaCha20 is run with the session key and nonce to produce an initial keystream block, and the first 32 bytes of that block become a single-use Poly1305 key (per RFC 8439 §2.6). The message encryption then proceeds from counter position 1, with counter 0 having been consumed by key generation. Because the Poly1305 key is derived fresh per (key, nonce) pair and used only once, it is a genuinely one-time MAC.

Together, ChaCha20 and Poly1305 form an AEAD cipher with the same security model as AES-256-GCM: a single operation produces both ciphertext and an authentication tag. Any modification to the ciphertext invalidates the tag. Both ciphers are considered equally secure by current cryptographic analysis; the difference is architecture and hardware.

WireGuard uses ChaCha20-Poly1305 exclusively. It is the only cipher in WireGuard’s fixed, non-negotiable cryptographic suite. There is no configuration option, no alternative, and no fallback. OpenVPN 2.6 and later include ChaCha20-Poly1305 in the recommended data-ciphers list alongside AES-256-GCM and AES-128-GCM. IKEv2 supports it via RFC 7634, under the transform identifier ENCR_CHACHA20_POLY1305 (IANA value 28), in implementations including strongSwan and Libreswan.

The reason two ciphers coexist in the VPN ecosystem is hardware. AES-256-GCM, with hardware acceleration, matches or exceeds ChaCha20-Poly1305 in throughput on any modern processor with AES-NI. On hardware without dedicated AES instructions — older mobile devices, embedded hardware, some IoT platforms — software AES has performance limitations that ChaCha20 does not share. WireGuard was designed for portability across all hardware, including low-end devices, and ChaCha20-Poly1305 was the right cipher for that goal. For a detailed performance comparison across protocols and hardware, see the WireGuard vs OpenVPN guide.

AEAD — why modern VPN ciphers also authenticate your data

Before AEAD ciphers became standard, VPN data channels relied on CBC-mode ciphers paired with a separate HMAC for integrity. OpenVPN’s actual factory default through version 2.4 was BF-CBC — Blowfish in Cipher Block Chaining mode, a cipher inherited from OpenVPN’s early 2000s origins. Security-conscious deployments upgraded manually to AES-256-CBC, a legitimate and common choice, but not the out-of-the-box setting. OpenVPN 2.5, released in 2020, changed the negotiated default to AES-256-GCM and AES-128-GCM and removed BF-CBC as an acceptable option.

CBC mode encrypts data but provides no integrity guarantee on its own. In CBC, each plaintext block is XORed with the previous ciphertext block before encryption, creating a chain where each block’s ciphertext depends on all preceding blocks. This provides diffusion but not authentication. Integrity required a separate step: an HMAC computation using a second independent key, applied after encryption. OpenVPN and TLS used a MAC-then-encrypt construction: the HMAC was computed over the plaintext, then both the plaintext and the HMAC were encrypted together. The problem appears on the decryption side.

When the receiver processes an incoming packet, it must decrypt first, remove the padding (CBC requires plaintext to be a multiple of the block size, so fixed-length padding bytes are appended and then stripped), and only then verify the HMAC. An attacker who can submit modified ciphertexts to the receiver and observe whether each modification produces a padding error before or instead of an HMAC failure gains a cryptographic oracle. Each probe reveals one bit of information, and one bit at a time is enough to recover plaintext incrementally. This is the padding oracle attack class. Lucky13 (Al Fardan and Paterson, 2013) exploited this through timing differences in TLS and DTLS. POODLE (CVE-2014-3566, 2014) exploited the same vulnerability class in SSL 3.0. Neither broke AES-256-CBC itself. Both broke the architecture that surrounded it, the interaction between CBC decryption and separate MAC verification.

Authenticated Encryption with Associated Data resolves the architecture. Instead of two sequential operations — encrypt, then MAC — AEAD performs a single cryptographic pass that simultaneously produces the ciphertext and an authentication tag. The two outputs are derived together from the same key material and cannot be separated. On the receiving end, the tag is verified, and if it fails, no plaintext is ever released. The packet is rejected silently, with no output, no error information, and no timing differential. There is no oracle because there is no step that decrypts the ciphertext before authentication succeeds. AEAD also eliminates block padding entirely: both AES-256-GCM (via CTR mode) and ChaCha20-Poly1305 are stream-cipher constructions in their encryption layer — no block boundaries, no padding bytes, nothing to build an oracle from. This removes the foundation on which bit-flipping attacks and padding oracles depend.

The authentication tag proves one thing: this ciphertext was produced by someone who holds the correct session key and has not been modified since. Any modification — a single bit flipped anywhere in the encrypted payload — produces a completely different tag value, with probability 1 − 2⁻¹²⁸ of detection: effectively certain. Without the key, no attacker can forge a valid tag; without leaving the tag intact, no one can touch the ciphertext. The two AEAD ciphers used in VPNs reach this guarantee through different mechanisms: AES-256-GCM uses GHASH, a polynomial hash over GF(2¹²⁸), and ChaCha20-Poly1305 uses Poly1305, a one-time MAC based on polynomial evaluation over a prime field. The architectures differ; the security function is the same.

The AD in AEAD refers to additional data that is authenticated but not encrypted. In VPN packet processing, this typically covers packet headers: source and destination addresses, sequence numbers, session identifiers, and similar fields that must remain visible to the network stack for routing. These headers cannot be encrypted — routers and network infrastructure need to read them. Without authentication, an attacker could modify a header without touching the encrypted payload, and the modification would be undetectable. AEAD covers headers in the authentication tag computation. An attacker cannot modify them without invalidating the tag, even though the headers themselves are plaintext. The authentication extends to the entire packet structure, not just the payload.

A VPN using AES-256-GCM or ChaCha20-Poly1305 cannot be silently corrupted in transit. Injected packets, replayed packets, modified packets, and header-tampered packets all fail the tag check and are dropped before any decrypted content reaches the application. This is not a marginal improvement over a correctly implemented CBC-plus-HMAC configuration. It is the elimination of an entire attack class — the one that required no cryptographic weakness in the underlying cipher, only a design flaw in how decryption and verification were ordered.

One practical marker for readers who have access to their OpenVPN configuration file: a line reading cipher AES-256-CBC with a separate auth SHA256 directive represents the old two-pass approach. A configuration containing data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305 is using AEAD. That single detail distinguishes a current configuration from a legacy one. For the full picture of what to look for in a provider’s .ovpn file, see the OpenVPN Explained guide.

Perfect forward secrecy

Consider a VPN deployment where session keys are derived from a long-term server private key. If that key is ever obtained by an adversary — through a server compromise, a court order compelling disclosure, or a future cryptographic break — every session ever established using that key becomes retrospectively readable. The persistence of the key is what creates the exposure.

Perfect forward secrecy resolves this by ensuring that session keys are derived from ephemeral material: key pairs generated fresh for each session and discarded when the session ends. The long-term server key is used only for authentication — proving the server’s identity during the handshake — and never directly encrypts any session data. Once the session ends, the ephemeral private key that produced the session key is gone. An adversary who later obtains the long-term server key gains no ability to decrypt past sessions, because the ephemeral component that generated those session keys no longer exists anywhere.

Past sessions are protected even against future key compromises because the keys that protected them are gone — that is what “forward secrecy” means. One qualification: PFS protects the symmetric session keys against retrospective decryption. The asymmetric key exchange used to establish those keys remains theoretically vulnerable to a sufficiently capable quantum computer — a separate concern covered in the forthcoming post-quantum VPN encryption guide.

The full mechanics of perfect forward secrecy — how rekeying intervals work across WireGuard, OpenVPN, and IKEv2; what session key compromise actually means in practice; and how PFS interacts with the post-quantum threat model — are covered in the dedicated Perfect Forward Secrecy in VPNs guide (forthcoming).

What “military-grade encryption” actually means

The phrase appears in the marketing of virtually every consumer VPN. It refers, accurately, to the cipher: AES-256 is defined in FIPS 197, the US federal standard for symmetric encryption published by NIST in 2001. The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), published in September 2022, specifies AES-256 for protecting US National Security Systems — classified and unclassified alike, up to and including TOP SECRET. CNSA 2.0 updates CNSA 1.0, which had itself replaced the earlier Suite B. The consolidation from Suite B’s tiered approach (AES-128 for SECRET, AES-256 for TOP SECRET) to AES-256 as the sole symmetric cipher happened at the CNSA 1.0 transition; CNSA 2.0 carried that requirement forward unchanged. The implication that your VPN uses the same cipher approved to protect US classified information up to TOP SECRET is, as a statement about the cipher itself, accurate.

AES-256 has withstood more than two decades of intense public cryptanalysis. The best known theoretical attacks require computational resources so far beyond practical that they are not a foreseeable concern. Calling it military-grade is not fabrication.

The problem with the phrase is what it implies. “Military-grade encryption” frames the cipher as the barrier between a user and a sophisticated adversary. In practice, no adversary targeting a VPN user is attempting to brute-force AES-256. That is computationally impossible. The realistic attack surfaces in a VPN are elsewhere: the key exchange implementation and its susceptibility to downgrade attacks; the provider’s logging practices and what they retain; the server’s operational security; the provider’s jurisdiction and exposure to compelled disclosure; and misconfigured cipher suites — CBC mode, weak DH groups, absence of perfect forward secrecy. A VPN running AES-256-GCM with PFS active and an independently audited no-log policy provides strong protection. A VPN running AES-256-GCM with detailed connection logs provides strong encryption and no privacy, because the logs answer every question that the encryption protects.

“Military-grade encryption” is accurate shorthand for “the strongest publicly standardised symmetric cipher, with no known practical vulnerability.” It is not misleading about the cipher. It is misleading when used as an overall privacy claim, because it draws attention to the one component of a VPN that is not the concern, while saying nothing about the components that actually determine whether a provider is trustworthy. The cipher protects your data in transit. Your provider’s practices determine whether your data is protected from the provider itself, from its governments, and from its commercial incentives. For the full framework on evaluating provider trustworthiness, see the no-log VPN guide.

How to evaluate your VPN’s encryption

The four criteria below separate a well-configured VPN encryption setup from a poorly configured one. Cipher strength is not the variable. The mode, the negotiation surface, the absence of legacy options, and the presence of perfect forward secrecy are.

AEAD mode is required. The data cipher must be one of three options: AES-256-GCM, AES-128-GCM, or ChaCha20-Poly1305. All three are AEAD. Any provider or configuration defaulting to AES-256-CBC, without the “-GCM” suffix, is using the old approach: encryption without single-pass integrity. This is rare in 2026 but appears in configurations generated before OpenVPN 2.5. How to check: for OpenVPN, look at the data-ciphers directive in the .ovpn file your provider supplies. For WireGuard, AEAD is guaranteed by the fixed cryptographic suite. There is no configuration option that could introduce a non-AEAD cipher. For the full OpenVPN configuration evaluation, see the OpenVPN Explained guide.

Fixed suite versus negotiable suite. WireGuard uses a single fixed cipher suite with no negotiation. An attacker cannot manipulate the connection to downgrade the cipher because there is nothing to negotiate. OpenVPN and IKEv2 negotiate from a server-configured list. The security of that negotiation depends on the server excluding all weak options. A provider’s data-ciphers list containing only AEAD options is correct. A list that includes AES-256-CBC as a fallback leaves a downgrade path open. For protocol-by-protocol cipher configuration, see the VPN Protocols guide.

No legacy ciphers. Blowfish (BF-CBC), DES, 3DES, RC2, and any cipher with a key length below 128 bits are unacceptable in 2026 and should not appear in any provider’s selectable options. If a VPN application exposes these as available choices — even not as the default — the cipher configuration has not been updated.

Perfect forward secrecy active. The protocol the provider defaults to must implement ephemeral key exchange. WireGuard, IKEv2, and OpenVPN in standard TLS mode all do. OpenVPN’s legacy static key mode, configured with --secret, does not — it uses a single persistent pre-shared key for all sessions, meaning a key compromise exposes all historical sessions. Static key mode is rarely used in consumer VPN products in 2026, but it is worth confirming. A provider whose documentation explicitly describes ephemeral key exchange is correctly communicating an important security property. One whose documentation is silent on this point has not demonstrated it.

Frequently asked questions

Does a VPN use symmetric or asymmetric encryption?

Both, in sequence. Asymmetric key exchange (Diffie-Hellman or its elliptic-curve variants) is used once at the start of each session to allow both parties to derive a shared secret without transmitting it. A key derivation function processes that shared secret into symmetric session keys. All actual data is then encrypted using a symmetric AEAD cipher — AES-256-GCM or ChaCha20-Poly1305. The asymmetric phase solves the key distribution problem; the symmetric phase handles the data. Neither alone would be adequate.

What does AES-256-GCM mean?

Three components. AES (Advanced Encryption Standard) is the block cipher — the mathematical transformation applied to data. 256 is the key length in bits, which determines how many rounds of processing AES applies: 14 rounds for AES-256. GCM (Galois/Counter Mode) is the mode of operation, the mechanism that turns the block cipher into one suitable for variable-length data streams and, critically, adds an authentication tag. The “-GCM” suffix is what makes AES-256 an AEAD cipher rather than an encryption-only cipher. Two configurations can both describe themselves as “AES-256” and have completely different security properties depending on the mode.

Is AES-256 encryption actually unbreakable?

By brute force, yes: the key space is 2²⁵⁶ and no practical attack exists. AES-256 has been publicly scrutinised for over 20 years with no successful break of the full cipher. The 256-bit key length also provides a post-quantum margin. Grover’s algorithm, the best known quantum attack against symmetric ciphers, provides a quadratic speedup for key search — reducing AES-256 to an effective post-quantum strength of approximately 128 bits, and AES-128 to approximately 64 bits. 128 bits of effective post-quantum security is considered comfortably adequate by current cryptographic consensus. (In practice, Grover’s algorithm is even less threatening than the numbers suggest, because it parallelises poorly — splitting the search across many quantum computers degrades the speedup.) The cipher is not the weak link in a VPN deployment.

What is the difference between AES-256-GCM and ChaCha20-Poly1305?

Architecture, not security level. AES-256-GCM is a block cipher in an authenticated mode; ChaCha20-Poly1305 is a stream cipher paired with a one-time MAC. Both are AEAD ciphers: both produce ciphertext and an authentication tag in a single operation. Both are considered equally secure by current cryptographic analysis. The practical difference is hardware. AES-256-GCM is faster on processors with AES-NI acceleration, which covers virtually all mainstream devices today. ChaCha20-Poly1305 is faster in pure software on hardware without dedicated AES instructions. WireGuard uses ChaCha20-Poly1305 exclusively; OpenVPN and IKEv2 support both.

What is perfect forward secrecy and why does it matter?

Perfect forward secrecy means each VPN session uses an ephemeral key pair for the key exchange, generated fresh and permanently discarded when the session ends. Session keys are derived from that ephemeral material, not from any persistent long-term key. If the VPN server’s long-term key is later compromised — through a breach, a court order, or a future cryptographic break — past sessions cannot be decrypted. The ephemeral keys that generated those session keys no longer exist. Without PFS, a single key compromise exposes all historical sessions protected by it. The full mechanics of perfect forward secrecy, including rekeying intervals across WireGuard, OpenVPN, and IKEv2, are covered in the dedicated Perfect Forward Secrecy in VPNs guide (forthcoming).

What is AEAD encryption?

Authenticated Encryption with Associated Data is a mode of encryption that simultaneously provides confidentiality (the data is encrypted) and integrity (the data is authenticated) in a single cryptographic operation. It produces both ciphertext and an authentication tag. If tag verification fails, no plaintext is ever released — the packet is rejected silently. AEAD eliminates the attack surface created when encryption and integrity verification are handled in separate sequential operations, specifically the padding oracle attack class exploited by Lucky13 and POODLE against CBC-mode TLS. AES-256-GCM and ChaCha20-Poly1305 are both AEAD ciphers.

Is AES-128 secure enough for a VPN?

Yes by current standards. AES-128 has no known practical vulnerability and has withstood the same decades of public cryptanalysis as AES-256. The reason VPNs use AES-256 is post-quantum margin: Grover’s algorithm reduces AES-128 to approximately 64-bit effective post-quantum security, which is considered a thinner margin than most cryptographers prefer for long-term security. AES-256 retains approximately 128-bit effective post-quantum strength, a comfortable margin. For current non-quantum adversaries, AES-128-GCM is fully adequate.

Can a quantum computer break VPN encryption?

The data ciphers — AES-256-GCM and ChaCha20-Poly1305 — retain meaningful security against quantum attack. Grover’s algorithm, the relevant quantum threat to symmetric ciphers, reduces their effective key strength by approximately half in bits rather than breaking them outright, leaving AES-256 with around 128 bits of effective post-quantum security. The more theoretically vulnerable component is the asymmetric key exchange (Diffie-Hellman and elliptic-curve variants), which Shor’s algorithm could break on a sufficiently powerful quantum computer — a machine that does not yet exist. Perfect forward secrecy partially mitigates the retrospective threat: since session keys come from ephemeral material that is discarded, there is no persistent key material for a future quantum computer to recover. The full picture — what ML-KEM and post-quantum pre-shared keys mean for VPN encryption, and which providers are already implementing quantum-resistant mitigations — is covered in the forthcoming post-quantum VPN encryption guide.

Do I need to choose between AES-256-GCM and ChaCha20-Poly1305?

For almost every VPN user, no — your protocol makes the choice for you. WireGuard uses ChaCha20-Poly1305 exclusively and offers no alternative. OpenVPN and IKEv2 negotiate from the server’s configured cipher list, defaulting to AES-256-GCM on modern hardware with AES-NI acceleration. The choice only surfaces if you are configuring a server yourself or evaluating a provider’s cipher list. On a modern phone or laptop, either cipher is fine from a security standpoint: both are AEAD, both are considered equally secure by current cryptographic analysis, and neither has a known practical vulnerability. The deciding factor is hardware. AES-256-GCM is faster on processors with dedicated AES instructions, which is almost all mainstream hardware sold in the last decade. ChaCha20-Poly1305 is faster in pure software on hardware without that acceleration. Neither is “more secure” — they are cryptographically equivalent options optimised for different hardware environments.

Does VPN encryption hide that I’m using a VPN?

No — encryption hides the contents of your traffic, not the existence of the VPN connection itself. Your ISP and anyone monitoring your network can still see that you are connected to a VPN server, observe the volume and timing of your encrypted traffic, and in many cases identify the VPN protocol from its packet signature. Hiding the fact that a VPN is in use requires obfuscation, a separate technique that transforms the observable characteristics of your traffic so it cannot be classified as VPN traffic by deep packet inspection systems. Most consumer VPNs provide encryption by default and obfuscation only as an optional feature. For a full explanation of when obfuscation matters and which providers offer it, see the obfuscated VPN guide.

Is my VPN FIPS-compliant if it uses AES-256-GCM?

Using AES-256-GCM means using a cipher standardised in FIPS 197 (the AES standard) and a mode standardised in NIST SP 800-38D. That is a necessary condition for FIPS compliance, but not a sufficient one. FIPS 140-2 and FIPS 140-3 are standards for validated cryptographic modules — the software or hardware implementations of those algorithms — not for the algorithms themselves. A VPN using AES-256-GCM on a non-validated implementation is using a FIPS-approved algorithm without being FIPS-compliant in the procurement sense. Enterprises with strict FIPS 140-3 requirements need to verify that their VPN provider’s implementation holds a current NIST CMVP validation certificate, not just that it names AES-256 in its documentation. One practical note: ChaCha20-Poly1305, while equally secure, is not currently on the NIST list of FIPS-approved algorithms. For organisations with strict FIPS module validation requirements, WireGuard’s exclusive use of ChaCha20-Poly1305 presents a compliance constraint that OpenVPN’s AES-256-GCM mode does not.