FIPS 203 is the US National Institute of Standards and Technology specification for ML-KEM, a post-quantum key-encapsulation mechanism. ML-KEM-768 is one of its parameter sets. It helps endpoints establish shared secret material; it does not encrypt every chat message by itself or certify a messenger that uses it.
The job of a key-encapsulation mechanism
A sender uses the recipient's ML-KEM public key to encapsulate a shared secret and sends the resulting ciphertext. The matching private key lets the recipient decapsulate the same secret. A messaging protocol still needs to bind the right key to the right person, derive message keys, encrypt and authenticate content, update keys over time and handle lost devices. A correct KEM call cannot replace those rules.
ML-KEM-768 identifies a parameter set, not a level of protection for all product features. The standard describes the primitive and its algorithms; it does not evaluate Livara's app, delivery service, group membership or release process.
Where Livara Chat says it uses ML-KEM-768
Livara's published security description says its LVR1 direct-message design mixes an ML-KEM-768 contribution with classical P-256 material. The aim is to make key establishment depend on contributions from two different families of assumptions. The hybrid ratchet explainer discusses how the direct-message state advances. Compatible private groups use LGS1 sender keys distributed through protected pairwise paths; public channels are server-readable.
This is the product maker's design description. The exact security result depends on identity binding, a sound combiner, key storage, downgrade behavior and the released implementation. Livara's security page does not claim an independent product audit. A matching APK hash confirms a match to a published binary, not correctness of that binary.
Why a hybrid path matters for stored ciphertext
The “harvest now, decrypt later” model asks whether an adversary who saves traffic today could read it after a future break of classical public-key exchange. Content that must remain private for many years makes this question more relevant. The threat depends on which handshake material and ciphertext the adversary collected and on the actual protocol. There is no known date for a cryptographically useful quantum computer. See the threat-model guide for a broader explanation.
What ML-KEM-768 cannot protect
- An unlocked or compromised device can reveal plaintext after decryption.
- The recipient can copy or forward a message.
- Routing, membership, timing and ciphertext size may remain visible to the service.
- A public channel does not become a private group because the app also supports ML-KEM.
- Lost-device recovery, linked devices, calls and backups require their own documented boundaries.
If you are evaluating a messenger, record the client version and conversation mode; read the published protocol and threat model; verify how contact keys change; and distinguish a vendor specification from independent review. FIPS 203 is a useful, precise starting point for the key-establishment question—not an all-purpose security seal.
