Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Symmetric Cryptography

Symmetric cryptography is the branch of cryptography in which both parties share the same secret key, used for both encryption and decryption. It is fast, well-understood, and forms the bulk-data layer of nearly every cryptographic protocol in production. It is also the branch where the choice of algorithm matters less than the choice of mode and the discipline of key management, and most real-world failures of symmetric cryptography are failures of those two things rather than failures of the underlying ciphers.

This page is the deep-dive companion to the Cryptography umbrella overview. The scope here is the primitives themselves — what they do, how they fail, and what to actually use. Key management has its own page.

The shape of the problem

A symmetric cipher is a function that takes a key and a plaintext and produces a ciphertext, plus an inverse function that takes the same key and the ciphertext and recovers the plaintext. The security property the cipher provides is confidentiality: an adversary who sees the ciphertext but does not know the key cannot recover the plaintext.

That is all a symmetric cipher provides. It does not provide integrity (the adversary may modify ciphertext bits and the decryption may succeed, producing a corrupted plaintext that the recipient cannot distinguish from a valid one). It does not provide authentication (anyone who knows the key can produce a ciphertext, including the adversary if the key has leaked). The properties beyond confidentiality come from constructions on top of the cipher — message authentication codes, AEAD modes, signed-then-encrypted protocols. The mistake of using raw encryption without authentication is one of the most expensive recurring failures in deployed cryptography.

Symmetric ciphers fall into two architectural families: block ciphers, which operate on fixed-size chunks of data, and stream ciphers, which produce a continuous keystream that is combined with the plaintext bit-by-bit (typically by XOR).

Block ciphers

A block cipher maps a fixed-size input block to a fixed-size output block under a given key. AES, the canonical modern block cipher, uses a 128-bit block. Earlier and regional ciphers use other block sizes — DES used 64 bits, which is part of why DES is now considered structurally inadequate quite apart from its key size.

AES — what to use

The Advanced Encryption Standard (AES), standardized as FIPS 197 in 2001, is the result of a five-year NIST competition that ran from 1997 to 2000. The winning algorithm, originally named Rijndael, was designed by Belgian cryptographers Joan Daemen and Vincent Rijmen. AES supports three key sizes: 128, 192, and 256 bits, performing 10, 12, and 14 rounds respectively. The block size is always 128 bits.

In 2026, AES is the default symmetric cipher for essentially every general-purpose protocol that has been updated in the last fifteen years. It has held up to twenty-five years of focused cryptanalysis. The best known attacks against the full-round AES are biclique attacks that reduce the effective security by a few bits relative to brute force — not even close to practical. The cipher is sound.

Hardware acceleration is the other reason AES dominates. Intel introduced the AES-NI instruction set in the Westmere generation in 2010; AMD followed shortly after. ARMv8 includes the AES extensions in its Crypto Extensions. Modern CPUs encrypt AES at several gigabytes per second per core. VAES (Vector AES), introduced with Intel Ice Lake in 2019 and Sapphire Rapids in 2023, processes multiple AES blocks in parallel using AVX-512 vectors, pushing throughput higher. For new systems, the cost of AES is dominated by memory bandwidth, not CPU.

The practical choice between AES-128, AES-192, and AES-256 comes down to threat model. AES-128 is sufficient against classical adversaries indefinitely. AES-256 is preferred for long-term confidentiality and for environments concerned about future quantum adversaries (see the quantum impact section below). AES-192 sees little deployment in practice; it exists for the FIPS standard but is rarely chosen over the other two.

Historical and regional block ciphers

A handful of other block ciphers are worth knowing by name, mostly to recognize them when they appear in legacy systems or regional standards.

  • DES (Data Encryption Standard), standardized in 1977, was the previous generation. 56-bit key, 64-bit block. Brute-force-broken since the late 1990s. Should never be used in new systems.
  • 3DES (Triple DES) applies DES three times with different keys, providing effective 112-bit security against meet-in-the-middle attacks. Officially deprecated by NIST in 2023 for new applications. Still appears in legacy payment systems and some banking protocols, primarily because the migration cost is enormous.
  • Camellia, jointly designed by NTT and Mitsubishi, is the European counterpart to AES with similar performance and security properties. Used in some Japanese government systems and as a TLS cipher.
  • ARIA, the South Korean standard, is structurally similar to AES with a different S-box design. Used in Korean government systems.
  • SM4, the Chinese standard (formerly SMS4), is mandated for products sold in China that handle commercial cryptographic data. Hardware support is becoming common on Chinese-market processors.
  • Twofish, Serpent, RC6, MARS — the four AES competition finalists that lost to Rijndael. Twofish and Serpent in particular are still occasionally used in specialized contexts (Serpent for its conservative security margin, Twofish for its open design lineage).

The high-level takeaway: AES is the default, and divergence from AES in new systems should be deliberate and justified. The regional ciphers exist because national cryptographic sovereignty is a real concern for some governments; that concern is rarely load-bearing for general engineering decisions.

Modes of operation

A block cipher by itself only encrypts one block. Any real message is longer than 128 bits, which means the block cipher has to be applied repeatedly, and how those applications are chained together is the mode of operation. The choice of mode determines whether the cipher’s security properties actually translate into protocol-level security. AES in a broken mode is broken cryptography that happens to be using AES.

ECB — the cautionary tale

Electronic Codebook (ECB) mode is the simplest possible mode: divide the plaintext into blocks, encrypt each block independently with the same key. The problem is immediately visible if you encrypt an image: identical plaintext blocks produce identical ciphertext blocks, which means patterns in the plaintext survive into the ciphertext. The famous “ECB penguin” demonstration — encrypting the Tux Linux mascot image with ECB and showing the outline still visible — is the standard illustration.

ECB should never be used. There are essentially no contexts in which the right answer to “how should I chain my block cipher applications” is “don’t chain them at all.” If you see ECB in production code, that is a bug.

CBC, CTR, CFB, OFB — the classical modes

Cipher Block Chaining (CBC) XORs each plaintext block with the previous ciphertext block before encryption. Requires an unpredictable initialization vector (IV) for the first block. CBC was the dominant TLS mode for years, until padding oracle attacks (BEAST in 2011, Lucky 13 in 2013) and the broader brittleness of CBC’s interaction with MAC-then-encrypt protocols pushed the standard toward AEAD modes. CBC also requires padding (PKCS#7 typically), which is where the oracle attacks land.

Counter (CTR) mode turns a block cipher into a stream cipher by encrypting a sequence of counter values and XORing the resulting keystream with the plaintext. CTR is parallelizable in both directions and has no padding requirement. It is sound when used correctly. The catastrophic failure mode is nonce reuse: encrypting two different messages with the same counter sequence reveals the XOR of the two plaintexts, which is often sufficient to recover both.

Cipher Feedback (CFB) and Output Feedback (OFB) are older self-synchronizing and synchronous stream-cipher-style modes derived from block ciphers. Both are largely obsolete in modern protocols, displaced by CTR for new designs.

XTS — the disk encryption mode

XEX-based Tweaked Codebook with Ciphertext Stealing (XTS) is the mode used for full-disk encryption: LUKS, FileVault, BitLocker, and most enterprise SED implementations. XTS solves a specific problem — encrypting a sector of disk such that the ciphertext is the same length as the plaintext (no expansion for IVs or authentication tags) and such that each sector is independently decryptable.

XTS does not provide authentication. A disk attacker who can write specific ciphertext can produce specific (corrupted) plaintext on decryption. This is a known limitation, and it is the right tradeoff for the disk encryption use case — adding authentication would require either expanding the sector size or maintaining out-of-band integrity metadata, neither of which fits the disk model. For threat models where the attacker can write arbitrary ciphertext (which is the typical threat model for stolen hardware), XTS is sufficient. For threat models where the attacker is online and can interact with the running system, additional integrity controls are needed.

GCM and the rise of AEAD

Galois/Counter Mode (GCM) combines CTR-mode encryption with a Galois-field-based authenticator (GHASH) to produce an authenticated encryption with associated data (AEAD) construction. GCM is parallelizable, fast, hardware-accelerated alongside AES, and provides both confidentiality and integrity in a single primitive. AES-GCM is the dominant symmetric construction in modern TLS, IPsec, and SSH.

GCM has one catastrophic failure mode: nonce reuse. Encrypting two distinct messages with the same nonce under the same key allows the authenticator key to be recovered, which destroys the integrity property entirely (and also leaks information about the plaintexts via the CTR-mode keystream reuse). The standard mitigation is to use a 96-bit nonce constructed as a fixed prefix plus a counter, ensuring uniqueness for the lifetime of the key. Random nonces are sound only if drawn from a space large enough that collisions are astronomically unlikely — which is why GCM-SIV exists.

AES-GCM-SIV, standardized in RFC 8452, is a nonce-misuse-resistant variant. If a nonce is reused, the worst-case leakage is that an attacker learns which two messages were encrypted with the same nonce — much less catastrophic than full GCM nonce reuse. It is slower than GCM but provides a robustness margin worth having in environments where nonce uniqueness is hard to guarantee.

Stream ciphers

A stream cipher generates a pseudo-random keystream from a key (and typically a nonce) and XORs the keystream with the plaintext to produce the ciphertext. The keystream is the entire security argument: if the keystream is indistinguishable from random, the cipher is secure; if there are patterns, the cipher is broken.

ChaCha20 — the modern alternative

ChaCha20, designed by Daniel J. Bernstein in 2008 as an improvement on his earlier Salsa20, is the dominant modern stream cipher. It uses a 256-bit key and a 96-bit nonce, and produces a keystream by applying 20 rounds of a quarter-round function to an initial state derived from the key and nonce.

ChaCha20’s primary advantage over AES is performance on platforms without AES hardware acceleration. Mobile chips, older embedded systems, and any environment without AES-NI or ARM Crypto Extensions can run ChaCha20 in software faster than software AES, often by a factor of three or more. This is why Google adopted ChaCha20-Poly1305 as a preferred TLS cipher for mobile clients in 2014, and why TLS 1.3 includes it as a standard option.

ChaCha20-Poly1305, specified in RFC 7539 (now RFC 8439), pairs ChaCha20 with the Poly1305 authenticator to produce an AEAD construction. Like AES-GCM, it provides confidentiality and integrity in a single primitive. Like AES-GCM, nonce reuse is catastrophic. The 96-bit nonce gives ample room for counter-based uniqueness.

Historical: RC4

RC4, designed by Ron Rivest in 1987 and leaked publicly in 1994, was the dominant stream cipher for two decades. Used in WEP, early WPA, original TLS, and many other protocols. Beginning in the early 2000s, statistical biases in the keystream were discovered, and by 2013 the biases were exploitable in practical attacks against TLS. RC4 was prohibited in TLS by RFC 7465 in 2015. It should never appear in new systems and is a signal of legacy infrastructure where it appears in old ones.

How symmetric cryptography fails in practice

The cipher choice is rarely the failure mode. The recurring real-world failures cluster around six patterns.

Nonce reuse. Every modern AEAD construction (GCM, ChaCha20-Poly1305) requires a unique nonce per encryption under a given key. Reusing a nonce destroys both confidentiality and authenticity in ways that are typically recoverable by an adversary. The pattern shows up most often in stateless or restart-prone systems that draw nonces randomly without sufficient entropy, or in distributed systems where multiple workers share a key but don’t coordinate nonce generation.

Missing authentication. A protocol that encrypts without authenticating is broken. CBC-without-HMAC, CTR-without-MAC, and raw stream cipher use are all failure patterns. The solution is to use AEAD constructions exclusively for new designs, or to use Encrypt-then-MAC explicitly when AEAD isn’t available.

Padding oracle attacks. CBC-mode encryption with separate MAC verification, where the MAC check and the padding check happen at different times or fail in distinguishable ways, leaks information about the plaintext. Lucky 13 against TLS, POODLE against SSL 3.0, and a long history of similar attacks all live in this family. AEAD modes eliminate the entire class of failures.

Side-channel leakage. A correctly implemented AES algorithm running in a way that leaks key information through timing (cache-timing attacks), power consumption (DPA), or electromagnetic emissions (TEMPEST) can be broken even though the mathematics is sound. The mitigation is constant-time implementations, hardware-protected key storage, and threat models that account for adversaries with physical access.

Key reuse across contexts. Using the same symmetric key for multiple purposes — encryption and MACing, encryption of file A and file B in incompatible modes, the same key in two protocols — is a recurring pattern of failure. The general principle is that each distinct security context should derive a fresh key from a master secret via a key derivation function.

Algorithm misuse via correct primitives. Using AES-ECB to “encrypt” a database column. Using a CTR-mode keystream without authentication, then complaining when an attacker flips bits. Implementing CBC-then-MAC instead of MAC-then-CBC or AEAD. The primitive does what the spec says; the deployment does not provide the property the engineer assumed. This is the largest category by volume.

Performance and what it costs

On modern hardware with AES-NI, AES-GCM at full throughput is bounded by memory bandwidth, not by the cipher. Benchmark numbers in the range of 5-10 GB/s per core for AES-128-GCM are typical on x86 server hardware in 2026. ChaCha20-Poly1305 on the same hardware runs at roughly 2-3 GB/s per core — fast enough that the choice between the two is rarely about throughput on modern x86.

On ARM mobile, the comparison is closer. ARMv8 has AES instructions, but the performance gap with x86 server hardware is real, and ChaCha20 in pure software remains competitive. On older ARM cores or embedded systems without crypto extensions, ChaCha20 in software typically beats AES in software by a meaningful margin.

For protocol design, the practical guidance is: prefer AES-GCM on systems with hardware acceleration, prefer ChaCha20-Poly1305 on systems without it, and let the protocol negotiate between them. TLS 1.3 does exactly this.

Quantum impact

Symmetric cryptography is far less affected by quantum computing than asymmetric cryptography is. Grover’s algorithm, the relevant quantum attack against symmetric primitives, provides a square-root speedup over classical brute force. Against AES-128, Grover reduces the effective security to roughly 64 bits, which is uncomfortably close to practical even before considering the engineering challenges of building a Grover-capable quantum computer. Against AES-256, Grover reduces the effective security to 128 bits, which remains far out of reach.

The standard recommendation for post-quantum-safe symmetric cryptography is therefore: double the key size. AES-256 is post-quantum-safe by current understanding. SHA-256 used as a building block in a symmetric construction retains 128-bit security against Grover. Most modern protocol specifications now default to 256-bit symmetric keys for any cryptographic context expected to remain secure into the era of large quantum computers.

This is one of the few corners of cryptography where the post-quantum transition is mechanically simple: pick larger keys. The hard work of the post-quantum transition is in asymmetric cryptography, not here.

Standards and references

The relevant specifications:

  • FIPS 197 — Advanced Encryption Standard.
  • NIST SP 800-38A — Recommendation for Block Cipher Modes of Operation: Methods and Techniques (ECB, CBC, CFB, OFB, CTR).
  • NIST SP 800-38D — Galois/Counter Mode (GCM) and GMAC.
  • NIST SP 800-38E — XTS-AES mode for confidentiality on storage devices.
  • NIST SP 800-67 — Recommendation for the Triple Data Encryption Algorithm (TDEA, the official name for 3DES).
  • RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols (the current ChaCha20-Poly1305 spec).
  • RFC 8452 — AES-GCM-SIV: Nonce Misuse-Resistant AEAD.

What to actually use in 2026

For new systems, the short answer is: AES-GCM if you have hardware acceleration, ChaCha20-Poly1305 if you don’t, with AES-256 if the threat model includes future quantum adversaries. Both are AEAD; both provide confidentiality and integrity in a single primitive; both are well-supported by every modern cryptographic library. Negotiate between them at the protocol level if you need to support a range of platforms.

For full-disk encryption, AES-XTS at 256-bit key strength remains the standard. For password-based encryption, derive the key using Argon2id before applying the symmetric cipher; do not use the password as a key directly.

Avoid: ECB mode in any context, CBC without integrated authentication, stream ciphers without authentication, RC4 entirely, DES entirely, 3DES for new applications, and any cryptographic construction implemented from a primitive instead of a vetted library. The libraries that produce correct results consistently — libsodium, BoringSSL, the Rust crypto ecosystem, the Go standard library — exist precisely because the failure modes above are common enough that no individual implementation should be trusted to avoid them all.

The cipher is the easy part. The mode, the nonce discipline, and the integration with the rest of the protocol are where the work lives.