FileShot.io — practical zero-knowledge file sharing (client-side AES-256-GCM)

[FileShot]

FileShot.io is a live example of zero-knowledge architecture in a file sharing context — files are encrypted with AES-256-GCM in the browser before upload, using the Web Crypto API. The server truly never sees plaintext.

Could be useful in the "Encryption" or "Tools" sections as a reference implementation or practical tool:

• Decryption key stored only in the URL fragment, never sent to the server
• No server-side key storage or key derivation
• MIT licensed, self-hostable: https://github.com/FileShot/FileShotZKE
• Link: https://fileshot.io

[paragonie-security]

You made 3 different issues (this one, #99, and #98) to promote your project. You call "zero-knowledge architecture" and your repository describes it as "zero-knowledge encryption".

I'm inclined to reject it simply because "zero-knowledge" describes a class of proof algorithms. Encryption is not a proof system, and is not "zero-knowledge". Architectures are not "zero-knowledge".

But, then I looked at your code out of curiosity. It does the following:

1. Relies on password hashing for randomness, using PBKDF2 with an iteration count appropriate for interactive logins, not encryption.
   • With a minimum length of 4 characters.
   • The 128-bit random salts should be longer. At least 192 bits is preferable.
2. Encrypts it with AES-256-GCM. This is fine, but neither the encryption nor decryption paths specify a tag length.

This is a very thin wrapper for what JavaScript's crypto.subtle gives you out of the box, and doesn't meet our bar. It's certainly not worth recommending 3 times within the span of 3 hours.

[FileShot]

Apologies for filing three separate issues in quick succession — that was an error on our end, not intentional spam.

You're correct on the terminology. We've been using "zero-knowledge" in the colloquial sense (server never sees plaintext or keys), but you're right that technically this refers to zero-knowledge proof systems. We'll revise the language to "client-side encryption" or "end-to-end encryption" going forward.

Thank you also for reviewing the open-source reference code. The PBKDF2 iteration count, salt length, and GCM tag length issues are valid and we'll address them in the library.

Understood that this doesn't meet the bar for inclusion. We'll close the duplicate issues.