The question behind the term
Encryption becomes end-to-end only when plaintext and the keys needed to read it stay with intended participant endpoints. TLS protects a network hop, and server-side encryption protects storage, but both leave a service boundary able to read content.
A reviewable approach
Document key creation, identity verification, message-key derivation, authenticated encryption, attachment handling, rotation and recovery. Pair the protocol with user states for missing keys, changed fingerprints and unrecoverable history.
- Define the endpoint and adversary
- Authenticate ciphertext and context
- Fail closed when required identities are missing
- Test recovery and key rotation across clients
The boundary to keep visible
E2EE does not prove endpoint safety, erase metadata or make every conversation type equivalent. Hybrid cryptography also needs implementation review; naming a post-quantum primitive is not an independent security guarantee.
What end-to-end encryption actually means
End-to-end encryption (E2EE) means the sender encrypts content before it leaves their device and only the intended recipients have the keys needed to decrypt it. The transport and storage service carries ciphertext. HTTPS still matters, but HTTPS alone protects a connection to the server; a server that decrypts messages is an endpoint of that connection.
Ask where plaintext appears, who can obtain the content keys, and what happens when a new device joins. A system can encrypt its database and network traffic while still letting its operator read messages. Those are useful controls, but they answer a different question.
Keys, identity and a message in flight
A typical message path is: authenticate the recipient’s device identity, establish or update a shared secret, derive a fresh message key, encrypt and authenticate the content, then deliver ciphertext. Authenticated encryption also detects changes to protected content; it does not tell you whether the public key really belongs to the person you intended to contact.
That last question needs identity verification. Compare a safety number or key fingerprint through a separate trusted channel, especially after a key change. A familiar display name is not a cryptographic identity. After a device replacement, the product also needs an honest answer about which older messages and keys can be recovered.
Where encryption stops
E2EE protects message content in a defined conversation mode. It does not hide that an account connected, which accounts exchanged traffic, when delivery occurred, or the approximate size of ciphertext. A compromised or unlocked device can expose content after decryption. A recipient can also copy or forward what they receive.
Check every mode separately: direct chats, private groups, public channels, calls, recordings, backups, search and notifications can have different readers. A single “encrypted” badge cannot describe all of them. For example, Livara Chat documents LVR1 for direct content and LGS1 for compatible private groups; its public channels remain server-readable. Optional server recording changes the call boundary and is presented as a separate mode.
Post-quantum keys are one part of the design
ML-KEM-768 is a standardized key-encapsulation mechanism, not an encryption algorithm for the whole message. In Livara Chat’s published direct-message design, its contribution is combined with classical P-256 material in LVR1. A hybrid design aims to avoid relying on one family of key-establishment assumptions; it still depends on correct identity binding, key handling, implementation and endpoint security.
A standard’s name does not certify an application. Evaluate the exact released build, protocol specification, recovery behavior and independent review status separately. Livara does not claim an independent product security audit on these pages.
References and further reading
Frequently asked questions
Is HTTPS the same as end-to-end encryption?
No. HTTPS protects the connection to a server. E2EE also keeps the content keys with the intended participant devices, so the service need not decrypt message content.
Does E2EE hide messaging metadata?
No. Account, routing, membership, timing and ciphertext-size data can remain visible to a service even when it cannot read protected message content.
What should I check after a contact changes devices?
Check the product’s key-change notice, compare the new fingerprint using a separate trusted channel, and confirm what history or backup can be recovered.