DIRECT CONVERSATIONS
Ciphertext reaches the server.
New one-to-one message bodies, edits, captions, and attachments are encrypted on a participant device before upload.
CLIENT-SIDE E2EE DIRECT-MESSAGE SECURITY
How Livara protects direct messages
New direct messages and media require hybrid ML-KEM-768 and P-256 encryption on participant devices. This page documents the protocol and its limits.
ENFORCED FOR NEW DIRECT SENDS
Hybrid direct-chat profile
CLASSICALP-256
POST-QUANTUMML-KEM-768
CONTENTAES-256-GCM
THE TRUST BOUNDARY
Direct chats are E2EE. Groups and channels are not.
Conversation types have different storage and trust models. This distinction defines which content the server can process and which content remains encrypted for participants.
GROUPS & CHANNELS
The server enforces access.
Membership, roles, authenticated storage, and HTTPS/WSS protect these spaces. Their message bodies are available to the server.
TLS + SERVER ROLES DIRECT-CHAT PIPELINE
How Livara derives a direct-message content key
A new direct send combines classical ECDH and a fresh post-quantum contribution before deriving the key material used for content encryption.
- Private identities remain on participant devices
- Missing hybrid identities block new direct sends
- Media is encrypted before storage
CLASSICAL SECRETP-256 ECDH
+Independent device identity
POST-QUANTUM CONTRIBUTIONML-KEM-768
↓Fresh two-recipient encapsulation
DERIVED CONTENT KEYHKDF-SHA-256 → AES-256-GCM + HMAC
IDENTITY & RECOVERY
Authentication, key recovery, and identity verification
These controls protect account access and help users retain or verify their direct-chat identity keys.
SRP verifies the password without sending it.
SRP authentication proves knowledge of the password without transmitting the password itself.
Key backups require the recovery phrase.
The P-256 private key and ML-KEM seed are sealed client-side before backup and require the recovery key to restore.
Key fingerprints support identity checks.
Participants can compare public-key fingerprints through a trusted channel to detect an unexpected identity change.
Server authorization controls account actions.
Server-side membership and role checks govern dialogs, uploads, receipts, edits, deletes, and realtime actions.
QUICK ANSWERS
Frequently asked security questions
01Which Livara conversations are end-to-end encrypted?
New direct one-to-one messages, edits, captions, and attachments require client-side hybrid ML-KEM-768 and P-256 encryption. Groups and channels use authenticated server storage and TLS and are not described as end-to-end encrypted.
02Can signing in alone restore direct-chat keys?
No. A prepared encrypted key backup also requires the recovery key represented by the user's recovery phrase. Losing both the local private identity and recovery phrase can make existing direct-chat ciphertext unrecoverable.
03Does Livara hide all metadata from the server?
No. The platform stores routing, membership, timestamps, delivery state, and ciphertext needed to synchronize direct conversations. Livara does not claim metadata-hiding.
Read the security model, then open Livara Chat
Open the web client or continue to the Learn section for longer technical explanations.