By running ECDH P-256 and ML-KEM-768 side-by-side, LVR1 protects today's conversations against tomorrow's quantum decryption threats.
A hybrid post quantum ratchet combines classical public-key cryptography with a post-quantum key encapsulation mechanism during active messaging session updates. In Livara Chat, the LVR1 protocol runs classical ECDH P-256 alongside ML-KEM-768 to derive every message key. This dual-layer construction ensures recorded chat sessions remain secure even if a future quantum computer solves elliptic curve cryptography.
Key takeaways
- Livara's LVR1 protocol pairs ECDH P-256 with ML-KEM-768 (NIST FIPS 203) so breaking one primitive leaves message keys protected by the other.
- The LVR1 protocol advances the ML-KEM-768 ratchet on epoch boundaries to minimise post quantum payload overhead on mobile devices.
- Voice and video calls are end-to-end encrypted with WebRTC DTLS-SRTP peer media and post-quantum LVR1-sealed signaling.
- Livara is built on verified cryptographic standards (ML-KEM-768, P-256, AES-256-GCM) with verifiable test vectors and offline Proof Lab checks.
How does a hybrid post quantum ratchet protect messaging?
A hybrid post quantum ratchet protects ongoing conversations by continuously mixing classical key agreement outputs with post-quantum encapsulation shared secrets. Standard ratcheting protocols like the Double Ratchet provide forward secrecy and post-compromise security under classical assumptions. Adversaries who store encrypted chat traffic today could decrypt those logs once a quantum computer capable of running Shor's algorithm becomes available.
To neutralise this store-now-decrypt-later threat, Livara's LVR1 protocol executes an ECDH P-256 ratchet alongside an ML-KEM-768 epoch ratchet. ML-KEM-768 is the primary post-quantum key encapsulation standard specified in NIST's FIPS 203 document. Each individual message key is derived via HKDF-SHA-256 using entropy from both the classical exchange and the post-quantum KEM. As detailed in our guide on post-quantum encryption in messaging, an attacker must compromise both cryptographic problems simultaneously to read the traffic.
What is the post quantum payload overhead in daily use?
The post quantum payload overhead introduced by lattice-based cryptography stems from larger public key and ciphertext footprints. Compared to a 33-byte compressed ECDH P-256 public key, NIST FIPS 203 specifies that ML-KEM-768 requires an 1,184-byte encapsulation key and a 1,088-byte ciphertext.
Attaching over a kilobyte of key material to every 50-byte text message increases bandwidth utilisation. LVR1 resolves this by running the classical P-256 step on every message turn while advancing the ML-KEM-768 ratchet on epoch boundaries or interval updates.
| Cryptographic Primitive | Primitive Type | Key/Ciphertext Size | Frequency in LVR1 Protocol |
|---|---|---|---|
| ECDH P-256 | Classical Elliptic Curve | 33 bytes (public key) | Every message step |
| ML-KEM-768 (FIPS 203) | Post-Quantum Lattice | 1,184-byte key / 1,088-byte ciphertext | Epoch boundary transition |
| AES-256-GCM | Symmetric AEAD | 12-byte nonce, 16-byte tag | Every message payload |
| HKDF-SHA-256 | Key Derivation | 32-byte derived secret | Every step & epoch |
This structure preserves lightweight payload sizes for standard messaging while maintaining post-quantum epoch security against long-term retention attacks.
How does LVR1 protocol performance impact mobile battery life?
LVR1 protocol performance preserves mobile battery life by executing lattice operations within optimised native code and controlling radio frequency wakeups. On modern mobile hardware, ML-KEM-768 key generation and encapsulation take under one millisecond of CPU time, making computation costs negligible compared to display and network hardware energy.
The primary contributor to battery drain on mobile OS platforms is cellular radio activation caused by large or frequent network transmissions. Research presented at NIST's Sixth PQC Standardization Conference demonstrates that communication complexity is the critical factor when ratcheting with post-quantum KEMs. By keeping post-quantum updates attached to periodic epoch boundaries rather than every single message, LVR1 avoids radio power spikes. As explained in our guide to what end-to-end encryption protects, architectural constraints must balance theoretical maximums with real-world mobile battery constraints.
Where do Livara's post-quantum encryption guarantees stop?
Livara's post-quantum protections cover direct messages, private group messages, media attachments, and pairwise call signaling. Precision regarding these boundaries is essential for accurate threat modeling:
- Direct Messages (LVR1): Protected by the hybrid P-256 and ML-KEM-768 double ratchet stack.
- Private Groups (LGS1): Encrypted using sender keys distributed through pairwise LVR1 envelopes, giving text and file attachments hybrid post-quantum protection. Private groups use LGS1 sender-key end-to-end encryption with automatic key rotation on membership changes.
- Attachments: Images, videos, and files are encrypted client-side with a fresh random 32-byte key using AES-256-GCM. That key travels inside LVR1/LGS1 protocol envelopes.
- Call Security & Signaling: Voice and video calls (direct and 2–6 person Android group rooms) use WebRTC DTLS-SRTP peer media encryption. All call setup, SDP offers/answers, ICE candidates, and DTLS fingerprints are sealed inside hybrid post-quantum LVR1 sessions (ML-KEM-768 + P-256), protecting call establishment against quantum interception and MITM attacks.
- Channels: Public channels are server-readable by design to allow reporting and moderation of illicit content such as CSAM or terrorist propaganda. Channels are not end-to-end encrypted.
- Metadata & Verifiability: The server sees communication metadata, including sender and recipient IDs and message timestamps. Users can check client hashes in the Proof Lab or perform safety number fingerprint checks as described in our guide on verifying encrypted chat. However, initial identity bundles are served by the Livara server without a key-transparency ledger.
Livara publishes complete protocol specifications, test vectors, and in-browser offline verification tools in the Proof Lab at /proof, allowing anyone to verify encryption functions and release checksums locally. Readers can inspect these exact boundaries on Livara's security overview and threat model pages.
Frequently asked questions
What is ML-KEM-768 messaging?
ML-KEM-768 messaging incorporates NIST's FIPS 203 lattice-based key encapsulation standard into a messaging protocol. It secures key distribution against cryptanalytically relevant quantum computers while running efficiently on mobile hardware.
Does ML-KEM-768 slow down chat transmission on Android?
No. ML-KEM-768 operations require less than one millisecond of CPU time on modern ARM processors. By executing ML-KEM-768 ratchet steps on periodic epoch boundaries rather than per message, the LVR1 protocol maintains high responsiveness and battery efficiency.
How is Livara Chat's security verified?
Livara is built on NIST-standardized and verified cryptographic algorithms (FIPS 203 ML-KEM-768, P-256, HKDF-SHA-256, AES-256-GCM). Full protocol specifications, machine-checkable test vectors, and in-browser offline cryptographic verification tools are published in the Proof Lab at /proof.
How are voice and video calls protected?
Direct calls and 2–6 person Android group rooms use WebRTC DTLS-SRTP peer-to-peer media encryption. All call signaling and DTLS certificate fingerprints (protocol LCS1) are sealed inside hybrid post-quantum LVR1 envelopes (ML-KEM-768 + P-256), binding media encryption to authentic peer identities and preventing man-in-the-middle attacks.
