Livara security: Where the seal ends.
Livara 0.2 · nothing rounded up
How Livara protects message content, what metadata remains visible, and where recovery and device security place limits on that protection. The custom LVR1 and LGS1 protocols have not undergone an independent security audit.
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?
This table describes message delivery. Separate AI processing is covered by the privacy policy and the controls for the client you use.
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 | Compatible 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 uploaded unencrypted | Never uploaded unencrypted | Never uploaded unencrypted |
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
The primitives and parameters below describe the design. Using established components does not independently validate the security of the complete protocol.
- 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; recovery backups are encrypted before upload
- 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.2
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 for delivery and sync. This table describes protected message delivery, not separate AI processing. Before using AI with chat content, check the controls and privacy policy for the client you use.
| The server sees | The server stores | Not readable in protected message delivery |
|---|---|---|
| Who communicates with whom | Message records, as ciphertext | Message plaintext |
| Group membership and dialogs | LVR1 and LGS1 ciphertext | Decrypted media content |
| 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 metadata-protection code exists, but it is not connected to ordinary message sending. Do not count it as an active protection for current messages.
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
During SRP authentication, your device proves knowledge of the password without transmitting the password itself. The server stores a verifier. This does not protect a compromised device or client.
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 trusted channel. If they differ unexpectedly, verify the change before sharing sensitive information.
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 authentication is separate from message encryption. A password alone cannot unlock the encrypted identity backup; restoring it requires your recovery phrase. A compromised device or client remains outside these protections.
Questions
The five we get asked most.
Which Livara conversations are end-to-end encrypted?
Direct messages and compatible private-group conversations are end-to-end encrypted on your device. Direct chats use the hybrid post-quantum LVR1 ratchet; compatible private groups use LGS1 sender keys for text, edits, photos, videos, files and voice notes. Older incompatible groups remain visibly outside E2EE.
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 use end-to-end encryption for 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 demonstrations in the Proof Lab, read the security explanations, or open the app and compare a key fingerprint with your contact over another trusted channel.