AES-256: The Cipher, the Mode, and the Limits

AES-256 is a block cipher with a 256-bit key, standardized in FIPS 197. It turns a fixed block of data into ciphertext under a key. The number 256 describes key length. It says nothing about your files, your device, or the person holding the key.

Two other choices matter as much as key size. The mode of operation decides how the cipher handles data longer than one block. Key derivation decides how your passphrase becomes a key. AES-256-GCM is one combination. AES-256-CBC is another. They share the cipher and differ almost everywhere else.

CBC chains each block to the previous one, which hides patterns in the plaintext. On its own it does not detect tampering. Someone who flips ciphertext bits can cause predictable damage without knowing the key. GCM adds an authentication tag over the ciphertext, described in NIST SP 800-38D. A modified file then fails to decrypt instead of yielding wrong data.

There is a second difference in what you may reuse. CBC needs a fresh random initialization vector per message. GCM needs a nonce that never repeats under the same key. Reusing a GCM nonce is one of the few mistakes that breaks the design outright, which is why libraries generate it for you and seldom expose the choice.

Key length says nothing about how the key was created. A key derived from a short or reused passphrase is as weak as the passphrase, whatever the cipher does. PBKDF2, described in RFC 8018, and similar functions slow guessing down. They cannot rescue a password that anyone can look up.

Encryption also says nothing about the endpoints. Malware on the device, a browser extension with page access, or a script injected into the page sees your plaintext before any cipher runs. Some metadata survives as well: file sizes, timestamps, and the fact that a transfer happened usually stay visible.

The Web Crypto API runs AES-256-GCM inside the browser and can hold a key as non-exportable. Script cannot read those raw key bytes back out. The page still has to receive your passphrase, though, and anything running in that page can read what you type. The origin you load therefore matters more than the mode you pick.

A non-exportable key helps in one narrow case. If someone copies storage or a memory dump later, a key that was never exportable is harder to lift. It does nothing against code running in the page while you type, and it does not survive a device that is already compromised.

Ask what you are defending against first. A lost laptop, a shared upload folder, and a provider that logs everything call for different designs. Then ask who has to decrypt. If only you hold the key, a client-side tool using AES-256-GCM and a long passphrase covers most of the risk. If someone else must read the data later, key exchange becomes the hard part.

One practical rule: prefer a tool that authenticates. Without a tag, a corrupted or edited file may decrypt into wrong data, and nothing in the output warns you. That failure is quiet, which is exactly why it is worth designing out.