I'm a solo developer building a browser-based file encryption tool. Files and passwords stay on the user's device and are never uploaded to a server. The current implementation uses AES-256-GCM through the Web Crypto API, deriving a 256-bit key from the user's password with PBKDF2-SHA256 and a unique random salt. There are currently no intentional file-size restrictions. What security, performance, usability, or trust improvements would make this more practical and useful?
3 Answers
The biggest issue is the claim that there are no file-size limits. Web Crypto’s encrypt operation is not streaming, so the browser generally has to load the entire file into memory and then create another buffer for the encrypted result. That can mean holding roughly two copies of a large file, which is especially problematic on mobile browsers.
A better design would process the file in chunks, such as 8–16 MB at a time, and store a small header describing the format. Every chunk needs its own unique nonce. Never reuse the same AES-GCM nonce with the same key, even across different chunks. You could use a securely generated starting value combined with a counter, as long as the format prevents reuse and handles interrupted or resumed operations safely.
Also, 150,000 PBKDF2 iterations is fairly dated. Consider using a current, calibrated work factor, or preferably Argon2id through a carefully reviewed WebAssembly implementation. Argon2id is memory-hard and generally more resistant to large-scale password cracking than PBKDF2. Include the salt, KDF parameters, nonce information, version, and authentication metadata in a documented file format so the encrypted files remain portable.
Be careful with the promise that the password never leaves the device. The page itself still has to be trusted: a compromised server, malicious dependency, browser extension, or injected script could potentially read the password before encryption happens. A strict content security policy, dependency pinning, minimal third-party code, secure deployment, and ideally an installable or independently auditable client can reduce that risk.
You should also add tamper detection and clear error handling. AES-GCM gives authentication, but the application needs to verify every chunk and reject altered, truncated, reordered, or duplicated data instead of producing a confusing partial result. A versioned container format and test vectors would make future upgrades much safer.
The local-only approach is a strong privacy feature, but users will need a reason to trust the tool. Publishing the source code, documenting the encryption format, and explaining exactly what the application does would help a lot. A reproducible build or an independently reviewed implementation would be even better.
For usability, consider drag-and-drop, progress reporting, cancellation, and recovery when a large operation is interrupted. Browser storage APIs such as the Origin Private File System can help with temporary files and reduce repeated permission prompts, but you should clearly explain storage limits, browser support, and what happens when the user clears site data. Optional local previews for common text and image files could also be useful, provided previews never upload data or weaken the encryption model.
That makes sense. I was initially planning to keep the implementation closed until it was more polished, but publishing the format and source would probably make the privacy claims much easier to evaluate.