Secure Comms

Internal messaging, end-to-end encrypted to the members shown in your conversation, on the IETF's Messaging Layer Security standard (RFC 9420). Our server is a blind relay: it forwards sealed ciphertext it cannot open and never holds a private key.

Today the relay is running and the client is still in build — so treat everything below as the server half of the promise, not the whole of it.

Design-partner stage. The server — the blind relay and the device directory — is built, tested and running; the client is not yet built, so nothing is encrypted end-to-end today (see what is not built yet). We are looking for the first security-conscious companies to shape it around how they actually work. This is a distinct service from Documents — Documents keeps the records you must retain and prove; Secure Comms will carry the day-to-day conversations, encrypted so that only the people shown in each conversation can read them.

What "end-to-end encrypted" means here — precisely

We build on MLS (Messaging Layer Security), IETF RFC 9420 — the open group-messaging standard the IETF ratified. Encryption, key agreement and group membership all run in the client; the message you type is sealed on your device and only ever unsealed on the devices of the members shown in your conversation. It is not Signal: no Signal relationship, and no Signal code.

We do not write our own cryptography. The MLS protocol runs in the client through mls-rs, an independent, permissively licensed implementation of the standard. What we build is the server side of MLS as the RFC defines it — the Delivery Service and the Authentication Service (RFC 9750) — plus the glue. A vendor who tells you they wrote their own protocol is telling you something alarming.

The consequence for the server is deliberate and worth stating plainly to a security reviewer:

• The delivery service stores each message as opaque AEAD ciphertext — it is not searchable, indexable or classifiable on the server, and there is no message-body column anywhere the server can read

  — the relay moves sealed bytes; it cannot read, log or scan what you said.

• A device publishes only the public half of its MLS signature key; the private key is generated on the device and never leaves it, and the server schema has no column for one

  — a full compromise of our database would expose who talks to whom (routing metadata and the device directory), but yields no ability to decrypt a single message. We do not claim "no metadata" — the relay necessarily sees delivery routing; it never sees content.

We ship the classical MLS cipher suite (MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519, RFC 9420 §17.1). We do not claim post-quantum security today. The cipher-suite column is a value, not a schema change, so when the MLS working group standardises a post-quantum suite we adopt it as an added suite rather than a migration.

The building blocks that exist today

A device directory you can see and revoke

• Each of your devices registers as its own entry with a human-readable label and its public signature key, so every device that can join your conversations is listed and nameable

  — you can recognise "Gökhun's MacBook" in the list, and revoke a device you no longer trust.

• Revoking a device is a tombstone, not a deletion — the device stops being addressable, but its past key material stays resolvable so historical group history still verifies

  — revocation is clean without rewriting the past.

One-time key packages, claimed exactly once

• Each device publishes single-use MLS KeyPackages (RFC 9420 §10); adding that device to a group consumes one, and a normal KeyPackage can be claimed only once — the server enforces the single-winner claim in the database — reusing a key package would weaken forward secrecy for the joining member, so it is structurally prevented, with a reusable last-resort package only as a reachability fallback.

A blind delivery relay that can't fork your group

• The delivery service accepts exactly one Commit per epoch — a database uniqueness constraint on (group, epoch) is the guarantee; the second concurrent committer loses and is told to re-fetch, re-derive and retry

  — MLS derives each epoch's keys from the previous one (RFC 9420 §8), so two accepted Commits from the same epoch would split the group into halves that can never talk again. As the single serialisation point (RFC 9750 §5.1), our relay is what prevents that fork — the one thing a blind relay must get right.

• Public group objects — Commits and Welcome messages — are relayed so an offline or newly added device can sync the group; the Welcome that admits a new member is encrypted to that member's claimed KeyPackage and the server cannot open it

  — a device that was offline drains its queue on reconnect without the server ever learning the contents.

Tenant isolation and an audit trail a CISO can check

• Every table holding ciphertext, the device directory or the social graph is under fail-closed Postgres Row-Level Security: a request with no tenant scope matches no rows at all, rather than defaulting to open

  — one company's ciphertext and contact graph cannot leak into another's, even on a query path that forgot to scope, because the default is deny.

• Device registration, revocation, key-package claims and accepted or rejected Commits are written to an append-only (WORM) audit trail the database itself refuses to update or delete — and it records that an action happened, never any message content

  — you get an accountability record that cannot be quietly rewritten, without the server ever holding a plaintext.

What is not built yet — read this before you evaluate us

The server described above is built, tested and running. The client is not. Because every byte of encryption happens on the device, that means nothing is encrypted end-to-end today: what exists is a relay that is structurally incapable of reading messages, waiting for the client that will send it sealed ones. We would rather you learn that here than in a pilot.

The browser clientComing soon — the reach tier: nothing to install, so everyone in the company can be on it. Note the honest limit even once it lands: a web page re-delivers its own cryptography from our origin on every visit, so you are trusting us on each load rather than trusting a binary you verified once.

The signed desktop clientComing soon — the strong-assurance tier. A verifiable, code-signed binary is the only honest way to raise the bar on client-side key handling and supply-chain trust. The unqualified end-to-end-encryption promise belongs to this tier.

Coming soon

• Encrypted voice and video conferencingComing soon — end-to-end encrypted meetings on the same MLS group, not just text.
• The compliance archiverComing soon — a lawful-intercept-free archive works only as a visible participant: an archiver joins the conversation as a member everyone can see in the roster and decrypts as a legitimate recipient, journalling into Documents' WORM store. It is deliberately gated pending a KVKK lawful-basis analysis and DPIA — we will not add an invisible server-side reader.
• Key transparencyComing soon — a verifiable log so a device can detect if it was ever handed the wrong public key.
• File attachmentsComing soon — encrypted files alongside messages, sealed to the same members.

See also

• Documents — the WORM records store the future compliance archiver would journal into.
• Carbon EU · All products · Talk to us