Zero-Knowledge File Sharing: What It Actually Means

"Zero-knowledge" is one of the more abused phrases in privacy marketing. The term comes from formal cryptography (Goldwasser, Micali, Rackoff, 1985) where it has a strict mathematical definition. In file-sharing land it's been stretched to mean almost anything.

Let's separate the real thing from the marketing.

The strict definition

In cryptography, a zero-knowledge proof lets one party prove something to another without revealing how they know it. In product terms, the practical use is simpler: a zero-knowledge service is one where the service operator has zero ability to read user content. Not "we promise not to look." Not "we encrypt at rest." Zero — as in mathematically impossible without the user's key.

How Zippd implements zero-knowledge

The architecture has three parts:

1. Key generation on-device. Your browser creates a random AES-256 key. The key never crosses our network.
2. Encryption before upload. The file gets gzipped and encrypted with AES-256-GCM in your browser. Only ciphertext leaves your machine.
3. Key transport via URL fragment. The base64-encoded key sits in the URL after #k=. Browsers don't transmit fragments. The recipient's browser parses the fragment locally and uses it to decrypt.

The result: our database stores opaque ciphertext. Our logs contain hashes, not plaintext. Our admin panel can't decrypt anything. That's E2EE, expressed differently.

Three tests for "is this actually zero-knowledge?"

1. The DevTools test

Open the upload page in Chrome DevTools. Watch the Network tab when you upload. Real zero-knowledge services upload random-looking bytes. You should see no plaintext filename, MIME type, or content in the request bodies.

2. The URL test

Look at the share URL after upload. Real zero-knowledge services put the decryption key in the URL fragment (after #). Without that fragment, the file is unrecoverable — by anyone, including the service.

3. The "lost key" test

Ask: "if I lose this URL, can the service recover my file?" If the answer is yes, they have your key — not zero-knowledge. If the answer is "no, that's gone forever," you're on the real thing.

What zero-knowledge does NOT mean

Plenty of "zero-knowledge" services still know plenty about you. Honest disclosure:

• We know your account email (if you registered).
• We know the size of your ciphertext, which gives an upper bound on plaintext size.
• We know when you uploaded and when downloads happened.
• We know the HMAC of your IP (not the IP itself — rate-limiting only).

Zero-knowledge applies to file content. It doesn't mean we know absolutely nothing about your usage patterns. Be wary of services that claim total opacity — they're either lying or have built something that doesn't work as a usable product.

Why services oversell "zero-knowledge"

It's a strong-sounding term that's hard for users to verify. Adding it to a landing page costs nothing. Some specific abuses to watch for:

• "Zero-knowledge passwords." Sometimes means client-side hashing — better than plain HTTPS, but doesn't make the service zero-knowledge overall.
• "Zero-knowledge architecture" with a search-inside-files feature. If they can search, they can read.
• "End-to-end zero-knowledge" with password reset for encrypted content. Mutually exclusive features.

The tradeoffs we accept to stay zero-knowledge

Real zero-knowledge has real costs:

• No "browse my files" search across the whole DB. We can list files by ID but can't query content.
• No image previews. We don't know what's in the file to render a thumbnail.
• No "smart" categorization. Same reason.
• No content moderation. We rely on aggressive expiry and recipient abuse reports instead.
• No way to recover lost files. The key is yours; we never have it.

Comparison: services and their honesty about zero-knowledge

FAQ

What's the difference between zero-knowledge and end-to-end?

Often used interchangeably, with a subtle distinction: E2EE describes the transit model (encrypted between endpoints). Zero-knowledge describes the service's position (cannot read user content). A correctly-built E2EE service is also zero-knowledge.

Can you prove you're zero-knowledge?

The crypto runs in browser JavaScript you can audit. Open DevTools, look at our crypto.js, follow the data flow. Independent audit isn't on the public roadmap yet but the design is verifiable individually.

If you're zero-knowledge, how do you handle abuse?

Recipient-side reports. The share URL is public; abuse reporters submit the URL and we delete the ciphertext. We can act on the public ID without ever needing to see contents. Anti-abuse architecture explained.

What can you still see?

Ciphertext size, public ID, upload timestamp, expiry, owner ID (if registered), HMAC of IP. Nothing about the file itself.

Test the model yourself

Upload a file and watch DevTools while it goes. You'll see only ciphertext leave your machine.