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.

Core · every plan

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

Create your workspace See pricing

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.

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.

MessagingTeams, channels, threads and direct messages, with search, files and a permission model checked in the data layer.Read more Video callsOne-to-one and group calls with screen sharing, a lobby, host controls and in-call chat, on LiveKit.Read more PeopleEmployee records, an org chart, effective-dated history, documents with acknowledgements, and onboarding that actually creates the accounts.Read more

Questions

Encryption: common questions

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.