Sealing a 6 GB file without freezing your laptop

Encrypting on the client sounds simple until someone drags a 6 GB video into the window on an eight-year-old laptop. The naive approach — read the file, encrypt it, then upload — needs the whole thing in memory or doubles your disk usage. Either way, the fan spins up and the app stops responding.

When we built AuroVault's sealer, we set one rule: memory use must not depend on file size. A 20 MB spreadsheet and a 60 GB project archive should cost the same RAM. This post explains how we got there.

Sealing as a stream

Instead of treating a file as one blob, the sealer reads it as a sequence of fixed-size windows. Each window is encrypted independently using XChaCha20-Poly1305 and handed to the uploader as soon as it's ready. Only a handful of windows exist in memory at any moment.

Why 4 MiB windows

We tested window sizes from 256 KiB to 64 MiB. Small windows add overhead from authentication tags and nonces; large windows hurt resume granularity and inflate memory. Four mebibytes was the sweet spot on every device class we tried.

• Per-file key: a fresh random key is generated for every file and wrapped by your master key.
• Per-window nonce: derived from the file identifier and window index, so nonces never repeat.
• Bounded queue: at most four windows are in flight, which caps memory near 16 MiB plus a small constant.

Pieces and proofs

Each sealed window is uploaded as its own object. Alongside the data we store a small manifest: an ordered list of piece digests, itself sealed with the file key. The server can confirm it received every piece intact without ever learning what they contain.

Verification happens twice. The uploader checks the digest the server reports back for each piece; later, the downloader checks each piece again before decrypting it. A corrupted piece is re-fetched automatically, and a repeatedly failing one raises a clear error rather than producing a damaged file.

Resuming cleanly

Laptops sleep, train Wi-Fi drops, people close the lid mid-upload. Because pieces are independent, resuming is just a matter of asking the server which digests it already holds and sealing the rest.

1. On restart, the client reads the local upload journal for the file.
2. It requests the list of piece digests already stored for that upload.
3. It re-seals only the missing windows, reusing the original file key.
4. It finalises the manifest once every piece is confirmed.

The journal contains no secrets — just indexes and digests — so it's safe to leave on disk.

What we measured

We sealed and uploaded a 6 GB video file from three machines over the same 500 Mbit/s connection. Figures are medians of five runs, taken in September 2026.

On the faster machines the network is the limit, not the sealer. On the older ultrabook, encryption becomes the bottleneck but the app stays responsive because sealing runs on a low-priority worker.

Try it yourself

The command line tool exposes the same engine. To seal and upload a folder into a space, then check what the server holds:

$ aurovault login
$ aurovault sync ./launch-film --space studio-north
sealing launch-film-final-cut.mov  [##########----------]  52%
$ aurovault ls studio-north --verify
launch-film-final-cut.mov  6.4 GB  pieces 1,600/1,600  ok

Add --limit-cpu 50 if you'd like it to share the machine more politely.

What's next

We're working on content-defined chunking so that small edits to a huge file upload only the changed pieces, without weakening the sealing guarantees. We'll publish the design and the trade-offs once we've measured them properly.

Questions or corrections? Write to engineering@aerovault.cc — we read everything.