How Rhema keeps your messages private

In plain language

Each of your devices has its own set of keys. When you send a message, your device locks it with a key that only the devices in that chat have. The server passes the locked message along but has no way to open it. The people you are talking to unlock it on their own devices.

Keys are created on your devices and never leave them unencrypted. SiliconBlast does not hold a copy, so we could not read your messages even if we were asked to.

Checking who you are talking to

Every pair of people in Rhema shares a safety number. You can compare it in person or over a call. If the numbers match on both phones, you know no one is sitting in the middle of your conversation. A safety number changes when someone sets up Rhema on a new device, so it is worth checking again then.

The technical detail

Rhema uses vodozemac, the audited Rust implementation of the Olm and Megolm protocols from the Matrix project. It runs in the apps as WebAssembly. Rhema adds no cryptography of its own beyond the safety number calculation below.

Olm, between devices

Each device publishes an Ed25519 identity key, a Curve25519 key and a supply of signed one-time keys. Two devices set up an Olm session, which uses the Double Ratchet algorithm. A device checks the signature on another device's keys before it opens a session with it. Rhema uses Olm sessions only to carry keys from one device to another. Messages themselves go through Megolm.

Megolm, for each chat

Every device keeps an outbound Megolm session for each chat it sends to, including direct chats. It shares the session key with every member device over Olm. Messages are encrypted with the m.megolm.v1.aes-sha2 algorithm. Your device starts a new Megolm session:

• when someone leaves the chat, so they cannot read anything sent after they left
• after 100 messages
• after a week

Megolm ratchets forward with each message, so a key that reaches a new member cannot decrypt messages sent before they joined. The apps also reject any message that repeats a session and index they have already seen, which stops replayed messages.

Safety numbers

A safety number is 60 digits shown as 12 groups of 5. Both sides sort the two Ed25519 identity keys, then compute SHA-512 over a fixed label and both keys. Each group of digits comes from 5 bytes of that hash. Both people get the same number, and it changes if either identity key changes.

Files, photos and voice notes

Your device encrypts each file with a new random AES-256-GCM key before uploading it. The key and a SHA-256 hash of the file travel inside the encrypted message, never next to the file. The server stores only the encrypted file, and the receiving device checks the hash after decrypting it.

Calls

Calls run through a LiveKit media server. Audio and video are encrypted end to end on your device, so the media server forwards streams it cannot decode.

What the server can see

End-to-end encryption hides what you say. It does not hide everything. The server can see:

• your account details, which are your name, handle and email address
• which chats you are in and who else is in them
• when messages are sent and how large they are
• the public keys of your devices
• push notification tokens, which let it wake your devices
• IP addresses of devices while they are connected

It cannot see message text, file contents, photos, voice notes, reactions or what is said on calls. Push notifications carry no message content.

Reporting a security problem

If you find a vulnerability in Rhema, email security@siliconblast.com. Please give us a reasonable chance to fix it before you make it public. We will reply to let you know we have your report and keep you updated as we work on it.