How the security model works

Written to be checked, not taken on faith.

The rule is simple: if the server is ever compromised, the attacker gets nothing worth having. Everything below follows from that.

• 0passwords stored — none exist anywhere in the system
• 0phone numbers or emails needed to chat
• 0trackers or analytics, first- or third-party
• 0messages our servers can read

Your device holds the keys

When you join a chat, your device generates a keypair (ECDH P-256). The public half goes on the chat’s member list. The private half never leaves your device. There’s no password to steal, because there’s no password. Your device is your identity.

Every chat has its own key

Each conversation, group or DM, gets its own AES-256 key. That key is wrapped (encrypted) separately to every member’s public key, and the server only ever stores the wrapped copies, which it can’t open. Membership is the boundary, and cryptography enforces it, not a server setting.

Your device encrypts every message before it’s sent: text, attachments, file names, even the sender’s name carried inside the message. Display names on the member list are sealed too, under a key only members hold. The server just stores and relays ciphertext it can’t read. Push notifications arrive encrypted as well, and get decrypted on your device.

Invites don’t leak

An invite link carries a one-time secret after the # in the URL. Browsers never send that part to any server. It exists to bootstrap your keys locally, then it’s spent. The admin credential only manages the member list — it can’t decrypt anything.

What the server has to see

To actually deliver messages, the server needs some information. We’d rather say what, plainly:

• Who’s in a chat with whom. It routes messages to members, so it knows each chat’s membership — as keys, not names.
• When, and how much. Message timing and sizes are visible in transit, as they are for any messenger.
• A posted link, if previews are on. The server fetches a URL you post, once, to build the preview card. It sees that URL and nothing else in the message. This is the one deliberate exception, and you can turn it off.

So if the database were ever stolen, it would show that keys talk to keys. It wouldn’t show a name, and it wouldn’t show a single word anyone actually said.

The honest limits

Every security model has edges. Ours:

• Removing someone doesn’t un-share the past. A removed member stops getting new messages, but a key they already held isn’t clawed back.
• Your keys are yours to keep. Saving your sign-in takes one tap, and then any device can let you back in. Skip it, lose your only device, and your keys are gone along with any history only you could read. We can’t recover it. We never had it.
• Key hand-out still trusts the server — but no longer quietly. Public keys are handed out by the server, and full out-of-band verification is still to come. What’s already shipped narrows the gap: every key hand-out is committed to a signed, append-only history that members’ devices cross-check with each other, and invite links cryptographically pin the invited person’s first key — so a swapped key is no longer silent; it raises an alarm in the app. The last piece — a public log that every device checks every key against — is designed and being built.

Check our work

All of this runs in the open — plain, readable code on your device, not hidden behind an API. It’s audited by the latest AI models too, including security review by Claude Fable. If something here doesn’t match what the code actually does, tell us: team@elevenmessenger.com.

For what data is handled and kept, see Privacy. For the full technical picture — ciphers, key wrapping, what a stolen database yields — see the nerdy stuff.