Security & privacy
Exactly what is protected — and what isn't
We would rather you trust Lumen for the right reasons. This page describes the protections in place, their limits and the work that remains.
End-to-end encryption
Chats use the Matrix protocol's encryption: Olm (a Double Ratchet derivative) to set up keys between devices, and Megolm to encrypt room messages efficiently for every device in a room. The implementation is vodozemac, a Rust library maintained by the Matrix.org Foundation and audited by Least Authority, compiled to WebAssembly and used through the official Matrix JavaScript SDK. Lumen does not implement any cryptography of its own.
- New rooms are encrypted by default, server-wide.
- Keys are generated on your device. Our servers store only public keys and ciphertext.
- Attachments are encrypted in your browser (AES-256-CTR with a SHA-256 integrity hash) before upload.
- Rooms that are not encrypted — for example a public room joined from another server — are clearly labelled as such.
Verification
Encryption is only as good as knowing who holds the keys. Verify a contact by comparing a short list of emoji on both screens. With cross-signing, each person has a master identity key that signs their own devices, so you verify a person once. If someone's identity key changes — because they reset their account, or because someone else is trying to impersonate them — the app warns you before you keep talking.
Backup & recovery
Your devices can upload an encrypted backup of message keys to the server. It is encrypted with a key derived from your recovery key, which is generated on your device and shown to you once. We never receive it. If you lose all your devices and your recovery key, your encrypted history cannot be recovered by anyone — including us.
Metadata the server can see
End-to-end encryption hides content, not the existence of a conversation. Like every Matrix server, ours stores:
| Data | Visible to | Why |
|---|---|---|
| Your user ID, display name, avatar | Servers of rooms you join | Needed to route and display messages |
| Room membership and timestamps of events | Every server participating in the room | Federation replicates room history |
| Room names and topics (state events) | Servers in the room | Room state is not end-to-end encrypted in Matrix today |
| IP addresses, device names, last-seen times | Your homeserver | Sessions, abuse prevention, security notifications |
| Email address, billing details | The portal and the payment provider | Account recovery and invoices; never linked to message content |
Transport security
Every public endpoint is HTTPS-only with TLS 1.2+ (TLS 1.3 preferred), HSTS and strict security headers. Certificates are issued and renewed automatically. Server-to-server federation traffic is also TLS-encrypted and every federation request is signed by the sending server's key.
Post-quantum status
Large quantum computers would break the elliptic-curve cryptography that almost every messenger relies on, and an adversary could record encrypted traffic today to decrypt it later. Here is where Lumen stands:
| Layer | Status |
|---|---|
| Message encryption (Olm/Megolm) | Not post-quantum. Matrix has no standardised, interoperable post-quantum Olm/Megolm yet. We will adopt one once it is specified, implemented upstream and reviewed — not before. |
| Encrypted key backup (stored on the server) | Not post-quantum. Your message keys are backed up encrypted to a Curve25519 key that only your recovery key unlocks. That protects them today, but a future quantum computer could attack the stored copy. |
| Browser ↔ server connections | Hybrid post-quantum key exchange (X25519MLKEM768, combining X25519 with NIST FIPS 203 ML-KEM) is offered and used automatically when your browser supports it. This protects the connection to our server, not the end-to-end layer. |
| Server ↔ server federation | Hybrid key exchange is used when both servers support it; many Matrix servers do not yet. |
| Operator VPN (WireGuard) | Each peer uses a preshared key, which WireGuard mixes into its handshake for post-quantum resistance of the tunnel. |
You will not see a "quantum-safe" badge on your chats, because that would not be true. The full analysis is published with the source code.
Account security
- Passwords are hashed with Argon2id. Minimum length 12, with checks against common passwords.
- Two-factor authentication with authenticator apps, security keys and one-time recovery codes. Workspaces can require it.
- Sign-in rate limiting, session idle timeouts and a list of active sessions you can end at any time.
- Your chat sign-in goes through your Lumen account (single sign-on). The account service decides who you are; it never sees your message keys.
Limits we want you to know
- If your device is compromised (malware, an unlocked phone), encryption can't help: the attacker sees what you see.
- A compromised account service or server could try to add a new device to your account. Other people will see an unverified device and a warning; keep verification on.
- The web app is delivered by the server you use. Someone who controls that server could serve modified code. For the highest assurance, use a desktop or mobile Matrix app from an independent source.
- Lumen is not an anonymity tool. Use Tor or similar if you need to hide your IP address.
Found a problem? Please tell us through our vulnerability disclosure policy.