Zero-Knowledge: Simple Explanation of Zero-Knowledge Encryption
By Simon Themiot - freelance cybersecurity consultant. Published May 20, 2026.
Summary
- For E2E content, zero-knowledge means the provider does not receive the key needed to read files. It may still hold metadata, and endpoint and client-code security remain decisive.
- It is an architectural property of the cryptographic design, not merely a contractual promise: the server does not receive the E2E key. It still assumes an uncompromised browser, device, and served JavaScript.
- Very few file transfer services are truly zero-knowledge. Most encrypt your files with their own key that they store on their own servers.
Table of contents
1. The safe analogy
Imagine you want to send a confidential document to a colleague. You have two options:
Option A: Regular mail (= standard cloud)
You give your open document to the postman. He puts it in an envelope locked with a key. He keeps the key. He delivers the envelope to your colleague. The postman promises not to open the envelope. But he could. And if someone steals his key, they could too.
Option B: Personal safe (= zero-knowledge)
You put your document in a safe whose combination YOU hold. You give the locked safe to the postman and send the combination to your colleague through a suitable channel. The postman cannot open it, and stealing the safe in transit is not enough to reveal the document.
Zero-knowledge is option B applied to digital. The provider transports your data without ever being able to read it.
2. Technical definition
A service is called "zero-knowledge" when it meets these three conditions:
- Data is encrypted before leaving your device (client-side encryption, in the browser or application).
- The encryption key is never sent to the provider's server, nor stored by them, in any form.
- The provider cannot reconstruct the key, even by combining all information they have on their servers.
In this context, "zero-knowledge" means that the server has no knowledge of the plaintext content. It sees ciphertext and the metadata needed to provide the service, but does not hold the key required to recover the content.
3. How it works in practice
On a zero-knowledge file transfer service like PrivCloud, here is what happens technically when you share a file:
- Key generation: Your browser generates a random 256-bit key (AES-256-GCM) using the built-in
Web Crypto API. This key is created locally. - Local encryption: A Web Worker encrypts the file in independent 1 MB AES-256-GCM records. When E2E is enabled, the plaintext file is never sent to the server.
- Encrypted upload: Records are grouped into adaptive transport chunks and uploaded. The server sees ciphertext and the metadata required for sharing, not the plaintext content.
- Key goes in URL fragment: The key is placed after the
#in the sharing URL. Example:https://share.privcloud.fr/s/abc123#KEY_HERE. By HTTP protocol design, the fragment (everything after#) is never transmitted to the server. It stays in the browser. - Link sharing: You send the complete link (with fragment) to your recipient.
- Decryption by recipient: The recipient's browser extracts the key from the URL fragment and decrypts the stream locally. The server never received the key or plaintext content.
4. What happens without zero-knowledge
On WeTransfer, Dropbox, Google Drive, SwissTransfer and most cloud services, here is the actual flow:
- Your file is sent in plaintext from the service's perspective, while TLS protects it in transit.
- The server receives the file in cleartext. It encrypts it with its own key that it generates and stores.
- When the recipient downloads, the service authorises access and returns the content over TLS.
In this model, the provider's infrastructure can technically access the content. Encryption at rest remains useful against theft, loss, or improper disposal of storage media and against some storage-only access; however, it creates no cryptographic barrier against the provider, a valid legal demand, or a compromise that also reaches the key service.
5. How to know if a service is zero-knowledge
Here are concrete indicators to identify a true zero-knowledge service:
- For E2E link sharing, the fragment after
#can carry the key: this is the model used by PrivCloud. Its absence is not proof by itself, since another service may distribute keys through accounts or an application. - The source code is open: You can inspect the JavaScript code to verify encryption happens in the browser before upload.
- For link sharing, losing the fragment means losing the key: the provider must not be able to reconstruct it. Team spaces may instead redistribute an encrypted key among authorised members without revealing it to the server.
- Technical documentation is transparent: The service publishes a security model explaining where and how encryption occurs.
- The Network tab provides evidence: uploaded content must already be encrypted and expose no plaintext file data. A code and protocol audit is still needed to reach a conclusion.
6. FAQ
Are zero-knowledge and end-to-end encryption the same thing?
The concepts overlap, but they are not synonyms. End-to-end encryption describes the protected path between authorised clients. Zero-knowledge describes what the provider can learn or reconstruct. An implementation must also document visible metadata, key distribution, and the client-code trust model.
If I lose the link, do I lose the file?
Yes. For a link share, if the full link and its key are lost, the provider cannot recreate the key. Team shares use a different mechanism: file keys are wrapped for authorised members, enabling collaboration and assisted rotation without giving the keys to the server.
Does zero-knowledge slow down transfer?
It adds CPU work and memory copies, especially in a browser. On a recent machine, the network is often the main bottleneck, but this is not guaranteed: hardware, browser behaviour, chunk sizing, and disk writes also affect throughput. The architecture separates 1 MB cryptographic records from adaptive network chunks to limit that overhead.
Related articles
Try zero-knowledge yourself
PrivCloud is a temporary sharing application, not a cloud-storage service. AES-256-GCM E2E encryption can be enabled in the browser, with a URL-fragment key for link shares. Up to 2 GB without an account and 3 GB with a Free account.
Last updated: July 14, 2026.