Encryption
The useful document is Encryption in Rift, last updated September 2026. It says it is "written from the code that ships, not a design doc." The code is not public. What follows is that page, read against the homepage and the features page.
What they say is end to end
- The text of 1:1 direct messages, including edits and formatting.
- Voice, camera, and screen share in a 1:1 DM call, when both clients support it. An older client gets a call the UI marks as plaintext. They say there is no quiet downgrade.
The construction they describe is a Signal-style X3DH handshake and a Double Ratchet (X25519, HKDF-SHA256, AES-256-GCM). Identity keys are derived from the 12-word Rift Key. The server is supposed to store public keys only, and to refuse an unsigned identity upload.
What they say they can read
The encryption page's own short version:
Shard channels, Splinters, and file attachments are encrypted on our servers with keys we hold.
- Shard (community) messages: per-message keys wrapped by a master key Rift holds. This is encryption at rest. It is aimed at a stolen database, not at Rift, a subpoena to Rift, or a staff account that can use the master key.
- Splinters, their name for private group chats of three or more: same model. The features page does say this in plain language. The homepage slogan does not mention it.
- Attachments in any conversation, including DMs. "The file bytes, filename, size, and type are visible to our storage layer." A photo in a DM is not in the "we literally can't" bucket. The text around it is.
- Shard voice, and any call that is not a supported 1:1 DM call: "TLS between you and us, plaintext on our media server." They self-host the media servers and say no third party receives the audio. Rift's server mixes it, so Rift's server hears it.
For an encrypted DM, the server still stores who the two people are, when the conversation started, sender, timestamps, reply relationship, expiry, client message id, ratchet header, and ciphertext length. Messages are not padded, so length is visible. Link previews are not generated for encrypted DMs, because the server cannot see the links. Push notifications for those DMs cannot include the text, for the same reason.
The second copy
Multi-device is the part that retires the features-page slogan.
Ratchet state lives on one device. A message sealed only with the ratchet would not open on your phone if you sent it from the desktop, and it would not open when a new device loads history. So every DM carries a second ciphertext. The key is an X25519 shared secret between the two accounts' long-lived DM identity keys, passed through HKDF with the info string rift-dm-static-fallback-v3. Any of your devices can derive it. The server stores the ciphertext and, by their account, cannot open it.
They write the consequence in the same section. Forward secrecy covers the live session. It does not cover stored messages. A compromised Rift Key, or a compromised DM identity key on any signed-in device, decrypts every stored message in both directions. One identity exists per account, not per device. Signing a device out ends its session and does not take back keys that device already copied. Recovery changes the password and ends sessions. The DM keys come from the Rift Key, so they stay the same. If the Rift Key gets out, their instruction is to make a new account.
The features page still says a later key leak leaves old messages locked, and calls the construction the model Signal uses. Signal's ratchet is built so that compromising today's keys does not open yesterday's messages. Rift's history copy is a static fallback they chose so a second device can read the log. Both descriptions are on therift.chat.
Trust on first use, and the client they serve
Signature checks run against the account signing key the server gave the client. They say the server writes that key once and has no code path to replace it. The first time you talk to someone, you are trusting the server to hand you their real key. They say so. Safety numbers exist: a 60-digit fingerprint, and a verification flag. A contact you have not verified is trust on first use. There is no public key-transparency log. A compelled or compromised server, on their own description, can hand you the wrong key the first time.
Then the client:
The web and desktop clients load their code from our servers. End-to-end encryption in a browser is only as strong as the code the browser was served that day, and no design can fix that from inside the page.
Keys in the web and desktop apps sit in IndexedDB, wrapped by a non-extractable WebCrypto key that is also in IndexedDB. Any script running on the Rift origin can use that key. They say this stops a stolen browser profile, not code running as you. The Windows comparison page says the chat UI runs inside WebView2. The mobile apps and desktop installers are described as signed releases. The download page also still offers an Android APK from the website.
Homepage copy treats "we literally can't" as a property of the universe. The encryption page treats it as a property of a client you have decided to trust, on a day they chose what that client contains.
Other limits they list, and the homepage does not
- The signed prekey is static for the life of the account. Re-uploading it does not change it. Signal rotates signed prekeys.
- If one-time prekeys run out, X3DH drops from four Diffie-Hellman operations to three. They call that standard, and weaker against a replayed handshake.
- Ciphertexts are not padded.
- Encrypted calls keep packet sizes that still vary with speech versus silence. They say they have not closed that.
- A compromised signed-in device holds the whole identity.
- The Rift Key is not stored unless you turn on an optional cache. The cache wraps it with PBKDF2-HMAC-SHA512 at 600,000 iterations, or with a platform authenticator where the browser supports the WebAuthn PRF extension.
The "how to check any of this" section says the client code is not public. The checks they offer are: key-bundle endpoints return only public keys, encrypted DMs on the wire have the shape they describe, the server refuses an unsigned identity upload, and a data export lists counts of encrypted messages and none of the content. "If the code doesn't match this page, that's a security issue."
The contract around the check
The terms, September 2026, say you may not copy, decompile, reverse engineer, or scrape the service, and you may not use a modified or unofficial client. Automation of a user account is banned. Webhooks are the supported way to post without a person at the keyboard.
The security page, also September 2026, asks for reports by email, aims to acknowledge them within 72 hours, and offers a safe harbor for good-faith research that stays in scope and gives them time to fix. It says there is no formal bug bounty. The FAQ's substitute for an audit is that the promises are written down, and that Rift would rather not be sued.
A design document this detailed is more than a slogan. It is also the document that makes the slogan false. Until someone can read the client that the terms mostly forbid reading, the design document is the evidence.