Where theseal ends.
How encryption works in this private messenger — and where it stops.
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 work out yourself by using the app for five minutes.
> LVR1 direct sessions · LGS1 compatible group text
A missing encryption identity stops a protected send. A new group is not created as encrypted until every member is ready, and an older incompatible group stays visibly outside E2EE instead of borrowing a stronger label.
> the relay still learns the envelope: who, when, how large, and whether it arrived.
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.
| What it is | Direct 1:1 | Groups | Channels |
|---|---|---|---|
| Message text | Sealed on your device | End-to-end sealed (LGS1) | Public broadcast channels |
| Text edits | Sealed on your device | End-to-end sealed (LGS1) | Public broadcast channels |
| Photos, video, files, captions | Encrypted before upload | Encrypted before upload | Public broadcast channels |
| Who you talked to | Routing metadata only | Routing metadata only | Public broadcast channels |
| When you talked | Delivery timestamps only | Delivery timestamps only | Public broadcast channels |
| Your password | Never leaves your device | Never leaves your device | Never leaves your device |
| Your private keys | Never leave your device | Never leave your device | Never leave your device |
note routing, membership, timestamps, delivery state and ciphertext are stored so devices can synchronise.
note that storage is what makes reconnect recovery possible. It is a trade, and this is the side you pay.
How one message gets its key
LVR1 starts with both classical and post-quantum material, then keeps two ratchets moving. Ordinary messages advance cheap one-way chains; periodic ML-KEM epochs refresh the quantum-safe root without carrying a three-kilobyte handshake on every send.
Run the classical half in your browser →Identity
A P-256 private key and an ML-KEM-768 seed, generated on the device, never uploaded in the clear.
Authenticate prekeys
Signed P-256 and ML-KEM-768 prekeys are checked on the client; one-time keys add freshness when available.
Establish
Hybrid X3DH mixes several P-256 agreements with ML-KEM secrets into independent classical and post-quantum roots.
Ratchet
One-way send and receive chains advance after every message; periodic ML-KEM epoch updates refresh the post-quantum root.
Seal
A message key is combined with the current PQ root, then AES-256-GCM encrypts and authenticates the content and header.
LVR1, written out
Named primitives and named parameters, so the claim can be checked rather than felt. Both roots are independent: either one alone still keeps the message closed.
- Classical root
- P-256 ECDH, signed prekeys
- Post-quantum root
- ML-KEM-768, periodically re-keyed epochs
- Establishment
- hybrid X3DH-style, one-time keys when available
- Ratcheting
- independent send and receive chains
- Content cipher
- AES-256-GCM over content and header
- Key custody
- generated on the device, never exported
- Attachments
- per-file random key, carried inside the session
One ciphertext, every member.
Encrypting the same text separately for a large group grows with every member. LGS1 gives each sender one signed chain instead. Its key travels through pairwise LVR1, then one opaque ciphertext can be delivered to the whole group.
The same encrypted application message carries unique random attachment keys, captions, and file descriptions, ensuring all private-group media and voice notes are sealed on your device before upload.
Create
Every member generates a cryptographically secure sender chain and signing key for their own group messages on-device.
Distribute
Sender keys are securely distributed to group members inside pairwise post-quantum LVR1 encrypted sessions.
Advance
Each message derives a single-use AES-256-GCM encryption key from the chain and carries the sender's cryptographic signature.
Rotate
When members join or leave, fresh sender keys are automatically minted and distributed to protect conversation history.
LGS1, written out
Sender chains instead of one copy of every message per member.
- Sender chains
- one signed chain per sender, one message per position
- Key distribution
- sender keys travel inside pairwise LVR1 sessions
- Per-message key
- a one-use AES-256-GCM key, derived per position
- Authentication
- a P-256 signing identity per sender
- Membership change
- old sender keys go stale, members must rotate
- Covers
- text · edits · captions · filenames · attachment keys
Every group message is authenticated and encrypted with high-performance symmetric cryptography, combining rapid delivery with zero server access to your plaintext.
Read the full threat model →Encryption protects content. It does not hide the graph.
Livara stores and processes operational metadata. Saying so plainly is the cost of the sync that makes a second device work at all.
| the server sees | the server stores | the server never sees |
|---|---|---|
| who communicates with whom | message records, as ciphertext | message plaintext |
| group membership and dialogs | LVR1 and LGS1 ciphertext | media bytes, encrypted before upload |
| timestamps and ciphertext sizes | receipts, reactions, edits | captions and filenames |
| delivery state and routing | a sync cursor per account | attachment keys |
| that you connect to Livara | push tokens and security records | your password — SRP proof only |
LSS1, the metadata-protection code, exists but is not wired into ordinary message sending yet. When it is, this table gets shorter — and this paragraph will change on the day it does, not before.
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 — not because the wording got better.
Not promised — today
ten items, straight from the published threat model
- metadata anonymity
- channel end-to-end encryption (channels are public broadcast streams)
- browser group-call rooms (Android supports 2–6 person rooms)
- protection of an unlocked/compromised device
- recovery without your recovery phrase
- hiding your connection to Livara from your network provider
- That channel content is private. Channels are public broadcast streams by design.
- That the server does not store basic routing metadata required for real-time delivery and sync.
- That losing both your physical device and your recovery phrase is recoverable. Your recovery phrase is required to restore your encrypted key backup.
- That safety numbers should never be checked. Comparing safety numbers provides physical verification of encryption keys.
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 on your email.
The key backup is sealed before it is uploaded
Your P-256 agreement key, P-256 signing key and ML-KEM seed are encrypted on your device under a random 256-bit recovery key. Format v7 authenticates its suite, identity epoch and backup generation. It restores identity, not chat history; a new device still needs transparency to detect a full server rollback.
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.
password never leaves the device proof computed locally, exchanged with the server server holds a verifier, not your password result authenticated — and the wire never carried the secret identity a username. not a SIM, a carrier or a country.
SRP is separate from the message encryption above it. Breaching the login path does not hand anyone a password to reuse on your email, and it does not open a single message either.
The four we get asked most
Which Livara conversations are end-to-end encrypted?
All one-to-one direct messages and private group conversations are fully end-to-end encrypted on your device. Direct chats use the hybrid post-quantum LVR1 ratchet, while private groups use LGS1 sender-key encryption for all messages, text, edits, photos, videos, files, and voice notes. Keys are generated and stored exclusively on user devices.
If 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.
Does Livara hide who I talk to?
No. Like all modern messaging infrastructure, standard delivery routes encrypted packets using sender, destination, and delivery timestamps. Generic mobile push removes all private message details and names from push notifications.
How does group encryption work, and what does it cover?
Each group member creates a unique cryptographic sender chain and securely shares sender keys with group members over pairwise-sealed sessions. All group text, edits, media, files, and voice notes are encrypted on the sender's device before transmission. When members join or leave, keys are automatically rotated for forward and backward secrecy.
How are direct and group calls protected?
Direct calls and 2–6-person Android group rooms use WebRTC DTLS-SRTP peer media encryption with pairwise-sealed signaling for audio, video, and screen sharing.
Now go and check it
Read the longer explanations, run the instruments in the Proof Lab, or open the client and compare a key fingerprint with someone. The last one takes about ten seconds.