What is AES-256-GCM and why it matters for note-taking apps

Q: What does AES-256-GCM mean, piece by piece?

The name has three parts: AES, 256, and GCM. Each means something specific.

Quick Answer. AES-256-GCM is an authenticated encryption mode that combines AES-256 (the symmetric cipher used by governments, banks, and Signal) with GCM (Galois/Counter Mode, which adds tamper-detection). It's the mode used by TLS 1.3, WireGuard, Signal, and 1Password. A note-taking app claiming "AES-256 encryption" should specify GCM (or another authenticated mode) — plain AES-256-CBC without authentication is a red flag.

When a privacy-focused app says "your data is protected with AES-256 encryption," that statement is incomplete. AES-256 is a cipher, not a complete encryption scheme. The mode of operation matters as much as the cipher itself — and a poorly chosen mode can make AES-256 effectively useless.

This article unpacks AES-256-GCM in plain English: what each piece does, why it beats older modes like CBC, what its known pitfalls are, and what to look for when a note-taking or file storage app claims to use it.

What does AES-256-GCM mean, piece by piece?

The name has three parts: AES, 256, and GCM. Each means something specific.

AES (Advanced Encryption Standard) is a symmetric cipher standardized by the U.S. National Institute of Standards and Technology in 2001 (FIPS 197). "Symmetric" means the same key encrypts and decrypts. AES is the most analyzed cipher in the world and remains unbroken in its full form.

256 is the key length in bits. AES is defined for three key lengths: 128, 192, and 256 bits. AES-256 is the strongest variant, with a key space of 2²⁵⁶ — astronomically larger than any brute-force attack can practically reach, even with imagined quantum hardware (Grover's algorithm halves the effective key length, leaving AES-256 with 2¹²⁸ post-quantum security, still infeasible).

GCM (Galois/Counter Mode) is a mode of operation. AES on its own only encrypts a single 128-bit block. To encrypt data of arbitrary length, you need a mode that chains blocks together. GCM is one such mode, and importantly it provides authenticated encryption with associated data (AEAD) — it not only encrypts your data, it also produces a tag that detects any tampering.

Put together, AES-256-GCM = "encrypt with AES, key length 256 bits, in a mode that detects tampering."

Why does GCM matter? Isn't AES already secure?

AES is secure as a block cipher. But block ciphers are useless on their own — you need a mode of operation, and the choice of mode determines the security properties of the whole system.

The classic mistake is using AES in CBC mode without authentication. CBC encrypts your data correctly, but it doesn't tell you if the ciphertext was tampered with. An attacker who can flip bits in the encrypted blob can corrupt your plaintext in predictable ways — a class of attacks called "padding oracle" attacks (see the BEAST and Lucky 13 attacks on TLS CBC). Decryption succeeds, but you get back a tampered plaintext.

GCM solves this by computing a Galois MAC (GMAC) tag alongside the ciphertext. On decryption, if the tag doesn't match, decryption fails — you never see tampered plaintext. This is authenticated encryption, and in 2026 it is the only acceptable choice for new systems.

Mode	Encrypts?	Detects tampering?	Status
AES-ECB	Yes (badly)	No	Broken — never use
AES-CBC (no MAC)	Yes	No	Avoid
AES-CBC + HMAC	Yes	Yes (if combined right)	OK but error-prone
AES-GCM	Yes	Yes (built-in)	Recommended
AES-OCB	Yes	Yes (built-in)	Patent-encumbered historically
ChaCha20-Poly1305	Yes (different cipher)	Yes (built-in)	Equally good alternative

How does GCM actually work?

GCM combines two operations:

Counter mode (CTR) encryption. GCM takes a 96-bit nonce ("number used once"), concatenates a 32-bit counter, encrypts that block with AES, and XORs the result with each plaintext block. This turns AES into a stream cipher. Every block uses a different counter, so identical plaintexts produce different ciphertexts.
Galois field MAC. Alongside encryption, GCM computes a polynomial hash in GF(2¹²⁸) over the ciphertext and any associated data (headers, metadata). The result is a 128-bit authentication tag appended to the ciphertext.

To decrypt, GCM repeats the GMAC computation, compares it to the received tag, and only proceeds with decryption if the tags match. One bit flipped in the ciphertext = tag mismatch = decryption refuses to return plaintext.

The performance is excellent: GCM is parallelizable (counter mode), and modern CPUs implement both AES and the GF(2¹²⁸) multiplication in hardware (Intel AES-NI and PCLMULQDQ instructions). On a 2026 laptop, AES-256-GCM runs at 5–10 GB/s.

What is the deadly pitfall of AES-GCM?

GCM has one critical rule, and breaking it has real consequences: never reuse a nonce with the same key. The 96-bit nonce must be unique for every encryption performed with a given key.

If you reuse a nonce, GCM's confidentiality and authenticity both collapse. An attacker who sees two ciphertexts encrypted with the same (key, nonce) pair can:

XOR them together to leak the XOR of the plaintexts (cribs from any one breaks the other)
Recover the GMAC authentication subkey, then forge arbitrary ciphertexts that decrypt to anything they want

This is called the forbidden attack and is the reason GCM implementations must be careful. NIST SP 800-38D (the GCM standard) limits the number of encryptions per key to 2³² before nonce-reuse risk becomes unacceptable with random nonces.

Real-world consequences of nonce reuse have happened — most famously in some early Bluetooth implementations, in WPA2 (the KRACK attack), and in early implementations of GCM in TLS implementations. A correct implementation either uses a deterministic counter or uses per-message random nonces with documented rekeying limits.

When evaluating a notes app's encryption, the right question is not "do you use AES-256-GCM?" but "how do you derive nonces and how often do you rotate keys?"

Why do note-taking apps use AES-256-GCM?

For notes and files, AES-256-GCM is the right choice because:

It's standardized. NIST SP 800-38D, used in TLS 1.3, WireGuard, Signal, IPsec.
It's fast. Hardware-accelerated on every CPU made in the last decade.
It detects tampering. If a server (or attacker) modifies your encrypted note, decryption fails immediately. You never read corrupted plaintext.
It's available everywhere. Implementations exist in Node.js's crypto module, browser SubtleCrypto, libsodium, OpenSSL, Go's stdlib, Rust's aes-gcm crate.

For a notes app, the typical pattern is:

The user's password is run through a slow key derivation function (PBKDF2 or Argon2id) to produce a master key — see KEK and FEK explained.
Each note (or each file) gets its own random 256-bit data key.
The data key encrypts the note with AES-256-GCM, using a fresh random or counter-based nonce.
The data key itself is encrypted ("wrapped") with the master key, also via AES-256-GCM.

This per-file key architecture means a single compromised key only exposes one file, not the whole vault. It's the model used by Filarr — see Filarr's security architecture for the exact parameters.

What to look for in a notes app claiming "AES-256 encryption"

When a privacy-focused app advertises AES-256 encryption, ask the following:

Which mode? GCM or another authenticated mode is required. Plain CBC, ECB, or "AES-256" without a mode is a red flag.
How is the key derived? From the user's password directly? That's wrong — passwords are too low-entropy. There must be a key derivation function (PBKDF2, Argon2id, scrypt) with documented iteration counts.
Are there per-file keys, or one global key? Per-file (or per-note) keys limit blast radius — a single key compromise doesn't expose everything.
How are nonces generated? Deterministic counter? Random with how many bits? "We use AES-GCM" without nonce discipline is fragile.
Where is the encryption documented? A serious app publishes its threat model and encryption design. If you can't find it, assume marketing-grade crypto.
Is the code auditable? Open-source implementations let security researchers verify the claims. Closed-source AES-256 is a promise, not a proof.

How does Filarr use AES-256-GCM?

Filarr encrypts every file and every note with AES-256-GCM using per-file keys. The full pipeline:

Your password is stretched with PBKDF2-SHA-512, 600,000 iterations (and Argon2id for newer profiles) to produce a Key Encryption Key (KEK)
Each file gets a fresh random 256-bit File Encryption Key (FEK)
The file is encrypted with its FEK using AES-256-GCM, with a random nonce per encryption
The FEK is encrypted with the KEK, also using AES-256-GCM, and stored alongside the file

The KEK never leaves your machine in plaintext. The FEKs never exist in plaintext on disk. If our cloud sync servers are compromised, all an attacker sees is a stream of encrypted blobs they cannot decrypt — the keys are not on our servers. See Filarr's security model for the full architecture, threat model, and audit details.