AES (Symmetric) Cryptography

AES is the established standard for symmetric-key encryption, adopted by NIST in 2001. It operates on fixed-size 128-bit blocks and supports key sizes of 128, 192, or 256 bits. Unlike RSA or ECDSA, which use separate keys for encryption and decryption, AES uses the same secret key for both operations. AES’s design—a substitution-permutation network—provides strong diffusion and confusion properties, making it highly resistant to linear and differential cryptanalysis. Its efficiency and security have made it ubiquitous in protocols like TLS, disk encryption (BitLocker, FileVault), VPNs (IPsec), and wireless security (WPA2).

AES transforms each 128-bit plaintext block through multiple rounds of substitution using an S-box, row-wise and column-wise permutations, and mixing operations that combine bytes across the block using finite field arithmetic in GF(2^8). The number of rounds depends on key length: 10 for 128-bit, 12 for 192-bit, and 14 for 256-bit keys. Each round uses a round key derived from the main key via a key schedule, ensuring that every bit of the key influences all bits of the ciphertext over multiple rounds.

AES by itself is a raw block cipher—encrypting the same plaintext block under the same key repeatedly yields identical ciphertext blocks, which leaks patterns. Block cipher modes of operation provide semantic security by introducing an initialization vector (IV) or counter. - **CBC (Cipher Block Chaining)**: Each plaintext block is XORed with the previous ciphertext block before encryption, using a random IV for the first block. - **CTR (Counter)**: Uses a counter value as input to AES to generate a keystream, which is XORed with plaintext; allows random access and parallel processing. - **GCM (Galois/Counter Mode)**: A variant of CTR that adds authentication via a GHASH function over ciphertext and additional data, providing both confidentiality and integrity in one pass.

AES requires a secret key of the chosen length (128 or 256 bits). Secure applications derive keys from passphrases via a Key Derivation Function (KDF) such as PBKDF2, bcrypt, or Argon2, using a salt to prevent rainbow-table attacks. Modes like CBC and GCM require an IV: - **CBC**: IV must be unpredictable and unique; reuse leaks patterns. - **CTR/GCM**: Counter or nonce must be unique per encryption under the same key; reuse breaks security drastically. Good practice is to generate random IVs per encryption and prefix them to the ciphertext for decryption.

Encryption in CBC: pad plaintext to a multiple of 16 bytes (PKCS#7), generate a random IV, and process blocks in chain. Decryption removes padding and verifies integrity only if an authenticated mode like GCM is used. CTR and GCM avoid padding by treating the block cipher as a keystream generator. Libraries may provide high-level APIs, but developers must pass the correct key, IV, and additional authenticated data (AAD) for GCM to ensure both confidentiality and authenticity.

AES is secure against all known practical attacks when used with proper modes and key sizes. However, improper IV reuse in CBC or CTR leads to plaintext leakage. Padding oracle attacks exploit CBC’s padding validation to decrypt data byte-by-byte if an oracle reveals decryption errors. GCM’s authentication tag prevents such oracles but still requires unique nonces. Side-channel attacks on AES implementations—cache timing, branch prediction—necessitate constant-time code and hardware features like AES-NI to mitigate risk.

AES is highly optimized in modern CPUs via the AES-NI instruction set, enabling encryption and decryption at multiple gigabytes per second. In JavaScript environments, the Web Crypto API offloads AES to browser-native implementations for speed and security. Throughput depends on mode: CTR and GCM allow parallel block processing, while CBC is inherently sequential due to chaining.

AES secures web traffic (HTTPS), disk and file encryption, secure messaging (Signal, WhatsApp), VPN tunnels, and cloud storage encryption. Its speed and hardware acceleration make it the default choice for bulk data encryption, while GCM’s integrated authentication simplifies secure protocol design by preventing tampering.

– Use AES-GCM for combined confidentiality and integrity. – Derive keys with a KDF and a unique salt. – Generate fresh IVs/nonces per encryption and include them with ciphertext. – Avoid manual padding logic; use well-tested libraries. – Protect keys in secure enclaves or hardware modules and rotate keys periodically.

// Pseudocode for AES-GCM in JavaScript-like syntax const key = await deriveKey(passphrase, salt, { length: 256 }); const iv = randomBytes(12); const { ciphertext, tag } = encrypt({ key, data: plaintext, iv, additionalData: Buffer.from('header'), mode: 'GCM' }); const decrypted = decrypt({ key, data: ciphertext, iv, additionalData: Buffer.from('header'), tag, mode: 'GCM' });