eduKateSG · Information · The Gold Standard of Education
Limit what one key compromise reveals by moving secrets forward and deleting the past
Choose the explanation you need, or follow all twelve chapters in order.
Full chapter index · Independent practice · Information subject guide
Forward secrecy and post-compromise security answer different timeline questions. Forward secrecy protects earlier messages when a current or later secret is compromised. Post-compromise security aims to restore protection for later messages after fresh secret input enters the protocol. A key ratchet can support both, but only when state advances correctly, old keys are deleted, new entropy arrives and the endpoint itself is no longer controlled.
This article explains protocol concepts, not an implementation recipe. Secure messaging requires reviewed specifications and libraries, authenticated identity, reliable randomness, protected devices, careful state storage and expert threat modelling.
The useful mental model is an exposure window, not a magic shield. Ask when the adversary first gained state, which directions and devices were affected, whether old material was truly deleted, and which later honest contribution the adversary could not predict. Then bound the messages that remain at risk. This timeline approach keeps forward secrecy, break-in recovery, endpoint security and identity authentication from being collapsed into one vague claim that the conversation is “encrypted.”
Testing should include delayed messages, skipped-key expiry, state rollback, device addition and an interrupted ratchet update. Security properties that disappear during recovery or multi-device synchronisation are operationally incomplete.
Document the state machine with test vectors that show which secret is stored before and after each transition. Crash the process between derivation, encryption, transmission and deletion to verify that a restart neither reuses a message key nor loses necessary receiving state. Measure the maximum skipped-key store and confirm expiry. These checks do not prove cryptographic security, but they can expose integration failures that contradict the protocol’s assumptions while every primitive still passes a unit test.
Incident response should preserve the same precision. Replace compromised identity and device material through an authenticated path, establish a new session where required, and state the first message believed to have regained protection. Avoid promising retrospective safety for messages whose endpoint or plaintext copies were exposed.
Keep the evidence for that boundary: device replacement time, verified identity event, ratchet transition and successful authenticated message in each direction.
Continue from The Gold Standard of Information within The Gold Standard of Education: learning that transfers into life and the How X Works learning library.
Full chapter index
See the mechanism · Chapters 1–2
Build the worked model · Chapters 3–5
Test what changes · Chapters 6–8
Check evidence and limits · Chapters 9–10
Practise and continue · Chapters 11–12
Mark messages before, during and after a compromise. Then ask what the adversary learns: one message key, a chain key, a long-term identity key, device state or the whole endpoint.
Forward secrecy concerns the left side of the compromise. Learning today’s state should not reconstruct properly deleted past message keys. Post-compromise security concerns the right side after honest fresh input and protocol progress.
Do not use “future secrecy” without defining the recovery event. Time alone does not heal a compromised state.
Evidence check: for Draw the compromise on a timeline, preserve the observation before the interpretation. Record the exact erasure unit and tolerated failure domain. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
A key-derivation chain takes a chain key and produces a message key plus the next chain key. The message key encrypts one message; the old chain key and used message key are then deleted.
Given the next chain key, a secure one-way construction should not reveal earlier keys. That supports forward secrecy against later state compromise.
The same chain does not by itself provide break-in recovery. An attacker who steals the current chain key can derive future chain keys until fresh secret input changes the root.
Evidence check: for One-way chains move keys forward, preserve the observation before the interpretation. Record k, m, shard order and coding profile. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Imagine chain states C0 through C4 and message keys M1 through M4. Sending message 1 derives M1 and C1 from C0, encrypts, then deletes C0 and M1. The process repeats for each message.
If an attacker steals C3, the intended property is that M1 and M2 remain unrecoverable from C3. But the attacker may derive M3, C4 and later outputs on that chain.
The example makes deletion an assumption. If backups, crash dumps or logs retain C0, the mathematical ratchet cannot erase them.
| After message | Stored chain state | Deleted message key | Compromise can derive |
|---|---|---|---|
| 1 | C1 | M1 | M2 onward, not M1 |
| 2 | C2 | M2 | M3 onward, not M1–M2 |
| 3 | C3 | M3 | M4 onward, not M1–M3 |
| 4 | C4 | M4 | Later chain only |
Evidence check: for A worked four-message chain, preserve the observation before the interpretation. Record which position is missing and which values remain valid. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 4 OF 12 · Build the worked model
4. The second ratchet introduces fresh entropy
The Double Ratchet combines symmetric-key chains with Diffie–Hellman ratchet steps. New public values are exchanged, and a Diffie–Hellman output enters a root key-derivation chain, creating new sending and receiving chains.
If a passive adversary once learned the state but does not control a later honest private value, the fresh input can make future keys unpredictable again. This is break-in recovery or post-compromise security under stated conditions.
An active attacker controlling the endpoint or substituting keys can prevent recovery. Replace a suspected compromised device or identity path; do not rely on ordinary messages to fix active control.
Evidence check: for The second ratchet introduces fresh entropy, preserve the observation before the interpretation. Record survivor count and independence of repair equations. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 5 OF 12 · Build the worked model
5. Sending and receiving chains are directional
Each party holds separate sending and receiving chain keys. Alice’s sending chain corresponds to Bob’s receiving chain, and the reverse direction uses another chain.
A compromise can therefore have asymmetric effects. Learning one sending chain need not reveal the other direction if the protocol and state separation hold.
Record direction in test vectors and incident analysis. “The session key leaked” is too vague to bound exposure.
Evidence check: for Sending and receiving chains are directional, preserve the observation before the interpretation. Record field, matrix, padding and interoperability tests. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Asynchronous networks deliver messages late or out of order. A recipient may derive and temporarily store skipped message keys so a delayed message can still decrypt.
Stored skipped keys weaken deletion for those specific messages. Bound their count and lifetime. Signal’s specification uses a maximum-skip limit to prevent excessive work and storage.
Delete a skipped key immediately after successful use and expire old entries. A malicious sender should not be able to force unbounded key retention.
Evidence check: for Out-of-order messages create skipped-key risk, preserve the observation before the interpretation. Record source-block and symbol identifiers. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
A ratchet can protect message keys while a user talks to the wrong party. Initial key agreement, identity keys and user verification establish who the session belongs to.
Compromise of a long-term identity key may enable impersonation or new sessions even when earlier message keys stay protected. Separate confidentiality history from authentication consequences.
When identity changes, surface it through the product’s verified mechanism. Silent replacement weakens the human trust path.
Evidence check: for Identity authentication is a different layer, preserve the observation before the interpretation. Record integrity verification before and after decoding. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Messaging Layer Security organises group state into epochs. Commits update the group’s secrets and membership state. Forward secrecy protects earlier epochs after state advances and old secrets are erased.
Post-compromise security depends on uncompromised members contributing fresh update material and the group accepting a commit. An update proposal alone does not complete recovery.
Membership removal, delivery delay and compromised services change which messages remain exposed. Group timelines need more than a two-party diagram.
Evidence check: for Group messaging uses epochs and commits, preserve the observation before the interpretation. Record physical placement and correlated failure. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 9 OF 12 · Check evidence and limits
9. Backups and multiple devices widen the state boundary
A second device, cloud backup or migration archive may retain old chain state or plaintext. Forward secrecy is only as strong as the complete state lifecycle.
Inventory where session state, skipped keys and message history are stored. Apply encryption, access control and deletion policies to each copy.
Restoring a very old state can cause key reuse or protocol confusion if rollback is not handled. Use the protocol’s supported multi-device and recovery design.
Evidence check: for Backups and multiple devices widen the state boundary, preserve the observation before the interpretation. Record scrub interval, repair load and reduced-redundancy time. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Forward secrecy does not protect a message while the endpoint is compromised and reading plaintext. It does not prevent screenshots, malicious input capture or copied content.
Key rotation on a calendar is not automatically a ratchet. The security property depends on one-way derivation, fresh entropy, state replacement and deletion.
Post-compromise security is not instant. Recovery occurs only after the required honest update is incorporated, and active compromise can continue to defeat it.
| Compromise | Fresh honest update | Past protection | Future recovery |
|---|---|---|---|
| Current chain key | None | Earlier deleted keys protected | No |
| Current chain key | DH ratchet input | Earlier deleted keys protected | Possible after update |
| Whole active endpoint | Ordinary messages | No endpoint protection | No |
| Identity key only | New authenticated session | Old sessions depend on state | Requires identity replacement |
Evidence check: for Limits and common misconceptions, preserve the observation before the interpretation. Record metadata version, catalogue and recovery history. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 11 OF 12 · Practise and continue
11. Independent practice and changed-context transfer
Practice: an attacker obtains receiving chain key R7 and a store of skipped keys for messages 3 and 5. Identify which past and future messages may remain exposed, assuming earlier states were deleted.
Changed context: the next Diffie–Hellman ratchet step includes a fresh private key generated after malware removal. Explain why passive access may end there, and why an active man-in-the-middle or still-compromised random generator changes the conclusion.
Transfer to a group. A member updates a leaf key but nobody commits the proposal. Decide whether the new group epoch and post-compromise recovery have occurred.
Evidence check: for Independent practice and changed-context transfer, preserve the observation before the interpretation. Record the failure pattern that exceeds the promise. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Does forward secrecy mean past messages are always safe?
No. It protects against specified later key compromise when prior keys and plaintext copies are not retained. Endpoint capture and backups can defeat the practical promise.
Does a symmetric ratchet recover after compromise?
Not by itself. A stolen chain key can derive later keys. Recovery needs fresh secret input unknown to the attacker.
Is deleting the application record enough?
Not necessarily. Keys or plaintext may persist in backups, swap, logs, crash reports or another device. The full storage boundary matters.
For related information architecture, read envelope encryption and key rewrapping and secret sharing and threshold recovery.
Authoritative sources include Signal’s Double Ratchet specification and the IETF’s RFC 9420, Messaging Layer Security. Both distinguish past-message protection from recovery after fresh updates and state explicit limitations. Sources and links were checked on 22 October 2026.
Evidence check: for FAQ, sources and connected reading, preserve the observation before the interpretation. Record a test fixture decoded by the future system. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Contents · Previous chapter · Return to the Information guide