Transfers
How it works
Every transformation that protects a file happens on your device, in order, before a single byte leaves it. This is the whole journey, and downloading runs it precisely in reverse.
The short version
When you add a file, zcrypt splits it into chunks, then compresses and encrypts each chunk, all on your device: then pushes those chunks to repositories in your own connected account. The plaintext never leaves your machine, and your passphrase never leaves your browser.
chunk (4 to 16 MiB) → compress (zstd) → encrypt (AES-256-GCM) → upload to your storage1. Chunk (4 to 16 MiB)
The file is split into chunks sized to your device (4, 8, 10 or 16 MiB; 10 MiB is the usual). Chunking keeps each piece within platform file-size limits, enables parallel and resumable transfers, and means one failed piece can be retried without re-sending the whole file. Each chunk then goes through the next two steps on its own, and every stored chunk is given a randomized filename.
Chunk size per device
~10 MB is the typical size. zcrypt picks 4, 8, 10 or 16 MB based on your device, trading memory for throughput.2. Compress (zstd)
Each chunk is compressed on your device with Zstandard (zstd). This happens before encryption, while the data is still readable and therefore still compressible: encrypted data looks random and cannot be shrunk. zcrypt skips file types that are already compressed, and keeps the compressed chunk only if it is at least 5% smaller. Smaller payloads mean less of your storage used and faster uploads.
3. Encrypt (AES-256-GCM)
Each compressed chunk is encrypted with AES-256-GCM. zcrypt generates a random content encryption key (CEK) for the file, then wraps (encrypts) that CEK with a key derived from your passphrase. The wrapped CEK travels with the file's metadata; the passphrase itself never does.
Why this makes zcrypt zero-knowledge
The server only ever receives ciphertext and a wrapped key it cannot open. Even if the server, the database, and your storage platform were all compromised at once, your files would stay unreadable, because the key that unwraps the CEK exists only on your device, derived from a passphrase we never see.4. Upload to your storage
Each encrypted chunk is pushed to the platform you connected. GitHub, GitLab, Hugging Face, or Telegram: stored as an ordinary-looking binary blob under disguised filenames and commit messages. When a repository nears its size threshold, zcrypt creates a new one automatically so your vault keeps growing without you managing anything.
The platform sees only opaque data: never your file names, never your content, never your folder structure.
Downloading reverses it
Downloading is the same pipeline run backwards, and every step still happens on your device:
- Fetch the encrypted chunks back from your repositories, several in parallel for speed.
- Verify each chunk against its SHA-256 hash, so a corrupted or tampered piece is caught before it is used.
- Decrypt the reassembled blob locally with the key unwrapped from your passphrase.
- Decompress back to the original file and save it. No plaintext ever touches the server.