How your files are encrypted
A plain description of the encryption used here, what it protects you against, and honestly what it does not.
The mechanism
Every file gets its own randomly generated key, used with AES-256-GCM. That key is then itself encrypted with a key derived for your account, and the wrapped version is stored beside the file record. This is standard envelope encryption. Its practical benefit is that the key protecting your file is never stored anywhere in a usable form.
Files are encrypted block by block as they upload, with each block carrying its own authentication tag. Two things follow from that. Memory stays bounded, so a 2GB file uses no more memory than a 2MB one. And any tampering with the stored ciphertext is detected when the file is read, rather than quietly producing corrupted output.
The complete set of block tags is fingerprinted and stored with the file record, and that fingerprint is verified when a file is decrypted. This catches truncation: an attacker who removes whole blocks from the end of a stored file cannot make the result look intact.
What this protects you from
The realistic threats, which are all about data at rest:
- Someone obtaining the storage bucket, or a copy of it.
- A leaked or stolen backup.
- A misconfigured server exposing files directly.
- The storage provider's own staff reading what they hold.
In all of those cases, what the attacker has is ciphertext without the keys, and AES-256-GCM is not something anyone breaks.
What it does not protect you from, honestly
Decryption happens on our server, at the moment you download a file or a vault delivers one. This is not zero knowledge encryption, and we will not describe it as if it were. An attacker who fully compromised the running application at the moment you were downloading could read that file.
That is the trade made to give you an ordinary product: a vault that can email an attachment to someone who has no account and no key is a vault that must be able to decrypt on your behalf.
If your threat model needs more
Encrypt the file yourself before you upload it, with a tool you control, and pass the passphrase to your recipient by some other route. The vault then delivers an encrypted blob that we could not read under any circumstances. It costs your recipient one extra step and it puts the key entirely beyond us.
In transit
Everything travels over TLS, with HSTS set so browsers refuse to fall back to an unencrypted connection.
Still stuck?
The assistant has read every page in this help centre and answers in seconds. If it cannot help, a person will.