Security
Last updated: 2026-10-29
This page explains how Mailbees encrypts your messages, where the keys are, and what the server can and cannot see. The full list of data that the server stores is in the Privacy Policy.
End-to-end encryption
- Mailbees uses libsignal, the official library of the Signal protocol. We do not use our own cryptography.
- A new chat starts with PQXDH: a key agreement that combines X25519 with the post-quantum ML-KEM (Kyber).
- Each message gets a new key from the Double Ratchet together with SPQR, Signal's post-quantum ratchet. A key that leaks later does not open earlier messages.
- Groups, channels and stories use Signal sender keys: each device encrypts a message once for all members. When a member leaves, the other members make new sender keys before their next message.
- Files are encrypted on your device with a random key before upload. The server stores only the encrypted pieces.
- Calls use WebRTC with DTLS-SRTP. The call setup (with the DTLS fingerprints) travels end-to-end encrypted, like a message, so the server cannot put itself in the middle of a call.
Keys
- Your identity key is made on your device when you sign up. The server gets only public keys: the identity key and the signed, Kyber and one-time prekeys that let others start a chat with you.
- On the device, the database fields and media files are encrypted with AES-256-GCM. The key for them is in the Android Keystore or the Apple Keychain.
- A Mac is a linked device of your phone account. It gets the account keys from your phone over an encrypted channel after you scan a QR code.
- An encrypted backup is a file that you keep. It is encrypted with a key derived (Argon2id) from a 30-digit code that the app makes; we do not get the file or the code.
Safety numbers
Each chat has a safety number made from the identity keys of both people. Compare it in person or scan the QR code on your contact's phone. If a contact's keys change (a new phone, or someone tries to put in their own key), the app tells you that the safety number changed. A server that gives you a false key cannot hide this from a verified contact.
What the server sees
The server is a relay: it keeps a message only until your device confirms delivery, and 7 days at most. It keeps no history. It cannot read messages, files, calls, locations, names or profile pictures. It does see some metadata:
- the random account IDs of the sender and the recipient, the time and the size of each message;
- your IP address while you are connected (used in memory for rate limits, not stored);
- the push token of your device; Apple or Google get only an empty "wake up" signal, never the content or the sender;
- the IP addresses of call participants on the TURN server, when a call cannot connect directly.
If the server is taken over, the attacker gets this metadata and the encrypted messages waiting for delivery, but not the keys to read them. A server can also delay or drop messages; it cannot change them without the recipient noticing.
Other Mailbees servers
- Each account has one home server; an address looks like
id@server. Your app talks only to your home server, and that server forwards to other servers. Other servers do not see your IP address. - Servers sign every request to each other with Ed25519. The keys are published over HTTPS at
/.well-known/bumblebeeof each server. A server accepts messages from another server only for that server's own accounts. - End-to-end encryption is the same across servers. The other server sees the same metadata as your own server: who, to whom, when and how large.
- Settings and news that a server sends to the apps are signed. The app remembers the key on first use and rejects data with another key.
What Mailbees does not protect against
- Metadata: the server knows which accounts talk to each other and when (see above).
- An unlocked or compromised device: whoever controls your phone or Mac can read your chats.
- Screenshots and copies: the person you write to can save what you send.
- Push services: Apple and Google know when your device gets a notification.
Report a vulnerability
If you find a security problem, write to pentabion@gmail.com before you publish it. Tell us the app version and the steps to reproduce. We will reply and tell you when it is fixed.