Security
How Lewo encryption works
Lewo is a private messenger. Your one-to-one chats, group chats, private channels, business chats, voice and video calls, and the media you share in them are protected with end-to-end encryption (E2EE). Public channels are the deliberate exception — they are broadcasts to an unlimited audience, encrypted in transit and at rest rather than end to end. This page explains how that works, what we can see, and — just as importantly — what our encryption does not yet protect against.
What end-to-end encryption means
End-to-end encryption is like sending a letter inside a locked box where only you and the person you're writing to hold a key. The courier — in this case Lewo's servers — carries the box but cannot open it. Your message is encrypted on your device before it leaves, travels as unreadable data, and is decrypted only on the recipient's device.
Because the private keys that unlock your messages are kept on the devices involved, someone who intercepts your network traffic or steals our stored data sees only ciphertext. If we were legally compelled to hand over your private messages, we could only provide encrypted data we cannot decrypt — we don't hold the keys. Two honest caveats: our servers manage who is in a group or channel and which devices are linked to an account, so for those you are partly trusting us not to add an unauthorized member or device; and to be certain no one is impersonating a contact, you can compare a safety number with them. See the threat model for the full picture.
What's encrypted, and what the server sees
The content of your private communication is end-to-end encrypted. To deliver it, our servers necessarily handle some routing information (metadata). Here's an honest breakdown.
| End-to-end encrypted (we can't read it) | Visible to the server |
|---|---|
| Text of your messages | Who you're messaging, and which conversation a message belongs to |
| Photos, videos, voice messages and documents | When a message was sent, delivered and read (timestamps, receipts) |
| Attachment file names and file types | The approximate size of an attachment (sizes are padded into buckets) |
| Link previews (fetched by the sender's device, then encrypted) | Which message a reaction is attached to — and, from older app versions, the reaction emoji |
| Voice and video call audio and video | That a call happened, between whom, and when |
| Group, private channel and business (B2C) message content | Group and channel membership, and your linked devices |
| Reaction emoji (from current app versions) | Your public keys, your profile, and an approximate region or language |
Link previews are fetched by the sender's device, so the linked website sees that device's IP address, as it would if you opened the link.
The server stores end-to-end encrypted message content only as ciphertext. It never holds the plaintext of those messages, your private keys, or the per-message keys used to decrypt them. Push notifications for encrypted chats say only "New message" and which conversation to open — never the content.
The protocol we use
Lewo's encryption follows the well-studied design pioneered by the Signal protocol — it is an independent implementation of X3DH and the Double Ratchet written by Lewo, not the Signal app's own library. It combines two building blocks:
X3DH — establishing a shared secret
When you first start an encrypted conversation, your device and your contact's device run an Extended Triple Diffie-Hellman (X3DH) key agreement. Each side combines several public keys to independently derive the same shared secret — without that secret ever being transmitted. One side can begin while the other is offline, because the necessary public keys are published in advance.
Double Ratchet — a fresh key for every message
From that shared secret, the Double Ratchet derives a unique key for every message and moves forward after each one. This gives two guarantees:
- Forward secrecy. Used message keys are discarded and cannot be re-derived, so compromising your device today does not expose messages it had already decrypted and deleted keys for.
- Post-compromise security. One-to-one conversations started on current versions of the app regularly mix in fresh key material, so they "heal" after a temporary compromise. Groups and channels use sender keys (below), which recover only when those keys are rotated.
Each message is sealed with authenticated encryption (AEAD) using XChaCha20-Poly1305. The Poly1305 authentication tag means any tampering with a message in transit causes it to be rejected rather than silently accepted. Message counters provide replay protection. Key agreement uses X25519 and signatures use Ed25519. Our cryptographic primitives come from the @noble libraries (@noble/curves, @noble/ciphers, @noble/hashes), each of which has been audited by an independent security firm. Lewo's own protocol code built on top of them has not yet had an independent audit.
Groups, channels and calls
Group chats
Groups use a sender-key approach: each member encrypts a message once with their own sending key, which is distributed to the other members over the encrypted one-to-one channel. When a member leaves or is removed, our servers instruct the remaining members to rotate: each member discards its sending key and creates a new one before its next message, so the former member cannot read messages sent after that. Group rosters are signed by admins, and members refuse sender keys from anyone not on a valid signed roster — but this does not yet stop a member added by a malicious server from receiving new messages (see the threat model).
Channels
Channels come in two kinds, and your app shows you which one you are reading. Posts in a private or approval-only channel are end-to-end encrypted with a sender key and signed with the channel's Ed25519 admin signing key, so before decrypting, a reader's app verifies each post was signed by the channel's admin key and was not altered. (The admin key is distributed through our servers, so this authenticates the key we vouch for rather than proving the admin's real-world identity.)
A public channel is not end-to-end encrypted, and we don't pretend otherwise. It is a broadcast to an unlimited audience, so its posts are encrypted in transit and at rest on our servers under a key we hold — which means we can read them, and can act on them when they are reported.
Voice and video calls
Call media is end-to-end encrypted: audio and video are encrypted with DTLS-SRTP directly between the participants' devices. Group calls connect each participant to every other one (up to 8 for video, 16 for audio) — there is no media server that decrypts them. When a direct connection isn't possible, the encrypted media is relayed through our TURN server, which cannot decrypt it. Call setup is relayed by our servers and is not itself end-to-end encrypted; it is signed with Ed25519, and that signature covers the encryption fingerprint, so a tampered setup is rejected. The app marks a call as verified only when the signature matches your contact's identity key; otherwise the call still connects but is shown as unverified.
Business messages (B2C)
Messages with businesses use the same end-to-end-encrypted protocol as private chats.
Keys and where they live
Your private keys are generated on your device and never sent to our servers. Only public keys are uploaded, so other people can start an encrypted session with you.
| Key type | Role |
|---|---|
| Identity key | Your long-term identity: an X25519 key for key agreement and an Ed25519 key for signing. |
| Signed pre-key | A medium-term key, signed by your identity key, used to set up new sessions and rotated periodically. |
| One-time pre-keys | Single-use keys that strengthen forward secrecy for the first messages of a conversation, replenished automatically. |
| Per-message keys | Derived fresh for each message by the Double Ratchet and discarded after use. |
On iOS and Android, private keys are kept in the device's protected key storage — the Keychain on iOS and the Keystore on Android — guarded by your device's passcode and biometric lock.
In the web app, a browser has no equivalent hardware-backed store, so private keys are kept in your browser's local storage for web.lewohq.com, with an integrity check against tampering. They still never leave your device, but they are not hardware-protected: anyone — or any malicious browser extension — with access to that browser profile could read them. Use the web app only on a computer you trust, and sign out on shared machines.
Because keys live only on your devices, losing or wiping a device means we cannot recover its message history for you (unless you made an encrypted backup), and your contacts will see a notice that your security keys changed when you set up again.
Linked devices and backups
Linked devices
You link a new device by scanning a QR code with your primary device, which runs an encrypted key exchange between the two. Your primary device signs each linked device. Once a contact uses signed devices, your app refuses to encrypt to any of their devices that lacks a valid signature; for contacts who have never linked a signed device, an unsigned device is flagged but still receives messages. History moved to a new device travels end-to-end encrypted between your own devices.
Encrypted chat backups
Chat backups are optional (Settings → Chat Backup) and end-to-end encrypted. Each backup is encrypted under a fresh random key, which is wrapped to a key derived from your Backup Master Secret — a secret only you hold and export yourself. Backups are signed with Ed25519 so your device can detect a forged or altered backup. We store the encrypted backup but cannot decrypt it; if you lose your Backup Master Secret, we cannot recover the backup for you.
Verifying who you're talking to
To be certain you're really talking to the right person — and not an impostor in the middle — open a chat's encryption settings and compare its safety number (a fingerprint of both of your keys) with your contact in person, by scanning their QR code, or over a channel you trust. If the numbers match, the connection is verified. It's especially worth checking when you see a "security keys changed" notice you didn't expect.
What is not end-to-end encrypted
- Public channels — readable by us, as explained above.
- Lewo AI — messages you send to the Lewo AI assistant are processed on our servers and are not end-to-end encrypted. We do not feed your end-to-end encrypted chats to it.
- Bots — messages to and from bots are not end-to-end encrypted, and the app says so in its bot settings.
- Public content — posts, profiles, marketplace listings, jobs and Lewo Websites are public or semi-public by design. They are protected in transit (TLS) but not end-to-end encrypted.
- Contact discovery — to find which of your contacts use Lewo, the app sends hashed phone numbers. Phone numbers are easy to guess, so treat these hashes as visible to us, not secret.
What we don't do
- We never use the content of your end-to-end-encrypted messages or calls for advertising, profiling, or to train models.
- We do not store the plaintext of your end-to-end encrypted messages on our servers — only ciphertext we cannot read.
- We do not sell your private messages, your media, or your contacts.
- We do not hold copies of your private keys (no key escrow), and we have no backdoor to decrypt your conversations.
- We do not silently turn off encryption on your conversations.
Ads and end-to-end encryption
Lewo is free and supported by ads. Ads are never targeted using the content of your private messages, calls or shared media — that content is end-to-end encrypted and unreadable to us and to advertisers. We serve ads ourselves, based only on limited non-content signals such as device type, app version, and a coarse region and language. We do not use your device's advertising identifier (Android Advertising ID / Apple IDFA), we do not track you across other apps or websites, and we do not share your personal data with third-party advertising networks. For full details see our Privacy Policy.
Open-source encryption core
The core of Lewo's encryption — key agreement, the Double Ratchet, sender keys, channel-post sealing, backups and device signing — is published at github.com/Hamzakfareed/lewo-e2ee-core under the GPL-3.0 licence, with its test suite, so anyone can read it and run the tests. To be precise: it is the cryptographic core that is published, not the whole app, and it is updated from the app's code periodically rather than on every release.
Threat model
What it protects against
- A compromised or hostile network. Anyone intercepting traffic sees only ciphertext.
- A server breach. An attacker who breaks into our servers finds encrypted message content and public keys, not readable messages or private keys.
- Us reading your content. We can't, even under legal compulsion, because we don't hold the keys.
- Tampering and replay. Modified or replayed messages are detected and rejected.
- Past-message exposure after a future compromise. Forward secrecy keeps old messages safe.
- Impersonation in the middle. Safety-number verification lets you confirm identities.
What it does not protect against
- A compromised device or browser. If someone has unlocked access to your phone, or to the browser profile where you use the web app, they can read what you can read.
- The other person. Anyone you message can screenshot, copy, or forward what you send.
- Metadata. The server-visible items listed above are not hidden from the service.
- A server that adds a participant or device. Our servers manage group and channel membership and the list of linked devices. Signed rosters and device signatures make this harder, but they do not yet fully block a malicious or compelled server from adding a member or device that then receives new messages. This is the main reason to compare safety numbers, and full cryptographic membership verification is on our roadmap.
- A removed member or device catching up. Group and channel keys rotate when the next message is sent after a removal, not instantly, and a removed device may keep keys for groups it belonged to until they rotate.
- Ignored verification warnings. A brand-new contact or device is trusted on first use without a prompt, and an unverified call still connects. Safety numbers only help if you compare them.
Reporting a security issue
We welcome responsible disclosure and are grateful to researchers who help keep Lewo safe.
For privacy questions see our Privacy Policy or email privacy@lewohq.com. For general help, contact support@lewohq.com. Our commitment to protecting minors is described in our Child Safety Standards, and your use of Lewo is governed by our Terms.