How It Works
Canium uses MLS (Messaging Layer Security, RFC 9420), the IETF standard for secure group messaging. It is the single encryption system behind every conversation, in channels and direct messages alike.
Secure Login
Canium uses OPAQUE (RFC 9807), a password authentication protocol in which the server never receives your password, not even in hashed form. What the server holds is a record that is useless without your password and encrypted key material that cannot be opened without the key your password produces. Neither half is of any use on its own.
A breach of the server database would hand an attacker no password and no key they could use. What would remain is guessing, one password at a time, against a check built to be slow.
MLS Group Encryption
Every Canium channel is an MLS group, and so is every direct message. MLS is a cryptographic protocol for secure group messaging at scale, standardized by the IETF in 2023. It provides:
- End-to-end encryption. Messages are encrypted on the sender's device and decrypted only on the recipients' devices. The server stores no message content it can read.
- Forward secrecy. Compromise of a current key does not expose past messages.
- Post-compromise security. Every message sent after a compromised user is removed from a group is encrypted under keys that user does not hold.
- Post-quantum encryption. MLS group keys are established with a hybrid mechanism, the X-Wing combiner, which pairs classical X25519 with ML-KEM-768, the post-quantum algorithm standardized by NIST. Traffic recorded today is not unlocked later by a quantum computer, because the key exchange protecting it is hybrid. That is the "harvest now, decrypt later" attack, and it does not work here.
Data Recovery Agent (DRA) envelopes, described under Compliance, use the same hybrid construction.
Direct Messages
A direct message in Canium is a two-person MLS group with keys of its own. It works the same way as any channel: the same encryption system, the same recovery paths, the same blindness on the server's part. There is no separate system for direct messages, and so no second threat model to reason about.
Meeting Security
Audio, video, and text all run through the same encryption system. There is no separate layer for calls with its own rules to get wrong. Every call and every message is encrypted end to end, and there is no unencrypted fallback: if encryption cannot be established, nothing is sent.
What the Server Never Sees
| Item | Server access |
|---|---|
| Your password | Never. Held on your device and never sent |
| Your encryption keys | Never in readable form. Stored encrypted and rebuilt on your device each time you sign in |
| Message text | Never. Encrypted on your device before it is sent |
| Files and images | Never. Encrypted before they are uploaded |
| Reactions | Never. Encrypted like any other message |
| Link preview cards | Never. Built on your device and stored encrypted |
| Call audio and video | Never. Encrypted between participants |
What the Server Does See
Encryption protects what you say. Some structure has to stay readable for the product to work: to deliver a message to the right channel, to put a meeting in your calendar, to send an invitation by email. We set it out plainly rather than leave it to a blanket claim.
| Item | Why |
|---|---|
| Organization and channel names | Navigation, invitations, and access control |
| Member names and roles | Permissions and member lists |
| Meeting titles, times, and invitees | Calendars and invitation emails |
| Who joined a call, and when | Connecting participants and ending the meeting |
| Email addresses | Invitations, notifications, and account recovery |
Email addresses are encrypted in storage under a key we hold, because we are the ones who send your mail.
Multi-Device Support
Adding a new device is just signing in. Your keys are rebuilt on the new device from your password alone, so existing channels do not have to be rejoined and nothing has to be transferred between devices.
Threat model, standards, and what the server never sees.
Canadian sovereignty, lawful access, and the DRA architecture.