What is post-compromise security?

Most encryption is judged by what happens before an attacker gets in. Post-compromise security asks the opposite question: once an attacker has copied the keys from someone’s device, is that conversation lost for good, or can it become private again?

Katriel Cohn-Gordon, Cas Cremers and Luke Garratt gave the property its name and its first formal definitions in a paper published at the IEEE Computer Security Foundations Symposium in 2016. They point out that at first sight it seems impossible to offer any security to a party whose secrets are already known, and show that under some conditions useful guarantees are still possible.

RFC 9420, the MLS standard, puts the two properties side by side. Forward secrecy means messages sent at a certain time stay secure if a member is compromised later. Post-compromise security means messages are secure even if a member was compromised at some point in the past.

If the attacker’s copy of the keys is a snapshot, new keys that it cannot derive from that snapshot shut it out. Two things are needed. Each new key must depend on fresh randomness the attacker has not seen, and the other side must start using it.

The Signal Double Ratchet shows the pattern for two people. Its symmetric ratchet derives a new key for every message, but because those steps use constant inputs, the specification says they do not provide break-in recovery. An attacker who steals the chain keys could compute every future message key. So each party also generates new Diffie-Hellman key pairs and sends the public halves with its messages, and the results are mixed into the keys. In the specification’s words, later keys cannot then be calculated from earlier ones.

Groups are harder, because every member holds shared secrets. MLS arranges those secrets in a ratchet tree, where each member sits at a leaf. RFC 9420 says post-compromise security is provided between epochs by members regularly updating their leaf key, so group secrets stop being encrypted to public keys whose private keys had been compromised.

The timing matters, and the RFC is precise about it:

• An Update proposal on its own does not achieve post-compromise security until another member includes it in a Commit.
• A member can get it straight away by sending its own Commit with the path field filled in. A Commit with no proposals at all exists for this: it resets the sender’s leaf and the nodes above it.
• In every case the guarantee starts when the other members process the Commit, not when the sender creates it.

RFC 9750, the MLS architecture document, gives the same idea as a timeline. If a member is compromised at time t1 and performs an update at a later time t2, the MLS guarantees apply to that member’s messages sent after t2, and to other members’ messages once they have processed the update. How MLS works covers epochs and Commits in more detail.

Post-compromise security assumes the attacker steps back. Several situations break that assumption.

• The attacker is still inside. RFC 9750 notes that an active attacker holding group secrets can take part in the protocol and perform updates on the victim’s behalf, so the group cannot recover by updates alone. MLS still offers a way out through its Remove operation: once the compromised member is removed, later epochs are secure as long as the remaining members are honest.
• The signing key leaked. If the attacker has the value of the private signature key, RFC 9750 says the compromised endpoint has to refresh its credentials and invalidate the old ones before the attacker can no longer authenticate messages.
• The device itself is controlled. The Double Ratchet specification warns that an attacker could impersonate the victim with its identity key, sit in the middle of the session substituting its own ratchet keys, or tamper with the random number generator so future keys are predictable. If a party suspects its keys or devices are compromised, the specification says it must replace them immediately.
• Updates are suppressed. RFC 9420 notes that a compromised Delivery Service could work with an attacker to defeat post-compromise security by dropping the Update and Commit messages that would lock the attacker out.
• Old key packages are used. A member added to a new group through an old key package whose private key was compromised starts that group already exposed, which is why the RFC recommends regularly uploading fresh ones.

The property is only as good as the habits around it. RFC 9420 says Update messages should be sent at regular intervals while a group is active and that members who do not update should eventually be removed, leaving the interval to the application. It suggests the right frequency is usually hours or days, not milliseconds.

RFC 9750 adds advice that matters on phones, which are often offline. It recommends requiring key updates from clients that are not otherwise sending messages, evicting clients that stay idle too long, and keeping signature private keys apart from other secrets, preferably in dedicated hardware, so that authentication can be recovered after a compromise.