AES-⁠256 encryption, explained

AES-⁠256 means the Advanced Encryption Standard, used with a key that is 256 bits long. It is a public standard, published by the US National Institute of Standards and Technology (NIST) as FIPS 197. Because it is public and widely used, many apps mention it. It is also why “AES-⁠256” on its own tells you less than it seems: the cipher is rarely the weak part.

What AES is

AES is a symmetric cipher. The same secret key that encrypts the data also decrypts it. Anyone with the key can read the data; anyone without it sees random-⁠looking bytes.

That is different from public-⁠key cryptography, where one key locks and a different key unlocks. Public-⁠key methods are used to share keys and to sign things. Symmetric ciphers like AES do the heavy lifting of encrypting the actual files, because they are fast.

AES is a block cipher. FIPS 197 defines it as working on blocks of 128 bits (16 bytes) at a time, with three key sizes:

Each round mixes and substitutes the bytes of the block using the key. More rounds and a longer key make AES-⁠256 slightly slower than AES-⁠128.

What the 256 means

A 256-⁠bit key can take 2^256 different values. Written out, that number has 78 digits. Trying every possible key is not a realistic attack for any computer, so attackers don’t try. They go after the password that protects the key, the place where the key is stored, or the software that uses it.

AES-⁠128 is also considered strong. Apple, for example, describes notes locked with a passphrase as using a 16-⁠byte key, which is 128 bits, with AES in Galois/Counter Mode. People pick AES-⁠256 for extra margin over the long term. One reason often given is quantum computing: Grover’s algorithm, a known quantum search method, would in theory reduce the work of searching a key space to about its square root. For a 256-⁠bit key, that still leaves around 2^128 steps.

AES needs a mode, and the mode matters

On its own, AES encrypts one 16-⁠byte block. A photo is millions of bytes, so AES runs inside a mode of operation that decides how blocks are handled.

The simplest mode, called ECB, encrypts identical blocks into identical output. That leaks patterns: encrypt a picture with large areas of one color this way and its outline can still show through. Good software doesn’t use it.

The mode you want to see today is an authenticated one. A widely used one is GCM (Galois/Counter Mode), defined by NIST in SP 800-⁠38D. It does two jobs:

• Encryption, so the content can’t be read without the key.
• Authentication, through a short tag added to the data. If anyone changes even one bit, the tag no longer matches, and decryption fails instead of handing you a corrupted file.

GCM has one strict rule: the value used to start each encryption, called the nonce or IV, must never repeat under the same key. Reusing it can expose data and let an attacker forge changes. Well-⁠built software handles this for you, often by giving each file its own key.

Large files are often split into pieces, each encrypted and authenticated, so the app can open part of a video without decrypting all of it. Good designs also build each piece’s position, and a marker for the last piece, into its check, so a piece that has been changed, removed or moved is caught too.

Where the key comes from

AES is only as strong as its key, and how the key is made matters more than its length.

A random key

The best key is 256 bits from a secure random number generator. No one can guess it. The problem is that no one can remember it either, so it has to be stored somewhere safe, and protected by something you can remember.

A key from a password

Passwords and PINs have far fewer possibilities than a random key. A 6-⁠digit PIN has 1,000,000 possible values, whether the data behind it uses AES-⁠128 or AES-⁠256. So software turns your password into a key with a key derivation function.

The classic one for passwords is PBKDF2, described in RFC 8018. It mixes in a random salt, so two people with the same password end up with different keys, and it repeats its work many times. It is slow on purpose. You wait a fraction of a second when you unlock. Someone guessing has to pay that same cost for every guess.

Phones add another defense: a key kept inside the phone’s security hardware, mixed into the derivation. Guesses then only work on that one phone. It does not slow guessing on the phone itself, so a longer PIN or password still matters.

Many keys from one key

A different tool, HKDF (RFC 5869), takes one strong secret and derives many separate keys from it, for example one per file. It is fast, which is fine because its input is already random. It is not meant for turning a weak password into a key.

What “AES-⁠256” on an app’s page doesn’t tell you

Because AES is a public standard, any app can say it uses AES-⁠256. These questions tell you far more:

1. Which mode? Look for an authenticated mode such as GCM.
2. How is the key made from my password or PIN? Which key derivation function, how slow, and is there a hardware key or a limit on guesses?
3. Who holds the key? Only your device, or the company too? If the company can reset your password and restore your data, it holds a key.
4. What is encrypted? Only the photos, or thumbnails, album names and file details too?
5. Is the design written down? A published description that outsiders can check is worth more than any adjective.

What AES-⁠256 can’t do

Strong encryption protects data that is stored or sent. It can’t help once the data is decrypted to be shown on your screen, if malware is running on an unlocked phone, or if someone simply learns your password. It also doesn’t hide everything about a file: its size and when it changed can still be visible unless the software takes extra steps.

Most failures happen around the cipher, not in it. Judge an app by its answers to the questions above, not by the number.