Where the seal
ends.
Most security pages are a list of things a product does well. This one starts with the boundary, because the boundary is the only part you cannot check by using the app for five minutes.
> enforced for every new direct send
A missing hybrid identity on either side stops the message. There is no quiet fallback to something weaker, because a quiet fallback is just a vulnerability with a nicer error message.
Can the server read it?
The same table as the home page, because the answer should not change depending on where you entered the site.
| ITEM | DIRECT 1:1 CHAT | GROUPS & CHANNELS |
|---|---|---|
| Message text | [+] Sealed on your device | [!] Server can read it |
| Photos, video, files | [+] Encrypted before upload | [!] Server can read them |
| Captions and edits | [+] Sealed on your device | [!] Server can read them |
| Who you talked to | [!] Server knows | [!] Server knows |
| When you talked | [!] Server knows | [!] Server knows |
| Your password | [+] Never leaves your device | [+] Never leaves your device |
| Your private keys | [+] Never leave your device | [+] Never leave your device |
note routing, membership, timestamps, delivery state and ciphertext are stored so your devices can synchronise.
note that storage is what makes reconnect recovery possible. It is a trade, and this is the side of it you are paying.
How one direct message gets its key
Two independent secrets are mixed. A classical one that is well understood today, and a post-quantum one for the recording-now-decrypting-later problem.
Break one of the two and the other still holds. That is the entire point of a hybrid.
- Private identities are generated on the device and never uploaded in the clear
- The ML-KEM contribution is fresh per message, encapsulated to both participants
- Attachments are encrypted before upload, not encrypted at rest afterwards
- An HMAC-SHA-256 check rides along with the AES-256-GCM ciphertext
Why hybrid: if ML-KEM turns out to have a flaw, P-256 still stands. If a quantum computer eventually eats P-256, ML-KEM still stands. You need both to fail.
Things Livara does not claim
This list exists so you never have to work it out from what is missing elsewhere. If something moves off this list, it will be because it shipped.
- That group and channel messages are end-to-end encrypted. They are not.
- That the server does not know who you message, or when. It does.
- That call media carries post-quantum protection. It does not.
- That your network operator cannot see you connecting to Livara. They can.
- That losing both your device and your recovery phrase is survivable. It is not.
- That an independent audit has been completed. When one is, it will be linked here with a date and a scope.
Getting in, and getting back in
SRP proves the password without moving it
Authentication is a proof of knowledge, not a transmission. The server stores a verifier. Your password does not travel, so a breach of the login path does not hand anyone a password to reuse elsewhere.
The key backup is sealed before it is uploaded
Your P-256 private key and ML-KEM seed are bundled and encrypted on your device with a random 256-bit recovery key, HKDF-SHA-512 and AES-256-GCM. Format v5 binds its version and suite into the authenticated data. Hybrid v4 backups still restore and are upgraded afterwards.
Fingerprints let you check the other end
Public-key fingerprints can be compared with the person you are talking to over some other channel. It takes ten seconds and it is the only way to notice a key that changed when it should not have.
The server still decides who may act
Membership and role checks govern dialogs, uploads, receipts, edits, deletes and realtime actions. This is server authority, not cryptography, and it is listed separately here for exactly that reason.
The four we get asked most
01Which Livara conversations are end-to-end encrypted?
One-to-one direct chats. Every newly sent direct message, edit, caption and attachment requires client-side hybrid ML-KEM-768 and P-256 encryption. Groups and channels use authenticated server storage and TLS, and their content is readable by the server. Livara does not describe them as end-to-end encrypted.
02If I sign in on a new phone, do my direct-chat keys come back?
Not by themselves. The encrypted key backup can only be opened with the recovery key represented by your recovery phrase. A correct password is not enough. This is deliberate: if a password alone could restore your keys, then a password alone could hand them to someone else.
03Does Livara hide who I talk to?
No. The platform stores routing, membership, timestamps, delivery state and direct-chat ciphertext so devices can synchronise. Livara makes no metadata-hiding claim, and any messenger that makes one while also giving you instant multi-device sync is worth a second look.
04Why not just encrypt group chats the same way?
Because doing it properly means solving key distribution for a membership list that changes, on devices that are frequently offline, without silently weakening the guarantee when someone joins. Livara has not shipped that yet, so it does not claim it yet. Group content today is protected by TLS in transit and by server-side membership and role checks.
Now go and check it
Read the longer explanations, or open the client and compare a key fingerprint with someone. The second one takes less time.