How to Encrypt a Document with AES-256

AES-256 in plain English

AES, the Advanced Encryption Standard, is a cipher published by the US National Institute of Standards and Technology (NIST) in 2001 as FIPS 197. It's a symmetric cipher: the same key locks and unlocks the data. It's built into modern processors and every mainstream browser, and it protects most of the web's encrypted traffic.

"256" is the key length in bits. A 256-bit key has 2²⁵⁶ possible values, a number with 78 digits. Trying them all is not a realistic attack for anyone. In practice, nobody breaks AES-256 by attacking the cipher. They attack what's around it: a guessable password, a copy of the file saved before it was encrypted, or the device where it's opened.

That's why the rest of this guide is mostly about the password, and about how the file travels.

What "GCM" adds: tamper detection

A cipher on its own needs a mode that says how to apply it to data longer than one block. GCM (Galois/Counter Mode, described in NIST SP 800-38D) encrypts the data and also computes an authentication tag over it. When you decrypt, the tag is checked first. If a single bit of the encrypted file was changed, by corruption or on purpose, decryption fails instead of producing silently damaged output.

GCM needs a fresh random value, called a nonce or IV, for every encryption with the same key. Vault Studio Pro generates a new random 96-bit nonce for every file, and a new salt too (next section), so the same key is never reused.

PBKDF2: turning a password into a key

AES needs a 256-bit key, not a password. A key-derivation function turns one into the other. Vault Studio Pro uses PBKDF2 with SHA-256 (described in NIST SP 800-132), with two settings that matter:

A random 128-bit salt for every file. The salt is mixed into the derivation, so the same password produces a different key for every file. An attacker can't precompute keys for common passwords once and reuse them.
600,000 iterations. The derivation is repeated many times so each password guess costs real computing time. That turns a fast guess into a slow one. This matches OWASP's Password Storage Cheat Sheet recommendation for PBKDF2-HMAC-SHA256. The iteration count actually used is stored with each file, so a future increase won't break decrypting files you make today.

Iterations only change the cost of each guess by a constant factor, while every extra random word in a passphrase multiplies the number of guesses needed by thousands. The passphrase is still what keeps your file safe; the iteration count is a smaller, secondary factor.

Choosing a passphrase that holds up

Someone who has your .vault file can try passwords offline, as fast as their hardware allows, with no lockout. So the password must be hard to guess even for a computer trying billions of candidates.

Length beats complexity. NIST's current digital identity guidelines (SP 800-63B) favour long passwords and passphrases over composition rules like "one capital and one symbol", which lead to predictable patterns.
Use random words, chosen randomly. The EFF publishes word lists for rolling dice to pick words. It recommends six words from its long list, which gives about 77 bits of entropy. Words you choose yourself, song lyrics and quotations are far weaker, because people choose predictably.
Never reuse a password from an account. Leaked passwords are the first thing an attacker tries.
Store it in a password manager, and generate it there if the manager supports passphrases.

The File Safe has a strength meter that flags weak passwords. Treat it as a warning light, not a guarantee.

How to encrypt a file with the File Safe

Open the Vault in the app, then the File Safe panel.
Choose any file: a PDF, .docx, .xlsx, image or .zip. To encrypt a folder, zip it with your operating system first.
Enter your passphrase.
Save the resulting .vault file. It gets a neutral default name (not the original file name) — the original name, type and size are encrypted inside it, and come back automatically when you decrypt it, no matter what you rename the .vault file to in the meantime.
Test it: open the .vault in the File Safe, enter the passphrase and check the file comes back intact. Only then delete the unencrypted original, if that's your goal.

Encryption and decryption use your browser's built-in Web Crypto API, inside the page. The file and the passphrase stay on your device.

Docs, Sheets and Slides projects can also be exported directly as encrypted .vault files. Two things are not encrypted: projects autosaved in the app, which live unencrypted in your browser's storage, and the full-backup.vaultbackup file, which is plain JSON. Put a backup in the File Safe before you store it anywhere shared.

What we checked in this repository

The site's test suite runs the File Safe's own encryption code on a small sample file and inspects the .vault it writes. The test confirms that:

The salt is 16 bytes and the nonce 12 bytes, and both change every time, even for the same file and password.
The file's contents don't appear anywhere in the .vault.
The right passphrase restores the original exactly, and a wrong one fails.
Flipping a single bit of the encrypted data makes decryption fail, which is GCM's tamper detection at work.
The original file name, type and size are encrypted along with the file, not stored in plain text. The .vault's small JSON wrapper exposes nothing identifying beyond the format tag and a timestamp — the name, type and size only come back after the correct passphrase decrypts them.

Send the file and the passphrase by different routes. Email the .vault, then share the passphrase by phone, text message or a different messaging app. If both travel in one email, anyone who gets that email gets both.
Tell the recipient what they need. A .vault is not a standard PDF or Office password, and other programs can't open it. The recipient needs Vault Studio Pro, which is free for decrypting, and the passphrase.
Use a new passphrase for each recipient or project, so one leak doesn't unlock everything else.

If the recipient must open the file in a particular program without installing anything, that program's own password protection may suit them better. Check what encryption it uses before relying on it.

If you lose the password

The file can't be recovered. There's no reset link, no master key and no backdoor. We never see your passphrase, and without it, decrypting means guessing it, which is exactly what a strong passphrase is designed to prevent. That is the point of encryption, and also its sharpest edge. Keep the passphrase in a password manager, and keep an unencrypted copy of anything irreplaceable somewhere you trust.

What encryption does not protect

The file before and after. Encryption protects the .vault. The original on your disk, a copy in your downloads folder or an email draft is still readable.
Your device. Malware or someone using your unlocked computer can see the file while it's open.
What the recipient does next. Once decrypted, the document is only as safe as their computer.

The File Safe is free, as is editing in every tool. Pro adds OCR on every page, larger PDF batches and revision history. The security page documents the full cryptographic details and the app's network behaviour.

Try it

The File Safe is free. Open it from the Vault in the app, or read the File Safe page for the exact parameters. For documents you are still editing, the .docx editor can export a project straight to an encrypted .vault.

Open the File Safe See plans and pricing

Sources

FIPS 197: Advanced Encryption Standard (AES). NIST
SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. NIST
SP 800-132: Recommendation for Password-Based Key Derivation. NIST
Password Storage Cheat Sheet. OWASP
SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management. NIST
EFF Dice-Generated Passphrases. Electronic Frontier Foundation