What Is Zero-Knowledge Encryption? (Explained Simply)
— Brendan Gray, Founder & Developer, FileShot.io
Zero-knowledge encryption is the architectural difference between a cloud service that could, in theory, hand your files to law enforcement tomorrow — and one that physically cannot. FileShot was built on this model from day one. This is a technical explanation of what zero-knowledge encryption actually is, how it works, and why it matters.
The Core Concept: The Server Is Blind
In a standard cloud service, your files are stored on a server. The server can read them. The company running the server can read them. Governments can subpoena them. Employees can access them. Even if the connection is encrypted in transit (HTTPS), the server decrypts your files on arrival and stores them in a form the provider controls.
Zero-knowledge encryption breaks this assumption:
The server receives only encrypted ciphertext. The encryption key never leaves your device. The service provider has zero knowledge of your file contents — hence the name.
How FileShot Implements Zero-Knowledge Encryption
Here is the exact technical flow when you upload a file to FileShot:
- Key generation: Your browser generates a cryptographically random 256-bit AES key using
window.crypto.getRandomValues()— a hardware-backed random number generator. - Client-side encryption: Your file is encrypted in JavaScript using AES-256-GCM before any network request is initiated. The unencrypted file bytes never leave your device.
- Upload: Only the encrypted ciphertext is transmitted over HTTPS to FileShot's server. The ciphertext is indistinguishable from random noise — the server receives no information about the original file.
- Key delivery: The encryption key is appended to the download URL as a
#fragment— for example:https://fileshot.io/d/abc123#key=YourRandomKeyHere. URL fragments are never sent in HTTP requests by design — browsers strip the fragment before making the network call. FileShot's server therefore never receives the key. - Decryption: When a recipient opens the link, their browser reads the key from the URL fragment, fetches the encrypted ciphertext, and decrypts it locally. Decryption happens entirely on their device.
What this means in practice:
- FileShot cannot read your files — even if it wanted to
- FileShot cannot comply with a government demand for file contents — because it doesn't have them
- A data breach of FileShot's servers exposes only encrypted ciphertext — useless without the keys
- FileShot employees cannot access your uploads
The Cryptographic Primitives: AES-256-GCM
FileShot uses AES-256-GCM — a combination of the most widely vetted symmetric cipher with an authenticated encryption mode:
AES (Advanced Encryption Standard)
AES is the symmetric cipher selected by the US National Institute of Standards and Technology (NIST) after an international competition in 2001. It's used to protect classified US government information including Top Secret data. At 256-bit key length, there are $2^{256}$ possible keys — approximately $10^{77}$. At current computing speeds, brute-forcing a random AES-256 key is physically impossible within the lifetime of the universe.
GCM (Galois/Counter Mode)
GCM is an authenticated encryption mode. It doesn't just encrypt your data — it also generates an authentication tag as part of the operation. This means:
- Confidentiality: The ciphertext reveals nothing about the plaintext without the key.
- Integrity: If any single bit of the ciphertext is modified — by a server-side attacker or a transmission error — decryption fails and the tampering is detected. You cannot silently substitute modified data.
- Authenticity: The tag proves the ciphertext was produced by someone with the key.
GCM is used in TLS 1.3, SSH, IPSec, and is the official recommendation from NIST for symmetric authenticated encryption.
Zero-Knowledge vs. End-to-End Encryption vs. "Encrypted in Transit"
| Model | What provider can see | Example |
|---|---|---|
| Encrypted in transit only | Full plaintext content | Google Drive (standard), Dropbox |
| Encrypted at rest | Full plaintext (provider holds keys) | AWS S3 with AES-256 (server-managed) |
| End-to-end encrypted | Only metadata (who, when, size) | Signal, WhatsApp, FileShot |
| Zero-knowledge | Nothing — not content, not keys | FileShot, ProtonDrive, Tresorit |
The critical distinction: Google encrypts your Google Drive files — but Google holds the keys. Zero-knowledge means the provider is architecturally incapable of decryption, not just promising not to look.
The URL Fragment Key Transport Mechanism
One of the most elegant aspects of FileShot's design is using the URL fragment (#) as the key transport mechanism. This works because of a fundamental property of HTTP:
// Full URL visible to the user (and recipient)
https://fileshot.io/d/abc123#key=dGhpcyBpcyBhIHNhbXBsZSBrZXk
// What the HTTP GET request actually sends to the server:
GET /d/abc123 HTTP/1.1
Host: fileshot.io
// The #fragment is stripped by the browser before the request is made
// The server receives: /d/abc123 — with no key data whatsoever
This means even a fully compromised FileShot server — one that logs every incoming request in full — cannot extract the encryption key from server logs. The key never traverses the network in any server-readable form.
Limitations of Zero-Knowledge File Sharing
Zero-knowledge is not a magic solution that eliminates all risk:
- The URL is the key. If the recipient forwards the link to a malicious party, the file is compromised. The URL is a bearer credential.
- Endpoint security: If malicious code runs on the sender's or recipient's device, it can capture the plaintext before encryption or after decryption. Zero-knowledge protects against server-side threats, not endpoint compromise.
- Metadata: FileShot knows that a file of a certain encrypted size was uploaded at a certain time from a certain IP address. Zero-knowledge protects content — not metadata. For metadata protection, FileShot works over any VPN or Tor connection.
- The JavaScript trust problem: If you don't trust that the JavaScript FileShot serves is actually doing client-side encryption correctly, you'd need to audit the source. FileShot's core ZK library (FileShotZKE) is GPL v2 open source on GitHub — you can read and verify the encryption implementation yourself.
Zero-Knowledge in the Real World: Use Cases That Demand It
- Journalists and sources: Sharing documents with reporters without creating a server-side record of the content
- Legal teams: Sharing attorney-client privileged files that cannot be disclosed even under subpoena to the file host
- Healthcare: Transferring patient records where any server-side storage could trigger HIPAA requirements
- Security researchers: Sharing vulnerability disclosures, exploit code, or sensitive findings
- Personal privacy: Sharing files without any company building a profile of what you share and with whom
Who Else Uses Zero-Knowledge Architecture?
- ProtonMail / ProtonDrive: End-to-end encrypted email and cloud storage from CERN researchers
- Tresorit: Enterprise zero-knowledge cloud storage
- Standard Notes: Zero-knowledge encrypted note-taking
- Bitwarden: Zero-knowledge password manager (open source)
- Signal: End-to-end encrypted messaging
FileShot belongs to this category — privacy is the architecture, not a feature toggle.
FileShot: Zero-Knowledge File Sharing
AES-256-GCM encryption in your browser. Keys in the URL fragment. Server is blind. Free for files up to 10 GB.
Further Reading
- FileShot Technical Whitepaper — full cryptographic specification, key derivation, and threat model
- What Is End-to-End Encryption? — a gentler introduction to the concepts
- How to Encrypt a File — practical guide for encrypting files before sharing
- Secure File Transfer Guide — methods compared by security model