Zero-knowledge6 min read•
What zero-knowledge encryption really means
Zero-knowledge is a precise architectural claim, not a marketing word. Here is what it actually requires — and how to tell when a cloud truly qualifies.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
A precise claim, not a slogan Zero-knowledge encryption describes a service architecture in which the provider has no technical ability to access user data. It is a statement about *what is possible*, not about *what is promised*.
A traditional cloud provider may sincerely promise to behave well, but if their servers can decrypt your files, that promise depends entirely on policy and on trust. Zero-knowledge removes that dependency.
The three architectural requirements - **Keys derived on the client.** Your password is processed on your device — typically with a memory-hard KDF such as Argon2id — to derive a master key. - **Keys never transmitted unencrypted.** The server may store *wrapped* (encrypted) keys, but never the plaintext keys themselves. - **No server-side decryption path.** There is no admin override, no key escrow, no support tool that can read your content.
How to test a vendor's claim Ask three questions: - Where is my master key generated? - Can your staff reset my password and still recover my files? - What does your server actually receive when I upload a file?
The honest zero-knowledge answers are: *on my device*; *no*; *ciphertext only*.
Why this matters Confidentiality by architecture is robust to staff changes, policy changes, court orders and server compromise. Confidentiality by promise is robust only as long as the promise holds.
How DRIVUNO implements it Your password is stretched on your device with Argon2id. The resulting master key wraps a per-file encryption key and a private signing key. Servers store only ciphertext and wrapped keys. There is no server-side decryption path — by design.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.