AES-256 Names One Component of a VPN Tunnel

A VPN tunnel is assembled from several mechanisms with different responsibilities, and AES-256 names exactly one of them: the cipher that turns each packet’s contents into something unreadable and turns it back at the other end. Everything else the tunnel has to get right — obtaining a key without transmitting it, establishing that the far end is the server you meant, noticing a packet that was altered or resent, and replacing the key before it has protected too much — is done by components the label does not describe.

Knowing which component the figure refers to is the difference between reading a spec sheet and reading a slogan. The division of labour it sits inside is the subject of which part of your VPN is the protocol.

The one job the cipher has

Transform a payload using a key both ends already hold, reversibly and in both directions.

AES is symmetric, which means the same key encrypts and decrypts. Your device holds it and the VPN server holds it, and each of them uses it on every packet in the tunnel for as long as that key is in force. The transformation is fast enough to apply to a continuous stream of traffic, which is the practical requirement for a tunnel.

Three limits are built into that description, and they are the ones people miss.

The cipher does not know or care what it is encrypting. A packet’s contents are bytes to it, so it protects an important request exactly as well as a background update check, and it has no notion of whether the packet should have been sent at all.

It does not conceal the fact of the packet. Something has to route each packet to the server, so the outer header is not encrypted. Sizes and timings remain observable.

And it protects the payload from everyone except the two parties holding the key. One of those parties is the VPN server. “Encrypted with AES-256” has never meant “hidden from the provider”, because the provider’s machine is the other end of the key — the scope drawn in what a VPN hides about your IP address.

Getting the key is a different job entirely

The cipher cannot produce its own key, and the key cannot be sent across the network in the clear.

This is what a key-agreement step is for. Both ends contribute to a calculation whose result they can each work out but an observer of the exchange cannot, and the shared value that emerges is turned into the keys the cipher will use. Nothing that would let a watcher reconstruct the key ever crosses the wire.

The cipher plays no part in this and has no way to check it. If the agreement step is implemented poorly, or the randomness feeding it is weak, the resulting key can be predictable — and AES will then encrypt your traffic flawlessly with a key someone else can work out.

The cipher is a well-understood transformation with no moving parts. Everything around it involves state, timing, negotiation, and randomness, which is where mistakes actually happen.

Deciding who you are encrypting to

A cipher will encrypt perfectly to the wrong party, and be no less correct for it.

Server authentication is the separate mechanism establishing that the machine you completed a key agreement with is the server you intended — done with a certificate chain your client validates, or with a server public key configured in advance so only the holder of the matching private key can complete the handshake.

Without it, an encrypted tunnel to an impostor is still an encrypted tunnel. It is confidential against everyone except the party you did not mean to talk to, which is the party that matters. No cipher choice affects this in any way.

The same applies in the other direction: proving you are entitled to a tunnel is an authentication question, not an encryption one.

Detecting a changed packet, and a replayed one

Encryption on its own hides contents; it does not report tampering.

An attacker who cannot read a packet can still modify the bytes in transit, and a cipher used naively will decrypt the modified packet into different, meaningless plaintext without complaining. Tunnels therefore use the cipher in an authenticated mode producing a verification tag alongside the ciphertext, or pair it with a separate authentication code over the same data; a packet whose tag does not verify is dropped rather than processed.

Replay is a second, distinct problem. A packet captured earlier is a genuine packet with a valid tag, so authentication alone accepts it. Tunnels add a counter and refuse packets whose counter has already been seen or has fallen too far behind.

Both of these are properties of the construction the cipher sits in, not of the cipher. A features page listing a cipher name and nothing else has not told you whether either is present, though in current protocols both are.

Why the key does not stay the same

A key that protected a long session is a bigger prize than one that protected a few minutes.

Tunnels rekey: they run the agreement step again periodically and switch to fresh keys, discarding the old ones. This bounds how much traffic any single key ever protected, and it means keys derived for one session are not recoverable from anything a later session exposes.

The cipher does not schedule this and cannot enforce it. Rekeying is protocol behaviour, and how often it happens is a design decision made by whoever specified the protocol. If a client implements it badly — failing to rotate, or reusing a counter after a rekey, which is a genuinely dangerous mistake in authenticated modes — the cipher gives no indication.

Where the label on the box actually lands

It names the first component in this list and says nothing about the other four.

Of the five jobs above, “AES-256” describes only the first. It says nothing about how the key was agreed, whether the server was authenticated, whether packets are checked for tampering and replay, or how often keys are replaced — and those are the parts where implementations differ and where mistakes have consequences.

There is also a case where the label may not describe your connection at all. WireGuard does not use AES; it fixes a different construction entirely — ChaCha20 paired with the Poly1305 authenticator — and it is not a weaker tunnel for it, the choice following from design goals about implementation simplicity. So if a provider’s page advertises AES-256 while its recommended protocol is WireGuard, the figure is describing a different tunnel from the one you are probably using: a features page written for the search term rather than for the connection. That contrast between fixing a primitive and negotiating one is itself a design difference, examined in how OpenVPN and WireGuard differ by design.

What the figure on a features page is describing

Attach every number to a component, and note which components have no number next to them.

When a page lists several values together, work out which is the bulk cipher, which the key agreement, and which the authentication — then ask which protocol the list applies to, because a client offering three protocols cannot have one set of primitives. Your client’s connection detail or configuration file names the protocol actually in use, and that settles the question whether or not the marketing agrees.

Keep the boundary of the claim in view too. Encryption in transit stops the path between you and the exit from reading or altering your traffic. It is not protection against malware, a compromised account, anything on your own device, or a provider that keeps records — that last being a question you answer from written policy, as in what a no-logs VPN means. Those live outside the tunnel, and no component inside it reaches them.