How LEWO Encryption Works

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 can never open it. Your message is scrambled on your device before it leaves, travels as unreadable data, and is unscrambled only on the recipient's device.

Because the keys that unlock your messages exist only on the devices involved, someone who intercepts your network traffic or steals our stored data sees only ciphertext — not LEWO, not advertisers. Even if we were legally compelled to hand over your messages, we could only provide encrypted data we cannot decrypt — we simply don't hold the keys. Two honest caveats: our servers manage who is in a group or channel, so for those conversations you are trusting us not to add an unauthorized member; and to be certain no one is impersonating a contact in the middle, 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 communication is end-to-end encrypted. To actually deliver a message, our servers necessarily handle some routing information (metadata) — for example, who a message is addressed to and when it was sent. Here's an honest breakdown.

The server stores message content only as ciphertext — scrambled data it cannot turn back into readable text. It never holds the plaintext of your messages, your private keys, or the per-message keys used to decrypt them.

The protocol we use

LEWO's encryption is built on the same well-studied approach pioneered by the Signal protocol — an independent implementation of X3DH and the Double Ratchet, 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 even 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 algorithm derives a unique key for every single message and advances forward after each one. This gives two important guarantees:

• Forward secrecy. Old keys are discarded and cannot be re-derived, so compromising your device today does not expose past messages.
• Post-compromise security. For conversations started on current versions of the app, the session periodically introduces fresh key material, so it can "heal" and regain security even after a temporary compromise.

Each message is sealed with authenticated encryption (AEAD) using XChaCha20-Poly1305, a modern, fast cipher. 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. Our cryptographic primitives come from the audited @noble libraries (@noble/curves, @noble/ciphers, @noble/hashes).

Groups, channels and calls

Different conversation types use the right tool for the job, but all of them are end-to-end encrypted:

Group chats

Groups use a sender-key approach: each member encrypts a message once with their own sending key, which has been securely distributed to the other members. This is far more efficient than encrypting separately for every recipient. When a member leaves, keys are rotated so they cannot read future messages.

Channels

Channel posts are end-to-end encrypted and additionally signed with the admin's Ed25519 signing key, so a reader's app can verify a post was signed by the channel's admin key and was not altered in transit. (As with group membership, the admin's key is distributed through our servers, so this authenticates the key we vouch for rather than being an independent proof of the admin's real-world identity.)

Voice and video calls

Call media is end-to-end encrypted. The media path is secured using SRTP over DTLS with keys agreed directly between the participants, so the live audio and video are protected end to end. Call setup (the signaling that connects a call) is relayed by our servers and authenticated with Ed25519 signatures, but is not itself part of that end-to-end media encryption.

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 leave it. Only public keys are shared with our servers so other people can start an encrypted session with you. There are a few kinds of keys:

Private keys are kept in your device's protected key storage — the Keychain on iOS and the Keystore on Android — guarded by your device's security (passcode and biometric lock) and never transmitted off the device.

Because keys live only on your device, losing or wiping your device means past message history on it cannot be recovered by us, and your contacts will see a notice that your security keys changed when you set up again. This is by design: it keeps your past conversations safe even if your device is lost or stolen.

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, view its safety number (a fingerprint of the conversation's keys) in the encryption settings, and compare it with your contact in person or over a trusted channel. If the numbers match, the connection is verified. It's especially worth checking when you see a "security keys changed" notice that you didn't expect.

What we don't do

To be precise about the promises that matter most:

• 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 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, and we want to be straightforward about how that coexists with strong encryption.

Ads on LEWO are never targeted using the content of your messages, calls or shared media — that content is end-to-end encrypted and unreadable to us and to advertisers. To show ads and keep LEWO free, 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.

Because LEWO does not use a cross-app advertising identifier, there is no third-party advertising profile built from your activity. You can manage app permissions (such as location) at any time in your device settings. For full details on what we collect and how it's used, see our Privacy Policy.

Threat model

It helps to be clear about what LEWO's encryption is designed to defend against — and what it can't.

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 data 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. If someone has unlocked access to your phone, they can read what you can read. Use a strong device passcode and biometric lock.
• The other person. Anyone you message can screenshot, copy, or forward what you send.
• Routing metadata. Delivering messages requires knowing who and when; that metadata is not message content but it is not hidden from the service.
• A server that adds a participant or device. Our servers manage group and channel membership and the list of your linked devices. A malicious or compelled server could add an unauthorized member — or register an extra device — that would then receive keys. Today this is not blocked cryptographically; it is the main reason to compare safety numbers, and cryptographic membership verification is on our roadmap.
• A removed device catching up on groups. Removing a linked device stops new one-to-one messages from being sent to it, but it may retain the keys for groups and channels it already belonged to until those keys next rotate.
• Ignored verification warnings. Safety-number checks only help if you actually compare them, especially after an unexpected key change. Note that a brand-new device or contact is trusted on first use without a prompt.

Reporting a security issue

We welcome responsible disclosure and are grateful to researchers who help keep LEWO safe.

For privacy questions see privacy.html or email privacy@lewohq.com. For general help, contact support@lewohq.com or visit contact.html. Our commitment to protecting minors is described in child-safety.html, and your use of LEWO is governed by our Terms.