HandyTools Hub

← All guides

AES Encryption Explained: The Algorithm Behind the Padlock, and What It Means for Your Data

2026-08-21

Every time you see a padlock, AES is probably doing the work — TLS, disk encryption, password managers, encrypted notes. Yet AES is also the algorithm people misuse the most: they “encrypt with a password” and assume that’s enough, when the real security decisions live in three places they never think about — how the password becomes a key, which mode of operation runs the cipher, and whether the nonce is unique. This guide gives you the three-layer mental model so you can tell a well-encrypted file from one that’s only decorated.

One Key Does Both Jobs

AES is a symmetric cipher: the same key encrypts and decrypts. Whoever holds the key can read the data — which is both its power (fast, simple) and its contract (protect the key, or you’ve encrypted nothing). It’s the opposite of asymmetric systems like RSA, where a public key encrypts and a separate private key decrypts. AES is also not a hash: a hash has no key, can’t be reversed, and has a fixed-size output. Hashing is its own topic; encryption is a two-way door with a key.

Key Sizes: 128, 192, 256

AES comes in three key sizes — AES-128, AES-192, AES-256. The number is the key length in bits, and it controls the number of internal rounds (10/12/14).

Two things worth knowing:

  • 256 is not “twice as secure” as 128. An extra 128 bits of key means a search space that is astronomically larger, but for real-world attacks AES-128 is already unreachable. The practical differences are speed (slightly slower) and the security margins favored in some contexts.
  • The key size matters less than how the key is made and used. A weak password turned into an AES-256 key is still a weak key. Strong key material used badly in ECB mode is still broken. Get the pipeline right and the bit size is a rounding error on your risk.

A Password Is Not a Key

You type a password; AES needs a key of exactly 16, 24, or 32 bytes. That translation is a key derivation function (KDF), and it’s where most “encrypted” files actually get cracked.

The standard approach is PBKDF2 (or a modern alternative like Argon2 or scrypt): the password is fed through a hash repeatedly — thousands or millions of times — together with a random salt, to produce the key. Two consequences:

  • Salt. A random salt per encryption means the same password never produces the same key — so two files “encrypted” with the same password don’t reveal that they match, and precomputed password tables are useless.
  • Iterations. The repeated hashing is deliberately slow, because it makes guessing your password expensive. An “encrypted” file where the KDF runs once is trivially brute-forceable; one where it runs 600,000 times is the difference between minutes and years.

If you’re encrypting with a password, ask what the KDF is — not just what cipher is on the tin.

Modes of Operation: Where the Real Vulnerabilities Live

AES encrypts fixed 16-byte blocks. A mode wires those blocks together to encrypt arbitrary-length data, and the mode — not the cipher — is where security is won or lost:

  • ECB — encrypts each block independently. Two identical plaintext blocks produce identical ciphertext blocks, which leaks patterns (the famous encrypted-Tux image). Never use ECB.
  • CBC — chains each block to the previous one and uses a random IV (initialization vector). Solid, but needs correct padding and is not authenticated.
  • GCM — an authenticated mode: it produces an auth tag that detects any tampering with the ciphertext. This is the default you should reach for: encryption plus integrity in one mode. GCM also has a nonce requirement — the nonce must never be reused under the same key, or security collapses.

The practical lesson: prefer GCM, use a fresh random nonce/IV for every encryption, and never store or send the key and the ciphertext together in a way that shares the nonce.

Encryption Protects Secrecy, Not Integrity or Identity

AES hides content; it doesn’t prove who sent it or that nothing changed. That’s the job of hashes and message authentication codes:

  • A hash is a fixed-size fingerprint of data — it detects accidental or malicious changes but has no key.
  • A MAC (like HMAC) is a keyed hash — it detects changes and proves the data came from someone with the key. GCM bundles an HMAC-style tag in.

This is why JWT signing and encryption are different steps, and why “encrypted” is not the same as “trusted.” If you need both, use an authenticated mode (GCM) or encrypt-then-MAC.

A Practical Checklist

When you encrypt your own data — a file, a note, a config value:

  1. Use AES-256-GCM if your tool offers it (or CBC with a random IV if not).
  2. Derive the key from your password with a strong KDF — PBKDF2 with a high iteration count, or Argon2/scrypt — and a random salt.
  3. Generate a fresh random nonce/IV per encryption; never reuse it under the same key.
  4. Store the nonce and salt with the ciphertext (they’re not secret) but never the key.
  5. Use a long, unique password — the KDF slows guesses, but it can’t make “password123” strong.
  6. Don’t roll your own. Any homegrown scheme almost certainly gets one of the above wrong.

Quick Reference

  • AES is symmetric: one key encrypts and decrypts. It’s not a hash (no key, irreversible) and not asymmetric (no key pair).
  • Key sizes 128/192/256 → rounds 10/12/14; 256 isn’t “twice as secure,” it’s a bigger margin.
  • A password is turned into a key by a KDF (PBKDF2/Argon2/scrypt): random salt + many iterations. Weak KDF = brute-forceable file.
  • Mode decides the security: never ECB, CBC needs a random IV, GCM is authenticated and the best default.
  • GCM’s nonce must be unique per key — reuse collapses the encryption.
  • Encryption is secrecy only; integrity/identity come from hashes and MACs (HMAC, GCM tag).
  • Checklist: AES-256-GCM + strong KDF + random salt + unique nonce/IV per message + long password. Never hand-roll.

To encrypt a string with a password locally, the AES Encryption Tool uses password-based AES-GCM with a random salt and per-message nonce — the pipeline this guide recommends. To detect whether something has been tampered with (rather than hidden), the Hash Generator produces the fingerprints for comparisons.