Symmetric cipher reference
Symmetric ciphers use the same secret key to encrypt and decrypt. They are fast and used for bulk data: TLS records, disk encryption, file encryption and tokens. This reference compares AES, ChaCha20, 3DES, Blowfish and others by key size, block size, the recommended mode of operation, and current security status.
Block ciphers vs stream ciphers
A block cipher (AES, 3DES) encrypts a fixed-size block of bits at a time — typically 128 bits for AES or 64 bits for 3DES. To encrypt a message longer than one block, a mode of operation chains the blocks together.
A stream cipher (ChaCha20) generates a continuous pseudorandom keystream and XORs it byte-by-byte with the plaintext, working naturally on arbitrary-length data without block-padding logic.
Modes of operation
The cipher algorithm itself is rarely the vulnerability — the mode usually is:
| Mode | Authentication | Notes |
|---|---|---|
| GCM (AEAD) | Built-in | Preferred for most uses. Fast with AES-NI. Nonce reuse is catastrophic. |
| ChaCha20-Poly1305 (AEAD) | Built-in | Preferred on hardware without AES acceleration. |
| CCM (AEAD) | Built-in | Used in constrained environments (802.11, Bluetooth). |
| CBC | External MAC needed | Vulnerable to padding-oracle attacks without careful implementation. |
| CTR | External MAC needed | Parallelisable, but nonce management is the developer’s responsibility. |
| ECB | None | Never use. Identical plaintext blocks produce identical ciphertext blocks. |
Choosing the right cipher
New systems: Default to AES-256-GCM. It is hardware-accelerated on every modern processor via AES-NI and offers 256-bit keys with authenticated encryption in one operation.
No AES hardware acceleration: Choose ChaCha20-Poly1305. It is constant-time in software, resistant to timing side-channels, and used widely in TLS 1.3, SSH, and WireGuard.
Migrating legacy code: If you are still on 3DES or RC4, migrate. 3DES has a 64-bit block size that makes it vulnerable to Sweet32 birthday attacks on long sessions, and it is deprecated by NIST. RC4 is fully broken.
The nonce problem
Both AES-GCM and ChaCha20-Poly1305 require a unique nonce (number used once) per encryption under the same key. Reusing a GCM nonce with the same key is catastrophic: it leaks the authentication key and makes all messages under that key-nonce pair decryptable. In practice, generate a random 96-bit nonce per message (the collision probability at scale is negligible) or use a deterministic counter that never repeats.
Key size context
AES-128 provides 128 bits of security — no practical attack exists today, and it is sufficient for virtually all applications. AES-256 provides extra margin against future cryptanalysis and partially mitigates Grover’s algorithm for hypothetical quantum attackers (reducing effective security to 128 bits under Grover). In practice the choice of mode and nonce discipline matters far more than the key length jump from 128 to 256 bits.
Quick decision guide
- Store a file or a database column → AES-256-GCM with a random nonce stored alongside the ciphertext.
- TLS record or network packet → handled by the TLS 1.3 handshake (usually AES-GCM or ChaCha20-Poly1305 negotiated automatically).
- Embedded / IoT / no AES-NI → ChaCha20-Poly1305.
- Legacy interop requiring 3DES → plan a migration; never build new code around it.