Imagine a patient adversary. They cannot decrypt your communications today, but they record all of them and keep them. Then, one day, they manage to steal the private key of the server you were communicating with, perhaps from a forgotten backup or through a vulnerability. Can they now read years of archived traffic? The answer depends on one specific property: forward secrecy, also called perfect forward secrecy.
The definition
A protocol offers forward secrecy when compromising the long-term keys does not allow past sessions to be decrypted. Long-term keys are those that identify a party for months or years: the private key of a website's certificate, the identity key of a messaging app, a person's PGP key.
In a system with forward secrecy, those keys serve only to prove identity, not to protect the data directly. The data is protected by temporary keys that are destroyed after use.
Without forward secrecy: key transport
To appreciate the value of this property, it helps to look at how many HTTPS connections worked until a few years ago. In versions of TLS before 1.3 it was still possible, and for a long time common, to use RSA key exchange:
- the browser generated a random secret;
- it encrypted it with the RSA public key in the server's certificate;
- the server decrypted it with its private key;
- the session keys were derived from that secret.
The problem is obvious: anyone who had recorded the traffic and later obtained the server's private key could decrypt the secret of every session and, with it, all the content. A single stolen key unlocked the entire archive.
With forward secrecy: ephemeral keys
The solution is to separate authentication from encryption by using an ephemeral key exchange, typically elliptic curve Diffie-Hellman (ECDHE):
- for each session, client and server generate a temporary key pair, used only once;
- with these keys they compute a shared secret that never travels over the network;
- the server signs its temporary key with the certificate's private key to prove who it is;
- at the end of the session the temporary keys are deleted.
Now, if the certificate key were stolen in the future, the attacker could at most impersonate the server from that moment on, until the certificate is revoked. They could not, however, decrypt sessions recorded in the past, because the temporary keys that protected them no longer exist anywhere.
TLS 1.3 removed RSA key exchange: every TLS 1.3 connection offers forward secrecy by design.
Forward secrecy in chat apps
Messaging apps that use the Signal protocol take the concept even further. Keys change not just with every session but with every message, thanks to the mechanism known as the double ratchet. If an attacker managed to extract the current keys from a phone, they still could not decrypt earlier messages.
There is also a complementary property, post-compromise security: after a few messages have been exchanged, the injection of fresh random material locks the attacker out of future communications as well.
Where forward secrecy is missing
Not every system offers it.
| System | Forward secrecy |
|---|---|
| TLS 1.3 | Always |
| TLS 1.2 with ECDHE or DHE | Yes |
| TLS 1.2 with RSA key exchange | No |
| Apps using the Signal protocol | Yes, for every message |
| PGP-encrypted email | No |
| Files or disks encrypted with a fixed key | Not applicable: the key protects data over time |
The PGP case is instructive: a message encrypted to your public key remains decryptable with your private key for as long as that key exists. Anyone who kept your encrypted emails and one day obtains your key and passphrase can read them all.
A technical detail that can undermine it
Even with ephemeral key exchanges, some optimisations can weaken forward secrecy. To speed up reconnections, TLS servers can issue session tickets encrypted with a server key. If that key stays unchanged for months and is stolen, sessions resumed with those tickets may be exposed. Server administrators should make sure ticket keys are rotated frequently.
What forward secrecy does not do
Forward secrecy protects recorded traffic in transit from an adversary. It does not protect:
- data stored in plain text on the server or the device;
- sessions in progress at the moment a device is compromised;
- future communications if the attacker uses the stolen key to impersonate the server before revocation.
In short
- Forward secrecy prevents the theft of a long-term key from exposing past sessions.
- It is achieved with ephemeral key exchanges, signed by the long-term key for authentication only.
- TLS 1.3 always guarantees it; the old RSA key exchange did not provide it.
- The Signal protocol applies it to every single message; PGP does not offer it.
- Session tickets with keys that are never rotated can weaken it.
