The expensive part of post-quantum cryptography is scheduled, not repeated: ML-KEM-768 runs once per session or key epoch, while every message is sealed with cheap symmetric encryption.
Post-quantum key agreement costs a phone far less than most people expect. The extra work happens once per session rather than once per message, so the post-quantum cryptography battery impact in everyday messaging is small enough that most users will never notice it. On Android, ML-KEM-768 performance comes down to a handful of Keccak hashes and roughly 2.3 KB of extra handshake data per session, while every message after that is sealed with AES-256-GCM using keys derived from that handshake. The honest caveat: the cost is real and measurable, it just lands on handshake latency and data usage long before it lands on your battery.
Key takeaways
- Post-quantum key agreement runs at session setup, not per message, so it cannot drain a battery the way a display or a cellular radio does.
- ML-KEM-768, standardized by NIST in FIPS 203, puts a 1,184-byte encapsulation key and a 1,088-byte ciphertext on the wire, against 65 bytes for an ECDH P-256 public point — roughly 2.3 KB more per session.
- The OpenSSL post-quantum performance benchmark measures key exchanges per second and reports ML-KEM-768 as competitive with classical ECDH curves on the same hardware.
- Per-message cost is unchanged by post-quantum cryptography, because messages use HKDF-SHA-256 and AES-256-GCM, and modern Arm cores accelerate AES in hardware.
- The largest post-quantum costs are paid at group setup, where sender keys are sealed in pairwise envelopes, and on very slow connections where an extra 2.3 KB is a bigger share of the transfer.
Does post-quantum encryption drain your battery? The arithmetic says no
No — not in any way a user would notice, and the reason is arithmetic rather than optimism. Battery drain is energy per operation multiplied by how often the operation runs. A hybrid key exchange runs when a session is established: once for a chat that may stay open all day. Everything after that is symmetric encryption, which is the cheap part of any messaging stack.
That distinction is what most "post-quantum is slow" arguments skip. They compare one ML-KEM-768 operation against one ECDH P-256 operation and stop there, which is a fair comparison of a single operation and a misleading comparison of a working messenger. A phone that performs one hybrid handshake and then sends 400 messages pays the post-quantum cost once.
Where the energy actually goes on a phone is somewhere else entirely: display on-time, the cellular or Wi-Fi radio, and continuous background synchronisation of routing metadata such as sender, destination and delivery timestamps, which is what keeps messages arriving on all your devices. Those run constantly. A key agreement does not.
What is ML-KEM-768, and why does it run on your phone at all?
ML-KEM-768 is a key encapsulation mechanism, meaning a two-step way for two devices to agree on a shared secret key: one side publishes a public key, and the other returns a ciphertext that only the holder of the matching private key can turn back into that secret. It is the algorithm NIST standardized in FIPS 203, and the "768" denotes a security category, not a key length in bits.
It runs on your phone because the classical half of a modern handshake, ECDH P-256, is breakable by a sufficiently large quantum computer. A hybrid handshake runs both sides at once — the classical elliptic-curve agreement and the post-quantum ML-KEM agreement — and mixes both secrets into the final key. If either algorithm falls, the other still protects the session.
That hybrid design is what Livara uses for direct messages under its LVR1 protocol, and it is why the app can offer post-quantum protection today rather than promising it later. If you want the longer version of how the two halves are combined and why it matters, there is a full explainer on how post-quantum encryption works in messaging.
One limit belongs in the same paragraph as the claim: ML-KEM protects key agreement, it does not encrypt message content. Message bodies are sealed with AES-256-GCM, and NIST's guidance treats AES-256 as still providing adequate security against quantum search algorithms.
ML-KEM-768 performance on Android: where the CPU time actually goes
Almost all of the ML-KEM-768 CPU time on a phone goes into two places: polynomial multiplication over the ring defined in FIPS 203, usually implemented with a number-theoretic transform, and Keccak-based hashing through SHA3-256 and SHAKE256. A number-theoretic transform is the fast way to multiply long polynomials — the same trick as a fast Fourier transform, applied to a different mathematical structure. Neither step is memory-hungry, which is why the algorithm behaves well on phones with modest caches.
The bytes are the part fixed by the standard; the CPU time is the part that varies by device. An older mid-range Android phone with software-only SHA-3 spends more time in the hashing than a recent flagship whose Arm cores include SHA-3 instructions, which the Armv8.4-A architecture introduced. Neither changes the per-message cost, because neither runs per message.
| Operation | What it produces | Bytes on the wire | How often it runs |
|---|---|---|---|
| ML-KEM-768 key generation | the encapsulation (public) key | 1,184 | at identity setup |
| ML-KEM-768 encapsulation | shared secret plus ciphertext | 1,088 | per session or key epoch |
| ML-KEM-768 decapsulation | the same shared secret, recovered | none | per session or key epoch |
| ECDH P-256 key agreement | classical shared secret | 65 | per session |
| HKDF-SHA-256 + AES-256-GCM | per-message key and sealed message | 12-byte nonce, 16-byte tag | every message |
| Where a messaging phone's energy goes | How often it runs | Relative share (illustrative) |
|---|---|---|
| Screen on-time | continuously while in use | ██████████ |
| Cellular or Wi-Fi radio | continuously | ███████ |
| Metadata sync across devices | frequently | ███ |
| Hybrid key exchange (ECDH + ML-KEM-768) | per session | █ |
| Per-message AEAD (AES-256-GCM) | per message | █ |
The chart above is an order-of-magnitude illustration of where energy goes in a messaging app, not a measurement from a named device. The point is the frequency column: cryptography that runs once per session cannot compete with hardware that runs continuously.
ECDH vs ML-KEM latency: how much slower is the handshake really?
On the same hardware, ML-KEM-768 is competitive with classical ECDH rather than catastrophically slower. The OpenSSL post-quantum performance benchmark measures key exchanges per second for ML-KEM-768 against ECDH P-256 and ECDH P-384 across a series of OpenSSL releases, and its headline finding is that ML-KEM offers quantum resistance at competitive performance.
A smaller, isolated benchmark of ML-KEM-768 key encapsulation measures the same primitive on its own, which is the useful thing to check whenever a vendor quotes one impressive number: ask whether they measured encapsulation, decapsulation, or a whole handshake.
For an end-to-end view, an IEEE evaluation of hybrid TLS with ML-KEM-768 reported positive end-to-end results after adding the KEM to a standard TLS connection.
The caveat that matters on a phone is this: handshake latency on mobile networks is dominated by network round-trip time, not local computation. Adding a post-quantum key agreement adds a local computation and about 2.3 KB of data; it does not add a round trip. On a strong connection you will not feel it. On a poor one, those extra kilobytes are a small but real cost, and that is the honest limit of any "you will not notice it" claim.
Hybrid key exchange on a mobile CPU: why you pay once per session, not per message
Livara's direct-message protocol, LVR1, is a hybrid post-quantum double ratchet: a P-256 ECDH ratchet and an ML-KEM-768 epoch ratchet run side by side, and every message key is derived from both. In practice that splits the cost into two very different tiers.
- Per message: a symmetric ratchet step. HKDF-SHA-256 derives the next message key and AES-256-GCM seals the message. This scales with how much you talk, not with how large the keys are.
- Per epoch or key change: a fresh ML-KEM-768 encapsulation and a new ECDH agreement, which is what restores forward secrecy and post-compromise security.
That structure is exactly the property a raw key-exchange benchmark cannot show you: the expensive operation is scheduled, not repeated. Rotating keys on an epoch boundary rather than on every message is what keeps hybrid key exchange affordable on a mid-range phone.
Group chats are the honest exception. Under LGS1, Livara's private-group protocol, each sender key is sealed inside pairwise LVR1 envelopes, so setting up a group performs one envelope per recipient and a large group costs more at setup than a one-to-one chat. It is still setup work: once sender keys are distributed, a group message is encrypted once and decrypted once, at the same per-message cost as a direct message.
How much battery does PQ crypto energy consumption use on a phone?
Less than almost anything else your phone does with the screen on. Energy is power multiplied by time, and the post-quantum part of a hybrid handshake runs for a tiny fraction of the time the display, the radio and the operating system's background services run. There is no ordinary day of messaging in which ML-KEM-768 is the reason your battery is low.
What does add up, and what a fair comparison should mention:
- More sessions means more handshakes. Force-stopping the app, reconnecting on every network change, or holding many short-lived connections all multiply the fixed setup cost.
- Large groups multiply setup cost per member, for the reason described above.
- Background metadata synchronisation runs continuously and costs more across a day than key agreement ever will.
If you are choosing a messenger and want the questions that actually separate a secure app from a marketing page, the 12 questions to ask of any messenger are a better filter than any battery benchmark.
Does post-quantum encryption speed affect photos, video and file sends?
No, and this is the clearest place where the post-quantum cost model separates from the symmetric one. Attachments are not encrypted with ML-KEM. Each image, video, file, caption or voice note gets a fresh random 32-byte content key and is encrypted before upload, and that key travels inside the LVR1 or LGS1 message. The bulk encryption is AES-256-GCM, which Arm cores accelerate with dedicated AES instructions.
So the time to send a photo is dominated by compressing it, reading it from storage and uploading it over your connection, not by cryptography. The same applies to voice notes and to video.
Two limits belong here. First, this covers private conversations: direct messages and private groups. Public broadcast channels in Livara are deliberately public and unencrypted, so that reports can be acted on and abusive material removed — channel content should never be treated as private. Second, encrypting a file protects its contents, not the fact that you sent it or when you sent it; that is metadata, and what end-to-end encryption does and does not protect is a separate discussion.
How can you run your own post-quantum encryption speed test?
Measure three things rather than one: how long a handshake takes, how many bytes it puts on the wire, and whether the app you tested is the app that was published. A single throughput number with no method attached is not a speed test, it is a slogan.
For the third point, Livara makes the check concrete. The Android APK integrity check rests on published SHA-256 checksums that you can check locally and offline in the Proof Lab, which tells you the build on your phone matches the build that was released. You can also compare safety numbers (v3) with a contact out of band to confirm that no key changed underneath you. Call media is a separate case: calls use WebRTC DTLS-SRTP, which is not post-quantum, and only call signalling travels as an ordinary pairwise-sealed message.
Frequently asked questions
Does post-quantum encryption drain my phone's battery?
Not in normal use. ML-KEM-768 runs during session setup, not for every message, so the energy it consumes across a day is a small fraction of what the display and the cellular radio use. You would have to reconnect constantly for key agreement to become visible in battery statistics.
Is ML-KEM-768 slower than ECDH P-256?
On the same hardware it is competitive with classical elliptic-curve key exchange rather than dramatically slower, according to the OpenSSL post-quantum benchmark suite. On a phone the practical difference appears as a few kilobytes of extra handshake data and a small amount of local computation, both dwarfed by network latency.
Why use a hybrid key exchange instead of ML-KEM alone?
Hybrid means running a classical agreement (ECDH P-256) and a post-quantum one (ML-KEM-768) together and mixing both secrets. If a future quantum computer breaks ECDH, ML-KEM still protects the session; if ML-KEM is ever weakened, ECDH still holds. The cost is additive but small, and paid once per session.
Does post-quantum encryption slow down sending photos?
Not noticeably. Attachments use AES-256-GCM with a fresh random 32-byte content key, and that key travels inside the encrypted message. Symmetric encryption with hardware AES instructions is fast, so compressing, reading and uploading the file dominate the time it takes to send a photo or video.
Are Livara's public channels end-to-end encrypted?
No. Channels are public broadcast streams, deliberately unencrypted so that Livara can act on reports and remove abusive material. Direct messages under LVR1 and private groups under LGS1 are fully end-to-end encrypted with hybrid post-quantum key agreement; channel content is readable by design.
