Zero-knowledge architecture

Zero-knowledge means the service can store and serve your data without ever being able to read it. Your file contents are encrypted on your device with keys derived from a passphrase we never receive. Even with full administrative access to the database and storage, we cannot reconstruct your files, and neither can anyone who compels us to hand over what we have.

It does not mean we store nothing. Running a usable drive requires some metadata , sizes, chunk counts, timestamps. The honest version of the claim is: encrypted content stays encrypted, and we are explicit about every piece of metadata that is not.

Here is the full inventory of what lands in our database for a typical file and its folder.

• •Your passphrase. It is never transmitted and never stored, not even as a hash. It exists only in your device's memory while your vault is unlocked.
• •Your encryption keys. The CEK and the passphrase-derived KEK are computed and used entirely client-side.
• •Your plaintext file contents. The server only ever handles already-encrypted chunks.
• •Your folder names. These are encrypted on your device before upload.
• •Your X25519 private key. The private half of your sharing keypair is wrapped under your passphrase before it is stored; we hold only ciphertext we cannot open.
• •Shared-space keys. When you share, the key is sealed to the recipient's public key; only their private key can open it, never the server. See below.
• •Any per-folder password. A protected folder is verified locally; the password never reaches us. See per-folder encryption.

Sharing with another zcrypt user does not open a back door. Every account publishes an X25519 public key to a registry we keep in the clear, while the matching private key is wrapped under that user's passphrase and is opaque to us. To share a space and its files, your device seals the space key to the recipient's public key, an operation only their private key can reverse.

• •We store the sealed grant and the space-wrapped file envelopes, and can read neither. The plaintext space key exists only on members' devices.
• •The server is a directory of public keys and a courier for sealed blobs, never a party to the key exchange itself.
• •Removing a member rotates the space key and re-seals it to whoever remains, so a revoked grant opens nothing.

We will not over-claim here. Folder names are fully encrypted client-side: the database stores only an opaque encrypted_name blob it cannot read. File names are encrypted the same way: every upload must send an opaque encrypted_name (the server refuses uploads without one) and the legacy plaintext original_name column stays empty. That legacy column still exists and can hold plaintext for files uploaded long ago; the web app re-seals those names automatically when you unlock your vault and list your files.

• •Folder structure and folder names are private. A locked vault shows folders as [locked].
• •Older files may still carry a plaintext name in the legacy metadata column until your web app has re-sealed it. New uploads do not.
• •File contents are unaffected. Names are metadata; the bytes inside every file are encrypted regardless.

Other labels are sealed too: timed-vault names, snapshot labels, sync-folder paths, decoy file names, Send and folder-link display names, and Space names and descriptions are sealed on your device and carry an enc1: prefix. Rows saved before sealing shipped stay plaintext until they are saved again.

There is exactly one surface that is not zero-knowledge, and we would rather you hear it from us. To push and pull encrypted chunks on your behalf, the server has to use your storage-provider credentials (GitHub, GitLab, Hugging Face, Telegram). Those tokens are encrypted at rest, but not with your passphrase. They are encrypted with a key the server itself can derive.

• •The server holds a single MASTER_KEY and derives a per-user Key Encryption Key from it using HKDF-SHA256.
• •That KEK encrypts your storage-provider tokens with AES-256-GCM before they touch the database, never plaintext at rest.
• •This lets zcrypt act on your storage account, but it does not give the server any ability to read your files: the tokens unlock the repository, and the repository holds only ciphertext.

• •Encryption model: the algorithms and the upload pipeline
• •Storage obfuscation: how stored chunks are made unremarkable
• •Threat model: the full list of what is and isn't covered
• •Zero-knowledge encryption, the feature tour