Symmetric vs Public-Key Encryption in a VPN: What Each Does

People describe a VPN as "using public-key encryption" and then picture every packet being locked with the server's certificate. That picture is wrong in a way that matters when you read a config file or a packet capture. The public-key half of a VPN is about proving who the peer is and agreeing on secret material; the symmetric half is what actually protects the traffic, packet after packet, for the life of the session.

The two halves have different lifetimes, different failure modes, and different things you can safely publish. Once you separate them, questions like "is RSA 2048 weaker than AES-128" stop being confusing, because they were never comparable in the first place.

Three operations that get lumped together

Public-key cryptography is an umbrella over at least three distinct operations. A signature proves that the holder of a private key approved a particular message. Key agreement lets two peers derive a shared secret from values they exchange in public. Public-key encryption hides data under someone's public key so only the private key can open it.

VPN handshakes mostly use the first two. A certificate is not an encryption key; it is a signed statement binding a name to a public key, which lets the other side decide whether to trust the key it just received. TLS 1.3 key establishment, for example, is built on (EC)DHE key agreement plus certificate signatures, not on encrypting the session to the server's public key.

What the handshake actually produces

In a modern handshake, each side generates an ephemeral key pair, exchanges the public halves, and computes a shared secret that never crosses the wire. That secret is then run through a key-derivation function to produce separate keys for each direction, plus the nonces and IV material the record layer needs. WireGuard does this with its Noise-based construction; TLS 1.3 does it with HKDF over the handshake transcript.

The long-term credential — certificate and private key, or a static WireGuard key — authenticates that exchange. It signs or mixes into the transcript so a stranger cannot complete the handshake in the peer's place. After that, the credential is not doing per-packet work. If it were, every packet would need a private-key operation, and a busy tunnel would be limited by the slowest operation in the stack.

Two side effects follow. First, the session keys are fresh each time, which is why an attacker who later steals the long-term key cannot decrypt sessions recorded earlier, provided the agreement was ephemeral. Second, a leaked session key compromises one session, not the identity.

Why bulk data uses symmetric keys

Symmetric ciphers handle volume well: AES-GCM or ChaCha20-Poly1305 process each packet with a key that is already in memory, authenticate the header, and increment a counter. The receiving side checks the nonce and the authentication tag, and drops anything that fails or replays. That is cheap enough to run at line rate on ordinary hardware, and the same construction gives confidentiality and integrity in one pass.

The construction is also where most implementation bugs live. A repeated nonce in GCM breaks confidentiality and authenticity at once, so protocols derive keys per direction and maintain an explicit counter or epoch. If you are reading a packet capture and the ciphertext length matches the plaintext plus a fixed overhead, that is the symmetric layer at work, not a public-key operation happening per packet.

Lifetimes, rekeys, and forward secrecy

Session keys are meant to expire. TLS 1.3 allows a KeyUpdate message to roll the traffic keys; WireGuard rekeys a session after a configured time or message count and keeps the old one briefly for in-flight packets. OpenVPN renegotiates its data-channel keys on a schedule, with reneg-sec controlling the interval.

None of that rotation is the same as renewing a certificate. A certificate can be valid for a year while the session keys change every few minutes, and a certificate can be replaced without touching the running tunnel's keys. When you plan an expiry, ask which object you are rotating; the answer decides whether clients reconnect or simply rekey.

Reading configs and diagnostics without mixing objects

In practice, you are choosing a complete protocol and its supported primitives, not assembling your own. OpenVPN's --tls-crypt key protects the control channel; the data channel uses negotiated symmetric ciphers. WireGuard's PrivateKey and PublicKey entries are identity material, while its transport keys are derived internally. Reading those fields as the same kind of secret leads to mistakes like pasting a public key where a private one belongs.

Keep public material separable from private. A certificate, a WireGuard public key, and a fingerprint are safe to share in a ticket. A private key, a pre-shared key, and an exported session key are not. When you compare strengths, compare within a type: an elliptic-curve identifier, an RSA modulus size, and an AES key size measure different things under different assumptions. The TLS 1.3 specification is a useful reference for how the two layers fit together, even when your tunnel is not TLS.