How we can't read your code
Last updated: July 3, 2026
rbox encrypts your files before they leave your machine. Our servers store ciphertext, not readable code. Here is exactly what they can see, what they cannot, and where the model has limits.
What the server sees, and what it can't
The rbox server stores encrypted data and keeps changes in the right order. It hands your devices the right encrypted bytes and bills you for storage — and that's the ceiling of what it can do. Here's the honest split.
How it works — the keys, in plain words
There's a small hierarchy of keys, and the whole design turns on one fact: none of them ever reach our servers in a form we can use.
- A master key is generated on your first device and never sent to us. It's the root of everything.
- The master key wraps a per-workspace key. A device that holds the master key can open all of your workspace keys — and, through them, your files.
- Files are encrypted with per-file keys (AES-256-GCM) derived from the workspace key, on your machine, before upload.
- Unwrapped key material never leaves your devices. We store only wrapped — encrypted — copies that we can't open. There is no escrow: no master password we hold, no backdoor, no "reset" we can perform on your behalf.
Recovery — the 24-word phrase
Because we hold no copy of your keys, there has to be one thing that only you hold. That's a 24-word recovery phrase, generated on your device at setup and shown to you once. Setup offers to save a recovery-kit file; --kit makes that explicit. The phrase is the only way back in if you ever lose every signed-in device.
The flip side is the honest one: because we never see that phrase, losing it and all of your devices means your data is gone — we cannot recover it for you. That's not a gap in the design; it's the design. A recovery path we could walk on your behalf would be a backdoor by another name.
The honest caveats
A zero-knowledge claim is only worth as much as the limits it's willing to name. Here are ours — the three things a careful reader should know before trusting the model.
Identical files look identical (within one workspace)
Two byte-for-byte identical files encrypt to identical ciphertext inside the same workspace. That's what lets us deduplicate storage — but it also means the server can tell that two blobs are the same, an "is this exact file present?" oracle, without ever learning what either one contains. It can't compare across workspaces or accounts (each workspace has its own key), and it never sees names or contents. Padding and size-bucketing to blunt this further are on the roadmap, not shipped — so we don't claim them yet.
Revoking a device isn't key rotation — yet
When you revoke a device, its access token dies immediately: its very next call to our API is rejected. What revoke does not yet do is cryptographically re-key your data. A device that already cached your keys still holds them. So revoke stops that device from syncing new changes; it does not re-encrypt your existing data under a new key to lock out a device that was already compromised. Automatic key rotation on revoke is designed but not yet built, and we'd rather say that plainly than let you assume more.
We do see some metadata
Encryption hides your contents, names, and structure — not the shape of your usage. From the "what it can see" list above: the server sees blob counts, ciphertext sizes (close enough to exact file sizes, just unlinked from any name), sync timing, which pseudonymous device id pushed a change, and your account email. If your threat model needs those hidden too, rbox isn't there today.
What this means for you
A compromised or compelled rbox server can deny you service, withhold or reorder your commits, or serve you stale ciphertext — but it cannot decrypt your files or forge a commit your client will accept. That's the whole trust model in one line. For the legal treatment of what we collect and how we handle it, see the privacy policy.