Forward Secrecy: If Today's Key is Lost, Are Yesterday's Secrets Still Safe?

The one-sentence version

An attacker can first record all your encrypted traffic, then wait until they steal your long-term private key one day to decrypt it all. Forward secrecy is designed to prevent this exact move: every communication uses ephemeral keys that are discarded after use to negotiate a session key, while the long-term private key is used only to prove identity and does not participate in encryption. This way, even if the long-term private key is leaked in the future, past communications remain undecryptable. Real-time communication (HTTPS, video calls, instant messaging) can achieve forward secrecy; however, stored data that "must be decryptable later" is structurally difficult to protect this way and can only minimize loss by rotating keys periodically and destroying old ones.

This article has three layers:

Layer 1: The Intuition: A one-time use codebook
Layer 2: Real-World Use: TLS 1.3, Signal, video calls, and why storage encryption cannot achieve it
Layer 3: Principles and Engineering details: Static DH vs. Ephemeral DH, Double Ratchet, and Key Rotation

Layer 1: The Intuition

1.1 Record now, decrypt later

A common strategy for intelligence agencies and advanced attackers is: record all encrypted traffic now, even if it cannot be decrypted temporarily. They wait until:

One day, a server is compromised and the long-term private key is stolen;
Or one day, quantum computers become available (see "Post-Quantum Cryptography");

Then, they go back and decrypt all the stored data.

1.2 A one-time use codebook

If every call uses a new codebook that is burned after use, then:

If today's codebook is stolen, only today's call can be decrypted;
Yesterday's and the day before's codebooks were burned long ago, so the recorded old calls can never be decrypted.

This is forward secrecy. The "long-term identity key" still exists, but it is only used to prove "I am who I say I am" and is not used to encrypt any data.

Layer 2: Real-World Use

System	Forward Secrecy
TLS 1.3 (HTTPS)	Mandatory: Only allows ephemeral (EC)DHE key exchange. TLS 1.2 and earlier allowed "encrypting the session key directly with the server's RSA public key," which lacks forward secrecy.
WebRTC Video Calls	Performs a DTLS handshake for every call; both parties use ephemeral keys and discard them once the call ends.
Signal / WhatsApp	Double Ratchet algorithm: Performs a new DH almost every round of messages, providing not only forward secrecy but also "post-compromise security."
Telegram Secret Chats	Performs a new DH periodically (based on message count or time).
SSH	Uses ephemeral DH for key exchange.

Heartbleed (2014) was a pivotal event that drove the adoption of forward secrecy: this OpenSSL vulnerability could allow an attacker to read the server's private key from memory. Websites without forward secrecy enabled meant all recorded historical traffic could potentially be decrypted. Since then, major websites have prioritized ECDHE, and eventually, TLS 1.3 made it a mandatory requirement.

2.1 Why storage data cannot achieve it

An encrypted recording or file intended for storage must be decryptable in the future, otherwise, there is no point in storing it. Therefore, the recipient must retain a private key capable of decrypting it (see "Envelope Encryption"). As long as this private key exists, if it is leaked, all historical files can be decrypted.

This is not an implementation flaw, but a requirement of the use case itself. What can be done is to reduce the blast radius:

Periodically rotate receiving keys, using a new one for each time period;
Once data from an old time period is decrypted and processed, destroy the old private key (or re-encrypt the data with a new key and then destroy the old one);
This way, leaking one key only affects the data from a single time period.

Layer 3: Principles and Engineering

3.1 Static DH vs. Ephemeral DH

Toy DH: Modulo 13, Generator 2

Static Receiver (No forward secrecy): Receiver's long-term private key $x = 5$ , public key $X = 2^5 \equiv 6$ .

The sender generates an ephemeral private key $y$ , e.g., $y = 7$ , and an ephemeral public key $Y = 2^7 = 128 \equiv 11$ , resulting in a shared secret $X^y = 6^7 \equiv 7$ ; the receiver calculates $Y^x = 11^5 \equiv 7$ , and both sides match.

What is stored on the server are $Y = 11$ and the ciphertext. If $x = 5$ is leaked one day, an attacker can calculate $Y^5$ for every stored $Y$ , allowing them to recover all historical shared secrets.

Both sides are ephemeral (With forward secrecy): For every call, $x$ and $y$ are newly generated and deleted after use. An attacker cannot obtain any $x$ or $y$ after the fact, making the recorded $X$ and $Y$ useless. (Verified with Python.)

3.2 Ephemeral Keys + Long-term Identity

Forward secrecy does not mean there are no long-term keys. A complete protocol is:

Both parties generate ephemeral DH keys and exchange public keys;
Use the long-term identity key to sign the handshake content (or use a certificate to prove identity) to prevent a Man-in-the-Middle from replacing the ephemeral public key;
Derive the session key from the result of the ephemeral DH.

The consequence of a stolen long-term key is: an attacker can later impersonate you (active attack), but cannot decrypt past recorded sessions (passive attack).

3.3 Double Ratchet: Forward Secrecy + Post-Compromise Security

Signal's Double Ratchet algorithm has two "ratchets":

Symmetric Ratchet: For every message sent, a KDF is used to advance the current chain key, and the old chain key is immediately deleted. Even if the current key is leaked, one cannot backtrack to previous message keys (the KDF is one-way). This provides forward secrecy;
DH Ratchet: Whenever the other party replies, both sides perform a new DH, mixing in fresh randomness. Even if all keys are leaked at a certain moment, the attacker will "lose the trail" after a few rounds of messages because they do not know the new DH private key. This provides post-compromise security.

3.4 Engineering pitfalls

Pitfall	Description
Session resumption	If TLS session tickets are encrypted with a long-term key that is never rotated, forward secrecy is quietly broken. Ticket keys must be rotated frequently.
Ephemeral keys not truly deleted	If they remain in logs, swap partitions, or core dumps, they are effectively not discarded.
Protecting transport but not storage	The call itself has forward secrecy, but if the recording is stored using a long-term key, the storage side still lacks it.
Multi-party calls via a server	If the server participates in decryption and forwarding, the server can see the plaintext; this is a different issue from forward secrecy (see "Comparison of End-to-End Encryption").

Summary

Layer	Key points
Threat	Record now, wait until the long-term private key is stolen (or quantum computers arrive) to decrypt
Method	Use ephemeral keys for each session negotiation and discard them after use; long-term keys are only for identity proof
Application	Mandatory in TLS 1.3; also used in WebRTC, Signal, and SSH
Storage	Structurally impossible; rely on periodic rotation and destruction of old keys to minimize loss