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 | LGS1 sender-key sealed | Server can read it |
| Text edits | Sealed on your device | LGS1 sender-key sealed | Server can read them |
| Photos, video, files, captions | Encrypted before upload | Encrypted before upload | Server can read them |
| Who you talked to | Server knows | Server knows | Server knows |
| When you talked | Server knows | Server knows | Server knows |
| 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 can carry a unique random attachment key, caption and file description, so private-group media is sealed before upload. The server still controls the member list, and channels remain server-readable.
Create
Every member creates a random sender chain and a fresh P-256 signing key for their own messages.
Distribute
That sender key reaches each server-listed member inside an LVR1 pairwise envelope. Livara cannot read the envelope directly, but a compromised service can insert a member before distribution.
Advance
Each text or media-key message consumes one chain position, derives a one-use AES-256-GCM key, and carries the sender's signature.
Rotate
Joining or leaving makes every old sender key stale. Current members mint and distribute new keys before sending again.
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
The long-term answer is MLS — continuous group key agreement with membership integrity, tracked internally as LGS2. It is on the roadmap, and until it ships this paragraph stays on the page, because pretending the gap does not exist would be easier rather than better.
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
- group membership proof against a malicious server
- automatic key transparency
- MLS/SFrame group-call protection
- browser group-call rooms
- post-quantum call media
- protection of an unlocked device
- recovery without the phrase
- hiding that you use Livara at all
- an independent cryptographic audit
- That channel content is end-to-end encrypted. It is a server-readable publication surface.
- That LGS1 protects group membership from a compromised Livara server. It does not; MLS/LGS2 is still a target.
- That the server does not know who you message, or when. It does.
- That group calls use MLS/SFrame, that call media is post-quantum, or that browser clients join group rooms. Android mesh rooms do not make those claims.
- That first-contact keys have automatic transparency. They do not; compare safety numbers for strong identity assurance.
- 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 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?
Direct-chat text and media are end-to-end encrypted. Compatible private groups use LGS1 for text, edits and messages carrying unique attachment keys, so group media and captions are encrypted before upload. Channels, reactions and some control relationships remain server-readable. LVR1/LGS1 are custom and have not completed an independent cryptographic audit.
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. Ordinary delivery exposes sender, destination, membership, timestamps, delivery state and ciphertext size to Livara. Generic mobile push removes private message details from FCM/Expo payloads, but it does not hide the fact that a device received a Livara message.
How does group encryption work, and what does it cover?
Each group member owns an LGS1 sending chain and distributes it to the other members inside pairwise LVR1 sessions. Text and media-key messages are ciphertext to Livara, and an honest membership change requires rotation. The server still supplies the member list; a compromised service can insert an account before redistribution, so LGS1 is not malicious-server group-state protection.
How are direct and group calls protected?
WebRTC DTLS-SRTP encrypts media between peers, while SDP, ICE and screen-share state are sealed pairwise through LVR1/LCS1 signaling. Android supports 2–6-person mesh rooms and screen sharing. This is not MLS/SFrame or post-quantum media protection; Livara still sees call participants and timing, and browser clients do not join group rooms yet.
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.