A benchmark needs a device, a workload, a method and uncertainty—not just a fast-looking number.
There is no defensible universal battery percentage for ML-KEM-768 on Android. Cost depends on the implementation, phone, session setup, key-refresh frequency and network behaviour. A fast cryptographic benchmark on a desktop does not establish the battery life of a complete mobile messenger.
This article explains what can be calculated from the standard and what needs measurement. No Livara Android battery benchmark was performed for this article. The procedure below is a test plan, not a claimed result.
What the standard tells us
ML-KEM is a key-encapsulation mechanism: it helps establish a shared secret that a protocol can use for symmetric encryption. In FIPS 203, ML-KEM-768 has an encapsulation key of 1,184 bytes and a ciphertext of 1,088 bytes. Together those two objects total 2,272 bytes.
That total is not the complete size of a messaging handshake or necessarily its incremental network cost. Certificates, signatures, classical key material, framing, encoding, cached keys and retransmission can all change the bytes actually sent. The “768” is a parameter-set identifier, not a 768-bit shared-secret length; this set targets NIST security category 3.
| Quantity | Fixed by the algorithm or measured? |
|---|---|
| Encapsulation-key and ciphertext lengths | Defined by the selected ML-KEM parameter set |
| Key generation, encapsulation and decapsulation time | Measure for the actual implementation and device |
| Full session-establishment bytes | Measure the protocol, including framing and retries |
| End-to-end send latency | Measure the app and network together |
| Energy per workload | Measure with a controlled device-level experiment |
Is the cost paid once per session?
Not necessarily. A protocol may use a KEM at initial setup and again during periodic post-quantum key updates. Group membership changes, new devices, failed sessions and recovery can trigger more work. The correct unit is the protocol event, not an assumption that every conversation performs exactly one KEM operation.
Livara's published LVR1 architecture describes periodic ML-KEM epochs alongside ordinary message-chain steps. Therefore, a useful benchmark must cover both steady-state messaging and key-refresh events. It should not claim that the post-quantum work never recurs.
A stored ciphertext byte count also says little about energy by itself. An extra packet can affect radio behaviour differently from a few more bytes inside an already-active transfer.
A reproducible Android measurement plan
1. Record the environment
Write down phone model, Android build, app version, cryptographic library version, build mode, battery state and thermal state. Record the network type and signal conditions. Do not publish private account data or packet contents in a benchmark report.
2. Separate primitive and application tests
A primitive test measures key generation, encapsulation or decapsulation in isolation. A full-app test measures creating a session, sending messages and recovering from a connection interruption. Report both if available; do not label one as the other.
Use repeated trials and report the spread, such as median and a high percentile, rather than selecting the fastest run. Warm-up, runtime compilation and thermal throttling can affect results.
3. Define realistic workloads
- Establish a new direct-message session.
- Send a fixed number and size of messages in an established session.
- Exercise a documented key-refresh boundary.
- Add or remove a member in a test group, if supported.
- Send the same attachment under the same conditions.
- Leave the app idle for a fixed interval and measure background behaviour separately.
Use synthetic content and consenting test accounts. A group test should state its member count; a two-person result cannot be silently extrapolated to a large group.
4. Measure energy as well as time
Android Studio's Power Profiler can correlate activity with power-rail measurements on supported hardware. Google cautions that these are device-level measurements, so other activity introduces noise. Supported measurement methods differ by device.
Control screen brightness, background work, network conditions and test duration. Repeat the same workload and compare like with like. If your method cannot isolate the cryptographic contribution, say so instead of attributing all battery drain to ML-KEM.
Illustration of a measurement setup, not recorded benchmark results.
What would a useful results table contain?
| Result field | Example of the information to record |
|---|---|
| Workload | New session, established messaging or key refresh |
| Environment | Exact device, app build and network |
| Trials | Count and handling of warm-up runs |
| Timing | Median, variation and units |
| Traffic | Measured bytes and retransmission conditions |
| Energy | Method, interval and uncertainty |
| Limitations | What the test did not isolate or cover |
Leave unmeasured cells blank or mark them “not measured.” An illustrative energy bar chart with invented relative shares is not evidence.
What about photos and video?
Large attachments generally use symmetric encryption rather than ML-KEM for every content block. Key establishment can still affect setup, while file processing, storage, network transfer and retry logic affect the complete operation. The relative contribution must be measured on the actual workload; “never noticeable” is not a sound universal claim.
Frequently asked questions
Is ML-KEM-768 always slower than P-256?
No universal comparison applies across libraries and hardware. Compare the same operations under the same conditions, then measure the complete hybrid protocol separately.
Does an APK checksum validate performance results?
It can identify the exact file tested when compared with a trusted reference. It does not validate the test method, implementation safety or energy measurement.
Should users disable encryption to save battery?
Do not trade away a security requirement based on an unsupported performance claim. First identify the actual source of battery use and use supported settings or updates.
