Hybrid post-quantum messaging combines classical elliptic curves with ML-KEM-768 encapsulation, ensuring offline contacts remain safe from store-now-decrypt-later attacks.
Post-quantum encryption works during offline periods by combining classical key agreement with post-quantum Key Encapsulation Mechanisms (KEM) uploaded to a server in advance. In hybrid PQ asynchronous messaging, an offline recipient's device publishes a pool of signed ML-KEM-768 prekey bundles alongside classical ECDH keys, allowing a sender to establish a post quantum double ratchet offline session without waiting for the recipient to reconnect. This architecture prevents store-now-decrypt-later attacks while ensuring messages remain deliverable instantly.
Key takeaways
- Asynchronous messaging relies on server-stored pre-keys so senders can establish encrypted sessions while recipients are offline.
- Hybrid protocols pair elliptic-curve Diffie-Hellman (P-256) with NIST FIPS 203 (ML-KEM-768) to protect current sessions against future quantum supercomputers.
- Exhaustion of one-time post-quantum pre-keys forces a fallback to signed medium-term KEM keys without sacrificing hybrid forward secrecy.
- Livara’s LVR1 protocol executes dual ECDH and ML-KEM-768 ratchets per message, deriving message keys through HKDF-SHA-256.
- Public channels remain intentionally unencrypted for moderation, while all direct and group conversations use end-to-end hybrid post-quantum encryption.
How do asynchronous E2EE pre-keys establish an encrypted session offline?
To send an encrypted message to an offline contact, your application must generate a shared secret without communicating with their device in real time. Classical systems solve this using initial key exchange protocols, such as X3DH, where devices pre-upload signed ephemeral keys to a central server. When you initiate a conversation, your client fetches the recipient’s public pre-keys from the server, executes a Diffie-Hellman calculation locally, and encrypts the payload immediately.
Introducing post-quantum resistance requires substituting or augmenting classical Diffie-Hellman exchanges with lattice-based key encapsulation mechanisms. As defined in NIST FIPS 203, ML-KEM-768 does not permit two parties to independently derive a shared key from static public keys in the same manner as elliptic-curve cryptography. Instead, the sender encapsulates a random symmetric secret against the recipient's post-quantum public key, producing a ciphertext that must travel alongside the first message.
When combined with classical keys, these asynchronous E2EE pre-keys form a hybrid key agreement. The sender computes both a P-256 ECDH shared secret and an ML-KEM-768 encapsulation, mixing both inputs through HKDF-SHA-256 as specified in RFC 5869. The offline recipient later receives the message payload, decrypts the classical component, decapsulates the ML-KEM ciphertext using their private lattice key, and arrives at the exact same master key.
How does a post quantum double ratchet offline protocol prevent key exhaustion?
Maintaining forward secrecy across thousands of offline session initiations requires managing pre-key inventory carefully. In a standard Double Ratchet architecture, a device publishes identity keys, a signed pre-key, and a limited pool of one-time pre-keys (OTKs). Each incoming session consumes one OTK, which the server deletes immediately to ensure that compromising the server at a later date cannot reveal past session keys.
If a user remains offline while receiving hundreds of new conversation requests, the server eventually exhausts that user's one-time post-quantum pre-keys. A post quantum double ratchet offline protocol addresses this exhaustion by falling back to a signed medium-term ML-KEM-768 pre-key. Although losing one-time keys slightly reduces individual session isolation against immediate local device extraction, the hybrid ratchet immediately advances as soon as both parties exchange active messages.
In Livara’s LVR1 protocol, the double ratchet operates two distinct ratchets in tandem: a classical P-256 DH ratchet and an ML-KEM-768 epoch ratchet. Every ratchet hop re-capsulates a fresh ML-KEM seed alongside a classical Diffie-Hellman exchange. This dual structure provides both classical forward secrecy and post-compromise security, preventing an adversary who captures a long-term key today from retroactively decrypting intercepted offline traffic.
What happens inside an ML-KEM-768 prekey bundle during an offline session?
An offline session setup depends on the contents of the recipient's pre-key bundle retrieved from the routing server. A standard classical bundle contains lightweight raw public keys, whereas a hybrid post-quantum bundle includes larger lattice parameter sets.
| Component | Classical Pre-Key (P-256) | Hybrid PQ Pre-Key Bundle (LVR1) |
|---|---|---|
| Identity Key | 64-byte P-256 Public Key | 64-byte P-256 Public Key |
| Signed Pre-Key | 64-byte P-256 + ECDSA Signature | 64-byte P-256 + ECDSA Signature |
| Post-Quantum Key | None | 1,184-byte ML-KEM-768 Encapsulation Key |
| One-Time Keys | Array of 64-byte P-256 Keys | Array of ML-KEM-768 + P-256 Pairs |
| KDF Derivation | HKDF-SHA-256 (DH secrets only) | HKDF-SHA-256 (Combined DH + KEM secret) |
| Primary Defense | Discrete Logarithm Hardness | Lattice Learning With Errors (LWE) + ECC |
When your device requests an ML-KEM-768 prekey bundle for an offline user, the server responds with the target’s classical keys and an active post-quantum key. Your application validates the ECDSA signature attached to the bundle (using NIST FIPS 186-5 standards) to verify that the server has not substituted public keys in transit.
Once validated, your phone generates an ephemeral ML-KEM ciphertext (1,088 bytes) and encapsulates a 32-byte post-quantum shared secret. This ciphertext is attached to the initial header of your message. Even if an adversary intercepts and records this payload from the network, they cannot decapsulate the secret without solving the Module Learning With Errors (M-LWE) problem or breaking the underlying P-256 elliptic curve.
How does hybrid PQ asynchronous messaging balance key size with server memory?
Post-quantum cryptography trades computational speed and mathematical security for significantly larger key sizes. While a classical P-256 key requires just 64 bytes of storage, an ML-KEM-768 public key occupies 1,184 bytes, and its corresponding ciphertext takes 1,088 bytes. Multiplying these overheads across thousands of pending offline messages creates significant bandwidth and storage challenges for mobile clients and servers.
To maintain performance, hybrid PQ asynchronous messaging architectures implement strict lifecycle management for key bundles. Servers enforce maximum caps on published one-time pre-keys while prioritizing active session rotation. If a recipient's client reconnects, it immediately uploads a fresh batch of post-quantum pre-keys to replenish spent pools.
For media transmission during offline periods, large files are never embedded directly into the asymmetric protocol payload. Photos, videos, and documents are encrypted locally using a fresh random 32-byte content key with AES-256-GCM (12-byte nonce, 16-byte tag). The encrypted file payload uploads to blob storage, while only the lightweight 32-byte symmetric content key travels wrapped inside the post-quantum LVR1 message envelope. This separation guarantees that bandwidth stays minimal while preserving end-to-end security.
Furthermore, users can verify key integrity offline. Through Livara's Proof Lab, users can inspect published SHA-256 checksums and review verifiable protocol builds to ensure local binaries handle post-quantum prekey bundles without tampering.
Frequently asked questions
What happens if an offline user runs out of ML-KEM-768 prekeys?
If an offline user consumes all allocated one-time ML-KEM-768 prekeys, the server issues the user's signed medium-term post-quantum prekey. The sender continues to establish hybrid post-quantum sessions using this signed key, maintaining protection against quantum interception while queuing key replenishment for when the recipient reconnects.
Does post-quantum asynchronous encryption slow down message delivery?
No. Although ML-KEM-768 public keys and ciphertexts add approximately 2.2 kilobytes to the initial session initiation header, subsequent ratchet messages within an established session use lightweight symmetric updates. Network transmission latency remains virtually identical to classical messaging protocols on modern mobile networks.
Is my offline group chat also protected by hybrid post-quantum pre-keys?
Yes. In private group chats using Livara’s LGS1 protocol, every participant distributes sender keys sealed inside pairwise LVR1 envelopes. When you send a message to an offline group member, the underlying sender key relies on the same hybrid ML-KEM-768 pre-key mechanism as direct messages.
Are public channels on Livara encrypted with post-quantum pre-keys?
No. Public channels are unencrypted broadcast streams designed for open public distribution. Because channels serve an unbounded audience rather than private conversations, they do not use end-to-end pre-keys or post-quantum ratchets. This design choice allows platform safety systems to inspect reports and remove illicit content effectively.
Livara Team is the collective in-house author. This byline does not indicate independent review; assess claims using the cited sources and stated limits.
