AES-256-GCM explained: the lock, the key and the tamper seal

AES-256 is a symmetric encryption standard: one secret key, 256 bits long, both locks and unlocks your data. GCM is the mode that wraps AES around real text and adds a tamper-evident seal, so a single changed bit makes decryption fail instead of quietly producing a wrong message. Together, AES-256-GCM keeps a note private and tells you if anyone touched it, but only for as long as the key stays with the right person.

This is AES-256 encryption explained without formulas. You will see what the "256" really buys you, why a random "number used once" matters, what the seal protects, and why the question "who holds the key?" matters more than the name of the cipher.

What is AES encryption?

Picture a strongbox with one key. The same key locks it and opens it. That is symmetric encryption, and AES (the Advanced Encryption Standard) is the most widely used symmetric cipher in the world. Your browser uses it for most HTTPS connections, your phone uses it to protect its storage, and your Wi-Fi router very likely uses it too.

Cipher

A recipe for scrambling data with a key so that only someone with the same key (or, in some systems, a matching key) can unscramble it. The scrambled result is called ciphertext; the readable original is plaintext.

AES came out of an open competition. In 1997 the U.S. National Institute of Standards and Technology (NIST) invited cryptographers worldwide to submit designs, and cryptographers spent years publicly trying to break them. In 2000 NIST picked Rijndael, created by the Belgian researchers Joan Daemen and Vincent Rijmen, and published it as FIPS 197 on November 26, 2001. A 2023 update to the document was editorial only: the algorithm itself has not changed.

That history matters for trust. AES is not a secret company formula. It has been studied in public for more than 25 years, and no practical attack recovers a correctly used AES key.

What does the 256 in AES-256 mean?

The number is the length of the key in bits. A bit is a single yes-or-no choice, so a 256-bit key is like the outcome of 256 coin flips. AES comes in three sizes, 128, 192 and 256 bits, and all three scramble data in blocks of 128 bits (16 bytes).

Each extra bit doubles the number of possible keys. With 256 bits there are 2 to the power of 256 possibilities, a number with 78 digits. Here is an estimate to make that concrete. Assume a billion computers, each testing a trillion keys every second. On average they would need to try half of all keys before hitting the right one, which would take roughly 10⁴⁸ years. The universe is about 13.8 billion years old, a number with just 11 digits.

Two honest caveats. First, AES-128 is also considered strong today; the larger key mostly adds a safety margin. Second, real attackers almost never try to guess an AES key. They go after whatever protects the key instead: a weak password, a phished login, malware on a laptop. Keep that in mind, because it comes back later.

Why does AES need a mode like GCM?

On its own, AES does one small thing: it turns exactly 16 bytes into 16 scrambled bytes. A note is longer than that, so you need a recipe for applying AES to text of any length. That recipe is called a mode of operation.

The naive recipe is to cut the text into 16-byte pieces and scramble each one separately. It has a famous flaw: identical pieces give identical scrambled output, so patterns show through. The classic demonstration is a cartoon penguin encrypted this way that is still clearly a penguin afterward.

GCM (Galois/Counter Mode, standardized by NIST in SP 800-38D) works differently. AES takes the key, a fresh starting number and a counter, and produces a long stream of random-looking bytes. That stream is mixed with your text, byte by byte. The result has exactly the same length as your text, and repeated words look nothing alike.

What GCM adds: a tamper-evident seal

Think of the ribbon and wax seal on an old document. The seal does not hide anything, but if someone opens and reseals the envelope, you notice. GCM gives every encrypted message a digital version of that seal, called the authentication tag. It is 128 bits (16 bytes) long and is computed from the key, the ciphertext and any extra data you choose to protect.

When you decrypt, the tag is computed again and compared. If even one bit of the ciphertext, the tag or the protected extra data has changed, the comparison fails and decryption returns nothing at all. You get a clear "no" instead of a scrambled note.

Why is that so important? Plain counter-mode encryption without a seal is malleable: flipping a bit in the ciphertext flips the same bit in the decrypted text. Someone who could guess where a number sits in a message could turn a 1 into a 9 without ever reading the rest. The seal closes that door. To forge a valid one without the key, an attacker would have to guess a 128-bit value, and every wrong guess is simply rejected.

Authenticated encryption

Encryption that protects secrecy and integrity at the same time: nobody without the key can read the data, and nobody without the key can change it without being detected. AES-GCM is the most common example.

Try it: encrypt a note in your browser

The box below runs real AES-256-GCM using your browser's built-in Web Crypto. It creates a random key inside this tab, and nothing you type leaves your device.

Try a few things:

1. Type a short note and look at the sizes. The ciphertext is always 16 bytes longer than your text. Those 16 bytes are the seal.
2. Press Encrypt again. The text and the key stay the same, yet the nonce and the whole ciphertext change completely. That is the fresh nonce at work, and it is why two identical notes do not look identical once encrypted.
3. Press Change one byte. A single byte of the ciphertext is altered, and decryption is refused. There is no partly readable result: the seal is broken, so the key will not open it.

The nonce: a number used once

"Nonce" is short for "number used once". It is the fresh starting number that GCM mixes with the key each time it encrypts. It is not secret; it is stored right next to the ciphertext, because decryption needs it. What matters is that the same key never uses the same nonce twice.

If a nonce does repeat under the same key, two messages get scrambled with the same stream of random-looking bytes. Anyone holding both ciphertexts can compare them and learn how the two texts differ, which is often enough to reveal both. Worse, in GCM a repeated nonce can leak the secret used to build the seal, which lets an attacker create forged messages that pass the check. This is not only theory: a 2016 study found 184 HTTPS servers on the internet repeating GCM nonces.

In Cappa, every time a note or setting is encrypted, the app asks the browser's cryptographic random number generator for a new 96-bit (12-byte) nonce. Editing a note and saving it again therefore produces a completely new ciphertext, just like the Encrypt again button.

Random nonces have a known budget. NIST's GCM guidance limits a single key to about 4.3 billion encryptions with random 96-bit nonces, which keeps the chance of an accidental repeat negligible. For one person's notes that is a very large allowance: more than one encryption every second, around the clock, for a hundred years.

Additional authenticated data: the label on the box

Sometimes information must stay readable but still needs protection. A parcel's shipping label is a good analogy: the courier has to read it, but you would want to know if someone peeled it off and stuck it on a different box. GCM handles this with additional authenticated data (AAD). The AAD is not encrypted, but it is covered by the seal. If the label and the box do not belong together, decryption fails.

Cappa uses AAD to tie every encrypted record to its place. The seal on each record covers the vault it belongs to, the record's ID, its type (a note or your preferences), its revision number and the encryption format version.

Encrypted record as storedwhat the server keeps

Label (readable, sealed)

vaultrecord IDtyperevisionformat version

Nonce (readable, never reused)

Ciphertext and sealunreadable without the vault key

Lk3LNjmZSqKhOF9D0gS1lLUNQDB2hzvlQdS6kksyws2uUmHFcdd2Z4m26bp5qBkjFsKJW6bN

In practice, whoever controls the database cannot take the ciphertext of one note and file it under another note's ID, present an old version as a newer revision, or move it into someone else's vault. The browser would refuse to open it.

Why "AES-256" on a marketing page says little

Almost every online service can truthfully say it uses AES-256. The cipher is not the interesting part. The interesting part is who creates the key, where it lives, and who can use it.

Many cloud services encrypt data at rest: the files on their disks are encrypted, but the company holds the keys, so its systems (and anyone who gets far enough into them) can decrypt your data. Apple's own iCloud documentation describes its standard mode this way: "Apple can decrypt your data on your behalf." Its optional Advanced Data Protection moves most keys to your devices instead. Same AES, very different result.

Here is how Cappa arranges it. When your vault (the encrypted collection of your notes) is created, your browser generates a random 256-bit vault key. That key encrypts your notes with AES-256-GCM. On the server, the vault key itself exists only in wrapped form: encrypted (again with AES-256-GCM) by a key derived from your master password using Argon2id, and separately by a key derived from your recovery code. The server keeps those wrapped copies and your encrypted notes, but not the master password, the recovery code or the unwrapped vault key.

Master password

Typed on your device

Argon2id

Password key

Opens the envelope that holds the vault key

unwraps

Vault key

Random, 256 bits, encrypts every note

AES-256-GCM

Encrypted note

Nonce, ciphertext, seal

HTTPS

Server

Stores ciphertext it cannot read

This is why the strength of your master password and the slow key derivation matter so much. AES is not the weak spot; the path to the key is. How Argon2 turns a password into a key explains that step, and end-to-end encrypted notes covers what the server can and cannot see. If you are choosing an app, our comparison of notes apps asks the key question for each of them.

When you read "military-grade AES-256" somewhere, try these questions instead:

• Where is the key created, and who can use it?
• Can the company read my data if it wants to, or is ordered to?
• What protects the key: my password, and how is that password slowed down against guessing?
• What stays visible, such as file names, sizes and times?
• What happens if I forget my password?

Is AES-256 quantum safe?

As far as current knowledge goes, yes. The quantum algorithm that applies to AES is Grover's algorithm, which in theory speeds up guessing a key by roughly a square root. That would make a 256-bit key about as hard to guess as a 128-bit key is today, which is still far beyond reach.

NIST is more relaxed still. Its post-quantum cryptography FAQ explains that Grover's algorithm will offer little or no practical advantage against AES, because the attack has to run step after step on expensive quantum hardware. It says AES-128 should stay secure for decades, AES-192 and AES-256 for a very long time, and that there is no need to double AES key lengths.

The real quantum concern is public-key cryptography (RSA and elliptic curves), which is used to agree on keys and sign data. That is why NIST published its first post-quantum public-key standards in August 2024 (we explain them in post-quantum cryptography explained simply, and what quantum computers mean for passwords in a separate guide). Cappa's encryption of note contents uses no public-key cryptography at all: the keys come from your master password, your recovery code and random numbers, and the notes are sealed with AES-256-GCM. Your HTTPS connection does use public-key cryptography, like every website, but what it carries for your notes is already AES ciphertext.

FAQ

Is AES-256 better than AES-128?

Both are considered secure, and both are approved by NIST. AES-256 uses a longer key, which gives a larger safety margin (including against the theoretical speed-up from quantum computers) at a small cost in speed. For stored personal data, AES-256 is a sensible, common choice.

Can AES-256 be cracked?

No practical attack is known that recovers a correctly used AES-256 key, and guessing it by brute force is out of reach. Encrypted data gets exposed in other ways: a leaked or weak password, a reused nonce, a key stored next to the data, or malware on the device doing the decrypting.

What is the difference between AES and AES-GCM?

AES is the core cipher: it scrambles one 16-byte block with a key. AES-GCM is AES used in Galois/Counter Mode, which encrypts text of any length and adds a 16-byte authentication tag. The tag makes decryption fail if anything was changed.

Why does the same text encrypt differently every time?

Because each encryption uses a new random nonce. That hides whether two notes are identical and is required for GCM to stay secure. You can see it with the Encrypt again button in the demo above.

Does AES-256 hide how big my files are?

No. In GCM the ciphertext is the same length as the text plus a 16-byte tag, so the size stays visible to whoever stores it. Hiding sizes would require padding or other techniques on top of encryption.