Recovering a cryptographic identity, signing back into an account, and restoring chat history are three different tasks. According to Livara’s security documentation, the v7 format is used to recover a cryptographic identity; the format itself does not restore chat history.
Nor should this architecture be described as having “no cloud backup at all.” The current document says identity material is encrypted on the device and then uploaded as an encrypted backup. The important distinction is between storing readable keys on the server and storing an encrypted copy that requires a recovery key to unlock.
Three doors that do not share one key
| Operation | Purpose | Why is it not enough? |
|---|---|---|
| Account login | Prove the right to access a service account | Does not necessarily provide the key to decrypt earlier messages |
| Identity recovery | Regain access to cryptographic identity material | Does not, by itself, establish that all messages exist or can be restored |
| History recovery | Restore the required messages and attachments | Requires the data itself and a supported recovery method, as well as the key |
This distinction prevents a costly mistake: erasing an old phone on the assumption that knowing the login password is enough to restore every conversation.
What exactly does the v7 documentation say?
Livara’s security page explains that P-256 agreement and signing keys and the ML-KEM seed are encrypted on the device under a random 256-bit recovery key. The v7 format description also authenticates the algorithm suite, identity epoch, and generation. This is the provider’s documentation and does not, on its own, constitute an independent audit of the implementation.
Livara’s threat model says the recovery phrase is necessary to unlock the key backup. This explanation is not a basis for guessing the exact phrase-to-key conversion algorithm or assuming that all keys are directly reconstructed. Practical details must be checked against the app version and its corresponding guide.
Why does a derivation function not make a weak phrase strong?
A function’s output length is not the same as its input’s unpredictability. RFC 5869 states that HKDF concentrates existing entropy but does not increase it. You therefore cannot claim that any arbitrary phrase automatically acquires full 256-bit security by passing through HKDF.
Do not arbitrarily shorten, rewrite, or replace the phrase generated through the app’s official flow with a guessable sentence. Do not send it to anyone, a support bot, or an unfamiliar form.
Before replacing or erasing your phone
- Check in the app what has been backed up: identity, history, or both through separate methods.
- Keep the recovery phrase in a secure place independent of that phone; treat other people’s access to it as a serious risk.
- Read the current version’s recovery guide. A “login successful” message alone is not evidence of complete recovery.
- If a recovery-testing method is supported, first try it with nonsensitive data and without erasing the only existing copy.
- After the transfer, check the conversations and files you need; only then decide whether to retire the old device.
What if I do not have the recovery phrase?
If you still have an authorized device, check only the official options available in that app; do not assume that a new backup can be created without checking the version. If both the device and phrase are lost, Livara’s documentation does not promise key recovery. No “guaranteed decryption” service should be treated as an alternative to this boundary.
Start your account-transfer plan by asking “Which data will be restored, with which key, and from which backup?”—not by assuming that signing back in means getting every chat back.
