Most encryption protects your data until the key is exposed. Forward secrecy changes that guarantee: even if your keys are compromised tomorrow, messages from yesterday remain protected.
Here's the mechanism behind that property and why it matters.
The Problem With Static Keys
Traditional public-key encryption has a vulnerability most people don't think about: 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 it 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 an adversary can obtain to retroactively decrypt past sessions.
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 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. 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. With a static-key system, an attacker now has 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) 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 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 that private key — forever, unless you explicitly revoke and regenerate.
| 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 | ✅ Yes (TreeKEM) |
| Key rotation on member removal | ❌ Manual only | ⚠️ Partial | ✅ 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, the ratcheting protocols 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 today can potentially be decrypted years later when one of three things happens: your key is compromised, 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 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 end-to-end encryption 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 services that offer both encrypted email and interactive messaging can provide forward secrecy in the messaging layer even when the email layer doesn't.
The key question: 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.
This post is part of the Haven Blog series on practical encryption. Haven uses MLS (RFC 9420) for encrypted chat — key ratcheting means past messages stay private even if future keys are compromised. havenmessenger.com
Top comments (0)