How zero-knowledge works at Terebyte

Updated October 12, 2026

“Zero-knowledge” means your files are encrypted on your own device, with keys that only you hold, before anything is uploaded. We store what we’re sent, and what we’re sent can’t be read without your keys. This page explains how, in plain words, with the real names of the methods used.

In short

Your browser encrypts every file, and every file and folder name, before upload.
The keys come from your vault passphrase and stay on your device. We never receive the passphrase or your recovery key.
Our servers, our storage provider and our download servers only ever hold encrypted bytes.
If you lose both your passphrase and your recovery key, nobody can open your files: not you, and not us.
Today Terebyte is a web app, so you also trust the code your browser downloads from us each visit (see the last section).

The keys

Everything rests on one random key per account, the master key, made in your browser when you create your vault.

Master key. 256 random bits from your browser’s cryptographic random number generator (the Web Crypto API). It never leaves your device unencrypted.
Your vault passphrase is stretched with PBKDF2-SHA256, 600,000 rounds, with a random salt. The result locks (“wraps”) the master key with AES-256-GCM. That locked copy is what we store.
Your recovery key is 160 random bits, shown to you once as 32 characters. Through HKDF-SHA256 it makes a second key that locks the same master key. That second locked copy is stored too. It’s the only other way in.
From the master key, HKDF-SHA256 makes two working keys: one that encrypts file and folder names, and one that locks each file’s own key.
Every file version gets its own random 256-bit key. The file is cut into 8 MiB pieces, and each piece is encrypted with AES-256-GCM. Each piece carries its position and whether it’s the last one, so pieces can’t be reordered, repeated, cut short or altered without the download failing.

Every encrypted value also carries a label saying what it is (a name, a file key, a piece of a file). So an encrypted name can’t be passed off as a file key, or the other way round.

Where the keys live

On your device, in memory, while your vault is unlocked. The browser holds them in a form that page scripts can use but can’t copy out.
Across a reload, your browser keeps the master key locked under a secret that only our server holds for that sign-in. Neither half is any use alone. The server deletes its half when you lock the vault, when you sign out, after the inactivity time you choose (5 minutes to 4 hours), and after 7 days in any case. After that, a copied browser profile can’t reopen the vault.
On our servers: only the two locked copies of the master key, which we can’t open, and the salts and settings needed to open them on your device.

Your browser refuses a locked copy made with fewer than 600,000 PBKDF2 rounds, or one of the wrong shape. So even a server that tried to trick it couldn’t get it to make passphrase guesses cheaper.

A share link carries its own 128-bit secret after the “#” in the address. Browsers never send that part to any server. The recipient’s browser uses it to unlock the file, then removes it from the address bar and history. If you add a password, it’s checked in a way that needs the link’s secret too, so a copy of our database can’t be used to guess it.

What our servers can and can’t see

We can see

your email address (to send sign-in links and notices);
how much you store and download;
the size and time of each upload;
how many files and folders you have, and how they nest;
when a share link was made, when it expires, and how often it’s used;
your IP address, briefly, to stop abuse;
your plan and payments (through Stripe; we never receive your card number).

We can’t see

the contents of any file;
file and folder names;
file types;
your vault passphrase or recovery key;
share-link secrets and passwords.

Our download servers see your IP address and which encrypted piece you asked for while they send it. They keep no access logs and only ever handle encrypted bytes. The full list of what we keep, and for how long, is in the Privacy Policy.

If you lose your passphrase

You still have your recovery key: on the unlock screen, choose Forgot your passphrase? Use your recovery key, type the recovery key, then Choose a new passphrase. Your files are untouched.
You’ve lost both: your files can’t be decrypted by anyone. We hold no copy of your keys and no way around them. That’s the cost of encryption we can’t undo, and why we ask you to keep the recovery key somewhere safe and offline. You can still close your account: on the unlock screen choose Lost your recovery key too?, confirm from the email we send, and the account is deleted 14 days later, with a one-click way to keep it until then (see the Terms).

Signing in (with an emailed link) and unlocking (with your passphrase) are separate. Getting into your email lets someone sign in, but not open your files.

The honest caveat: it’s a web app

Today Terebyte runs in your browser. Every visit, your browser downloads the app’s code from us and runs it. The encryption is real, but you are also trusting that the code we send is the code we describe. If our servers were taken over, or we were forced to, a changed version could be sent that copies keys as you type them. Every browser-based encrypted service has this limit.

What we do about it today: a strict Content Security Policy lets only our own scripts run on the page, which blocks code injected from anywhere else. It can’t protect you from us. Native apps change this: their code is installed once, signed, and updated in a way you can see, not fetched fresh on every visit. Native apps are what we’re building next.

More detail is in the security whitepaper, and what we do and don’t protect against is in the threat model.