Recovering an account, an identity and a conversation history are different operations; verify which one the product actually supports.
Cryptographic identity recovery restores key material associated with your messaging identity. It is not automatically the same as signing back into an account, restoring every conversation, or proving that a replacement device is safe.
An encrypted key backup can let a server store a recoverable package without possessing the secret needed to open it. Whether that design protects the user depends on key generation, authentication, recovery-secret custody and how the client handles the recovered identity.
Three things people call “recovery”
| Recovery goal | What must be restored or authorized |
|---|---|
| Account access | Permission to sign in and use the service |
| Cryptographic identity | The appropriate private keys or a new authenticated identity |
| Chat history | Message data and whatever keys/state are required to read it |
A successful login proves neither of the other two. Similarly, an identity key does not necessarily recreate old message keys that were deliberately erased or a history file that no longer exists.
Write down which goal a product’s recovery feature actually promises before relying on it.
How an encrypted identity backup can work
A typical design generates identity material on a trusted device, encrypts a backup under a separate recovery secret, and stores only the protected package with the service. A replacement device retrieves the package and uses the recovery secret locally.
The server may still control access to the package, observe requests, withhold data or return an older version. Authenticated encryption and version/identity binding help address particular tampering risks; availability and rollback handling need their own design. “Encrypted on the server” is not a complete answer to every server-compromise scenario.
A random high-entropy recovery key and a human-chosen password are also different inputs. Do not describe HKDF as a method that turns any weak passphrase into a strong secret. RFC 5869 discusses HKDF’s role and distinguishes it from password stretching.
What Livara’s v7 documentation says
Livara’s security page says its P-256 agreement/signing keys and ML-KEM seed are encrypted on the device under a random 256-bit recovery key before upload. The v7 format authenticates information including the suite, identity epoch and generation.
The same page is explicit: it restores identity, not chat history. It also says a correct login password alone is insufficient to open the encrypted key backup; the recovery key represented by the recovery phrase is required.
These are published product claims, not a fresh audit of the backup format or every recovery path. The more general threat model should be read together with this narrower recovery description.
Where SRP fits
The SRP authentication model concerns password-based login. It can avoid transmitting the password itself in the intended protocol exchange, but it does not define the contents of a key backup or automatically derive every recovery key.
Its server-side verifier still requires protection. RFC 5054, section 3.3 describes password-guessing risk after a verifier is stolen. Do not translate “the server does not receive the password in this exchange” into “a server breach cannot expose anything useful.”
Account sessions, recovery packages, operational metadata and client software are separate assets with separate failure modes.
A safe recovery preparation checklist
- Confirm exactly which data the feature restores and which data it does not.
- Keep the recovery secret where losing the phone does not also mean losing the only copy.
- Avoid putting the secret in a message, support ticket or public screenshot.
- Protect the place where the secret is stored; anyone who obtains it may gain important capabilities if they also obtain the relevant backup and access.
- Review official recovery instructions before wiping or replacing the only working device.
- Test only through supported procedures, without destroying the sole copy of important data.
After recovery, inspect linked devices and sessions separately. Recovered identity material does not automatically revoke an old device. If the cryptographic identity changes, sensitive contacts should verify the new key through an independently trusted route.
If the recovery phrase is lost
Do not assume support can recreate a secret the system was designed not to retain. Equally, do not assume every forgotten account password means all local messages are already gone. Outcomes depend on surviving devices, available backups and the product’s documented rules.
The useful question is specific: “Which secret or copy is missing, and which recovery goal remains possible?” That produces a safer answer than a blanket promise that recovery is either effortless or impossible.
