What Is the Double Ratchet? Forward Secrecy, Explained

A ratchet is a gear that turns one way and cannot turn back. That single mechanical idea is the reason a phone seized today cannot reveal the messages you sent yesterday. The Double Ratchet is the algorithm RVNT uses to give every message its own encryption key, derive each new key from the last, and then destroy the old key. The result is a conversation where compromise is contained: recovering one message key does not unlock the messages before it, and a one-time break-in does not hand an attacker the future. This post explains how that works without assuming you know cryptography, while staying accurate to what the algorithm actually does — and where it stops.

Two properties worth caring about

Most encryption you have heard of protects a message in transit. The Double Ratchet protects a conversation over time. It does that by guaranteeing two distinct properties, and it is worth pinning down exactly what each one means, because they defend against different attacks.

Forward secrecy

Forward secrecy means that compromising your keys now does not expose messages encrypted before. If someone recovers whatever session keys are currently live, they still cannot reconstruct the keys that protected last week’s traffic — those keys were derived, used once, and erased, and the one-way functions involved cannot be run backward.

The keys that protected yesterday’s messages no longer exist, and cannot be rebuilt from what remains.

Break-in recovery

The reverse property is subtler. Break-in recovery (also called future secrecy or post-compromise security) means that if an attacker does obtain a copy of your current key material, the conversation can heal. After the next Diffie-Hellman ratchet step — which we will get to — fresh randomness the attacker never saw is mixed in, and from that point forward they are locked out again. A one-time compromise stays a one-time compromise instead of becoming a permanent wiretap.

Together these properties bracket the moment of compromise: forward secrecy protects the past, break-in recovery reclaims the future.

Why deleting keys is the whole point

The instinct in software is to keep things. Keep the key and you can decrypt later — convenient. The Double Ratchet does the opposite on purpose. Each message key is used exactly once, to encrypt or decrypt a single message, and then it is erased. There is no archive of message keys and no master key sitting in memory that decrypts everything.

This is what turns forward secrecy from a promise into a property. You cannot leak a key you no longer hold. An attacker with the current ratchet state gets only the keys for messages still in flight, not the thousands that came before. Key deletion is not housekeeping; it is the security mechanism itself.

The two ratchets

The algorithm is called Double because two ratchets run together, each solving a different problem.

The symmetric ratchet (the fast one)

The symmetric ratchet handles a run of messages flowing in one direction. It keeps a “chain key.” To produce the key for the next message, it feeds the current chain key through a one-way key derivation function — a KDF, easy to run forward and infeasible to reverse. Out come two things: a message key for this message, and a new chain key for the next. The old chain key is discarded.

Because the KDF is one-way, knowing the new chain key tells you nothing about the old one. Even inside a single burst, capturing the chain at message 50 reveals nothing about messages 1 through 49.

chain_key_n
  --KDF--> message_key_n  (use once, delete)
  --KDF--> chain_key_n+1  (old key deleted)

This ratchet is cheap, which is why it carries the bulk of the traffic. But on its own it only moves forward — it cannot heal after a compromise, because everything still descends from one starting secret. That is the second ratchet’s job.

The DH ratchet (the healing one)

The Diffie-Hellman ratchet injects new randomness into the conversation. Each side carries a fresh ephemeral key pair. Whenever the direction of the conversation turns — you reply after a stretch of receiving — your side generates a brand-new key pair and includes the new public key in the message header. The two sides perform a Diffie-Hellman exchange, producing a shared secret neither side knew before and no attacker observed.

That new shared secret seeds new chain keys for both directions. This is the step that delivers break-in recovery: even if an attacker had captured the previous keys, this fresh secret resets the chains beyond their reach. The conversation effectively re-keys itself every time the talking turn changes hands.

How it all fits together

Plainly, a back-and-forth conversation looks like this under the hood:

• You send several messages — the symmetric ratchet advances once per message, each key deleted after use.
• Your contact replies — a DH ratchet step fires, mixing in fresh randomness and seeding new chains.
• They send several messages — their symmetric ratchet advances per message.
• You reply — another DH ratchet step, more fresh randomness.

The symmetric ratchet gives a clean key per message; the DH ratchet keeps re-seeding the system so compromise cannot persist. Out-of-order and dropped messages are handled too: the protocol can derive a skipped message key on demand and hold it briefly, so a late-arriving message still decrypts without breaking the chain.

How RVNT uses it

In RVNT, the Double Ratchet is the per-message layer that runs after two people first establish a session. That initial handshake is a hybrid X3DH key agreement: classical X25519 Diffie-Hellman combined with ML-KEM-768, a post-quantum lattice-based key encapsulation method (FIPS 203). An attacker would have to break both the elliptic curve and the lattice to recover the starting session key — the defense against “harvest now, decrypt later.” See the key exchange docs and the post-quantum write-up.

From there the Double Ratchet takes over. A few specifics worth naming:

• AES-256-GCM encrypts each message under its single-use key, providing confidentiality and authentication.
• Authenticated headers. The routing header — the ratchet public key and message counters the receiver needs — travels in plaintext, but it is bound into every message as authenticated associated data (AAD), so it cannot be forged or tampered with without breaking decryption. The header is kept off the network by the outer sealed sender envelope and Tor, not by the ratchet itself.
• It is implemented in Rust, in the rvnt-crypto core. There is no cryptography in JavaScript or TypeScript anywhere in the app, and the implementation is open source under AGPLv3 — see the Double Ratchet docs and the protocol overview, then read the code.

Sealed sender wraps the whole thing one layer further: the server that relays prekey bundles sees only a recipient id and an opaque blob, never who sent what.

What it does not protect against

The Double Ratchet is precise about its job, and it is worth being equally precise about its limits. It protects the keys of a conversation between two devices. It does nothing about a compromised endpoint — malware or a keylogger on your own phone reads your messages as you type them, keys or no keys. It does not stop the person you are talking to from screenshotting or forwarding what you said, and it does not stop someone reading over your shoulder. Note too that your own message history lives in RVNT’s local SQLCipher database: once you unlock that device, the plaintext is readable there. Forward secrecy keeps an attacker from reconstructing old session keys — it cannot protect plaintext that an unlocked device or a willing contact chooses to hand over.

That honesty is the point. The Double Ratchet is one of the strongest, most battle-tested ideas in modern cryptography, and it does exactly what it claims — no more. Don’t trust us on it; the code is public, and so is our threat model.