Perfect forward secrecy, plainly
Forward secrecy means each session uses temporary keys that are discarded afterwards, so an attacker who later obtains the server's long-term key cannot decrypt traffic they recorded in the past. It protects old sessions against a future compromise, which is the threat that store-now-decrypt-later describes.
4 min read
Imagine someone records your encrypted traffic today and stores it. They cannot read it. Years later they obtain the server's private key — by compromise, by purchase, by legal process. Can they now read what they recorded?
Without forward secrecy, yes. With it, no. That is the entire concept.
How it works
The long-term key proves who the server is. It is not used to encrypt your traffic.
Instead, each session generates a fresh ephemeral key pair, and the two ends perform a Diffie-Hellman exchange with those ephemeral keys to derive the session key. The long-term key signs the exchange, proving the server is who it claims, but never encrypts anything.
When the session ends, both sides discard the ephemeral keys. The material needed to decrypt that session no longer exists anywhere.
Store now, decrypt later
The threat this addresses is not hypothetical. Recording encrypted traffic is cheap; storage is cheap; a well-resourced adversary can keep years of it against the possibility of obtaining a key or a future cryptographic break.
Forward secrecy makes that strategy worthless for the sessions it covers. Each one has to be attacked individually, and the key that would do it was destroyed when the session ended.
How each protocol provides it
WireGuard rekeys roughly every two minutes while traffic flows. Its handshake
is Noise's IKpsk2 pattern, which performs ephemeral Diffie-Hellman on every
handshake. So the window of material compromised by any single key is a couple
of minutes rather than a session.
OpenVPN with a TLS control channel gets forward secrecy from TLS, provided the cipher suite uses ephemeral Diffie-Hellman — which every modern configuration does. It also renegotiates on a timer, by default hourly.
IKEv2 performs Diffie-Hellman during IKE_SA_INIT, and supports rekeying
child associations with a fresh exchange.
TLS 1.3, and therefore HTTPS, requires forward secrecy. The static RSA key exchange that lacked it was removed from the protocol entirely, which is one of the most significant changes in that revision.
The "perfect" is doing no work
The term is conventional rather than descriptive, and it promises more than it delivers. Three things it does not cover:
Traffic recorded and attacked directly. If the cipher itself is broken, forward secrecy is irrelevant.
The current session. An attacker who compromises a server while a session is live has the ephemeral key in memory. Forward secrecy protects the past, not the present.
Metadata. Who connected, from where, at what time, and how much data moved. None of that is encrypted by any tunnel, and it is often the more interesting part.
Why it matters specifically for a VPN
A VPN server is a concentration point. It sees every user's traffic, so its long-term key is a high-value target in a way that a single website's is not.
It is also the reason a no-logs claim and forward secrecy answer different questions. Forward secrecy means recorded ciphertext stays unreadable. A no-logs policy means the operator did not write down what it saw in plaintext at the moment it passed through. Neither substitutes for the other, and a provider needs both. VPNmine's privacy policy states what is recorded, which is the half a protocol cannot give you.
The quantum question
An attacker with a sufficiently large quantum computer could break Curve25519 and the elliptic-curve exchanges TLS uses. That would defeat forward secrecy retroactively for recorded traffic, because the ephemeral exchange itself becomes solvable.
This is exactly the store-now-decrypt-later scenario, aimed at the mechanism that was supposed to prevent it, and it is why post-quantum key exchange is being deployed now rather than when such a machine exists.
WireGuard's optional preshared key is a partial hedge: a symmetric secret mixed
into the handshake alongside the Diffie-Hellman result, which a quantum attacker
would also need. It requires distributing that secret out of band, which is
practical for a provider issuing per-device configurations and not for the open
web. VPNmine's profiles include one by default, which is visible as the
PresharedKey line in any issued configuration.
What to check
Nothing, if you are using WireGuard, IKEv2 or a current OpenVPN configuration — all provide it. It is worth checking on anything old: PPTP has no forward secrecy and several other serious problems, and an OpenVPN configuration pinned to a static key rather than TLS does not have it either. Both are reasons to change the configuration rather than details to note.
