How cryptography fails

The cryptographic truth

Modern algorithms are rarely the weak point. AES and SHA-256 have no practical breaks. Systems fall because of everything around the algorithm: how keys are generated and stored, how protocols compose primitives, and what the implementation leaks. This is exactly why the OWASP Top 10 category is Cryptographic Failures (A04:2025), not "weak algorithms"; the failures are overwhelmingly operational. "Don't roll your own crypto" is the field's most repeated advice for this reason: the primitive is the easy part.

Brute force and key length

Trying every key. The defence is a keyspace too large to search: 2^128 is beyond any conceivable classical machine, which is why AES-128 is safe and DES (2^56) is not. Brute force sets the floor; every other attack is about doing better than brute force.

Note the difference between attacking the cipher and attacking the password that protects a key, since the latter is usually far easier, which is why password and key management dominate real breaches.

Implementation and protocol failures

• Weak randomness. Keys, IVs and nonces must come from a CSPRNG. Predictable randomness has broken real systems repeatedly: the 2008 Debian OpenSSL bug crippled key entropy; reused ECDSA nonces leaked the Sony PlayStation 3 signing key outright. If you can predict the "random," you don't need to break the cipher.
• Nonce/IV reuse. Reusing a key+nonce in CTR/GCM/stream ciphers is catastrophic, not cosmetic: it can expose plaintext and, for GCM, the authentication key.
• Padding oracles. When a system reveals (through errors or timing) whether decryption padding was valid, an attacker can decrypt CBC ciphertext without the key. POODLE and the Lucky Thirteen attacks are examples. AEAD modes (GCM) sidestep the whole class.
• Downgrade attacks. Forcing two parties to negotiate a weaker, breakable protocol version (FREAK, Logjam). TLS 1.3 removed the weak options that made downgrades worthwhile.
• Using encryption without authentication. Confidentiality without integrity lets attackers tamper with ciphertext. Always use authenticated encryption.

Side-channel attacks

These attack the physical implementation, not the maths; the algorithm is perfect but the machine running it leaks.

• Timing attacks. Operations that take key-dependent time leak the key. The classic offender is a non-constant-time comparison (== on a MAC that bails out at the first wrong byte). Fix: constant-time comparison, where execution time is independent of the data.
• Power analysis (SPA/DPA): measuring power draw to read out key bits; relevant to smart cards and hardware tokens.
• Cache / microarchitectural attacks: Spectre, Meltdown, and cache-timing attacks recover secrets across security boundaries by observing shared CPU state. The least common mechanism design principle, violated.
• Acoustic, electromagnetic, even fault injection: physically glitching a chip to skip a security check.

Side channels are the reason "we use AES-256" is not a complete security argument. The data has to not leak through the side door.

Cryptanalysis (worth naming)

• Known-plaintext / chosen-plaintext / chosen-ciphertext attack models: what the attacker is assumed able to see or influence. Modern ciphers are designed to resist even chosen-ciphertext attacks.
• Frequency analysis: breaks classical substitution ciphers (Caesar, Vigenère) by exploiting letter distributions. Historical, but it's the intuition for why a good cipher's output must look uniformly random.
• Differential and linear cryptanalysis: the statistical techniques AES is explicitly designed to withstand.

The quantum horizon

A large fault-tolerant quantum computer would change the asymmetric landscape:

• Shor's algorithm efficiently factors integers and solves discrete logs, breaking RSA, Diffie-Hellman and ECC. Asymmetric crypto as deployed today would fall.
• Grover's algorithm gives only a quadratic speed-up on brute force, halving effective symmetric key strength. The fix is simply larger keys: AES-256 stays comfortably secure, SHA-512 likewise.

The threat is live now because of "harvest now, decrypt later": adversaries record encrypted traffic today to decrypt once quantum hardware arrives. Anything needing long-term confidentiality is already at risk.

NIST finalised the first post-quantum cryptography (PQC) standards in August 2024:

• FIPS 203 (ML-KEM), lattice-based key encapsulation from CRYSTALS-Kyber: the PQC replacement for key exchange.
• FIPS 204 (ML-DSA), lattice-based signatures from CRYSTALS-Dilithium: the primary PQC signature scheme.
• FIPS 205 (SLH-DSA), stateless hash-based signatures from SPHINCS+: a conservative signature backup resting only on hash security.

Further algorithms (HQC, Falcon) are being standardised to diversify the mathematical assumptions. NIST's transition plan (IR 8547) sets deprecation of quantum-vulnerable algorithms by 2035, with high-risk systems moving sooner, and deployments increasingly use hybrid modes (classical + PQC together) so a flaw in the new maths doesn't leave you worse off than before.

Quick recall

• Algorithms rarely break; key management, randomness, protocol design and side channels do; hence OWASP A04 "Cryptographic Failures" and "don't roll your own."
• Nonce/IV reuse, weak RNG, padding oracles, downgrade, and unauthenticated encryption are the recurring own-goals.
• Side channels (timing, power, cache) attack the implementation, not the maths; use constant-time code.
• Shor breaks RSA/DH/ECC; Grover only halves symmetric strength (AES-256 survives). "Harvest now, decrypt later" makes it a present concern.
• NIST PQC standards (Aug 2024): FIPS 203 ML-KEM, 204 ML-DSA, 205 SLH-DSA; migrate by ~2035.