Why AES-256 Does Not Describe a VPN Encryption Suite
A suite fills four roles: bulk encryption, integrity, key establishment and peer authentication. A cipher name covers one of them, at one layer.
Ask what encryption a VPN uses and the answer usually comes back as one word: AES-256, or ChaCha20, or maybe WireGuard. That answer names one component of one layer, while the thing actually protecting the connection is a set of algorithms filling four different roles. Confusing the component with the arrangement is the most common mistake in these conversations, and it produces comparisons that cannot be resolved.
Four jobs inside one connection
Bulk encryption turns plaintext into ciphertext for the data channel, and its key is derived rather than transmitted. Integrity protection detects modification, which is a separate job even when a single construction performs both. Key establishment produces the shared traffic material, and peer authentication decides who is on the other end. Miss any one of them and the connection is not secure, no matter how strong the surviving piece is.
Some designs collapse two roles into one. AES-GCM and ChaCha20-Poly1305 are authenticated-encryption constructions, so confidentiality and integrity arrive together; AES-CBC does not, and needs a separate message authentication code with its own key. Reading a proposal as a bag of independent numbers therefore misreads the ones that were designed as pairs.
The roles also sit at different layers, which is why the same word can mean different things in two products. A block cipher used inside ESP and a block cipher used inside TLS are the same primitive in different negotiations with different surrounding requirements. That is why quoting a primitive without its mode and its layer can be worse than quoting nothing at all.
Why a cipher name says almost nothing
Take the phrase "AES-256" seriously for a moment: it identifies a block cipher and a key size. It says nothing about the mode of operation, whether integrity is provided, how keys were established or how the peer was authenticated. Two products can both advertise AES-256 and differ in every other respect, including one that pairs it with an unauthenticated mode and one that uses an AEAD mode with a modern key exchange.
TLS 1.3 pushed this separation into the standard, which is a useful corrective for anyone who learned the older vocabulary. Its cipher suites name only the AEAD and the hash, while key exchange groups and signature algorithms are negotiated as separate parameters. A TLS 1.3 suite name is therefore not comparable with a TLS 1.2 suite name on a like-for-like basis, even though both appear in the same field of a configuration file. An auditor who compares the two strings directly will therefore draw a conclusion the protocol does not support. Read the negotiated group and signature parameters as well, or the comparison is incomplete.
WireGuard takes the opposite approach and removes negotiation almost entirely: the protocol specifies a fixed algorithm set, so two implementations either interoperate or they do not. That is a legitimate design choice, and it also means "what suite does WireGuard negotiate" has no answer worth comparing. If you are auditing it, read the specification once and then audit the key handling around it instead of the negotiation.
The layer decides the vocabulary
An IPsec deployment negotiates twice: an IKE proposal for the control channel and an ESP transform for the data, and the two can legitimately differ. Reading the first and assuming it describes the second is a common source of confusion during an audit, because the configuration file mentions both and the interesting one is the second.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
A name available in one library is not automatically implemented for another data path. That is why "our product supports AES-256" is a weaker statement than it sounds, and why an interoperability problem is usually solved by finding the maintained intersection rather than by enabling every legacy algorithm on both sides.
The TLS 1.3 specification is the clearest published example of the separation, since it defines the suite as a pair and moves the rest into their own negotiation. Once that shape is familiar, the IPsec proposal and the single fixed WireGuard set both become readable as variations on the same idea.
Read the negotiated result, then stop
A configured proposal is not evidence of what two peers selected. The live session carries the answer, and every mainstream implementation can report it without a packet capture.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showRead the output for the selected algorithms rather than the offered list. If the answer is weaker than the policy intended, the fix belongs in the proposal configuration on one side or the other, and a mismatch usually shows up as a failed negotiation rather than a silent downgrade in modern implementations.
Then remember what the suite does not cover. Routes, application permissions, logging and retention are separate decisions with their own review, and a compatible cryptographic arrangement says nothing about any of them. The cipher discussion is worth having, but it answers a narrower question than the one most people are actually asking.
Keep the vocabulary precise and the argument gets shorter. A suite is a set of roles at a layer, a cipher is one component, and the negotiated result is the only thing that describes the connection you actually have. Everything else in the comparison is decoration.