"AES-256 encryption" is on the marketing page of nearly every security product. It's a real, strong standard — but the three words hide almost everything that actually determines whether your file is safe. The cipher is rarely the weak link. How a key is made from your password, whether each file gets fresh randomness, and whether tampering is detected matter far more.
Here's exactly what happens when you encrypt a file with FileX, and why each piece is there.
The problem: a password is not a key
AES-256 needs a 256-bit key: 32 bytes of high-entropy randomness. Your password isn't that. "correct horse battery staple" is memorable, but as raw bytes it's low-entropy and the wrong length. If you fed the password straight into AES, two things would go wrong: short passwords wouldn't fill the key, and an attacker could guess passwords at billions per second.
So the first job is turning a human password into a proper key — slowly and unpredictably.
PBKDF2, salts, and deliberate slowness
FileX uses PBKDF2-HMAC-SHA256 with 250,000 iterations and a random 16-byte salt for every file. Three ideas are doing work here:
- The salt is random per file and stored (unencrypted) in the container. It means the same password produces a completely different key each time, so an attacker can't precompute a giant lookup table ("rainbow table") of password → key. They have to attack your file specifically.
- The iterations make derivation deliberately expensive: computing the key runs the hash 250,000 times. You don't notice a quarter-second when you unlock your own file. An attacker guessing millions of passwords pays that cost on every single guess, which collapses their throughput.
- HMAC-SHA256 is the well-studied primitive underneath, run by the browser's own crypto engine.
The cipher stops someone who has your file but not your password. PBKDF2 is what makes guessing the password impractical. A generated, high-entropy password plus slow derivation is the combination that actually holds.
Encrypting: AES-256 in GCM mode
With a real 256-bit key in hand, FileX encrypts using AES-256 in GCM mode. GCM (Galois/Counter Mode) matters because it's authenticated encryption — it does two jobs at once:
- Confidentiality — the file bytes become ciphertext that reveals nothing without the key.
- Integrity and authenticity — GCM also produces a 128-bit authentication tag, a cryptographic checksum over the ciphertext. If even one byte is altered — by corruption in transit, or by an attacker — the tag won't match and decryption fails loudly instead of returning silently wrong data.
Every encryption also uses a fresh random 12-byte IV (initialization vector, sometimes called a nonce). Reusing an IV with the same key is the classic way to break GCM, so a new random IV per operation is essential. Like the salt, the IV isn't secret — it's stored in the container.
What a .filex file actually contains
Put together, a FileX container is just four parts laid end to end:
[ 4-byte magic ][ 16-byte salt ][ 12-byte IV ][ AES-256-GCM ciphertext + tag ]
The magic header is FLX1 for a single file or FLX2 for a multi-file archive. The salt and IV sit in the clear on purpose — they're needed to derive the key and decrypt, but they give an attacker nothing without the password. Everything meaningful is inside the authenticated ciphertext.
Why the wrong password is rejected, not guessed at
A common question: "Why does FileX say my password is wrong instead of just producing a garbled file?" That's GCM doing its job. A wrong password derives the wrong key; the wrong key produces the wrong authentication tag; GCM refuses to return plaintext at all. There's no partial success and no way to tell "close" from "completely wrong" — which is exactly what you want. It also means a file corrupted in transit is caught, not quietly accepted.
The flip side: there is no recovery. No backdoor, no reset, no copy of your key anywhere. Forget the password and the file is gone. That's not a limitation to apologize for — it's the guarantee. Store passwords in a manager.
The part most tools skip: where does this run?
All of the above is standard cryptography. The thing that varies between products is where the plaintext lives. Many "encrypted" services encrypt your file after it's uploaded to their servers, which means the readable version crossed the internet and sat on someone else's disk first.
FileX runs every step above in your browser, using the built-in Web Crypto API (crypto.subtle) — the same audited implementation your browser uses for HTTPS. No hand-rolled crypto, and no upload: the file never leaves your device, so there's no server copy to breach in the first place. That's a deliberately different threat model, and it's the subject of a separate deep dive on client-side vs. cloud encryption.
The takeaway
- AES-256-GCM encrypts and authenticates, so tampering and wrong passwords are caught.
- PBKDF2 with a random salt and 250k iterations is what turns a password into a real key and makes guessing painfully slow.
- A fresh random IV every time keeps GCM safe.
- Running it all in the browser means there's no uploaded plaintext to steal.
You can try it right now — encrypt a file in your browser; nothing is uploaded, and the live monitor shows zero bytes leaving your device.