How AES-256-GCM Protects Your Files: A Visual Guide

Every file sharing service claims to be "encrypted." Most are. But there's a massive difference between encrypted and encrypted well — and it determines whether your data is actually safe or just password-locked.

AES-256 vs AES-128 vs ZIP password

The "AES" part stands for Advanced Encryption Standard, a cipher approved by NIST in 2001 and used by the U.S. government for classified information. The number — 128, 192, or 256 — is the key length in bits.

A 256-bit key has 2^256 possible combinations — approximately 10^77, more than the number of atoms in the observable universe. Brute-forcing AES-256 is computationally impossible with current or foreseeable technology. Even if you tried every key on every atom in the universe, you'd never crack it.

By contrast, the "password" on a PDF or ZIP file is usually not AES-256 at all. It's often ZipCrypto (deprecated since 2004) or a simple cipher that can be cracked in minutes with off-the-shelf tools. A "password-protected" file is security theater.

What the "GCM" means

AES has different modes of operation. FastDDL uses GCM (Galois/Counter Mode), which provides two critical properties:

1. Encryption — your data is scrambled so only the holder of the key can read it.

2. Authentication — an integrity check (called an "authentication tag") is attached to the ciphertext. If even one bit of the encrypted file is altered in transit, the decryption fails.

This second property is critical. Without it, an attacker could modify your encrypted file in transit and you'd have no way to know. With GCM, the moment you try to decrypt a tampered file, you get an error — not corrupted data.

The encryption process

When you upload a file to FastDDL, here's what happens:

1. Your browser generates a random 32-byte encryption key (256 bits) using a cryptographically secure random number generator.
2. The browser splits this key into a human-readable format — four groups of 6 hex characters, separated by dashes (e.g., a3b4c5-d6e7f8-1a2b3c-4d5e6f).
3. The browser generates a random 12-byte IV (initialization vector) — ensures the same file encrypted twice produces different ciphertext.
4. Your file is encrypted using AES-256-GCM with the key and IV.
5. The encrypted file (IV + ciphertext + auth tag) is uploaded to Cloudflare R2 storage.
6. You see the key once and copy it to share with the recipient.

What the server sees vs. what it doesn't

When FastDDL's server receives your upload, it sees:

• A scrambled file it cannot read
• The file size (encrypted size is slightly larger than original)
• The filename (unless you mask it)
• Your IP address and browser fingerprint
• The expiration timestamp

What the server does NOT see:

• Your decryption password (never transmitted)
• The plaintext content of your file
• Anything inside the file

This is called zero-knowledge encryption — even FastDDL's operators cannot decrypt your files, even if compelled by law enforcement.

What happens when someone downloads

1. Recipient opens the download page and enters the password.
2. The encrypted file is streamed from R2 to the server.
3. The server decrypts the file in memory using AES-256-GCM.
4. If the auth tag verifies (no tampering), the plaintext is streamed to the recipient.
5. If the auth tag fails, the recipient gets an "Incorrect password" error.

The decrypted data never touches disk on our server — it exists only in memory during the download stream.

Why this matters

Most "secure" file sharing services store your password server-side (even hashed). If their database is breached, your files are compromised. FastDDL's architecture makes this impossible — there's no password to steal because there is no password stored.

This is why we built FastDDL. Try it for yourself →