Zero-Trust File Sharing: Trust Nobody, Encrypt Everything

Zero-trust file sharing assumes the network is hostile, the server is compromised, and the recipient's device may be infected — then encrypts accordingly. Files get encrypted in the sender's browser with AES-256-GCM before any byte hits the wire, keys derive from a password plus a salt stored in the URL fragment, and the server handles only opaque ciphertext. This is the operating model codified in NIST SP 800-207 applied to file transfer: verify explicitly, grant least privilege, and assume breach at every layer.

The three assumptions that drive the design

Zero trust starts with three premises. First, the transport is compromised — corporate proxies do TLS inspection, coffee shop Wi-Fi runs ARP spoofing, and nation-state backbone taps exist (documented by Snowden in 2013, still operational per Bloomberg's 2024 reporting). Second, the server is compromised — cloud providers get breached (AWS in 2019, Microsoft in 2023), admins go rogue, and subpoenas arrive quietly. Third, the recipient's device may be infected — an employee's laptop runs an outdated Chrome, malware harvests decrypted files. Every design decision flows from these three assumptions.

Client-side encryption as the first principle

If the server can see plaintext, it's not zero trust. Everything begins with the sender's browser running the Web Crypto API: generate a 256-bit key, derive it from the user's password with PBKDF2 at 600,000 iterations, encrypt the file with AES-256-GCM, and only then stream the ciphertext to the server. Firefox Send proved this worked at consumer scale before Mozilla shut it down in 2020. Modern successors — HexaTransfer, Wormhole, Skiff — pick up the pattern. The server holds bytes it cannot read.

Key material never leaves the endpoints

The decryption key must reach the recipient without touching the server. Two mechanisms work. First, the URL fragment trick: the key lives after # in the download URL, which browsers never send in HTTP requests. Second, password-derived keys: the sender tells the recipient a password through a separate channel (Signal, phone call, 1Password Psst!), and the recipient's browser re-derives the key. Both keep key material out of server logs, CDN caches, and database backups — which matters when the inevitable breach happens.

Verifying the code that runs in the browser

Zero trust on the client is harder than on the server because the server ships the JavaScript that does the encryption. A malicious server could push a backdoored bundle to one targeted user. Mitigations: publish SHA-384 hashes of every release, sign them with Sigstore or a corporate PGP key, and encourage power users to verify with browser extensions like Code Verify (Meta ships this for WhatsApp Web). CSP headers with script-src 'self' and Subresource Integrity block injection from compromised CDNs. None of this is perfect, but it narrows the attack surface.

Authentication without shared secrets stored at rest

Passwords sent over email and stored in server databases are the antithesis of zero trust. Replace them with WebAuthn passkeys bound to the recipient's device — the private key never leaves the Secure Enclave, and the server stores only the public key. For one-off transfers, use OPAQUE (RFC 9380) for password authentication that never transmits or stores the password server-side. Magic links sent to pre-verified email addresses offer a middle path: the token's entropy (128 bits) replaces the need for a stored secret.

Segmenting transfers by sensitivity

Not every file deserves the same controls. A zero-trust file-sharing service should let senders classify uploads: public (no password, 7-day expiry), internal (password, 48-hour expiry), confidential (password + 2FA, 4-hour expiry, single download), restricted (passkey + IP binding + 15-minute expiry). Automate classification by file type when possible: .pdf tax returns → confidential; .docx contracts → internal; .psd marketing comps → public. NIST SP 800-171 calls this controlled unclassified information handling, and it maps cleanly onto transfer workflows.

Treating the recipient's device as untrusted

Once Bob decrypts Alice's 5 MB legal brief, it sits in his Downloads folder. If his laptop is compromised, the file leaks. Zero-trust thinking extends here: encourage recipients to decrypt into ephemeral storage (Tails OS, a Chrome OS guest session), avoid decrypting on shared machines, and wipe aggressively after use. For high-stakes transfers, use protected viewers that decrypt into a sandboxed browser tab and prevent download — the recipient sees the .pdf but never gets the bytes on disk. Obviously this is a UX hit; reserve it for the top tier.

Logging without becoming a surveillance system

A zero-trust audit trail logs what it must for incident response and compliance, nothing more. Hash IP addresses daily, store only User-Agent families (not full strings), never log passwords or keys, and retain for the minimum period each regulation requires — 90 days for GDPR Article 30 purposes, 6 years for HIPAA 164.316. The log itself lives on append-only storage (S3 Object Lock, compliance mode) so a compromised admin can't cover their tracks. Publishing Merkle roots daily to a public bulletin board adds external verification.

Where zero trust meets legal reality

Zero trust doesn't exempt you from law enforcement requests. It changes what you can hand over — ciphertext you can't decrypt, IP hashes you can't reverse, logs of who accessed what slug. That's usually enough to satisfy a valid warrant while keeping user data private from mass surveillance. Publish a transparency report (Twitter's old model) showing request volumes and response rates. Document your data minimization in the privacy policy so users understand the tradeoffs: you can verify a file was transferred, but you can't read it or identify the recipient with certainty.

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