Overview

Cryptography rarely fails because someone broke the math. AES has not fallen; RSA with proper parameters has not fallen. Systems fail because a nonce was reused, an error message leaked a secret, a comparison ran in non-constant time, or someone rolled their own cipher. This group is a tour of how real systems break, worked hands-on, so that you recognize the patterns before they end up in your code.

Why This Matters

The gap between “the algorithm is secure” and “my system is secure” is where every real-world breach lives. Understanding attacks is not academic: it is what lets you review code, choose libraries, and configure protocols defensively. An engineer who has walked a padding-oracle attack once will never again return distinguishable error messages from a decryption routine.

The Recurring Mistakes Behind Most Failures

A surprisingly small set of mistakes accounts for most cryptographic vulnerabilities. The sibling Common Mistakes page catalogs them with real CVEs.

Mistake	Consequence	Example
Nonce or IV reuse	Keystream reuse, forgery	GCM nonce reuse, WEP
ECB mode	Patterns leak through ciphertext	The famous encrypted penguin
Home-rolled crypto	Subtle, catastrophic bugs	Countless custom “encryption” schemes
Non-constant-time comparison	Timing side channel	HMAC verification leaks
Missing authentication	Ciphertext is malleable	Padding oracles on CBC
Weak or absent randomness	Predictable keys	Debian OpenSSL 2008

Classic Attacks Worked Hands-On

Three attacks in this group are chosen because they teach durable lessons:

• The sibling Padding Oracle page shows how a single distinguishable error message lets an attacker decrypt CBC ciphertext byte by byte, without the key.
• The sibling Side Channels page demonstrates a timing leak from a naive string comparison and explains constant-time programming.
• The sibling Common Mistakes page ties library misuse and bad defaults to concrete failures.

The through-line: confidentiality without integrity is not enough, secrets leak through channels other than the ciphertext, and defaults matter more than algorithms.

Post-Quantum: The Slow-Moving Threat

While implementation bugs are the present danger, a future one is already forcing action. A large quantum computer would break the asymmetric cryptography (RSA, elliptic curve) that underpins TLS and signatures. The sibling Post-Quantum page explains what breaks, the new NIST algorithms (ML-KEM, ML-DSA), and why “harvest now, decrypt later” means the migration matters today even though the threat is years out.

A Quick Taste

ECB mode leaks structure. Encrypt highly repetitive data and watch the pattern survive.

mkdir -p ~/crypto-lab && cd ~/crypto-lab
printf 'AAAAAAAAAAAAAAAA%.0s' {1..4} > plain.bin
openssl enc -aes-128-ecb -K 00112233445566778899aabbccddeeff -in plain.bin -out ecb.bin
xxd ecb.bin

Expected output:

00000000: d6a3 3f7e 1c2b 9a04 55e8 f10d 6b7a 3c29  ..?~.+..U...kz<)
00000010: d6a3 3f7e 1c2b 9a04 55e8 f10d 6b7a 3c29  ..?~.+..U...kz<)
00000020: d6a3 3f7e 1c2b 9a04 55e8 f10d 6b7a 3c29  ..?~.+..U...kz<)

Identical plaintext blocks produce identical ciphertext blocks. The “encryption” leaks exactly the structure it was supposed to hide. That single observation is the seed of the whole group.

Practical Guidance

1. Assume the algorithm is fine and the implementation is not; spend your review time on modes, nonces, comparisons, and error handling.
2. Prefer authenticated encryption (AEAD) so that integrity is not something you can forget to add.
3. Never invent your own cryptographic construction; use a vetted high-level library and its safe defaults.
4. Treat any observable difference (timing, error text, response size) as a potential oracle an attacker can exploit.
5. Start planning post-quantum migration for long-lived secrets now, because data captured today can be decrypted once quantum hardware arrives.