The extent of exposure depends on the key type and how long the attacker has access; a ratchet does not guarantee that only one message is at risk.
Strong encryption also needs correct execution on the device. A vulnerability in the operating system, cryptographic implementation or hardware may open a path to sensitive data; however, research on processor attacks does not establish that every phone or messenger can be compromised in the same way.
The useful questions are: what access does the attacker have, which key or plaintext can they see, and is their access temporary or ongoing? The answers matter more than the algorithm’s name.
How do side channels differ from memory extraction?
With direct memory extraction, an attacker may be able to read parts of a process’s or device’s memory. A side-channel attack uses signals such as operation timing or cache behavior to infer information. The two do not necessarily have the same prerequisites or outcomes.
The original FLUSH+RELOAD research examined cache behavior and shared memory pages in a specific experimental environment and demonstrated key extraction from a version of GnuPG. That result is not a security test of Livara or evidence that every phone processor is vulnerable.
| Type of access | Question needed for assessment |
|---|---|
| Running an ordinary app on the same device | Do process isolation and the attack’s prerequisites permit observation? |
| High-level operating-system access | Which data or key operations become available to the attacker? |
| Physical or laboratory access | What are the lock state, hardware model and key protections? |
| Ongoing access to the app | Can the attacker collect fresh plaintext or keys again? |
The general phrase “RAM hacking” is not an adequate technical explanation without these details.
How do Keystore and secure hardware help?
Android Keystore can restrict key use and, on suitable devices, perform operations with hardware backing. In this design, a non-extractable key is not the same as a key that an attacker cannot use: under some circumstances, a compromised app may be able to abuse permitted key operations even without extracting the key bytes. Android Keystore guide.
Nor are all keys and algorithms automatically placed in secure hardware. The key type, device support and how the app uses it must be specified. Saying that “the key is on the device” does not by itself establish its location or level of protection.
Does one exposed key reveal only one message?
Sometimes, exposure of an independent message key has a limited scope. But if an attacker obtains a chain key, session state, identity key, readable history or multiple buffers, the result is different. Without identifying the exposed data, we therefore cannot say that “at most one message” is at risk.
Changing the key for every message also does not necessarily cut off the attacker’s access. If subsequent keys derive from state the attacker possesses, or the attacker remains on the device, they may reach later messages too. Protection of the past and recovery of future security are separate properties with specific assumptions.
What are the limits of ratchets and memory clearing?
A ratchet can evolve keys throughout a conversation. Recovery after exposure requires fresh information that the attacker cannot access; simply sending a message does not establish that condition. The Double Ratchet specification discusses recovery as well as the risks of persistent access and recovery of deleted data.
Shortening the lifetime of sensitive data and clearing buffers are useful, but they do not establish any general claim that all copies in RAM have been erased. Libraries, programming languages and display paths must be examined.
What can we say about Livara?
Livara’s security page describes the hybrid construction and key evolution in LVR1. This article is not a side-channel test, memory audit or confirmation that all keys use Keystore. In particular, the public threat model does not guarantee protection of a compromised device.
Promises that “the next message neutralizes a hardware compromise” or “at most one message is exposed” should therefore not be attributed to the product without specific evidence for that version and scenario.
Practical decisions for users
Keep the operating system and app updated, choose a device with active security support, avoid untrusted installations and unnecessary permissions, and use an appropriate lock. If serious compromise is suspected, changing messengers or sending a new message is no substitute for investigating and cleaning the device.
When reading a security claim, ask for four things: the tested version, the attacker’s access, the exposed data and the limits of the result. A processor name or encryption standard alone does not answer these four questions.
