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. The server stores only ciphertext, the group identifier, the epoch, the sending device and a timestamp. It holds no key, so nobody with access to the server can produce the plaintext.

What is forward secrecy and does Enclessa have it?

Forward secrecy means a key compromised today does not expose earlier messages. Enclessa has it, and post-compromise security too: the group becomes secure again once a compromised device is removed. Both come from MLS.

End-to-end encryption with MLS (RFC 9420)

End-to-end encryption with MLS

Enclessa encrypts direct messages with MLS, the standard defined in RFC 9420, using OpenMLS. Each device holds its own key; the server delivers messages without a decryption key. Forward secrecy protects earlier messages, and post-compromise security lets the group recover after a compromised device is removed.

Updated 15 October 2026

Core · every plan

What does the server know?

What delivery needs, and nothing beyond it. Previews are generated by the sender and encrypted with the message.

Server sees

Ciphertext
Group id
Epoch
Sender device
Timestamp

Only your devices

Message text
Attachments
Link previews
Push content

What the server stores in a direct message

Ciphertext the server cannot read

An iPad channel with the managed-room badge

Enclessa is locked

Touch ID, or your login password, opens it again.

Unlock

Why MLS?

MLS is an IETF standard built for groups whose members and devices change constantly. Enclessa runs OpenMLS, compiled once from Rust for every platform.

One implementation shared by web and desktop
The server performs no MLS cryptography
Private keys leave a device only inside the encrypted key backup, which the server cannot open

How do I know who I am talking to?

Every device is a separate leaf in the group, and adding one is visible to everyone in it.

Cross-signing from an already-trusted device
Safety numbers for out-of-band checks
Encrypted key backup

At a glance

Encryption in brief

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

Limits

What it does not do

Encryption covers direct messages and group direct messages. Managed channels are server-readable so search, retention and export work.
No recording or dial-in in encrypted calls. Post-quantum key exchange and federation are not implemented.

FAQ

Questions

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.
No. The server stores only ciphertext, the group identifier, the epoch, the sending device and a timestamp. It holds no key, so nobody with access to the server can produce the plaintext.
Forward secrecy means a key compromised today does not expose earlier messages. Enclessa has it, and post-compromise security too: the group becomes secure again once a compromised device is removed. Both come from MLS.

Keep exploring

Works with

See it in practice

Bring your team over this afternoon

Free for up to 10 people, with encrypted direct messages and video calls. No payment card, no time limit, no server to run.

For businesses and organisations only — not available to consumers.

Create your organisation Compare plans