Client-side encrypted file sharing with Argon2id and AES-256-GCM

Built a disposable file transfer tool with a focus on minimising server-side trust. Wanted to share the architecture and get feedback from people who break things for a living. burnbox.au Crypto stack: AES-256-GCM for file encryption. Argon2id (32MB memory, 3 iterations) for password-protected files. PBKDF2 fallback for devices that choke on WASM. 96-bit unique IV per encryption. Key derived client-side, stored in URL fragment (never transmitted to server). Threat model: Server compromise returns only encrypted blobs. No plaintext filenames (encrypted and padded to 256 bytes). No key material server-side. Burn-after-reading enforced atomically in Postgres (prevents race conditions). Database stores: encrypted blob, padded filename, approximate size, expiry timestamp. Not protected against: Compromised endpoints. Link interception (share via secure channel). Malicious browser extensions. Coercion. Architecture: Static frontend on Netlify. Supabase backend (Postgres + Edge Functions). Retrieve requests proxied through Netlify (Supabase sees CDN IP, not user IP). Row Level Security blocks direct storage access. Downloads only via Edge Function with service role. Source: gitlab.com/burnbox-au1/Burnbox-au Interested in feedback on the implementation. What am I missing? submitted by /u/Necessary_Bed8732 [link] [comments]Technical Information Security Content & DiscussionRead More