AES Encryption & Decryption Tool

AES (Advanced Encryption Standard) is the most widely used symmetric encryption algorithm worldwide, approved by the NSA for protecting TOP SECRET information. AES evolved from the Rijndael cipher designed by Belgian cryptographers Joan Daemen and Vincent Rijmen, and was officially published by NIST in 2001 as a replacement for the aging DES algorithm. AES uses block encryption with a fixed block size of 128 bits (16 bytes) and supports three key lengths: 128, 192, and 256 bits, corresponding to AES-128, AES-192, and AES-256 security levels. Longer keys provide higher security but slightly slower performance. As a symmetric encryption algorithm, AES uses the same key for both encryption and decryption, making it far more efficient than asymmetric encryption. AES has extensive applications: in network security, TLS/SSL protocols use AES to protect web browsing and email transmission; in storage security, tools like BitLocker and FileVault use AES to encrypt user data; in database security, many systems support AES column-level encryption; in IoT, AES is widely used for secure device-to-device communication. This tool supports all 6 AES encryption modes (ECB, CBC, CFB, OFB, CTR, GCM) and 5 padding schemes to meet various encryption needs.

AES (Advanced Encryption Standard) was published by NIST as FIPS 197 in November 2001 after a five-year public competition that started in 1997 with 15 candidates. The winner was Rijndael, designed by Belgian cryptographers Joan Daemen and Vincent Rijmen, beating finalists including Twofish, Serpent, RC6, and Mars. AES replaced DES (FIPS 46, withdrawn in 2005) and is now the world's most widely deployed symmetric block cipher: it sits inside TLS 1.2/1.3, IPsec, BitLocker, FileVault, OpenSSL's default `aes-256-gcm`, the Linux kernel's dm-crypt, Apple's CryptoKit, and Android's Keystore. NSA approved AES-256 for TOP SECRET in 2003 (suite A), making AES the first publicly available cipher cleared for the highest US classification. Block size is fixed at 128 bits (16 bytes); key sizes are 128, 192, or 256 bits, mapped to 10, 12, or 14 rounds. A round (except the last) runs four operations on a 4x4 byte state: SubBytes applies a fixed 16x16 S-Box (0x63 = 01100011 sits at row 6 col 3 — the S-Box is constructed as the multiplicative inverse in GF(2^8) plus an affine transform to break algebraic structure); ShiftRows rotates row 0 by 0, row 1 by 1, row 2 by 2, row 3 by 3 bytes; MixColumns multiplies each column by a fixed circulant MDS matrix over GF(2^8) (the polynomial 0x03 * x in matrix form); AddRoundKey XORs with the round subkey. The final round skips MixColumns. The round keys come from the Rijndael key schedule: 11/13/15 round keys of 128 bits each, generated via RotWord (rotate left by 1 byte), SubWord (apply S-Box), and XOR with Rcon[i] = [0x01, 0x02, 0x04, ..., 0x80, 0x1b, 0x36] *2^(i-1) over GF(2^8). The page's `aes-js` library performs all four steps in pure JavaScript and is byte-compatible with OpenSSL's libcrypto. Five block modes are exposed. ECB encrypts each 16-byte block independently: identical plaintext blocks produce identical ciphertext blocks, leaking structure (the famous ECB-penguin image survives encryption because the pixel pattern survives). CBC XORs each plaintext block with the previous ciphertext block before encryption; the first block XORs with an IV. CTR turns AES into a stream cipher by encrypting an incrementing counter (nonce || counter, both 64-bit halves of a 128-bit block) and XORing the keystream with the plaintext — supports random access and parallel encryption. GCM is CTR plus GHASH (a universal-hash authenticator over GF(2^128)), producing a 16-byte authentication tag appended after the ciphertext. GCM is the default AEAD in TLS 1.3 (RFC 8446) and in most modern APIs (Node `crypto.createCipheriv('aes-256-gcm', ...)`). CFB and OFB are older stream-cipher modes retained for compatibility. The IV pitfall is the most common production bug. GCM with a 96-bit (12-byte) IV is the NIST-recommended configuration (RFC 5288, NIST SP 800-38D §5.2.1.1): the 12-byte IV is treated as a counter, and GHASH is computed over J0 = IV || 0x00000001. Reusing an IV under the same key in CTR mode leaks the plaintext XOR (C1 XOR C2 = P1 XOR P2 — a single chosen-plaintext attack recovers both messages). Reusing an IV in GCM is worse: an attacker can recover the authentication subkey H and forge tags for arbitrary messages (the attack is in Joux 2006 and is the reason NIST banned random 96-bit IVs without strict uniqueness). The page generates 12-byte IVs with `crypto.getRandomValues(new Uint8Array(12))` for GCM and 16-byte IVs for CBC/CFB/OFB, and the random-key button uses the same CSPRNG so every encryption starts with fresh material. This tool runs AES encryption and decryption entirely in the browser using aes-js, a pure-JavaScript AES implementation. There is no Web Crypto / SubtleCrypto fallback path — all operations go through aes-js regardless of payload size.

• AES is FIPS 197 (2001), selected via an open NIST competition that drew 15 candidates; Rijndael beat Twofish, Serpent, RC6, and Mars. Block size is always 128 bits; key sizes 128/192/256 bits run 10/12/14 rounds. The page supports all three via aes-js's AES_128, AES_192, and AES_256 constructors.
• The four-step round function: SubBytes (a 256-byte S-Box that is the GF(2^8) inverse plus affine), ShiftRows (rows shifted by 0/1/2/3 bytes), MixColumns (MDS matrix multiplication over GF(2^8) with the 0x03 polynomial), AddRoundKey (XOR with round key). Final round skips MixColumns. Same algorithm, same key = same ciphertext — AES is deterministic.
• ECB is unsafe because identical plaintext blocks produce identical ciphertext blocks (the famous 'ECB penguin' image preserves its silhouette). CBC is the safe classic; CTR adds parallelism; GCM adds authentication and is the TLS 1.3 default (RFC 8446). CFB and OFB are stream-cipher modes kept for legacy compatibility.
• PKCS#7 padding: 1 byte short → 15 bytes of 0x0f + 1 byte of 0x10; 2 bytes short → 14 of 0x0e + 2 of 0x0f, etc. The last byte's value is the padding length, so unpadding is unambiguous. Stream modes (CTR/CFB/OFB/GCM) skip padding entirely. ZeroPadding is ambiguous when data ends with 0x00 — do not use it.
• GCM is AEAD: ciphertext plus a 16-byte authentication tag, computed via GHASH over GF(2^128) using H = AES_K(0^128). AAD (additional authenticated data) covers headers without encrypting them. The 96-bit IV (RFC 5288) is treated as a counter; 128-bit IVs go through a GHASH to derive J0 — same security, slightly slower.
• IV reuse is catastrophic. CTR IV reuse leaks P1 XOR P2 (two-time pad). GCM IV reuse (Joux 2006) lets an attacker recover H and forge tags. The page generates IVs with `crypto.getRandomValues` (a CSPRNG), never reuses them within a session, and prepends the IV to the ciphertext so the decryption side can recover it without out-of-band state.
• AES key generation: this tool uses `crypto.getRandomValues` (a CSPRNG provided by the browser) when you click the random-key button. AES round computation runs through aes-js, a pure-JavaScript implementation that is byte-compatible with OpenSSL's libcrypto on the same key, IV, and padding settings.
• Side-channel reality: pure-JS AES is not constant-time (indexing into the S-Box array leaks timing). Web Crypto's AES runs in native code and is constant-time. For high-stakes workloads (HSM, server-side KDFs) prefer the native path; for an in-browser learning tool, aes-js is fine because the input is already in the page's memory. Migration path: SHA-1 → SHA-256 for hashes, DES → AES for ciphers, ECB → GCM for modes.