I made Rocket.Chat store only ciphertext for message text, with a key nobody holds

[sashyo]

Short version: in this fork, a message's msg is sealed before it reaches MongoDB. The database holds ms1: ciphertext, the encryption key is never assembled anywhere (not in the server, not on disk, not in one admin's hands), and a message opens back to plaintext only for a user a quorum granted a reading role. Turn it off and Rocket.Chat behaves exactly like upstream.

The seam I need to make this a drop-in plugin instead of a fork is a small one, and I wrote it up separately as an Ideas post: https://github.com/orgs/RocketChat/discussions/42188. This post is the "why" and the "does it actually work."

The problem

A chat server's most sensitive data is the message text itself. Today Rocket.Chat gives you two options and each leaves a gap:

• Default: message.msg sits in Mongo as readable text. TLS and disk encryption help in transit and at the volume level, but a stolen database, a leaked backup, or anyone with a Mongo connection reads every message.
• E2E Encryption: strong at rest, but the keys live only on user devices, so it is all-or-nothing. No admin, auditor, bot, integration, search, or push preview can ever read an E2EE room, users manage keys and lose history on a forgotten password, and it is a per-room manual toggle.

I wanted the middle ground most self-hosters actually ask for: make the database and backups useless to a thief, gate reads by a role someone can grant and revoke, and keep the product working.

What it does

The key is held by nobody. It lives as threshold shares across the Tide network and is never reassembled, not even to decrypt. The server asks the network to open a field on behalf of a named user, and the network only agrees if a quorum-granted role says that user may read.

• Your database holds only ciphertext. A dumped rocketchat_message collection or a leaked backup reveals nothing.
• There is no standing key to steal. Compromising the server does not hand over a key, because the key is never whole there.
• Reads are governed, not assumed. A quorum grants the reading role. Revoke it and reads stop everywhere, at once, with no re-encryption.
• Compliance and bots still work. An authorized reader (a support agent, an auditor, a service account) reads without anyone sharing device keys. E2EE cannot do this.
• Nobody juggles keys. People keep their normal Rocket.Chat login. The gate is a role, not a keyfile they can lose.

How it works (three small seams)

• Seal on write in BaseRaw (insertOne/updateOne), so msg is sealed before it hits Mongo. Routing keys (rid, u._id, ts) stay in the clear so the app keeps working.
• Open on read in normalizeMessagesForUser, which nearly every REST and method read of messages already passes through, so history, search, threads and pins are all covered in one place. It opens as the requesting user, gated by their role.
• Open per recipient in real time by reusing Rocket.Chat's existing per-subscription TransformMessage seam in the streamer (the one __my_messages__ already uses). Live delivery is a shared fan-out, so a message is opened once per connected recipient: granted members see plaintext arrive live, an ungranted viewer in the same room sees ciphertext.

Does it actually work

Yes, end to end on Rocket.Chat 7.x:

• Stored in Mongo (rocketchat_message): ms1:AQAAAAEA... ciphertext.
• A granted user reads: "The Q3 board deck is in the vault, passphrase 4417-orchid."
• An ungranted user in the same channel reads: ms1:... ciphertext.
• Revoke the role, and the granted user's reads go dark too, with no change to Rocket.Chat.

The honest tradeoff

E2EE gives a stronger "even a malicious server operator cannot read" guarantee, because it trusts only the device. This mode, in its lightweight form, trusts the app server to say who is calling (there is a stronger per-request enclave path if you need it). So E2EE is the right choice when you do not trust the server at all and only the two participants should ever read. This is the right choice when you want a stolen database to be worthless, reads to be governed and revocable, and search, bots, notifications and compliance to keep working.

One line: E2EE hides messages from everyone including your own org, the default hides them from no one, this hides them from a database thief while a quorum decides who may read.

Disclaimer: this is the lightweight form

What I have shown here is the lightweight, self-hostable form of the approach: minidauth, running "tideless", where the app vouches for who is calling and a quorum-granted role gates the read. It is a proof of concept, not production hardened, and per-field round trips are the demo shape rather than the envelope-encryption shape a real deployment would use.

The enterprise-grade version of this is TideCloak, Tide's identity and access product. There, who is calling is proven per request with threshold cryptography inside the network rather than asserted by the app server, which closes the "trust the app server" gap called out above. minidauth is the small on-ramp to that model, meant to show the shape and let you try it without adopting the full stack. Treat this fork as a demonstration, and TideCloak as the path if you want to run field-level, quorum-governed sealing for real.

Try it / the code

• Fork: https://github.com/sashyo/Rocket.Chat
• It is off unless MINIDAUTH_SEAL_URL is set, and it is a proof of concept (per-field round trips today; envelope encryption is the production shape).
• More on minidauth: github.com/sashyo/minidauth and dauth.me.

Feedback welcome, especially on the seam proposal in the Ideas post. If that lands, this stops being a fork and becomes a plugin.