Security
Threat model
A security tool is only as honest as its threat model. Here is what zcrypt is designed to stop, what it cannot, and why, so you can decide whether it fits your situation rather than taking a slogan on faith.
What zcrypt protects against
The architecture is built so that the most likely and most damaging server-side compromises yield nothing usable.
- •Server or database breach. An attacker with our full database gets ciphertext, wrapped keys they cannot unwrap, and bcrypt hashes. File contents stay sealed.
- •Storage-provider access. Your chunks live on GitHub, GitLab, Hugging Face, or Telegram: all of which see only encrypted
.binblobs, never plaintext. - •Man-in-the-middle. Transport is TLS, and the payload is already encrypted client-side, so intercepting traffic reveals ciphertext on top of ciphertext.
- •Insider access. No one operating zcrypt can read your files. There is no internal tool, key escrow, or admin override that decrypts user data, the keys simply are not on our side.
- •Metadata leakage. Folder names are encrypted client-side, and stored chunks are disguised with random filenames, plausible repository names, and generic commit messages. See storage obfuscation.
What it does not protect against
No client-side encryption scheme can defend everything. These are the real gaps, stated plainly.
- •A compromised device. Encryption happens on your machine, so malware or a keylogger that already has your device can capture your passphrase as you type it or read decrypted data from memory. Endpoint security is on you.
- •Metadata the server can see. Names are sealed, but the server still knows file sizes, timestamps, and the sharing graph (who shared what with whom). IPs in sessions and logs are coarsened to a /24 (IPv4) or /48 (IPv6) network, but a network-level view remains.
- •A weak passphrase. 600,000 PBKDF2 iterations slow guessing down dramatically, but they cannot save a passphrase that is short or common. If it can be guessed, the derived key can be reproduced.
- •Frontend supply-chain risk. The web app is code we serve, so in principle a compromised build could be made to exfil a passphrase. This is mitigated by the project being open source (you can audit and self-host it) and by an enforced Content-Security-Policy, but you still trust the JavaScript the site serves. The desktop app does not load code from the site and is the stronger option.
The honest summary
zcrypt removes us and the storage providers from your trust boundary. It cannot remove your device or the strength of your passphrase from it: those remain yours to protect.At a glance
| Threat | Covered? | Why |
|---|---|---|
| Database / server breach | Yes | Only ciphertext and unusable wrapped keys are stored |
| Storage provider snooping | Yes | Providers hold encrypted .bin blobs only |
| Network interception (MITM) | Yes | TLS plus client-side encryption |
| Malicious or compelled insider | Yes | No keys exist on the server to misuse |
| Folder-name / storage-name leakage | Yes | Encrypted names + disguised storage |
| Sizes, timestamps, sharing graph | No | Visible to the server |
| File-name leakage | Partial | Older files may keep a plaintext name until the web app re-seals it |
| Storage-token theft from server | Partial | Tokens are encrypted at rest under a server master key |
| Compromised user device | No | Plaintext and passphrase are exposed on-device |
| Weak / reused passphrase | No | A guessable passphrase reproduces the key |
| Frontend supply-chain attack | Partial | Mitigated by open source and self-hosting |
The two “partial” rows on file names and storage tokens are explained in full in zero-knowledge architecture . We would rather flag them here than quietly mark everything green.
Reducing your exposure
- •Use a long, unique passphrase from a password manager. This is the highest-leverage thing you can do.
- •Enable TOTP two-factor authentication on your account, covered in key management.
- •Keep the device you use with zcrypt patched and free of untrusted software.
- •For the strongest assurance, audit the open-source code or use the desktop app, which avoids browser-delivered JavaScript.
- •Put sensitivity-by-name files inside an encrypted folder rather than relying on the file name being hidden.