Hybrid does not mean switch to the stronger algorithm. It means every message key is derived from both, so breaking the system requires breaking P-256 and ML-KEM-768 at the same time.
Livara puts ML-KEM-768 directly alongside ECDH P-256 in every message because each algorithm covers a failure mode the other cannot. The classical P-256 ECDH ratchet rotates keys forward every session, giving forward secrecy, while the ML-KEM-768 epoch ratchet is the separate lock that stays intact even if an attacker captures your long-term identity key and hoards encrypted traffic for future decryption. Together they form the hybrid post-quantum messaging stack described in Livara's engineering documentation.
Key takeaways
- ML-KEM-768 is a lattice-based Key Encapsulation Mechanism standardised by NIST in FIPS 203, and NIST's own briefing notes it is selected to defend against future quantum decryption.
- ECDH P-256 runs as the per-message chain advance in LVR1, while ML-KEM-768 refreshes a separate epoch layer; the two ratchets are independent, so neither compensates for the other's weaknesses.
- Livara derives every message key from both algorithms at once, which is what keeps forward secrecy and post-compromise security alive under a single threat model.
- Channel broadcasts remain deliberately public and unencrypted, so this hybrid protection covers direct and private group messages only.
- You can verify the released Livara APK yourself using the published SHA-256 checksums in Livara's Proof Lab.
What is ML-KEM-768 and why does a secure messenger need it
ML-KEM-768 is a Key Encapsulation Mechanism, the cryptographic primitive that safely delivers a shared secret without either side sending a password. It is built on structured lattices rather than the elliptic-curve discrete-logarithm problem that ECDH relies on. That mathematical difference is the whole point: a sufficiently large quantum computer could solve discrete-logarithm problems with Shor's algorithm, but lattice problems resist current quantum techniques. NIST standardised ML-KEM-768 in FIPS 203 specifically because it provides that quantum-resistant property at an acceptable key and ciphertext size.
A messenger needs it because of harvest-now, decrypt-later. An adversary can record your encrypted messages today, keep the ciphertext forever, and wait for a quantum-capable attacker to break classical key exchange in the future. If the only thing protecting your old messages were P-256, that future attacker could read everything you ever sent. ML-KEM-768 adds a lock that the same attacker cannot open with a quantum computer, even after your classical private key leaks.
How the classical ECDH P-256 ratchet still earns its place
ECDH P-256 is not the weak link Livara is defending against; it is the engine for forward secrecy. The Double Ratchet algorithm advances the message key chain every time a message is sent, so compromising one message key does not compromise earlier messages. Livara implements that chain using ECDH P-256 key agreement, as documented in the LVR1 specification. As long as the chain keeps advancing, past session keys are computationally inaccessible even if an attacker later captures a device or session state.
That is why ML-KEM-768 does not replace P-256. The two solve different problems: P-256 protects past messages when a session key leaks, while ML-KEM-768 protects past messages when the long-term identity key leaks or when quantum decryption becomes feasible. Removing P-256 would throw away proven per-message forward secrecy; keeping it alone would leave every archived message exposed to a future quantum adversary.
What hybrid means in the LVR1 double ratchet
Hybrid does not mean "switch to the stronger algorithm". In Livara's LVR1 protocol, hybrid means both algorithms run side by side on every key derivation. There is a P-256 ratchet for per-message rotation and a separate ML-KEM-768 epoch ratchet that refreshes on a schedule, not per message. Every message key is derived from both ratchets, so the derived key is only usable if both the classical and the post-quantum secrets are intact. This design is described in Livara's field note on hybrid post-quantum ratchets, which explains how classical and post-quantum secrets combine and why epoch size affects overhead.
The benefit is defense in depth: breaking the hybrid key requires breaking both P-256 and ML-KEM-768 simultaneously. If quantum computing breaks P-256, the lattice layer still protects you. If a future lattice attack were found, P-256 would continue to protect you. The weakness of a hybrid scheme is that it does not gain speed or smaller keys from the stronger algorithm — you pay the full cost of both. Livara accepts that overhead as the price of covering two independent threat classes.
Why LVR1 ML-KEM-768 alongside P-256 beats either algorithm alone
Using P-256 alone leaves your archive exposed to quantum decryption. Using ML-KEM-768 alone gives you quantum resistance but no proven per-message forward secrecy, because a KEM by itself does not rotate message keys. Livara's design makes each message key depend on both, so the system inherits the best property of each. Livara's own security page documents this boundary explicitly, stating that direct messages use the hybrid post-quantum double ratchet and that every message key is derived from both the P-256 ECDH ratchet and the ML-KEM-768 epoch ratchet.
This is why the industry is moving toward the same pattern outside messaging. Hybrid TLS deployments pair X25519 with ML-KEM-768 so that a TLS connection keeps working even if one of the two algorithms is broken. PostQuantumSecurity's technical briefing explains how that hybrid model became a real deployment standard, and a separate practitioner guide maps the X25519MLKEM768 ecosystem status and common failure modes.
| What it protects | ECDH P-256 ratchet | ML-KEM-768 epoch ratchet | Both together |
|---|---|---|---|
| Forward secrecy when a message key leaks | Yes | Not applicable | Yes |
| Protection if long-term identity key leaks | No, not after chain compromise | Yes, across epochs | Yes |
| Resistance to future quantum decryption | No | Yes | Yes |
| Performance cost | Low | Moderate | Both paid |
Which security and performance claims actually need evidence
Hybrid post-quantum ratchets make strong claims, and the claims that matter are the ones backed by checkable engineering evidence. Livara publishes machine-checkable test vectors, open protocol specifications, release checksums, and in-browser offline verification in the Proof Lab, so the LVR1 key derivation is not a black box. That does not establish independent security assurance — published test vectors and checksums are engineering evidence, not a third-party audit — and Livara's comparison page is explicit about where it comes off worse than competitors on each named criterion.
There are honest limits worth stating. The ML-KEM-768 epoch ratchet depends on an epoch refresh schedule rather than per-message changes, so the exact interval determines how many messages are exposed if a single epoch secret leaks. Metadata — who you messaged, the destination, and delivery timestamps — is still stored server-side for real-time device synchronization and remains outside this encryption. You should also verify key changes out of band using safety numbers, which let two people compare key fingerprints to detect tampering, and check the published release checksums with the Proof Lab rather than trusting a downloaded APK blindly.
Sources
- NIST's FIPS 203 specification, the standard that selected and describes ML-KEM-768.
- PostQuantumSecurity.org, which traces the industry move from X25519-only key exchange to hybrid X25519+ML-KEM-768 TLS.
- nhimg.org hybrid TLS guide, covering X25519MLKEM768 ecosystem status, deployment decisions, and common failure patterns.
- Livara's field note on hybrid post-quantum ratchets, explaining how classical and post-quantum secrets combine and how epochs affect overhead.
Frequently asked questions
Does ML-KEM-768 make Livara messages unhackable?
No. Livara does not claim messages are unhackable or that it has been independently audited. The hybrid ratchet protects against key compromise and quantum decryption within its documented threat model, but it does not protect your device if it is seized, your passwords if you reuse them, or metadata the server must route.
Will switching to post-quantum messaging slow Livara down?
The hybrid design pays the cost of both algorithms on every key derivation, so there is more computation and larger keys than classical-only messaging. Livara publishes the protocol and test vectors so you can inspect the actual overhead, and the Proof Lab lets you verify released APKs offline without trusting the store.
Can someone decrypt my old messages with a quantum computer?
Not if they only have the classical key. ML-KEM-768 uses lattice mathematics that resists Shor's algorithm, so a quantum adversary cannot derive past epoch secrets from your long-term P-256 private key alone. The hybrid key still requires both secrets, which is what blocks the harvest-now, decrypt-later attack.
Do Livara channels use the same encryption?
No. Channels are public broadcast streams by design, not private conversations. Livara deliberately keeps channel content readable so it can act on reports, remove content, and ban channels used for abusive material. End-to-end encryption covers direct messages and private groups only.
How do I verify this encryption is real?
Livara publishes machine-checkable test vectors, open protocol specifications, and release checksums. You can compare key fingerprints with the person you are messaging using safety numbers, and you can verify the released APK against the published SHA-256 checksums offline in the Proof Lab before installing it.
