After the break-in

Start with the question most encryption marketing declines to ask: your device was compromised last Tuesday, the attacker got the keys, and today it is clean again. What, if anything, is protected now? The intuition is nothing. In 2016 Katriel Cohn-Gordon, Cas Cremers and Luke Garratt showed that intuition is wrong, and gave the property a name. Their CSF paper opens: "In this work we study communication with a party whose secrets have already been compromised. At first sight, it may seem impossible to provide any type of security in this scenario. However, under some conditions, practically relevant guarantees can still be achieved. We call such guarantees post-compromise security."

Signal frames forward secrecy and post-compromise security as mirrors of each other: "FS protects past messages against future compromise, while PCS protects future messages from past compromise." Both come out of the same ratchet, but not out of the same half of it.

Only one half of the ratchet heals

This is the detail worth carrying away. The Double Ratchet specification defines break-in recovery as: "Future output keys appear random to an adversary who learns the KDF key at some point in time, provided that future inputs have added sufficient entropy." That proviso is the whole mechanism. And the spec is explicit that the symmetric side does not satisfy it — "the KDF inputs for the sending and receiving chains are constant, so these chains don't provide break-in recovery." Hashing a chain key forward a million times gives you forward secrecy and nothing else; an attacker holding the chain key hashes forward too.

The entropy comes from the Diffie–Hellman step, and only from there. Each side attaches a new ratchet public key; when the other side sees a key it has not seen, it performs a DH calculation and derives a new root. The spec calls it "ping-pong" behaviour, and describes the payoff: "An eavesdropper who briefly compromises one of the parties might learn the value of a current ratchet private key, but that private key will eventually be replaced with an uncompromised one."

What it does not recover

Post-compromise security is a statement about key material, and it is easy to over-read. The specification's own warning is blunt: "a compromise of secret keys or of device integrity will have a devastating effect on the security of future communications." It then lists why. The attacker can impersonate the compromised party using their identity private key. The attacker can "substitute her own ratchet keys via continuous active man-in-the-middle attack" — healing assumes the adversary went away, and an adversary who stays never lets the fresh entropy through. The attacker can manipulate the random number generator, and a ratchet fed predictable randomness ratchets into a wall.

Add what no key schedule addresses at all: messages already decrypted in the local database, a screen recording, or a linked device the attacker enrolled while holding the phone — a full member of the account, with its own key, the subject of our previous note, still receiving mail long after the ratchet has healed.

Post-compromise security recovers the key schedule. It does not recover the device, the archive, or the account.

Where OSHI was wrong, again

None of this is theoretical for us. In OSHI's v2 key schedule, the Diffie–Hellman ratchet never turned — not rarely, never. The code comment carries the finding number, CV-010, and says so plainly.

The mechanism was a loop that closed on itself. performDHRatchet ran only when the peer's ratchet public key changed, and a side replaced its own ratchet key pair only inside performDHRatchet. On the first message from a peer the code took the "store their key, no DH ratchet" branch. So neither side ever rotated, neither side ever observed a change, and the ratchet never fired. It is pinned by a test whose name is the finding: after ten full round trips the root key was still the initial one, and a session rebuilt from the static X25519 identity secret alone decrypted brand-new traffic.

The consequence is the one the whole construction exists to prevent: every 1:1 message on that path was derivable from the long-term identity keys. Compromise the identity key once and the entire conversation opens, past and future, with no healing at any point. All the vocabulary above applied to us; none of the property did.

It was fixed on 4 September 2026 on iOS and Android. A Double Ratchet normally bootstraps from a responder key the initiator already has, which on this path does not exist; the responder's initial ratchet pair is now derived from the shared secret instead, so its first receive performs a real ratchet and generates a random key of its own. From its first reply onward both sides are on random ephemeral keys. It shipped behind a negotiated session version — v2 and v3 refuse to exchange a message rather than silently downgrading — and v3 is now forced. One residual, said here rather than found later: the initiator's first message is still derivable by someone holding the identity keys, because the responder's bootstrap key is.

The ceiling

Every property here rests on one assumption: that the attacker is no longer on the endpoint. When they are, they read what you read, at the moment you read it, and the cryptography is not involved. Citizen Lab documented three separate zero-click iOS exploit chains used against civil society in 2022 alone. Apple describes the class as attacks that "cost millions of dollars and often have a short shelf life," aimed at "a very small number of specific individuals" — journalists, activists, politicians, diplomats — with threat notifications sent to users in over 150 countries.

Post-compromise security is worth building, it is provable, and a messenger that lacks it is worse than one that has it. It is also the ceiling of what a protocol can promise. Everything above that line is device security, and device security is somebody else's ratchet.