Two systems can both say “your files are encrypted” and mean very different things by it. The difference is rarely the algorithm - both will say AES-256. It is where the key lives.
Where the key lives
Encryption at rest means data is encrypted on the disks it sits on, using keys held by the infrastructure. It is the baseline any serious provider should meet, and it defends against a real class of problems: a drive pulled from a rack, a decommissioned server, a misplaced backup tape.
Zero-knowledge encryption, usually called end-to-end, moves the key somewhere else entirely. A key is derived on your own device from something only you know. Your files become ciphertext before they travel anywhere, so what arrives is already unreadable, and what is stored stays that way.
The distinction is not about strength. It is about who holds the means of decryption, and therefore how many parties have to behave correctly for your guarantee to hold.
How the key is actually derived
This is the part worth understanding, because it explains the trade-offs that follow.
A passphrase alone makes a poor encryption key - it is short and people reuse words. So a key derivation function stretches it: Argon2id and scrypt are the modern choices, deliberately slow and memory-hungry so that guessing at scale is expensive. A random salt ensures two people with the same passphrase produce different keys.
The derived key never leaves your device. What leaves is your data, already encrypted under it, plus a wrapped copy of your key material - encrypted under a key derived from that same passphrase. Storing that wrapped blob is safe: it is opaque without the passphrase.
This is also why serious implementations give you a recovery code, typically a long random string shown once and stored by you. The same key material is wrapped a second time under a key derived from that code. Two doors, both of which only you have. Lose both and the data is genuinely gone - which is the guarantee working as designed, not a gap in it.
What this changes in practice
The practical consequence is about blast radius.
When encryption happens on your device, a breach anywhere later in the chain yields ciphertext rather than documents. That includes the parts nobody thinks about: database backups, log files, an analytics pipeline, a support tool with broader permissions than anyone intended, a misconfigured storage bucket.
It also changes the kind of assurance you have. Strong operational security is a promise about behaviour - good people, good processes, sustained over years and through acquisitions and staff changes. Keys that never leave your device are a property of the system. Properties survive reorganisations; promises are harder to verify from outside.
What it costs
End-to-end encryption is not free, and any explanation presenting it as pure upside is selling something.
Server-side features disappear. Full-text search across your files, thumbnail generation, in-browser document previews, virus scanning, content indexing - all require reading the content. They either move onto your device, with the performance limits that implies, or they stop existing.
Protocol access stops being useful. WebDAV, S3 and SFTP hand over whatever bytes the server holds. For end-to-end encrypted content those bytes are ciphertext, and the server has no key to turn them back into a file - so a mounted drive shows you unreadable blobs rather than your documents.
This is a property of where the key lives, not a limitation of the protocols
themselves: a client that holds the key can encrypt before upload and decrypt after
download over any of them, which is exactly what rclone’s crypt backend does. But
then the client is doing the work, and the server-side features you mounted the
drive for - search, previews, thumbnails, server-side copy - are gone anyway.
For that reason the dosya.dev Vault is not exposed through our S3, WebDAV or SFTP gateways. It is a separate, opt-in space rather than a setting applied to everything you store.
Sharing gets more complex. Giving someone access means re-wrapping keys for their identity, so sharing must be modelled explicitly rather than granted with a URL. Revoking access is harder still: you can stop issuing new keys, but you cannot un-see what someone already decrypted.
You lose the safety net. Key material you hold is key material you can lose, and no support ticket brings it back. That is the same property that makes the guarantee real.
The browser caveat nobody mentions unprompted
When end-to-end encryption runs in a web page, the code performing it is delivered by a server on each page load. A compromised server could, in principle, serve modified code that captures the passphrase before it is used.
This is inherent to in-browser end-to-end encryption generally, not a flaw in any one product. Native desktop and mobile clients reduce the exposure, because the code ships with the application and updates are signed and comparatively rare.
It does not make browser-based encryption pointless - it still removes the at-rest and backup exposure entirely. But it is a trust-on-first-use model rather than an absolute one, and anyone offering it should tell you so without being asked.
Deciding what you need
Most material does not need end-to-end encryption, and applying it universally would cost you search, previews and protocol access on files where none of that was worth trading.
The question is which files would genuinely damage someone if the storage were breached. Legal documents, medical records, identity documents, unreleased work under embargo, source material for sensitive journalism. Those justify the trade-offs.
For everything else, encryption at rest plus serious account security - two-factor authentication and unique passwords - addresses the risks that actually materialise. And for sharing specifically, the controls usually matter more than the cryptography: our guide to sharing sensitive documents covers the ladder from expiring links up to restricting access by identity.
