AES-GCM and ChaCha20-Poly1305 provide strong protection; the label "AES-256" on its own does not confirm that a connection is secure.
A virtual private network (VPN) protects the contents of tunnelled traffic from your ISP and the owner of the Wi-Fi network. The protection applies between your device and the VPN server, and only to packets routed through the tunnel. Choosing a connection to suit the situation is covered in the VPN protocol overview.
How AES, ChaCha20 and TLS 1.3 differ
The Advanced Encryption Standard (AES) hides data using a secret key. The numbers 128 and 256 denote the key length in bits. Authenticated encryption with associated data (AEAD) also verifies whether a packet has been modified in transit. Examples include AES in Galois/Counter Mode (AES-GCM) and ChaCha20-Poly1305.
Transport Layer Security (TLS) negotiates a secure connection and verifies the authenticity of the other party. Put simply, TLS 1.3 is a protocol version, whereas AES-256 denotes a cipher and key length.
| Notation | What it means for security |
|---|---|
| AES-128-GCM | Strong encryption and packet integrity checking |
| AES-256-GCM | The same task with a longer key; other settings still matter |
| ChaCha20-Poly1305 | Modern AEAD encryption, built into WireGuard |
| TLS 1.3 | A secure connection with its own set of algorithms |
The UK's National Cyber Security Centre (NCSC) uses AES-128-GCM in its recommended IPsec profile. The guidance applies to organisations and data classified as OFFICIAL; it does not certify consumer VPNs. It shows that a requirement of "AES-256 only" is not technically justified.
Which cryptography lies behind a protocol's name
WireGuard has a fixed set of algorithms. With OpenVPN and IPsec, security depends on the negotiated settings.
| Protocol | Data encryption | Key exchange and authentication | Assessment |
|---|---|---|---|
| WireGuard | ChaCha20-Poly1305 | Curve25519, Noise handshake | Modern fixed set |
| OpenVPN 2.6 | AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305 where supported | TLS, usually certificates | Reliable with a modern profile |
| IKEv2/IPsec, NCSC profile | AES-128-GCM | Groups 19 or 14, X.509 certificates | Reliable when the profile is followed |
| VLESS | External TLS/REALITY or the separate VLESS Encryption mechanism | Depends on the security layer | The name VLESS alone is not enough |
| Hysteria2 | QUIC transport encryption | QUIC mechanisms and client authentication | Assess the secure transport settings |
| PPTP | Considered broken | Outdated mechanisms | Do not use |
WireGuard: a fixed set and key rotation
WireGuard uses Curve25519 to negotiate a shared secret, ChaCha20-Poly1305 to protect packets and BLAKE2s to compute cryptographic hashes of data. The parties do not choose a cipher from a list and cannot agree on an outdated option. The handshake — the exchange of messages to obtain keys — is repeated every few minutes.
WireGuard: a fixed set and key rotation
OpenVPN: check the profile and disable compression
In OpenVPN 2.6, one of the AEAD ciphers listed in the table is negotiated by default. The control channel is protected by TLS; the tls-crypt option additionally encrypts and authenticates control packets.
Disable compression: it creates conditions for the VORACLE attack regardless of key length.
OpenVPN Connect offers security levels:
- Preferred: AEAD only, without compression. Choose it if the server supports it.
- Legacy: compatibility with older settings; the default level in the documentation.
- Insecure: allows outdated algorithms. Instead of lowering your security, request an updated profile.
For example, an old profile will only connect at the Insecure level. Request a new profile with AEAD and reconnect at Preferred; until then, the security problem cannot be considered resolved.
IKEv2/IPsec: certificates and exchange groups matter
Internet Key Exchange version 2 (IKEv2) negotiates security, while the IP security protocol family (IPsec) protects the packets. The recommended NCSC profile uses AES-128-GCM, X.509 certificates and Diffie–Hellman exchange groups 19 or 14.
IKEv1 has been formally deprecated according to RFC 9395. You should abandon old L2TP/IPsec connections with IKEv1; the IPsec family itself has not been deprecated.
VLESS and Hysteria2: find the layer that encrypts
VLESS does not encrypt traffic by itself. For use on the internet you need external TLS/REALITY or the VLESS Encryption mechanism. REALITY is a modified TLS with a handshake disguised as traffic to a target website.
Keep the layers separate: VLESS handles addressing and authentication, the transport carries the data, and TLS/REALITY secures the connection. The old transport name "VLESS tcp" in the Xray documentation has been replaced with RAW. It does not determine encryption.
Hysteria2 uses QUIC transport encryption. Connection masking serves a different purpose and does not prove the strength of the encryption.
What to check besides the protocol's name
The NCSC guidance for organisations contains a warning: weaker profiles or algorithms than those recommended increase the risk of data compromise. A protocol's name on its own does not confirm the security of its settings.
The Electronic Frontier Foundation (EFF) warns that issues such as TunnelVision can undermine security on a public network if the client is not updated. Breaking AES is not required for this.
- Update your VPN client and operating system.
- Abandon the Point-to-Point Tunnelling Protocol (PPTP): its security is considered broken. Apple removed support as far back as iOS 10 and macOS Sierra.
- Check the profile for outdated algorithms, IKEv1 and permitted OpenVPN compression.
- Keep server authentication enabled: do not switch it off to fix a connection error.
To replace an old profile, use the guide to changing VPN protocol. The choice between the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) concerns packet delivery. TCP does not, by itself, strengthen encryption: assess the differences between TCP and UDP separately.
If you want to know exactly which protocol and cryptography protect your router's traffic, take a look at CitadelVPN: MAX includes ready-made WireGuard/OpenVPN configurations — protocols with openly documented cryptography. Before choosing a plan, ask support about compatibility with your router model and firmware, which ciphers the OpenVPN profile sets, and whether WireGuard uses a pre-shared key (PSK).
Frequently asked questions about encryption strength
Can WireGuard or OpenVPN be easily decrypted?
No; for correctly configured modern connections such a claim is unfounded. A client error or a stolen key creates other attack paths than breaking the cipher.
What does forward secrecy mean?
Forward secrecy means that the disclosure of a long-term key does not automatically allow previously recorded sessions to be decrypted. In WireGuard, session keys are rotated regularly for this purpose; OpenVPN supports this principle in TLS mode with a Diffie–Hellman exchange.
Is post-quantum security needed now?
It matters primarily for data that must remain secret for many years: such cryptography is designed for the future threat of quantum computers. WireGuard is not post-quantum secure by default, but a PSK adds a layer of protection; the VLESS Encryption mechanism uses ML-KEM-768 for post-quantum key agreement. However, for now the NCSC is awaiting the relevant IPsec profiles, and the presence of these mechanisms in a particular service must be confirmed separately.
How to choose a reliable connection
Choose WireGuard, OpenVPN with AEAD and no compression, or IKEv2/IPsec with a modern profile. AES-128-GCM is sufficient for strong protection; insisting exclusively on AES-256 is unnecessary. For VLESS, check the encryption layer; abandon PPTP and IKEv1. Keep your client updated and keep server authentication enabled.