A lock icon is not a privacy model. Real privacy begins by knowing what is encrypted, where the keys live, and where the protection ends
A lock icon can make any messaging app look secure. But what does it actually protect?
End-to-end encryption—usually shortened to E2EE—is one of the most important technologies in private communication. It can prevent a message from being exposed while it travels through networks and servers. But it does not automatically hide every piece of information about a conversation, secure an infected device, or stop the recipient from sharing what you sent.
Understanding that boundary matters.
This guide explains how end-to-end encryption works, what it protects, what it cannot protect, and how Livara applies client-side encryption to direct conversations.
What is end-to-end encryption?
End-to-end encryption is a method of protecting information so that it is encrypted on the sender’s device and decrypted only on a participating recipient’s device.
In a properly designed E2EE conversation, the message does not leave the sending device as readable plaintext. It leaves as ciphertext: scrambled information that should be unusable without the correct cryptographic key.
The messaging service still helps deliver and synchronize the encrypted data, but the direct-message content is protected before it reaches that service.
The two “ends” are the participant devices.
That is the central difference between end-to-end encryption and ordinary transport encryption.
How does E2EE work?
The mathematics can be complex, but the basic journey of a message is understandable.
1. Each participant has cryptographic keys
A secure messaging client creates or stores cryptographic key material on the user’s device.
Some keys may be shared publicly. Private keys must remain protected because they help the device establish or recover the secret information required to decrypt messages.
2. The devices establish shared message secrets
The participants exchange the public information needed to derive matching secrets.
The secret itself should not need to be transmitted as readable data. Each device independently performs the required cryptographic operations.
3. The message is encrypted locally
When the sender taps Send, the application encrypts the message on the sending device.
The readable sentence becomes ciphertext before being uploaded or relayed.
4. The server delivers ciphertext
The messaging infrastructure routes the encrypted message to the recipient and may retain ciphertext to support synchronization, delivery, and multiple authorized devices.
The server still performs important operational work. E2EE changes the form of the message content the server handles.
5. The recipient decrypts it
An authorized recipient device uses its cryptographic material to authenticate and decrypt the ciphertext.
The readable message appears again only at the destination endpoint.
What does end-to-end encryption protect?
E2EE is primarily designed to protect the content of a conversation.
Depending on the application and implementation, that content may include:
- Direct text messages
- Photos and videos
- Voice messages
- Documents and attachments
- Audio or video calls
- Message edits and replies
When this content is encrypted correctly on the client, an attacker intercepting network traffic should see encrypted data instead of the original message.
It also reduces the amount of readable conversation content available to the service infrastructure.
But “encrypted” should never be treated as a magic word. Users deserve to know exactly which conversation types and content paths are covered.
What E2EE does not automatically protect
End-to-end encryption is powerful, but its boundary is often misunderstood.
Message metadata
A system may need operational information to route and synchronize messages.
Depending on the service, this can include:
- Which account sent a message
- Which conversation received it
- When the message was sent
- Delivery and read status
- Conversation membership
- Encrypted message size
- Device or session information
The message body may be unreadable while some information surrounding the message remains available to the system.
This is why “message content is encrypted” and “the service collects no metadata” are separate claims.
A compromised device
Encryption cannot protect a message after malware, an unsafe browser extension, or another attacker gains control of an unlocked endpoint.
The message must eventually become readable on an authorized device. An attacker controlling that device may be able to see what its owner sees.
Device security remains essential:
- Install operating-system updates
- Use a strong device passcode
- Review browser extensions
- Protect account recovery information
- Avoid unknown applications and downloads
The recipient’s actions
E2EE cannot prevent a participant from copying, forwarding, photographing, or taking a screenshot of a message after it has been decrypted.
Encryption protects delivery between endpoints. It does not control the person at the other endpoint.
Account recovery mistakes
Recovery systems must balance security and usability.
A weak recovery process can undermine strong encryption. On the other hand, a system that never allows recovery may make encrypted history permanently inaccessible when a key is lost.
A trustworthy application should explain how recovery works, what information is backed up, and what happens when recovery credentials are lost.
E2EE and TLS are not the same thing
Most modern websites use HTTPS and TLS to protect traffic between a browser and a server.
That is important. It helps prevent people on the same network or elsewhere in transit from casually reading or modifying the connection.
But TLS normally protects information only while it travels between the client and the service.
With standard server-readable messaging:
- Your device encrypts the network connection.
- The server receives and processes readable message content.
- The server opens a separate protected connection to the recipient.
With end-to-end encryption, the message itself is encrypted for the participants before it is placed inside the protected network connection.
A simple comparison:
| Protection | TLS-only messaging | End-to-end encryption |
|---|---|---|
| Protects data in network transit | Yes | Yes |
| Message encrypted before upload | Not necessarily | Yes |
| Server may process plaintext content | Yes | Direct-message content should remain ciphertext |
| Endpoint security still required | Yes | Yes |
| Metadata automatically hidden | No | No |
|
TLS and E2EE are not competitors. A private messaging system generally needs secure transport and correctly implemented content encryption.
How Livara protects direct conversations
Livara applies client-side encryption to direct one-to-one message bodies and media.
The current direct-chat design uses:
- P-256 ECDH for key agreement
- HKDF-SHA-256 for deriving context-separated keys
- AES-256-GCM for authenticated message encryption
- HMAC-SHA-256 as an additional integrity check
- Client-side encryption for direct media before storage
- Public-key fingerprints that participants can compare
- An encrypted private-key backup protected by a recovery phrase
In a direct chat, the sender’s device encrypts the content before upload. A participant device decrypts it after retrieval.
The service still retains information needed to operate the conversation, such as routing, membership, timestamps, receipts, and ciphertext. Being explicit about this boundary is part of responsible security communication.
You can inspect the current implementation boundary on the Livara Security page or read the definitions in Livara Learn.
Are Livara group chats end-to-end encrypted?
Not currently.
Livara’s present security documentation distinguishes between conversation types:
- Direct one-to-one chats: message bodies and media use client-side end-to-end encryption.
- Groups and channels: content is protected in transit with HTTPS/WSS and controlled through authenticated server-side membership and roles, but is not currently claimed as E2EE.
This distinction matters.
A user should never have to guess whether a lock icon applies to one conversation, every conversation, only text, or text and media. Precise limits are more valuable than vague promises.
Why public-key fingerprints matter
An encrypted conversation depends on communicating with the intended key—not merely any key presented by the system.
A public-key fingerprint is a compact representation of a participant’s public key. Two people can compare their fingerprints through another trusted channel, such as an in-person conversation or a verified call.
Matching fingerprints provide additional confidence that the expected keys are being used.
A changed fingerprint does not automatically prove an attack. It may happen after a legitimate key reset or device recovery. But the change should be visible and explainable rather than silently ignored.
How encrypted recovery works in Livara
Livara allows users to save an encrypted backup of their direct-chat private key.
The backup is encrypted on the client and protected by a recovery phrase. Signing in to an account alone is not sufficient to restore that private key.
This creates an important responsibility:
Keep the recovery phrase somewhere safe and separate from the device.
Losing both the device key and the recovery phrase may make previously encrypted direct-chat content unrecoverable.
That is not a cosmetic inconvenience. It is a real consequence of preventing ordinary account access from automatically unlocking private keys.
How to evaluate a private messaging app
Do not judge a messaging service only by the words “encrypted” or “secure.”
Ask specific questions.
Which conversations are E2EE?
Check whether the protection applies to direct chats, groups, channels, calls, and attachments.
Where are keys generated and stored?
Look for a clear explanation of whether keys are created on the client and how backups are protected.
What does the server retain?
A responsible service should distinguish message content from routing, timestamps, membership, delivery information, and other operational data.
What happens when keys change?
Unexpected key replacement should be visible. Silent key changes weaken the user’s ability to verify contacts.
How does recovery work?
Determine whether the provider can restore keys, whether a recovery secret is required, and what happens when that secret is lost.
Are the claims independently verified?
Security documentation, open protocols, professional reviews, and independent audits provide different levels of assurance.
Marketing language alone is not an audit.
Privacy depends on clear boundaries
The strongest privacy statement is not “trust us.”
It is a precise, testable explanation of:
- What is encrypted
- Where encryption happens
- Which keys are involved
- What the server receives
- What metadata remains
- Which conversation types are excluded
- How recovery changes the threat model
End-to-end encryption is not the whole privacy story. But when it is implemented carefully and described honestly, it is a critical foundation for private communication.
Livara’s goal is to make those boundaries understandable rather than burying them behind a lock icon.
Explore the technical details on Security, see how synchronization works on Features, or open Livara Chat in your browser.
Frequently asked questions
What does E2EE stand for?
E2EE stands for end-to-end encryption. It means protected content is encrypted at one participant endpoint and decrypted at another authorized endpoint.
Can an internet provider read E2EE messages?
An internet provider may be able to observe that a connection exists and see certain network-level information, but correctly encrypted message content should not appear as readable plaintext in transit.
Does end-to-end encryption hide metadata?
Not automatically. A messaging system may still process routing, membership, timestamps, delivery state, ciphertext size, or other information required to operate the service.
Can E2EE protect a stolen unlocked phone?
No encryption protocol can fully protect a message when an attacker controls an already-authorized and unlocked device. Strong device security remains necessary.
Are all Livara conversations end-to-end encrypted?
Livara currently documents E2EE for direct one-to-one message bodies and media. Groups and channels presently use TLS and authenticated server-side permissions and are not claimed as end-to-end encrypted.
Can a lost Livara encryption key be recovered?
A user who previously created a protected key backup can restore it with the recovery phrase. Losing both the private key and recovery phrase can make existing direct-chat ciphertext inaccessible.
