Skip to content

Core · every plan

Real end-to-end encryption, or none of the word

Enclessa encrypts direct messages end to end using MLS, the Messaging Layer Security protocol standardised as RFC 9420, implemented with the audited OpenMLS library. Each device holds its own key, the group re-keys as members and devices come and go, and the server operates only the delivery service — it never holds a key that could decrypt a message. That gives forward secrecy, so a key compromised today cannot open yesterday, and post-compromise security, so the group heals once the compromised device is removed.

Open betaThe platform is being built in the open, so parts of it are not there yet, behaviour changes between releases, and no availability figure is committed while it is in beta. What is still being built.

At a glance

Protocol
MLS, RFC 9420
Implementation
OpenMLS, compiled once in Rust
Key scope
One key per device, not per account
Server role
Delivery service only, holds no keys
Properties
Forward secrecy and post-compromise security
Verification
Safety numbers and cross-signed devices

Why MLS rather than an encryption scheme of our own?

Because a bespoke protocol is the single most reliable way to get this wrong. MLS is an IETF standard with a published security analysis, and it is designed for exactly the case a workplace has and a two-person chat does not: groups whose membership and devices change constantly, re-keying in logarithmic rather than linear time. Enclessa uses OpenMLS, compiled from one Rust crate to WebAssembly for the browser and through UniFFI for native clients, so every platform runs identical cryptographic code.

  • One implementation, compiled once, shared by web and desktop
  • The server implements the delivery service and performs no MLS cryptography
  • Key material never leaves the device that generated it

What does the server actually know about an encrypted conversation?

The ciphertext, the group identifier, the epoch number, which device sent it and when. Not the text, not the attachments, not the link previews — those are generated by the sending client and encrypted along with the message. Metadata that has to exist for delivery to work exists; nothing beyond it does.

  • Ciphertext, group id, epoch, sender device, timestamp
  • No plaintext, no attachment contents, no preview images
  • Push notifications carry no message content under encryption

How do I know I am talking to the right person?

Every device that joins a conversation is a separate leaf in the MLS group, and adding one is visible to everybody in it. Devices are cross-signed from a device you already trust, and safety numbers let two people confirm out of band that no third party sits between them.

  • A new device is announced in the conversation, never silently added
  • Cross-signing from an already-trusted device
  • Safety numbers for out-of-band verification
  • Encrypted key backup so a lost device is not a lost history

How does compliance work if the server cannot read anything?

Honestly, and visibly. In an encrypted room the only way to satisfy a retention or disclosure duty is a compliance recipient whose key sits in the room where everyone can see it — never a quiet copy taken on the server. An organisation with a blanket retention obligation runs those conversations in managed channels instead, where the server can read and therefore can retain, export and hold.

  • No silent key escrow, ever
  • Managed channels carry retention, export and audit
  • The choice is a policy setting the organisation makes, not a hidden default

What this does not do

  • Encryption covers direct messages and group direct messages. Managed channels are server-readable so that search, retention and compliance export can work.
  • Meeting recording and telephone dial-in are not offered in end-to-end encrypted calls, because either would require decrypting the media somewhere you cannot see.
  • Post-quantum key exchange and federation are kept architecturally open but are not implemented.

Related

Where this shows up

Questions

Encryption: common questions

What encryption does Enclessa use?

Enclessa uses MLS, the Messaging Layer Security protocol standardised by the IETF as RFC 9420, implemented with the OpenMLS library. Each device holds its own key and the server holds none.

Can Enclessa or its hosting provider read my encrypted messages?

No. In end-to-end encrypted conversations the server stores only ciphertext, the group identifier, the epoch, the sending device and a timestamp. It has no key that can decrypt the content, so neither Enclessa nor a hosting provider nor anyone served with a request for the server can produce the plaintext.

What is forward secrecy and does Enclessa have it?

Forward secrecy means that compromising a key today does not expose messages sent before it. Enclessa has it, and also post-compromise security, which means the conversation becomes secure again once a compromised device is removed and the group re-keys. Both properties come from MLS.

What happens if I lose a device?

You remove it from your device list, which removes its leaf from every MLS group you are in and triggers a re-key, so the lost device can no longer decrypt anything sent afterwards. An encrypted key backup restores your history to a new device.

Encrypted collaboration, hosted in Europe.

Create a workspace in a couple of minutes. It is yours at your-team.enclessa.app, hosted in the European Union, with encrypted direct messages from the first one you send.

Open beta. Free plan, no payment card to start.