How the security model works

Written to be checkable, not impressive

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

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 is no password to steal because there is no password — your device is your identity.

Every chat has its own key

Each conversation — a group or a DM — gets its own AES-256 key. That key is "wrapped" (encrypted) separately to every member's public key, and the server stores only the wrapped copies, which it cannot open. To read a chat, you must be a member of it; membership is the boundary, and it's enforced by cryptography, not by a server policy.

Your device encrypts every message — text, attachments, file names, even the sender's name inside the message — before anything is sent. The server stores and relays opaque ciphertext. Push notifications arrive encrypted too, and are 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 fragment to any server — it exists to bootstrap your keys on your device, then it's spent. The admin's own credential only manages the member list; it can't decrypt anything.

What the server necessarily sees

To deliver messages at all, the server has to know some things. We'd rather tell you exactly what than pretend otherwise:

• Who shares a chat with whom. It routes messages to members, so it knows each chat's membership.
• Members' screen names. The member list stores the display name each person chose.
• Posted links, if previews are on. The server fetches a URL you post once, to build the preview card. It sees that URL — never the message around it. This is the one deliberate exception, and it can be turned off.

So a stolen copy of the database reveals who talks to whom, and by what name — but not one word of what anyone said.

The honest limits

Every security model has edges. Here are ours:

• Removing someone doesn't un-share the past. A removed member stops receiving new messages, but a key they already held isn't clawed back.
• Lost device, lost history. If you lose your device with no backup or "add a device" link, your keys are gone — and so is the history only you could read. We can't recover it, because we never had it.
• Key hand-out currently trusts the server. Public keys are distributed by the server and aren't yet verified out of band. A stolen database can't exploit that — but an actively malicious server could substitute a key to intercept new conversations. Out-of-band verification is planned to close this.

Check our work

All of this is implemented in the open — the encryption runs in plain, readable code on your device, not behind an API. If we've claimed something here that the code doesn't do, we want to know about it: security@elevenmessenger.com.

For what data is handled and kept, see Privacy.