Livara security: Where the seal ends.
Livara 0.1.68 · nothing rounded up
How encryption works in this private messenger — and where it stops. Most security pages list what a product does well; this one starts with the boundary, because it is the one part you cannot work out by using the app for five minutes.
The primitives
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.
01 · The boundary
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.
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.
| What it is | Direct 1:1 | Private 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 |
02 · Direct chats
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.
LVR1, written out
Named primitives and parameters, so the claim can be checked rather than felt. Either root 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
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.
Create
Every member generates a sender chain and signing key for their own group messages, on their device.
Distribute
Sender keys travel to the other members inside pairwise post-quantum LVR1 sessions.
Advance
Each message derives a single-use AES-256-GCM key from the chain and carries the sender's signature.
Rotate
When members join or leave, fresh sender keys are minted and distributed.
03 · Private groups in 0.1.68
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 reaches the whole group — with unique attachment keys, captions and filenames sealed inside.
LGS1, written out
- 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 rotate
- Covers
- Text · edits · captions · filenames · attachment keys
04 · The uncomfortable part
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 changes on the day it does, not before.
05 · Disclosure
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 it, that is because it shipped — not because the wording got better.
Not promised today
Six items, straight from the published threat model.
- Metadata anonymity
- End-to-end encryption for channels — they are public broadcast streams
- End-to-end encryption while optional server recording is active
- Protection of an unlocked or compromised device
- Recovery without your recovery phrase
- Hiding your connection to Livara from your network provider
Claims we refuse to make
Phrased the way a marketing page would want to say them, then crossed out.
- That channel content is private. Channels are public broadcast streams by design.
- That the server does not store the routing metadata required for real-time delivery and sync.
- That losing both your device and your recovery phrase is recoverable.
- That safety numbers never need checking. Comparing them is how you verify a key in person.
06 · Identity
Getting in, and getting back in.
SRP proves the password without moving it
Sign-in is a proof of knowledge, not a transmission. The server stores a verifier, so a breach of the login path does not hand anyone a password to reuse on your email.
The key backup is sealed before upload
Your P-256 agreement and signing keys and ML-KEM seed are encrypted on your device under a random 256-bit recovery key. Format v7 authenticates its suite, identity epoch and generation. It restores identity, not chat history.
Fingerprints let you check the other end
Compare public-key fingerprints with the person you talk to over another 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. That is server authority, not cryptography — listed separately 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.
Questions
The five we get asked most.
Which Livara conversations are end-to-end encrypted?
All one-to-one direct messages and private group conversations are end-to-end encrypted on your device. Direct chats use the hybrid post-quantum LVR1 ratchet; private groups use LGS1 sender keys for text, edits, photos, videos, files and voice notes. Keys are generated and kept 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 opens only with the recovery key represented by your recovery phrase. A correct password is not enough — deliberately: if a password alone could restore your keys, a password alone could hand them to someone else.
Does Livara hide who I talk to?
No. Delivery routes encrypted packets using sender, destination and timestamps, and that routing metadata is stored so your devices can sync. Mobile push notifications for encrypted messages carry no message details or names.
How does group encryption work, and what does it cover?
Each member creates a sender chain and shares its key with the other members over pairwise-sealed LVR1 sessions. Group text, edits, media, files and voice notes are encrypted on the sender's device before they leave it. When members join or leave, keys rotate.
How are direct and group calls protected?
Direct and group calls are end-to-end encrypted, including rooms with more than 500 participants, with audio, video and screen sharing. Optional server recording is a separate mode: while the visible REC state is on, the call uses transport encryption instead of E2EE.
Do not take this page on faith
Now go and check it.
Run the instruments in the Proof Lab, read the longer explanations, or open the app and compare a key fingerprint with someone. The last one takes about ten seconds.