Traditional public-key encryption has a vulnerability that most people don't think about until it's too late: if your private key is ever exposed, every message encrypted to that key — past and future — can be decrypted. An adversary who records encrypted traffic today can sit on that traffic for years, waiting for a key compromise. Once they have the key, they have everything.
This is a real attack pattern. Intelligence agencies have long practiced "harvest now, decrypt later" collection — storing encrypted data in bulk and processing it when keys become available through compromise, court order, or cryptographic breakthrough. Forward secrecy is the countermeasure.
What Forward Secrecy Actually Means
Forward secrecy (sometimes called perfect forward secrecy or PFS) is the property that compromising a long-term key does not compromise past session keys. Each communication session uses a fresh ephemeral key that is discarded immediately after use. There's no accumulated secret that an adversary can obtain to retroactively decrypt past sessions.
The term "perfect" is something of a misnomer — it refers to the mathematical property that past sessions are independent of the current key state, not to the system being unbreakable. "Forward secrecy" is the more accurate term and has largely replaced "perfect forward secrecy" in cryptographic literature.
The classic implementation is Diffie-Hellman key exchange with ephemeral parameters. Each session negotiates a new shared secret; the private values used in that negotiation are discarded. Even if someone later compromises your long-term identity key, they cannot reconstruct the ephemeral session key — and therefore cannot decrypt the session content.
Key Ratcheting: Forward Secrecy for Every Message
In modern encrypted messaging, forward secrecy is implemented through a technique called key ratcheting. Rather than deriving a new key per session (which might span thousands of messages), ratcheting derives a new key per message — or per small batch of messages.
The Signal Protocol — used by Signal and WhatsApp — implements a "double ratchet" algorithm. Two separate ratchets operate simultaneously:
- The Diffie-Hellman ratchet periodically generates new key material through DH exchanges, providing forward secrecy across sessions.
- The symmetric ratchet derives new message keys from the current chain, providing per-message key derivation within a session.
Each message key is derived from the previous state and used exactly once, then discarded. An adversary who captures message key N cannot derive message key N-1 — the ratchet only goes forward. The cryptographic function used for derivation is a one-way HKDF (HMAC-based Key Derivation Function): you can derive forward, never backward.
A physical ratchet only turns in one direction — you can advance it but not reverse it. Key ratcheting works the same way: each step produces a new key from the current state, but the previous state is gone. Knowing where the ratchet is now tells you nothing about where it was before.
Break-In Recovery: The Property PGP Doesn't Have
Forward secrecy protects the past. A related but distinct property — sometimes called "break-in recovery" or "post-compromise security" — protects the future after a key compromise.
Suppose your device is briefly compromised: an attacker has access to your current key state. With a static-key system, they now have everything they need to read all future messages until you explicitly rotate keys. With a ratcheting system, the attacker's access is time-limited: once the DH ratchet advances again (requiring a new message from the other party), the chain state changes in a way the attacker cannot follow without continued access to your device.
MLS (Messaging Layer Security, RFC 9420) — the protocol Haven uses — formalizes both properties in group settings, where managing forward secrecy is significantly harder than in 1:1 conversations. In a group of 50 people, adding or removing a member triggers a key update that ensures the removed member cannot read future messages (forward secrecy from their perspective) and couldn't have read future messages even if they retained current key material (break-in recovery).
Where PGP Falls Short
OpenPGP, which underpins ProtonMail, Tutanota (in its legacy mode), and most encrypted email, has no forward secrecy. Your PGP private key is a long-lived static key. Every message encrypted to your public key remains decryptable by whoever holds your private key — forever, unless you explicitly revoke and regenerate keys.
| Property | PGP | Signal Protocol | MLS (RFC 9420) |
|---|---|---|---|
| Forward secrecy | No | Yes (per-message) | Yes (per-message) |
| Break-in recovery | No | Yes (DH ratchet) | Yes (member updates) |
| Group forward secrecy | No | Limited (per-sender) | Yes (TreeKEM) |
| Key rotation on member removal | Manual only | Partial (Sender Key) | Cryptographically enforced |
| Interoperability | Universal | Signal-ecosystem only | Growing (IETF standard) |
PGP's lack of forward secrecy isn't a failure of implementation — it's a design trade-off. PGP was built for a world where key management is manual and interoperability matters more than session-level security properties. For encrypted email between parties who have never established a live connection, a static key model is the practical choice.
For interactive messaging — where two or more parties are actively communicating in real time — the static key model is an unnecessary limitation. The ratcheting protocols designed for messaging provide forward secrecy without the interoperability cost, because both parties are running the same software.
The "Harvest Now, Decrypt Later" Threat
Forward secrecy is particularly important in the context of mass surveillance. An adversary capable of recording encrypted traffic in bulk can afford to be patient. If your encryption scheme uses static keys, captured traffic from 2026 can potentially be decrypted in 2035 when one of three things happens: your key is compromised, your key is obtained through legal compulsion, or cryptographic advances make the underlying algorithm breakable.
With forward secrecy, that calculus changes. Captured traffic from a ratcheting protocol requires the specific per-message key for each message — keys that existed momentarily during the communication and were immediately discarded. There's no long-term secret to harvest, compel, or wait for a cryptographic breakthrough against.
This is why the NSA's BULLRUN program — disclosed in Snowden documents — specifically targeted forward secrecy implementations. Weakening or circumventing forward secrecy was a priority precisely because it's the property that makes bulk traffic collection impractical to exploit.
What You Should Look For
For encrypted messaging, forward secrecy should be table stakes. Signal Protocol and MLS both provide it. Any messaging app claiming to be end-to-end encrypted should be able to tell you what ratcheting mechanism it uses and how per-message key derivation works.
For encrypted email, forward secrecy is genuinely harder — email's asynchronous delivery model makes session-based key exchange difficult. PGP remains the standard for encrypted email interoperability. But email services that also offer interactive messaging (like Haven) can and should provide forward secrecy in the messaging layer even when the email layer doesn't.
The key question to ask: if an adversary obtained your encryption keys today, how much of your past communication becomes readable? For a properly ratcheting system, the answer is: none of it. For a static-key system, the answer is: everything.