What is forward secrecy?

Encrypted traffic can be recorded today and attacked later. If every message is protected, directly or indirectly, by one long-lived key, then whoever obtains that key later through a seized phone, a breached server or a leaked backup can go back and decrypt the whole recorded history.

Forward secrecy breaks that link. RFC 9420, the MLS standard, defines it as messages sent at a certain point in time staying secure in the face of a later compromise of a group member. The phrase looks backwards from the moment of compromise: what was sent before stays private.

It helps to see what its absence looks like. The NIP-44 encryption format used on Nostr lists its own limits plainly, including “No forward secrecy: when a key is compromised, it is possible to decrypt all previous conversations.”

Forward secrecy has two ingredients: keys agreed fresh for each session, and the discipline to throw them away.

TLS 1.3 shows the pattern. RFC 8446 removed the static RSA and static Diffie-Hellman key exchanges that earlier versions allowed, so that all public-key based key exchange in TLS 1.3 provides forward secrecy. Each connection runs a new ephemeral Diffie-Hellman exchange, and the server’s long-term signature key only authenticates that exchange. The RFC states that if the long-term keys are compromised after the handshake, the session key stays secure, “as long as the session key itself has been erased.” It also notes the exception: a session resumed with a pre-shared key alone, without a fresh Diffie-Hellman exchange, does not get this property.

Deletion is the part that is easy to overlook. A protocol can derive perfect short-lived keys, but if the device keeps them, stealing the device still exposes the past.

A long-lived chat session needs more than one fresh key at the start. Signal’s Double Ratchet algorithm, used for one-to-one messaging, changes keys continuously.

• The symmetric-key ratchet. Every message is encrypted with its own message key, derived from a chain key that is then replaced. The specification calls this property forward security: keys from the past look random to an attacker who learns the current chain key. Old message keys can be deleted once used.
• The Diffie-Hellman ratchet. The two parties keep exchanging new Diffie-Hellman public keys and mix the results into their keys, so a stolen key is eventually replaced by one the attacker does not know.

The specification is candid about the limits. Its section on secure deletion warns that the protection fails if deleted keys or plaintext can be recovered from the device’s storage. Keys kept for messages that arrive out of order are another risk, and it recommends deleting them after an interval.

Forward secrecy protects the past. Its companion, post-compromise security, protects the future: once the attacker loses access, new messages become private again. The Double Ratchet calls this break-in recovery and gets it from the Diffie-Hellman ratchet. In MLS, a member regains it by updating its own leaf key in the group’s ratchet tree, and RFC 9420 notes the protection starts only when the other members process the Commit carrying that update, not when it is sent.

Both properties assume the underlying key exchange is sound. The Double Ratchet specification notes that against an adversary who records traffic now and waits for a cryptographically relevant quantum computer, classical Diffie-Hellman based key rotation offers no protection, which is why the specification now also describes post-quantum ratchets.

In a group, keys are shared, which spreads the responsibility for deleting them. RFC 9420 explains that MLS provides forward secrecy between epochs, the numbered versions of the group’s state, by deleting private keys from earlier versions of the ratchet tree, and within an epoch by deleting each message key once it has been used. How MLS works covers epochs and the ratchet tree in more detail.

Because those secrets are held by every member, the RFC warns that forward secrecy is at risk as long as any member has not deleted them, especially a member that is offline for a long time. It says applications should have a way to remove members that have not updated their keys within some period. RFC 9750, the MLS architecture document, makes the same point: a client that is persistently offline may still hold old keying material and is a threat to both forward secrecy and post-compromise security if it is later compromised.

That tension matters for apps built to work offline. Devices that sync rarely keep old keys longer, so an app needs a policy for how long a silent member stays in a group.

• It does not protect content an app stores after decrypting it. Message history on a device is only as safe as the device.
• It does not help against an attacker who controls a device while messages are being sent. That attacker reads them as they arrive.
• It does not hide metadata such as who talked to whom, when and how much.
• It depends on correct deletion. Keys that survive in logs, backups or swap space undo it.