End-to-End Encryption Without Compromise

Note: This article describes Mandraki’s architecture and design. Some features discussed are being rolled out progressively and may not yet be available in all plans.

End-to-end encryption is one of those features that is easy to promise and difficult to deliver properly. Many collaboration platforms claim to offer E2EE, but the details of their implementations vary enormously — and the details are where security lives or dies.

This post explains how Mandraki implements end-to-end encryption, the protocol choices we made, and the trade-offs we are transparent about.

What end-to-end encryption actually means

In a system with end-to-end encryption, messages and media are encrypted on the sender’s device and can only be decrypted on the recipients’ devices. The server that relays the data sees only ciphertext. It cannot read the content, even if compelled to do so by a court order, a rogue employee, or a security breach.

This is fundamentally different from transport encryption (TLS), which protects data in transit between a client and a server but leaves the server with access to plaintext. It is also different from at-rest encryption, which protects data on disk but leaves the application layer with access to plaintext during processing.

True E2EE means the server is untrusted by design. It is a relay, not a reader.

The MLS protocol for messaging

For encrypted messaging, we use the Messaging Layer Security (MLS) protocol, standardised as RFC 9420 by the IETF. MLS was designed specifically for group messaging scenarios and offers several advantages over older approaches.

MLS uses a tree-based key agreement structure called TreeKEM, which allows a group of participants to establish a shared secret efficiently. When a member joins or leaves a group, the key material is updated through a Commit message that advances the group’s epoch. This provides forward secrecy — compromising a member’s keys at one point in time does not reveal messages from earlier epochs — and post-compromise security — the group recovers security after a compromise as soon as the affected member’s key material is rotated.

Each user device uploads MLS key packages to the server. These are one-time-use cryptographic bundles that allow other devices to add them to a group without requiring the device to be online at that moment. When a key package is consumed, the device must upload fresh ones. The server stores and distributes these packages but never has access to the private key material they contain.

MLS groups in Mandraki map to channels and direct message threads. When you send a message in an encrypted channel, your client encrypts it using the group’s current epoch key. The server receives ciphertext, stores it, and distributes it to group members. Their clients decrypt it locally.

SFrame for media encryption

Encrypting real-time media — audio and video in a group call — presents different challenges from messaging. Latency tolerance is measured in milliseconds, not seconds. The data rates are orders of magnitude higher. And the media passes through a Selective Forwarding Unit (SFU), which needs to route packets to the right participants without being able to see the content.

We use SFrame (RFC 9605) for media encryption, applied via the WebRTC Encoded Transform API. This API allows JavaScript code to intercept encoded media frames after encoding but before packetisation, encrypt them, and pass the ciphertext to the transport layer. On the receiving end, the frames are decrypted after reassembly but before decoding.

The key advantage of SFrame in an SFU architecture is that the SFU can still perform its routing function — forwarding packets from one participant to others, making bandwidth-adaptive decisions about which layers to forward — without ever having access to the plaintext media. The SFU sees encrypted frames and forwards them as opaque blobs.

The trade-offs we are honest about

End-to-end encryption is not free. It introduces real constraints that we believe are worth acknowledging.

Server-side search is not possible on E2EE content. If messages are encrypted with keys the server does not hold, the server cannot index them for search. Mandraki addresses this by maintaining a local encrypted search index on the client using IndexedDB. This provides per-device search but does not support cross-device search history for messages received before a device was added to the group.

Server-side AI features are mutually exclusive with E2EE. Our AI transcription and summarisation features require server-side access to plaintext audio. A call or channel cannot have both E2EE and AI features enabled simultaneously. This is enforced architecturally, not just by policy. Organisations choose at the call or channel level which model they prefer.

New devices see messages only from join point forward. When you add a new device to your account, it can decrypt messages from the moment it joins the MLS group onward. Historical messages encrypted under previous epochs are not accessible on the new device. This is a fundamental property of forward secrecy. We are exploring secure backup mechanisms that would allow users to export encrypted message history to a new device, but this remains a work in progress.

Key management adds complexity. Each device must maintain key material, upload fresh key packages, and process group state updates. We invest significant engineering effort in making this invisible to users. The goal is that encryption is not something you configure or think about — it simply happens.

E2EE and server-side encryption coexist

It is worth noting that Mandraki’s E2EE layer and our server-side envelope encryption (the three-layer key hierarchy described in our security architecture) serve complementary purposes. Server-side encryption protects data at rest on our infrastructure — if a disk is stolen or a database backup is compromised, the data is unreadable without the encryption keys. E2EE goes further by ensuring the server never sees plaintext in the first place.

For organisations that enable E2EE, both layers are active simultaneously. Data is encrypted end-to-end by the clients and also encrypted at rest on the server. Belt and braces.

We believe that end-to-end encryption should be the default for sensitive communications, not a premium add-on or a checkbox that most users never find. Mandraki makes it straightforward to enable, transparent in its limitations, and robust in its implementation.