How Revault encrypts files up to 1 GiB

Revault encrypts a large file in segments of about 5 MiB, each with its own authentication tag, so the whole file never has to sit in memory at once. In the web app, that is what makes room for files up to 1 GiB.

Why not encrypt the whole file at once?

Large files should not require a large amount of memory. Revault reads files in segments of approximately 5 MiB, encrypts each segment in the browser, and stages ciphertext in IndexedDB. The original file is never read into one giant buffer.

Working in segments also means an interrupted upload can continue from ciphertext that is already staged, instead of encrypting the whole file again.

What protects segment order and completeness?

Each file gets its own encryption key, derived with HKDF from the vault master key. The derivation context includes the vault and file identifiers, the file’s byte length and the segment size.

Every segment’s 12-byte nonce combines a random prefix chosen for that file, a four-byte segment counter and a flag that marks the final segment. Segments carry 128-bit GCM tags. If segments are swapped, altered or cut off, verification fails.

What happens if an upload is interrupted?

Once encryption is complete, network uploads can resume from cached ciphertext after a page refresh. Retries send the same encrypted bytes, rather than encrypting a new source under old nonces. If encryption itself is interrupted, cancel that incomplete upload and start again with a fresh file identity.

How are downloads verified?

Downloads authenticate each segment before releasing it. Because checking happens as the file streams, an error late in a download can leave an incomplete file behind, so make sure the download finishes successfully before you rely on it.

What are the limits?

Each file in the web app can be up to 1 GiB. Image and video previews have a separate memory limit. Clearing local browser storage can remove the ciphertext needed to resume an upload.

The streaming format follows Tink’s documented AES-GCM-HKDF streaming construction, using native Web Crypto primitives. File identity and expected length are bound into the key derivation context; segment counters and the final marker protect ordering and completion. This implementation has not received an independent cryptographic audit.

The security model page describes the full construction, including the stream header and key derivation.