Culvert VPN

VPN encryption explained without the jargon

VPN encryption does three jobs: agreeing a secret key, scrambling each packet and proving nothing was altered. What each means and what it cannot do.

Protocols and the technology · 4 min read · By Culvert VPN

VPN encryption does three separate jobs. First, your phone and the server agree on a secret key over a network that may be watching, using a key exchange such as Curve25519. Second, every packet is scrambled with that key using a cipher such as ChaCha20 or AES, so the network sees only noise. Third, each packet carries a short authentication tag, so any alteration in transit is detected and the packet is dropped. When people say a VPN is "encrypted", they mean all three are happening, and a VPN that did only the second would not be safe.

The three jobs

JobQuestion it answersWireGuard's choiceOpenVPN and IKEv2
Key exchangeHow do we agree on a secret nobody in between can learn?Curve25519Diffie-Hellman over a negotiated curve or group
Encryption with integrityHow do we scramble each packet and detect tampering?ChaCha20-Poly1305Usually AES-GCM
Hashing and key derivationHow do we turn the exchanged secret into usable session keys?BLAKE2sSHA-2 family

The pairing of a cipher with an authentication tag, as in ChaCha20-Poly1305 or AES-GCM, is called authenticated encryption, and it is what every modern VPN uses. Encryption without authentication was the source of several old attacks, because an attacker who cannot read a packet can still flip bits in it and watch what happens.

Key exchange, in one paragraph

The problem is that the phone and the server have never met and the network is listening. Diffie-Hellman key exchange solves it: each side generates a temporary private number, sends a public value derived from it, and combines the other side's public value with its own private number. Both arrive at the same shared secret, and an observer who saw both public values cannot compute it. Curve25519 is one specific, well-studied way of doing this with elliptic curves. The handshake post walks through the messages that carry it.

Key exchange alone does not tell the phone it is talking to the real server rather than something impersonating it. That is authentication, and it comes from a long-term key on each side: a static public key in WireGuard, a certificate in OpenVPN and IKEv2. The temporary secret is mixed with the long-term keys so the session is bound to both.

What "256-bit" means, and does not

A 256-bit key has 2^256 possible values, a number so large that trying them all is not a realistic threat with any technology anyone can describe. Both ChaCha20 and AES-256 use keys of that size, and neither has a known practical attack. The marketing phrase for this is grandiose, but the fact underneath is plain: the cipher is not where a VPN will fail.

Where a VPN actually fails is around the cipher. A weak key exchange, a certificate that is not checked, a random number generator that is not random, a configuration that quietly allows an old cipher to be negotiated, or a bug in the code that handles the packets. This is why protocol design matters more than the number on the box. WireGuard's approach of fixing every choice and keeping the code small addresses exactly these failure points, as the WireGuard explainer covers.

Forward secrecy

Session keys should be temporary. WireGuard performs a fresh key exchange roughly every two minutes and throws the old keys away; OpenVPN and IKEv2 do the same on a longer schedule. The result is that a key recovered at some later date would decrypt only the few minutes it was in use. Recording encrypted traffic today in the hope of decrypting it later gains nothing, because the keys that would do it no longer exist anywhere.

What encryption does not do

The tunnel is encrypted between your phone and the VPN server, and it ends there. The server decrypts your traffic and sends it on to its destination exactly as your phone would have. That has three consequences worth being clear about.

  • The VPN provider is in the same position your ISP was. It can see which servers you connect to. If the site uses HTTPS, which nearly all do, it cannot read the contents, only the destination. The VPN and HTTPS post explains why both layers are worth having.
  • Encryption hides content, not behaviour. Your ISP can no longer see where you go, but the sites you visit still see your account, your cookies and your device. A VPN is not an anonymity tool.
  • It protects the path, not the ends. Malware on the phone, a phishing page, a weak password: none of these are inside the tunnel's job.

On the provider side, Culvert VPN does not log the sites you visit, your DNS queries or the contents of your traffic; its servers see only an opaque connection id, never an account; and it keeps the client IP address for up to 30 days for abuse handling, all of which is set out in its privacy policy. The post on what your ISP can see covers the other side of the same question.

Culvert VPN uses WireGuard's fixed cryptography, Curve25519, ChaCha20-Poly1305 and BLAKE2s, with automatic rekeying, on every connection where the network allows it, and the same tunnel wrapped in TLS where it does not; the app is on Google Play.

Questions people also ask

Is AES-256 better than ChaCha20?

Both are considered secure with no practical attacks. AES is quicker on processors with dedicated AES instructions; ChaCha20 is quicker on those without, which includes many phones. Neither is a reason to choose a VPN.

Can my VPN provider read my traffic?

The tunnel's encryption ends at the VPN server, so the provider sees the same thing your ISP would see without a VPN: where the traffic goes, and whatever is not separately encrypted by HTTPS.

What does forward secrecy mean?

That session keys are temporary and discarded, so recovering one later would unlock only the short window it covered, not past or future traffic.