How DRIVUNO encrypts files before upload

What happens when you drop a file - The browser reads the file in chunks. - For each chunk, a unique nonce is generated. - The chunk is encrypted with XChaCha20-Poly1305 using the per-file key. - An authentication tag is produced for each chunk. - The encrypted chunks are uploaded.

What the server stores The server stores ciphertext chunks, the wrapped per-file key, and minimal metadata (object id, size, timestamp). That is it.

Why chunked encryption Chunked AEAD allows large files to be streamed and resumed, with each chunk individually authenticated. Tampering with any chunk breaks decryption for that chunk and is detected.

What is not stored We do not store the plaintext filename inside the ciphertext envelope unless it is wrapped. We do not produce server-side thumbnails. We do not run OCR or content classification.

Step by step, inside your browser 1. Your password is processed locally with Argon2id to derive a master key. The password itself is never sent. 2. A fresh 256-bit content key is generated for each file using a CSPRNG. 3. The file is encrypted with XChaCha20-Poly1305 — an authenticated cipher that detects any tampering. 4. The content key is wrapped using your account's X25519 sealed-box public key. 5. Only the ciphertext and the wrapped key are uploaded.

What happens if you share To share a file, your client unwraps the content key locally, then re-wraps it for the recipient's public key. The server only ever brokers ciphertext. Revocation deletes the recipient's wrapped key — they no longer have the ability to decrypt new accesses.

Why "before upload" is not just a slogan If encryption happens after the upload, there is by definition a moment when the server holds your plaintext. That window is enough for backups, logs, AI scanners and incident response to capture readable data. Encryption-before-upload eliminates the window entirely.