A per-message chain advance and a post-quantum epoch refresh solve different parts of the ratchet problem.
A hybrid post-quantum ratchet updates messaging keys using both classical and post-quantum material. The aim is to retain protection under carefully defined assumptions if one component becomes vulnerable, while limiting the damage of particular key compromises over time.
Livara documents this approach for LVR1 using P-256 and ML-KEM-768. Understanding the design requires separating initial key establishment, ordinary message-chain updates and periodic post-quantum refreshes. They are not the same operation performed on every message.
From a shared secret to changing message keys
A key-establishment mechanism gives participants secret material they can use in a key schedule. A ratcheting protocol then evolves state and derives message keys, rather than keeping one unchanged content key for the entire conversation.
NIST FIPS 203 specifies ML-KEM, including the ML-KEM-768 parameter set. It establishes a shared secret; an authenticated cipher such as AES-GCM encrypts the message payload. Authentication and the way components are combined belong to the wider protocol.
Livara's security overview describes hybrid establishment, independent classical and post-quantum roots, one-way send/receive chains advancing with messages, and periodic ML-KEM epoch updates. It says a message key is combined with the current post-quantum root before content and header protection.
That account should not be rewritten as “a fresh P-256 exchange and fresh ML-KEM encapsulation happen for every message.” A chain advance can be a comparatively inexpensive key-derivation step.
What an epoch changes
An epoch is a period of protocol state associated with a particular refresh. Scheduling larger key-establishment messages across epochs can reduce repeated communication overhead, but it also makes the refresh rules security-relevant.
A reviewer should ask:
- What triggers a new epoch: a counter, time, peer action or another condition?
- How are epoch identifiers and key material authenticated?
- What happens to delayed, duplicated or out-of-order messages?
- How does a client handle a missing update or an older incompatible peer?
- Which old secrets remain for delayed delivery, and when are they discarded?
An implementation needs precise answers. The word “periodic” alone is not a complete recovery or interoperability specification.
Quantifying primitive sizes without inventing a benchmark
FIPS 203 gives ML-KEM-768 an encapsulation-key size of 1,184 bytes and a ciphertext size of 1,088 bytes. These are primitive encodings, not the total size of a Livara message or handshake. Protocol headers, signatures, framing and how often each value is sent determine actual traffic.
P-256 key sizes also depend on representation. For example, a compressed curve point and an uncompressed point have different encoded lengths. Comparing an unlabelled “P-256 key size” with an ML-KEM ciphertext is not a complete bandwidth analysis.
To evaluate the cost of a ratchet, measure bytes per conversation and epoch, CPU time, memory, radio wake-ups and end-to-end latency on representative devices. Report build and network conditions. Without those measurements, neither “negligible battery impact” nor a universal sub-millisecond execution time is justified.
Forward secrecy and recovery after compromise
Forward secrecy aims to protect earlier messages after specified later secrets are exposed, provided the required old secrets were erased. Post-compromise security concerns regaining protection after an attacker no longer controls the endpoint and fresh secret material unknown to the attacker enters the protocol.
The Double Ratchet specification explains these distinctions and the limits of break-in recovery. Continued malware access, manipulated randomness or an active attacker controlling the relevant exchanges can defeat the hoped-for recovery. Sending one more message does not prove that a stolen session is revoked or a compromised phone is clean.
A hybrid construction also needs sound authentication and combination. “The attacker must break both algorithms” is an intended property under the construction's assumptions, not an unconditional statement covering implementation bugs or malicious endpoints.
Keep the feature boundaries visible
In Livara's documentation, LGS1 group sender keys are distributed through pairwise LVR1 sessions. That does not mean a group sender chain is structurally identical to a direct-chat double ratchet. The current security page also excludes older incompatible groups from E2EE and requires members to be ready before creating a new encrypted group.
Attachments have their own content keys carried inside the protected conversation. Calls and optional server recording require separate review; do not infer post-quantum media protection simply because a signalling path uses a hybrid session. Public channels and operational metadata are outside private-content confidentiality.
What would strengthen confidence?
Look for a versioned specification, interoperability and failure-case tests, independent review and a clear relationship between reviewed source and the shipped client. Standard algorithms are useful evidence about components, not certification of their composition.
Livara's Proof Lab demonstrates selected classical primitives and explicitly excludes the full LVR1/LGS1 composition from that local bench. Its threat model remains necessary context. Together these materials help frame questions; they should not be presented as a substitute for a complete protocol and implementation assessment.
Where the hybrid key combiner fits
A hybrid protocol brings two independently generated shared secrets into a key-derivation step. In the published LVR1 design, the contributions come from classical P-256 and ML-KEM-768 paths. Binding both contributions to the conversation context is essential: simply advertising two algorithms does not show how their outputs are combined, authenticated, or refreshed after a key change.
This is a design goal, not a guarantee that one algorithm can fail with no consequence in every implementation. Device identity, downgrade behavior, entropy, key storage and the exact released code still matter. FIPS 203 defines ML-KEM; it does not evaluate Livara's ratchet. The Livara Chat security page names the protection boundary and states the independent-review status.
