Prekeys let the recipient be offline during setup. They do not remove the need for a delivery path or careful private-key lifecycle management.
An offline recipient can receive an encrypted message later because their device published public key material in advance. The sender still needs a reachable delivery service; “asynchronous encryption” does not mean messages cross a network outage or appear instantly on a disconnected phone.
Post-quantum designs extend this idea with a key-encapsulation mechanism. The important questions are how the initial secret is established, how old private keys are retired, and how later messages refresh security.
Prekeys solve a timing problem
Imagine Maya is offline when Sam starts a new conversation. Maya's device previously uploaded public prekeys. Sam can fetch that material, perform the sender's side of key agreement and send an encrypted first message. Maya processes it after reconnecting, using private keys kept on her device.
The server therefore supplies public information and queues encrypted data; it need not possess the resulting message secret. Signal's X3DH specification is a primary description of this asynchronous design. A signed prekey and a one-time prekey have different lifetimes and roles; “prekey” does not mean a secret password uploaded to the server.
For an already-established conversation, the app may use existing session state rather than repeat initial setup for every message. Starting a session and advancing its message keys are separate operations.
What a post-quantum KEM adds
A key-encapsulation mechanism has three basic operations: generate keys, encapsulate using a public key, and decapsulate using the corresponding private key. Encapsulation produces both a shared secret and a ciphertext. The ciphertext can be delivered later; the secret itself is not sent in the clear.
NIST FIPS 203 standardizes ML-KEM. For ML-KEM-768, the public encapsulation key is 1,184 bytes, the ciphertext 1,088 bytes and the shared secret 32 bytes. These are algorithm-level sizes, not the size of an entire messaging packet. Signatures, classical keys, identifiers and transport framing add overhead; a cached public key may not accompany every message.
In a hybrid construction, a protocol combines classical and post-quantum secret material according to a defined key schedule. Simply concatenating algorithm names does not establish that the composition is secure. Identity binding, validation, domain separation and failure handling need specification and review.
An example: PQXDH, not a universal blueprint
Signal's PQXDH specification describes signed one-time post-quantum prekeys and a signed last-resort key. The sender verifies the supplied signatures, performs key agreement and includes the KEM ciphertext and key identifiers with the initial encrypted message. The recipient later derives the same secret and processes the message.
Its last-resort key supports setup when one-time KEM keys are unavailable, but the compromise analysis is not identical. Private-key deletion and rotation affect protection of earlier sessions. The specification also distinguishes post-quantum forward secrecy from authentication against an active quantum attacker. These details should not be replaced with “fallback has no security cost.”
PQXDH is one specified construction. Its exact curves, signatures and parameter choices should not be copied into a description of a different product unless that product documents them.
A ratchet is not the same as a prekey pool
Prekeys support session establishment. A ratcheting protocol changes secrets during the conversation. The Double Ratchet specification explains message-key evolution and newer post-quantum ratcheting constructions, including designs that do not transmit a full post-quantum exchange with every application message.
Forward secrecy concerns earlier messages after later key compromise. Post-compromise security concerns recovery for future communication after the attacker loses access and fresh secret material is incorporated. Neither means malware can remain on a phone indefinitely while cryptography somehow hides that phone's plaintext from it.
Deleting a public prekey from the server prevents its ordinary reuse; it is not equivalent to deleting the corresponding private key from an endpoint. A useful audit checks both lifecycle rules and delayed-message behavior.
What Livara documents—and what still needs evidence
Livara's security page describes hybrid session establishment with one-time keys when available, ordinary message-chain advances and periodic ML-KEM epochs. That differs from the old claim that every message performs a full fresh ML-KEM exchange. These are product documentation statements, not an independent verification of the implementation.
Do not infer a specific exhausted-key fallback policy, replenishment interval or network-latency figure from those statements. Those questions need release-specific protocol documentation or measured results. The Proof Lab is also not a complete test of asynchronous setup, key exhaustion or delayed-message recovery.
How to evaluate offline messaging claims
Ask the vendor or reviewer for evidence covering these cases:
| Test case | What to observe |
|---|---|
| First message to a disconnected contact | Which public-key material was used and when the recipient actually receives the message |
| Exhausted one-time prekeys | Whether setup stops or follows a documented fallback, and its stated security tradeoff |
| Recipient reinstalls or changes identity | Whether old queued messages remain decryptable and whether key changes are visible |
| Delayed or reordered messages | Retention limits, skipped-key handling and understandable errors |
| Return after a long absence | Safe key refresh, bounded processing and accurate delivery status |
| Performance comparison | Device, app version, network, payload size and separate cold-setup versus established-session measurements |
Use non-sensitive test accounts and messages. A successful delivery test demonstrates that scenario, not every cryptographic property. Conversely, a failed delivery may be a networking or lifecycle issue rather than a break of the cipher.
Frequently asked questions
Can a recipient be offline while I send?
Yes, if the application has the required public material and delivery/storage infrastructure. The recipient cannot read the queued message until their device can retrieve and process it.
Do larger KEM keys always make chats noticeably slower?
No universal timing claim follows from key size alone. Setup frequency, batching, caching, implementation and network conditions matter. Publish a benchmark rather than promising zero overhead.
Does a signed prekey prove the person behind the account?
It authenticates material relative to a signing identity. How that identity is bound to the person you intend to contact is a separate trust and verification question.
Does post-quantum encryption work without any connection?
Some local calculations can run offline. Delivering messages still requires a communication path; cryptography does not supply one.
