I'm a solo developer building a file encryption tool that runs entirely in the browser. Files and passwords never leave the user's device or get uploaded to a server. It currently uses AES-256-GCM, with PBKDF2-SHA256 and a unique random salt to derive the encryption key from the user's password. The implementation relies on the browser's native Web Crypto API and is intended to have no practical file-size restrictions. What security, performance, usability, or feature improvements would make this tool more useful and trustworthy?
3 Answers
There are several useful product directions beyond the basic encryption flow. You could support the File System Access API where available, use browser-managed storage such as OPFS for temporary work, and provide clear progress indicators and cancellation for large files. File previews for text and images could be convenient, but be careful with previews of untrusted formats such as office documents or media files. Keep parsing isolated and avoid executing any embedded content.
A well-documented file format would also help adoption: include a version number, algorithm identifiers, salt, KDF parameters, nonce information, authentication tags, and a way to detect wrong passwords or corrupted chunks. Consider making the implementation open source after an independent security review, since users will need a way to verify that the zero-knowledge claims match the code.
Trust and transparency may matter as much as the cryptography. Explain exactly what happens in the browser, whether any analytics or third-party scripts are loaded, how passwords are handled, and what happens if the page is refreshed or the device loses power. A strict Content Security Policy and a reproducible, versioned build would make the client-side security model easier to evaluate.
You may also want to offer a command-line or desktop-compatible way to decrypt files. Browser-only tools can be useful, but people are more likely to adopt them if they are not locked into one website or dependent on a particular browser.
The biggest issue is the claim that there are no file-size limits. Web Crypto encryption is generally one-shot, so the whole file may need to be loaded into memory, and the encrypted result can require another large buffer. That can work on desktop for moderately sized files but may crash mobile browsers without a useful error message.
For larger files, consider encrypting fixed-size chunks, such as 16 MB each, and storing a small header with the format version, chunk size, and metadata. Every chunk must have a unique nonce under the same AES-GCM key. Never reuse one, because GCM nonce reuse can seriously undermine authentication and confidentiality. A counter-based nonce or carefully generated per-chunk nonce can work as long as uniqueness is guaranteed.
I’d also reconsider PBKDF2 at 150,000 iterations. Current recommendations are considerably higher for PBKDF2-SHA-256, and Argon2id is generally preferable when you can use a reliable WebAssembly implementation because it is designed to make password guessing more expensive in memory as well as CPU time. Make sure the parameters are documented and stored with the encrypted file so they can be upgraded later.
That makes sense. I had focused mostly on keeping files local, but chunking, a documented format, and making the implementation auditable should be priorities before adding more features.