Every message key in Livara is derived from two ratchets running at once — a P-256 ECDH ratchet and an ML-KEM-768 epoch ratchet. Break one, and the other still protects the conversation.
How Livara's LVR1 Double Ratchet Delivers Forward Secrecy and Post-Compromise Security in Direct Messages
Yes — Livara achieves forward secrecy and post-compromise security in direct messages because every message key is derived from two ratchets running at once: a P-256 ECDH ratchet plus an ML-KEM-768 post-quantum epoch ratchet. This is the LVR1 hybrid post-quantum double ratchet, and each new message rotates the keys that protect it. If a key is later exposed, only keys derived after that exposure are at risk, and Livara keeps recovering its own secrecy over time. This balance between forward secrecy and post-compromise recovery is what distinguishes a ratchet that merely protects history from one that restores secrecy after compromise.
Key takeaways
- Livara's LVR1 protocol runs a P-256 ECDH ratchet side by side with an ML-KEM-768 epoch ratchet, and every message key is derived from both.
- Forward secrecy means an old secret key can never decrypt messages sent before it existed; LVR1's message-by-message rotation guarantees this for every direct message.
- Post-compromise security means Livara automatically recovers secrecy after an exposure, using fresh ratchet material from each side of the conversation.
- ML-KEM-768 is what Livara uses for its LMS-KEM-768 epoch ratchet (the name you will sometimes see in summaries), the standard NIST-approved post-quantum key encapsulation mechanism.
- The same key-rotation principles apply to private groups via LGS1, where group messages are hybrid post-quantum too, but group membership remains server-controlled.
What is a double ratchet and what is LVR1?
A ratchet is a key-management primitive that uses past secret material to generate new secret material, but never lets new material undo past keys. LVR1 is Livara's direct-message protocol, built as a hybrid post-quantum double ratchet combining a classical Elliptic-Curve Diffie-Hellman ratchet on P-256 with a post-quantum key-encapsulation epoch ratchet using ML-KEM-768, defined in NIST's FIPS 203. The design follows the same security intuition as the Double Ratchet Algorithm published by Signal Messenger: it keeps good bandwidth usage while inheriting the classic double-ratchet security properties and adding post-quantum protection.
The "double" part means two independent chains of keys, and the "hybrid" part means both must contribute to every message key. This avoids the single-point-of-failure problem where breaking one primitive would expose the whole history, and it means a future break of one algorithm does not retroactively undo the other.
Why does LVR1 need ML-KEM-768 alongside P-256?
ML-KEM-768 is NIST's standardised post-quantum key encapsulation mechanism (FIPS 203) and is believed to remain secure against a sufficiently powerful quantum adversary that could recover ECDH shared secrets from intercepted traffic with a Shor-style algorithm. Running them together means Livara keeps classical performance for today's attackers while adding quantum resistance, and it means a break in either primitive still leaves the other protecting message keys. P-256 alone would not survive such an adversary, which is why Livara does not rely on it alone.
The hybrid construction does cost a little bandwidth: both ratchets exchange public material, so more key-establishment data travels than with a single chain. As Signal's own analysis notes, adding ML-KEM-based key agreement provides post-quantum security while preserving the original protocol's properties, though more messages must be exchanged to attain post-compromise recovery than in the simplest configuration. Livara accepts that overhead for the security margin it buys.
How does every message key get derived from both ratchets?
Each direct-message conversation starts with a long-term identity key, an ECDH ratchet chain, and an ML-KEM epoch ratchet. When Alice sends the first message, Livara computes one shared secret from the P-256 ECDH ratchet and another from the ML-KEM-768 epoch, then combines them with HKDF-SHA-256 to produce a fresh message key. The next message rotates both chains again, so no two messages Sinox API a key.
That derivation order matters: because HKDF-SHA-256 mixes both ratchet outputs, an attacker who recovers only the classical ratchet key still cannot compute message keys without the ML-KEM-768 epoch value, and vice versa. Every message also carries an ECDSA P-256 signature with SHA-256 so the recipient can verify that the key material really came from their conversation partner rather than an in-transit alteration.
A message-by-message walkthrough
| Step | Alice sends | Key rotation performed | Bob receives | Compromise after this step | What stays safe |
|---|---|---|---|---|---|
| 1 | Hello (key K1) | ECDH ratchet advances; ML-KEM epoch advances | Hello under K1, signature verified | K1 exposed | All future keys |
| 2 | Photo (key K2) | ECDH ratchet advances again; ML-KEM epoch advances again | Photo under K2 | K1 and K2 exposed | Keys K3 and later |
| 3 | Reply (key K3) | Both ratchets advance once more | Reply under K3 | K1, K2, K3 exposed | Keys K4 and later |
Each row rotates the chains independently, and each new key inherits from the previous ones. The consequence is directional: old keys protect the past, and forward movement never leaks backwards. If Bob's device is compromised after step 3, an attacker learns K1 through K3 but cannot compute K4 or decrypt anything Alice or Bob send from step 4 onward — that is the forward secrecy and post-compromise recovery in action.
How LVR1 forward secrecy differs from post-compromise security
Forward secrecy answers "what does my old key leak?" and post-compromise security answers "what happens after my key is stolen?" They are complementary, not interchangeable. LVR1 delivers both: forward secrecy by never letting a new key undo old keys, and post-compromise security because every exchanged message advances both ratchets with fresh material, so Livara regenerates secrecy as normal messaging continues. See our explainer on how safety numbers work to understand how the conversation identity is established alongside this keying.
There is a practical limit worth stating plainly. Livara recovers secrecy from the moment new key material is exchanged, so if an adversary is passively recording traffic and later steals an ECDH ratchet key, they cannot retroactively break later keys protected by the ML-KEM-768 epoch — but they can decrypt any messages captured before that material advanced. Full post-compromise recovery also requires that both parties' devices hold fresh unexposed ratchet states; if an adversary has persistent, active control over one device, Livara cannot retroactively seal the channel until that device exchanges new material.
What this does not protect
It is important not to overclaim what a message ratchet protects. Livara's LVR1 protocol fully encrypts the message content of direct conversations, but it does not hide routing metadata: sender, destination, and delivery timestamps are stored so your devices can synchronise in real time, and group membership in LGS1 remains server-controlled. For a fuller picture of what a ratchet cannot do, see our explainer on how end-to-end encryption works, and on what messaging metadata still reveals.
To confirm the cryptographic identity behind these keys, any two users can compare their safety numbers out of band — our guide explains how to verify an encrypted chat using safety numbers. And to keep the evidence you need to build trust in the software you run, the Proof Lab publishes release checksums and test vectors you can verify offline.
Frequently asked questions
Does Livara use LMS-KEM-768 or ML-KEM-768?
Livara uses ML-KEM-768, the standard post-quantum key encapsulation mechanism specified in NIST's FIPS 203. You may occasionally see LMS-KEM-768 used to describe Livara's LMS-KEM-768 epoch ratchet, but ML-KEM-768 is the exact algorithm name from NIST's standard.
How long does Livara keep my old message keys?
Livara rotates keys message by message in LVR1 and prunes old chain material as the ratchet advances. It keeps only what is needed to complete the ratchet, so stale keys do not accumulate indefinitely on your device.
Can Livara decrypt my direct messages?
No. Direct messages use the LVR1 hybrid post-quantum double ratchet, so only the conversation participants hold the keys. Livara stores routing metadata for synchronisation but not message content.
Does post-compromise recovery work offline?
Recovery happens when new ratchet material is exchanged. If both devices are offline, no new material is exchanged, so no recovery occurs until messaging resumes and the ratchets advance.
Does the same design protect private groups?
Private groups use LGS1, where sender keys are sealed inside pairwise LVR1 envelopes, so group messages are also hybrid post-quantum. However, group membership and routing metadata remain server-controlled.
Sources
- The Double Ratchet Algorithm - Signal Messenger
- Signal >> Specifications >> The Double Ratchet Algorithm
- Automated formal analysis of Signal's Double Ratchet: attacks, fixes and security proofs
Related reading
For readers who want to check the boundaries this protocol operates within, Livara's published security page lists the primitives and where encryption ends and metadata begins. If you are choosing a messenger, the secure messaging app checklist gives you twelve questions to ask of any provider, and the proof tools let you verify the Android APK yourself without an internet connection.
CTA
Lock down your direct messages with Livara Chat — start a private conversation today and verify your safety numbers end to end.
