AES-256 Encryption Explained — How to Encrypt Text in Your Browser

A Brief History of AES

In 1997, NIST announced a competition to replace the aging DES (Data Encryption Standard). DES used a 56-bit key, which had become feasible to brute-force. After a five-year public evaluation process involving cryptographers worldwide, NIST selected Rijndael, developed by Belgian cryptographers Joan Daemen and Vincent Rijmen, as the new standard. It was published in 2001 as FIPS 197 — the Advanced Encryption Standard.

Today, AES is used in virtually every security protocol: TLS (the "S" in HTTPS), WPA2/WPA3 (WiFi encryption), full-disk encryption, and countless applications that need to keep data private.

How AES Works

AES is a block cipher — it encrypts data in fixed-size blocks of 128 bits (16 bytes) at a time. The key length can be 128, 192, or 256 bits, corresponding to AES-128, AES-192, and AES-256. Longer keys perform more rounds of transformation:

• AES-128: 10 rounds
• AES-192: 12 rounds
• AES-256: 14 rounds

Each round applies a sequence of mathematical operations — byte substitution, row shifting, column mixing, and key addition — that thoroughly scramble the data. After 14 rounds, the output bears no recognizable relationship to the input.

AES-256 with a truly random key is considered cryptographically unbreakable by brute force with any foreseeable technology. The key space has 2²⁵⁶ possible values — far more than could be exhaustively searched even if every atom in the observable universe were a computer running since the Big Bang.

Modes of Operation

AES by itself only encrypts one 128-bit block. To encrypt longer data, you need a mode of operation that defines how blocks are chained together.

ECB (Electronic Codebook) — Never use this

ECB encrypts each block independently with the same key. The fatal flaw: identical plaintext blocks produce identical ciphertext blocks. Patterns in the data remain visible in the ciphertext. The canonical example is a PNG image of a penguin encrypted with ECB — the penguin's silhouette is clearly visible in the encrypted output.

CBC (Cipher Block Chaining)

CBC XORs each plaintext block with the previous ciphertext block before encryption, so identical plaintext blocks produce different ciphertext. It requires a random Initialization Vector (IV) for the first block. CBC is significantly better than ECB but requires careful handling to avoid padding oracle attacks.

GCM (Galois/Counter Mode) — The modern standard

GCM is an authenticated encryption mode: it simultaneously encrypts the data and produces an authentication tag that detects any tampering. When you decrypt, GCM verifies the tag before returning plaintext — if the ciphertext has been modified in any way, decryption fails rather than returning corrupted data.

GCM also does not require padding (it operates as a stream cipher internally) and is parallelizable — making it fast on modern hardware with AES-NI instruction support.

PBKDF2: Turning a Password into a Key

AES needs a cryptographic key — a specific number of random bits. A human-chosen password is not suitable directly: it is shorter than 256 bits and comes from a small, predictable space. PBKDF2 (Password-Based Key Derivation Function 2) bridges this gap.

PBKDF2 takes a password, a random salt, and an iteration count, and produces a derived key of any length:

• Salt: A random value (typically 16 bytes) that ensures the same password produces a different key each time — preventing rainbow table attacks against the derived key
• Iterations: The number of times the hash function is applied. More iterations = slower key derivation = harder brute-force. NIST recommends at least 600,000 iterations of PBKDF2-SHA256 for password storage as of 2023.

The salt must be stored alongside the ciphertext — it is not secret, but it must be unique per encryption. Without it, decryption cannot reproduce the correct key.

The IV: Never Reuse It

GCM mode requires an Initialization Vector (IV) — a 12-byte random value that must be unique for every encryption operation using the same key. Reusing an IV with the same key is catastrophic: it allows an attacker to recover the keystream and decrypt both messages. A new random IV should be generated for every encryption operation and stored with the ciphertext.

Browser-Based Encryption with the Web Crypto API

Modern browsers expose the Web Crypto API (crypto.subtle), providing access to cryptographic primitives including AES-GCM and PBKDF2. This allows browser-based tools to perform genuine cryptographic operations without sending data to a server — the encryption happens entirely within the browser's JavaScript engine using native C++ implementations.

Browser-based encryption is appropriate for protecting data against passive interception, but the security depends on the page itself not being compromised. A browser extension, XSS attack, or malicious script on the page could intercept plaintext before encryption.

Why "Encryption" Without Authentication Is Dangerous

Security researcher Moxie Marlinspike articulated the "Cryptographic Doom Principle": if you decrypt before authenticating, any vulnerability in your decryption code can be exploited against unauthenticated ciphertext. AES-GCM's authentication tag ensures you never process modified ciphertext — making this class of attack impossible when GCM is used correctly.