Every file you upload to Trustbourne is encrypted in your browser before it reaches our servers. We never see the contents. Not in transit, not at rest, not during a release.
That's true for both encryption modes we offer. The difference between them is what happens when your vault needs to be released to your contacts.
What happens when you upload a file
When you drag a file into your vault, your browser does four things:
- Generates a unique encryption key for that specific file
- Encrypts the file with that key
- Encrypts the file key with your vault's master key
- Sends the encrypted file and the encrypted file key to our servers
We receive two blobs of encrypted data. We store them. We can't read either one.
Your vault's master key never leaves your browser unencrypted. It's derived from your password (in Seamless mode) or your vault passphrase (in Maximum Privacy mode). We don't have it.
Seamless: we hold a release key
In Seamless mode (the default on all plans), your vault's master key is encrypted twice:
- Once with your password, so you can access your vault when you log in
- Once with a release key that we hold on your behalf
That release key is stored encrypted, on infrastructure that's physically separate from your vault data. We don't store your master key in any form. We store a way to unlock it, but only by combining the release key with the encrypted master key.
Here's what happens when your vault gets released to a contact after the full escalation process:
- Your contact gets a time-limited link
- They verify their identity through email and SMS or WhatsApp
- Their browser receives the encrypted vault data and the release key
- The browser decrypts the master key using the release key
- The browser decrypts each file key using the master key
- The browser decrypts each file
- Your contact sees your files
Every step of decryption happens in the contact's browser. Our servers send encrypted data and the release key as separate pieces. They're never combined on our end. Unencrypted files don't exist on our infrastructure. Not during upload, not during storage, not during release.
Could we theoretically decrypt your files? Yes. We hold the release key and we hold the encrypted data. A determined insider with access to both systems could combine them.
We prevent this with access controls, audit logging, separation of systems, and operational policies. But "we choose not to" is a different promise than "we can't."
That's the honest version. For most people, it's the right tradeoff. Your contacts click a link and see your files. No passphrase to find, no extra steps during what's already a difficult time.
But if "we choose not to" isn't good enough for you, there's the other mode.
Maximum Privacy: we can't
Maximum Privacy removes the release key entirely. Your vault's master key is encrypted only with a passphrase you choose, separate from your account password.
We don't have the passphrase. We don't store it. We can't recover it.
File names are encrypted too. In Seamless mode, we can see your folder structure and file names (which helps your contacts navigate the vault after release). In Maximum Privacy, we see nothing. Encrypted filenames, encrypted contents, encrypted file keys. The whole thing is opaque to us.
When your vault gets released, your contacts receive the encrypted data but no release key. They need the passphrase you've shared with them through some other channel. A sealed letter. A solicitor. A safe deposit box. You can leave them a personal message through Trustbourne that might hint at where to find it, but the vault itself stays locked until they enter the passphrase.
This is what "zero-knowledge" actually means in practice. Not "we promise not to look." We structurally, mathematically cannot look. The key doesn't exist on our servers.
Maximum Privacy is available on the Plus plan.
Why both exist
We could have shipped only Maximum Privacy. Purer security story. Simpler to explain.
But think about what happens on the other end. Your spouse needs to access your vault. They're dealing with grief, legal paperwork, account closures, maybe finances they've never handled before. And now they also need to find a passphrase you stored somewhere, figure out what it's for, and enter it correctly before they can see anything.
That's friction at the worst possible moment.
Seamless mode means your contacts click a link, verify their identity, and see your files. The tradeoff is that we technically hold a way to decrypt. We think that's the right default for most people. For most situations.
Maximum Privacy exists for people who need more than that. Seed phrases for significant crypto holdings. Sensitive business documents. Situations where the risk of any third-party access, however unlikely, outweighs the convenience.
One thing worth spelling out: if you're on Maximum Privacy and you lose your passphrase, your data is gone. Not "contact support and we'll sort it out" gone. Gone gone. We can't reset it. We can't recover your master key. We can't brute-force our way in. Not if you ask nicely, not if you pay us, not if a court orders it. The maths doesn't care. That's the whole point.
Why per-file keys
Every file in your vault has its own unique encryption key. Those file keys are then encrypted with your vault's master key.
Encrypting everything with one key would be simpler. But per-file keys give us two things.
First, replacing or updating a single file doesn't require re-encrypting the entire vault. The new file gets a new key, the old key is discarded, everything else stays untouched.
Second, it makes granular access architecturally possible. Per-file keys mean we could release parts of a vault without exposing the rest. That's not built yet, but the foundation is there.
On the Plus plan, you get multiple vaults, and each vault has its own encryption mode. Keep a Seamless vault for family documents your spouse should access easily. Keep a Maximum Privacy vault for crypto keys where zero-knowledge matters more than convenience. Different vaults, different rules, same account.
What we're not doing
Some services encrypt files server-side. Your data arrives unencrypted, they encrypt it on their servers, then store the encrypted version. This means they see your files during upload, even if briefly. It also means a compromised server could intercept files before encryption happens.
We skip that entirely. Your browser does the encryption. Plaintext never leaves your device. If our servers were completely compromised, an attacker would get encrypted blobs and, in Seamless mode, a release key stored on separate infrastructure. Still bad, still a breach we'd take seriously. But fundamentally different from someone walking away with your actual files.
More to come
We'll publish more technical details as we build. If you have questions about the encryption architecture, or if you spot something we should be doing differently, email security at trustbourne dot com.
— Frank