Zero-Knowledge Architecture: Why the Server Can't See Your Files

Zero-knowledge architecture means the service provider has no technical ability to read your files — the encryption keys never reach their servers, and there's no master key, no back door, no "trust us" required. Your browser encrypts files with AES-256-GCM before upload using a key it generated locally, and that key travels to the recipient only through the URL fragment after #, which browsers never transmit to servers. Even under a valid subpoena, the provider can produce only ciphertext. This is the model used by Tresorit, Proton, SwissTransfer, and HexaTransfer, and it's mathematically different from "encrypted at rest."

The proof is in what the server can produce

The cleanest test of zero-knowledge: what could the company hand over if compelled? In traditional cloud storage (Google Drive, Dropbox, OneDrive), the answer is: your files, in plaintext. Google's 2023 transparency report shows they complied with 83% of US government data requests, producing user content where legally required. That's not a failure of Google's security — it's how the architecture works.

With zero-knowledge, the company can produce:

Encrypted file blobs (useless without the key)
Account metadata (email, signup IP)
Upload and download IP addresses, timestamps
Payment information if applicable

They cannot produce filenames, content, recipient identity, or decryption keys. Not because they refuse — because they don't have them.

The URL fragment trick, explained precisely

The core technical move is using the URL fragment as a covert key channel. When a browser requests https://hexatransfer.com/d/xyz789#k=BASE64KEY, it sends only GET /d/xyz789 to the server. The fragment stays in the browser's address bar. JavaScript then calls window.location.hash to read the key and passes it to crypto.subtle.decrypt().

This was pioneered by Mega.nz around 2013 and refined by Firefox Send before Mozilla shut it down in 2020. The pattern is now standard. The server-side logs, including access logs on nginx or Caddy, never capture the fragment because HTTP RFC 3986 defines it as client-side only.

A provider could theoretically log the fragment via client-side JavaScript, which is why zero-knowledge services publish their client code for inspection and often ship it as signed static assets served from a separate origin.

Why this differs from "encrypted at rest"

Every cloud provider encrypts files at rest — it's table stakes and usually required by SOC 2 Type II and ISO 27001 certifications. But "encrypted at rest" with provider-held keys means the encryption is invisible to attackers with stolen disks and invisible to you in the sense that the provider decrypts automatically on request.

Zero-knowledge flips the key custody: you hold the key, the provider holds the ciphertext. The provider gains nothing by decrypting because they can't. This matters under three specific threats:

Rogue employees. A provider employee with database access sees only ciphertext.
Government requests. GDPR Article 48 and US CLOUD Act requests can compel disclosure, but you can't disclose what you don't have.
Server breaches. The 2021 LastPass breach exposed encrypted vaults; weak master passwords still got cracked, but the zero-knowledge design prevented mass plaintext exposure.

What's encrypted, what's metadata

A naive implementation encrypts file contents but leaves filenames, sizes, and folder structure visible. True zero-knowledge encrypts the filename too, typically by prepending a JSON header like {"name": "Q4-financials.pdf", "type": "application/pdf"} to the file bytes before AES-GCM encryption.

Metadata that's hard to hide:

File size — ciphertext length approximates plaintext length. Padding to fixed buckets (1 MB, 10 MB, 100 MB, 1 GB) obscures this but wastes bandwidth.
Upload timing — correlating timestamps with other data can still leak information.
IP addresses — the provider sees who uploaded and downloaded. Pair with Tor or a trusted VPN if this matters.

Proton and Tresorit publish detailed metadata exposure matrices. SwissTransfer and HexaTransfer take a simpler approach: minimal metadata, short retention (24 hours to 7 days), and no account linkage for free transfers.

The authentication problem

Zero-knowledge creates a challenge: if the server can't decrypt your files, how does it authenticate you to prevent strangers from downloading? Three common patterns:

Link-based auth. Possession of the URL (and fragment) is authorization. Used by SwissTransfer, HexaTransfer, Tresorit Send. Simple, works without accounts.
Password-protected links. The URL fragment contains a salt; the actual key is derived with PBKDF2 from the password. The server stores a verifier (hash of the key) to reject wrong guesses quickly.
Account-bound zero-knowledge. Proton and Tresorit derive your master key from your login password via Argon2id, then use it to unlock per-file keys stored encrypted on the server.

Each has tradeoffs. Link-based is simplest but leaks the key to anyone who gets the URL. Password-protected adds a second factor. Account-bound requires trusting the client code to not exfiltrate the master key.

Implementation pitfalls that break zero-knowledge

Several real-world failures worth knowing:

Server-side file previews. If the provider generates thumbnails or extracts text for search, they need plaintext. Zero-knowledge services can't offer these features on encrypted content.
Sync conflict resolution. Comparing file contents across devices normally requires plaintext. Syncthing and Cryptomator handle this with client-side diffs.
Analytics SDKs. Third-party scripts from Google Analytics or Segment can read window.location.hash in client code. Zero-knowledge services either self-host analytics or strip fragment access.
Password reset. If the provider can reset your password and still give you access to old files, they must hold a recovery key — which breaks zero-knowledge. Proton warns explicitly that password reset means losing encrypted data.

Who actually delivers zero-knowledge

A short list of services with credible zero-knowledge claims, verified by third-party audits (Cure53, NCC Group, Trail of Bits):

Tresorit — Swiss, SOC 2 Type II, zero-knowledge file sync and Send.
Proton Drive — Swiss, based on the Proton Mail cryptography model.
SwissTransfer — free tier with optional E2EE, run by Infomaniak.
Mega.nz — New Zealand, published cryptography whitepaper.
HexaTransfer — browser-based, no account, 10 GB per transfer.

Services that are encrypted but not zero-knowledge: Google Drive, Dropbox, OneDrive, Box, iCloud (except Advanced Data Protection tier), and WeTransfer standard tier.

Putting it into practice

Before trusting a service with sensitive files, run this checklist:

Does the privacy policy state the provider cannot read your files?
Is there a published security whitepaper naming AES-256-GCM and the KDF?
Does the share URL contain a fragment (text after #)?
Are there third-party audit reports from the last 24 months?
Is the client code open source or at least auditable?

Four yeses means you've found a zero-knowledge service. Three or fewer means the provider can see your files.

Try it at hexatransfer.com — free, no account, 10 GB max.