A genuine hybrid post-quantum key exchange produces one shared secret by combining two mathematically independent key agreements: a classical ECDH P-256 exchange and a lattice-based ML-KEM-768 encapsulation. An attacker must break both to recover the key, which is why neither algorithm's weaknesses alone compromise the conversation. In Livara's LVR1 protocol for direct messages, that same idea runs continuously: a P-256 ratchet and an ML-KEM-768 ratchet advance side by side, and every message key is derived from both at once.
Key takeaways
- A hybrid post-quantum key exchange means the final shared secret is a cryptographic function of two independent secrets — one classical (ECDH P-256) and one lattice-based (ML-KEM-768) — never of either alone.
- ML-KEM is the standardized key-encapsulation mechanism published as NIST's FIPS 203; its security rests on the Module Learning With Errors problem, which is currently believed to resist quantum computers.
- ECDH P-256 contributes long-studied, well-understood classical security; ML-KEM-768 contributes protection against a future quantum adversary. The hybrid covers for both failure modes.
- In Livara's LVR1, a P-256 ECDH ratchet and an ML-KEM-768 epoch ratchet run side by side, and each message key is derived from both ratchets via HKDF-SHA-256 — giving forward secrecy and post-compromise security.
- A hybrid does not make anything "unbreakable." Group membership and routing metadata stay server-controlled, and call media uses WebRTC DTLS-SRTP rather than the message ratchet.
What is a hybrid post-quantum key exchange, and why combine two algorithms?
A hybrid post-quantum key exchange is a method where two parties establish a shared secret using two independent key agreements at the same time, then combine their outputs into a single working key. The point is insurance: if either algorithm turns out to be broken — the classical one by a quantum computer, the new lattice-based one by an unexpected mathematical attack — the combined secret should remain protected by the other half.
The frame list of the combined secret matters as much as the ingredients. Simply concatenating secrets and feeding them into a key derivation function (KDF) is the standard, conservative construction, and it is what a well-designed KDF such as HKDF-SHA-256 is built for: it mixes both inputs so that an attacker who knows one input still cannot predict the output. The trade-off is honest but real — hybrid schemes need larger handshakes and more computation, because ML-KEM keys and ciphertexts are much bigger than elliptic-curve ones.
| Property | ECDH P-256 (classical) | ML-KEM-768 (post-quantum) | Combined (hybrid) |
|---|---|---|---|
| Underlying problem | Elliptic-curve discrete logarithm | Module Learning With Errors | Both, independently |
| Security against quantum attacker | No | Believed yes | Believed yes (via ML-KEM half) |
| Security if lattice attack found | Yes (via ECDH half) | No | Yes (via ECDH half) |
| Maturity of study | Decades | Newer (standardized 2024) | Inherits the weaker maturity; conservatism is the point |
| Shared-secret size | 32 bytes | Larger derived secret | From both, via KDF |
The honest limitation runs in both directions: the classical half guards against lattice attacks, the lattice half guards against Shor's algorithm, and the combination never claims more than the better-verified of its two parts. That is precisely why the pairing exists.
What is ML-KEM-768, and how does a KEM actually work?
ML-KEM-768 is the middle of three parameter sets of the Module-Lattice-Based Key-Encapsulation Mechanism standardized by NIST in FIPS 203, whose security is tied to the computational difficulty of the Module Learning With Errors problem. A key-encapsulation mechanism (KEM) is a set of algorithms that lets two parties establish a shared secret key over a public channel, as NIST's own standard page defines it — and that secret is then used with symmetric algorithms like AES to encrypt and authenticate communications.
A KEM works in three moves instead of the two moves of a Diffie–Hellman exchange:
- KeyGen — the receiver generates a key pair: a public encapsulation key and a private decapsulation key.
- Encapsulate — the sender takes the receiver's public key, produces a shared secret and a ciphertext together, and sends the ciphertext over the public channel.
- Decapsulate — the receiver runs their private key on that ciphertext and recovers the same shared secret.
"ML-KEM-768 explained" in one sentence: it is a lattice math version of that three-step exchange, parameterized so that both the shared secret and the ciphertext are sized for NIST security level 3. At present, NIST states that ML-KEM is believed to be secure even against adversaries who possess a quantum computer — a belief, not a proof, which is exactly why hybrids still pair it with ECDH.
How is ECDH P-256 combined with ML-KEM-768 into one key?
ECDH P-256 combined with ML-KEM-768 works by running both exchanges independently and feeding both resulting secrets into a single KDF, so the output key depends on both inputs. Elliptic-curve Diffie–Hellman (ECDH) is the classical method where two parties each hold a private number and exchange public curve points; each side mathematically derives the same shared point, and a fixed byte of that point becomes the classical shared secret.
The derivation pipeline looks like this in LVR1:
- Classical lane: perform ECDH on the P-256 curve → obtain the 32-byte ECDH agreed secret.
- PQ lane: run ML-KEM-768 encapsulation → the sender holds the ML-KEM shared secret plus ciphertext; the receiver decapsulates with the private key → both hold the ML-KEM shared secret.
- Combine: feed both secrets, plus a transcript of the public handshake material, into HKDF-SHA-256 as extract-and-expand input salt and keying material.
- Output: HKDF-SHA-256 emits the session key material; AES-256-GCM (12-byte nonce, 16-byte tag) consumes the resulting key to seal traffic.
The two lanes are mathematically unrelated — one lives on elliptic curves, the other on module lattices — so "one key from two worlds" is literal: HKDF would need an attacker to know both lane secrets to reconstruct anything. And if one lane is ever attested compromised, the transcript binding keeps the combination from silently downgrading, because each handshake's public material is mixed into the KDF input.
Why does a post-quantum encryption double ratchet run two ratchets side by side?
A post-quantum encryption double ratchet keeps rotating keys so that every message uses a fresh key, and pairing the classical and quantum ratchets means each new key is a function of both. "Forward secrecy" means a key from the past protects an attacker who later steals the current state; "post-compromise security" means that after a state compromise, honest key updates gradually heal the conversation. The ratchet machinery is what turns those properties from a one-time handshake into a per-message guarantee — see our post-quantum encryption overview for the broader picture.
In LVR1, the two ratchets have distinct jobs and run in parallel:
- P-256 ECDH ratchet: regularly performs fresh elliptic-curve DH agreements, so a classical adversary who records traffic gains nothing new without breaking ECDH.
- ML-KEM-768 epoch ratchet: regularly runs fresh lattice encapsulations, so a future quantum adversary who records traffic cannot decapsulate any epoch's secret.
- Per-message derivation: every message key is derived from both ratchets' current output through HKDF-SHA-256, so a message key is never a pure product of either world alone.
The consequence is that a message key inherits forward secrecy from both ratchets advancing and post-compromise security from both ratchets refreshing. The counterpart limit: if key state is compromised at a given moment, the current epoch's protection can be affected — the property heals going forward, it does not erase privileges an attacker already exercised.
How are the actual message encryption keys derived for each message?
Message encryption keys are derived by feeding the current ECDH ratchet output, the current ML-KEM-768 epoch output, and a per-message chain counter into HKDF-SHA-256, which outputs a fresh symmetric key for AES-256-GCM. Concretely, Livara Chat derives message keys like this in LVR1:
ECDH output (P-256 ratchet) ─┐
├─► HKDF-SHA-256 ─► message key ─► AES-256-GCM seal
ML-KEM output (epoch ratchet)─┘ ▲
ratchet counter / transcript context
AES-256-GCM — an authenticated encryption mode with a 12-byte nonce and a 16-byte tag — then encrypts the message so tampering is detected, not just eavesdropping. Private groups use LGS1, where each member's sender key is sealed inside pairwise LVR1 envelopes, so group text, edits, photos, videos, files, captions, and voice notes all inherit the same hybrid construction. Call media is the stated exception: voice and video use WebRTC DTLS-SRTP, not the message ratchet, and we do not describe call media as post-quantum. To check a conversation's keys out of band, safety numbers let two people compare key fingerprints; the full boundaries are on our security page, and the APK itself is verifiable offline in the Proof Lab.
What are the limits of a hybrid key exchange?
A hybrid key exchange protects the key agreement on each message — it does not protect what never enters the encryption pipeline, and it does not certify the implementation. You should also keep straight what metadata still reveals even under end-to-end encryption: routing metadata such as sender, destination, and delivery timestamps is stored for real-time device synchronization, and group membership and routing metadata remain server-controlled. Channels in Livara are public broadcast streams by design — one author publishing to an unbounded audience — not private conversations, so their content is deliberately readable rather than end-to-end encrypted. And no published checksum or test vector equals an independent audit; what Livara publishes — open protocol specifications, machine-checkable test vectors, release checksums — is evidence you can verify yourself, not outside assurance.
Frequently asked questions
What does "hybrid" actually mean in hybrid post-quantum key exchange?
It means the final shared secret comes from two independent key agreements, not one. A classical ECDH P-256 exchange and an ML-KEM-768 encapsulation each produce a secret, both are mixed via HKDF-SHA-256, and the resulting key depends on both. Breaking either one alone reveals nothing about the combined key.
Why not use ML-KEM-768 alone and drop ECDH P-256?
Lattice cryptography is newer and has less accumulated scrutiny than elliptic curves, so dropping ECDH would put all trust in one younger structure. Keeping both halves means an unforeseen lattice attack still leaves the ECDH secret protecting the key. The cost is larger handshakes and extra computation per exchange.
Is Livara's group encryption different from its direct-message encryption?
Yes, but it inherits the same hybrid core. Direct messages use LVR1, a hybrid post-quantum double ratchet. Private groups use LGS1 sender-key encryption where every sender key is sealed inside pairwise LVR1 envelopes, so group messages are hybrid post-quantum too. Call media, by contrast, uses WebRTC DTLS-SRTP, not the ratchet.
Does a hybrid key exchange protect me from profiling and metadata collection?
No. The hybrid protects message content confidentiality and authenticity once keys are derived. Routing metadata — sender, destination, delivery timestamps — is stored for real-time device synchronization, and group membership is server-controlled. Device compromise at a given moment also matters more than future quantum risk; that is why safety-number verification exists.
Why does every message key come from both ratchets instead of alternating?
Deriving each key from both means a single broken algorithm never produces a usable key, and each ratchet's rotation contributes independently to forward secrecy. Alternating would let a compromised classical key seal some messages or a broken lattice epoch seal others. Combining both keeps the guarantee uniform across every message.
