Forward Secrecy: Why Yesterday's Keys Can't Read Today's Chats

Imagine an attacker steals every secret key off your phone tonight. With most encryption schemes built before the 2010s, that single theft is total: every message you ever sent, going back years, springs open at once, because they were all locked with the same long-lived key. Forward secrecy is the property that breaks this assumption. It guarantees that the key sitting on your device right now is useless against the conversation you had last Tuesday. The keys that protected yesterday’s chat are already gone — zeroed out of memory, never written to disk, mathematically unrecoverable. That is the whole idea, and it is one of the quietest but most important shifts in how modern messengers protect you.

The catch is that “forward secrecy” is a name that confuses almost everyone, because it actually describes protection that runs backward in time. And it is only half the story. Its lesser-known twin — post-compromise security — covers the other direction, protecting the messages you haven’t sent yet. RVNT, like the Signal Protocol it builds on, gets both from the same engine: the Double Ratchet. Here is how that works, and just as importantly, what it does not save you from.

Two questions, two directions in time

When someone breaks into your device and grabs your keys, there are two separate questions to ask. They sound similar but have completely different answers.

Question one: Can they read the messages I sent before the break-in? Question two: Can they read the messages I send after the break-in?

Forward secrecy answers the first. The EFF’s Surveillance Self-Defense glossary puts it plainly: it is “a property of a secure messaging system which ensures that your past communications can remain secure even if one of the secret keys is stolen later.” Past communications. The protection points into the past — which is exactly why the “forward” label trips people up. The keys move forward; the secrecy they leave behind protects the past.

Post-compromise security (sometimes called break-in recovery or future secrecy) answers the second. It is the harder, more surprising guarantee: even after an attacker has fully compromised your session, the conversation can heal, and messages sent later become unreadable to them again. The concept was formalized by Cohn-Gordon, Cremers, and Garratt and is now a named requirement in standards like the Messaging Layer Security RFC (RFC 9420), which lists “forward secrecy (FS) and post-compromise security (PCS)” as core properties.

Keep these two directions straight and everything else about the ratchet falls into place.

Why old-school encryption fails the first question

To see why forward secrecy matters, look at the system that lacks it. Classic PGP email encrypts every message to your long-term private key. That key might live on your laptop for a decade. The design is simple and, for its era, reasonable — but it means one key guards every message ever sent to you.

Now suppose that key leaks: a stolen laptop, a subpoenaed backup, a malware infection, or an adversary who quietly archived your ciphertext years ago and waited. Every PGP-encrypted email you ever received becomes readable in a single stroke. There is no granularity. A single key compromise is a total compromise, stretching across your entire history.

This is not a hypothetical for anyone who handles sensitive correspondence. It is the threat model behind harvest-now-decrypt-later attacks, where the adversary collects encrypted traffic today and banks on cracking the key later. Without forward secrecy, “later” cracks everything at once. With it, cracking one key buys the attacker exactly one message.

How the symmetric ratchet kills past keys

RVNT’s answer is to never reuse a key. Every single message is encrypted with its own unique, single-use message key, and the machinery that produces those keys is built so that knowing the present tells you nothing about the past.

This is the symmetric ratchet — a one-way chain of keys. Each step takes the current chain key and runs it through HMAC-SHA256 to derive two things: the message key for this message, and the next chain key. Then the old chain key is destroyed. The Signal spec describes the resulting property precisely: “Output keys from the past appear random to an adversary who learns the KDF key at some point in time.”

The reason this works comes down to one-wayness. HMAC-SHA256 is a pseudorandom function: you can run it forward trivially, but you cannot run it backward. Given chain key number 50, deriving chain key number 49 would require inverting SHA-256, which is preimage-resistant. So:

chain_key[48] → chain_key[49] → chain_key[50]   (forward: trivial)
chain_key[50] → chain_key[49]                    (backward: infeasible)

Each message key is HMAC’d off its chain key once, used to encrypt with AES-256-GCM, and then securely zeroed. RVNT uses Rust’s zeroize crate with volatile writes and a compiler barrier so the deletion can’t be optimized away, and on supported platforms the key pages are mlock’d so they never hit swap. The window of exposure for any single message key is one message — it exists only for the microseconds of one encrypt or decrypt, then it is gone from RAM, disk, and everywhere else. That is forward secrecy at per-message granularity, and our forward secrecy docs walk through the deletion path in detail.

How the DH ratchet heals the future

The symmetric ratchet alone has a gap. If an attacker steals your current chain key, they can compute every future chain key in that same chain — because the chain only moves forward, and forward is exactly where they’re standing. They can’t read your past, but they can ride your future. That’s where the second ratchet earns its name.

The Diffie-Hellman ratchet periodically injects brand-new entropy that the attacker cannot have. Every time the conversation changes direction — you reply, they reply — each side generates a fresh X25519 keypair and performs a new Diffie-Hellman exchange. The output feeds an HKDF that produces a fresh root key and a fresh chain key, and the old root key and old DH private key are deleted.

The Signal spec calls this break-in recovery, defined 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.” The mechanism is elegant — the compromised private key “will eventually be replaced with an uncompromised one. At that point, the Diffie-Hellman calculation between ratchet key pairs will define a DH output unknown to the attacker.”

Walk through it concretely:

Attacker compromises your device, learns:
  root_key, send_chain_key, recv_chain_key, current DH keypair

A reply triggers a DH ratchet step:
  new_dh_private = X25519.generate()        ← attacker never sees this
  dh_output      = DH(new_dh_private, peer_public)
  new_root, new_chain = HKDF(root_key, dh_output)

Attacker cannot compute new_dh_private (random, never transmitted),
so cannot compute dh_output, so cannot compute the new keys.
→ The session heals. Future messages are dark to them again.

The price of admission is that the attacker is locked out only after the next round-trip. Between the compromise and that next DH step, they can read messages in the chains they captured. PCS is recovery, not prevention — but for a long-running conversation, automatic recovery is a remarkable property to get for free. The full mechanics, including the KDF chains and out-of-order handling, live in our Double Ratchet explainer.

What it protects, side by side

Property	Protects	Mechanism	When it kicks in
Forward secrecy	Messages before the compromise	Symmetric ratchet + key deletion	Immediately, per message
Post-compromise security	Messages after the compromise	DH ratchet (fresh entropy)	After the next round-trip

RVNT adds one more wrinkle on top of the standard design: the DH ratchet step is hybrid post-quantum. Alongside the classical X25519 exchange, the initial X3DH handshake mixes in ML-KEM-768, so the shared secret resists a future quantum adversary running the harvest-now-decrypt-later playbook against your captured traffic. The ratchet that gives you forward secrecy is the same ratchet carrying that post-quantum protection forward.

The honest limits

Forward secrecy is a property of keys and transport. It is not a force field around your conversation, and pretending otherwise does you a disservice. RVNT is also pre-release and has not been independently audited — treat every claim here as a description of the design, not a certified guarantee.

Here is what neither forward secrecy nor PCS will save you from:

• Live malware on your device. If something is reading your screen as you type, it sees the plaintext before encryption ever happens. Forward secrecy protects keys at rest and in transit, not a compromised endpoint in real time.
• The recipient. The person you message can screenshot, copy, forward, or simply remember what you said. Ratchets protect delivery, not what the other end chooses to keep.
• Metadata. Forward secrecy hides message content. It does nothing about who you talked to and when. That requires separate layers — sealed sender, Tor, and the mixnet — which is why we treat metadata as the message it so often is. Notably, RVNT’s ratchet headers travel in plaintext (authenticated as AEAD associated data, but not encrypted); concealing them is the metadata layer’s job, not the ratchet’s.
• Backups. If you export your database and that backup leaks, the attacker has the database key and everything stored under it. This is precisely why RVNT keeps no cloud backups and stores everything in a local SQLCipher database.

There is one upside to all that key deletion worth stating plainly: forward secrecy isn’t a setting. There’s no toggle, no “enable advanced security” checkbox. It is an emergent property of how the Double Ratchet manages keys — every message you send through RVNT benefits automatically, and it cannot be switched off. The keys that protected yesterday’s chat are already gone. That is the point.