Forward Secrecy and Harvest-Now-Decrypt-Later

Forward secrecy means that compromising a long-term private key does not reveal past sessions. Each session's key is generated fresh and destroyed afterwards, so an attacker who obtains the server's key next year cannot decrypt the traffic they recorded this year.

The problem it solves

Older TLS used the server's RSA key directly for key transport: the client generated a session key, encrypted it with the server's public key, and sent it. Anyone holding the server's private key could decrypt that message and recover the session key.

So an attacker recording traffic today and obtaining the private key later — through a breach, a subpoena, a departing administrator, or a flaw in the key's generation — could decrypt everything retroactively. One key compromise exposed years of sessions.

Ephemeral key exchange removes that. The session key is derived through a fresh Diffie-Hellman exchange, the private values are discarded when the session ends, and the server's long-term key only signs the exchange to prove identity — it never carries the secret. Compromising it later allows impersonation going forward and reveals nothing about what was recorded.

Modern TLS mandates this. Non-forward-secret key exchange was removed from TLS 1.3 entirely, which is why the question is now mostly about older systems and internal protocols.

Consequences worth knowing

Passive decryption appliances stopped working. A device given a copy of the server's private key could previously decrypt mirrored traffic without touching it. With forward secrecy there is no key to copy, so inspection must terminate and re-establish the connection — the proxy arrangement under TLS proxies, which is architecturally more intrusive and is the reason many organizations changed their inspection design.

Incident response loses a source. Captured traffic from a compromised server cannot be decrypted after the fact, even with full access to the server. Investigations rely more on endpoint telemetry and on metadata, which is one reason flow data matters more than it used to.

Cost. A fresh key exchange per session is more expensive than reusing a key, which is why session resumption exists — and resumption tickets have their own forward secrecy considerations, since a long-lived ticket key reintroduces the problem it was meant to remove.

What it does not protect against

Being precise here matters, because forward secrecy is frequently claimed to solve more than it does.

It does not protect the current session from an active attacker — that is authentication's job. It does not protect data at rest on either endpoint. It does not help if the endpoint is compromised, since the plaintext is there. And it does not prevent future decryption of recorded traffic by an attacker who can break the key exchange itself.

That last point is the important one.

Harvest now, decrypt later

An adversary records encrypted traffic today and stores it, expecting to decrypt it when a capability arrives. The capability in question is a cryptographically relevant quantum computer, which would break both elliptic curve and finite-field Diffie-Hellman, because quantum algorithms solve the underlying problems efficiently.

Forward secrecy does not help against this. The protection forward secrecy offers is against compromise of the long-term key; a future attacker who can break the key exchange derives the session key directly from the recorded handshake, which is exactly the material they captured.

The exposure depends on how long the data stays sensitive. Traffic whose content is worthless in a decade is not really at risk; medical records, legal material, state secrets and long-lived credentials are.

The response is hybrid key exchange — running a classical exchange alongside a post-quantum algorithm and combining both results, so the session is secure if either holds. It is already deployed in parts of the web and in several VPN implementations, and it is the migration path rather than a future plan.

The related practical work is crypto agility: being able to change algorithms without redesigning the system, which means avoiding hardcoded algorithm choices and keeping an inventory of where cryptography is used. Organizations discovering they cannot answer that question are the ones for whom migration will be expensive — and it is the same inventory problem as everywhere else in this subject.

Exam angles

Define forward secrecy as ensuring that compromise of a long-term private key does not expose previously recorded sessions, achieved through ephemeral key exchange with per-session keys that are discarded. Know that TLS 1.3 requires it and that it broke passive decryption appliances. Recognize harvest-now-decrypt-later as recording traffic for future decryption, that forward secrecy does not mitigate it, and that hybrid post-quantum key exchange and crypto agility are the responses.