Cryptographic Attacks

Cryptographic Attacks — Quick Reference

Attack	Target	Mechanism	Requires On-Path?	Primary Defense
Birthday Attack	Hash algorithm	Brute-force search for two inputs producing the same hash digest (collision)	No	Large hash output size (SHA-256 or higher)
Downgrade Attack	Protocol negotiation	Forces use of weaker protocol version or no encryption	Yes	Disable legacy protocols; HSTS; TLS_FALLBACK_SCSV
SSL Stripping	HTTP→HTTPS redirect	Intercepts 301 redirect; victim uses HTTP while attacker uses HTTPS with server	Yes	HSTS (forces HTTPS before first request reaches server)
POODLE	TLS version negotiation	Forces SSL 3.0 fallback; exploits SSL 3.0 CBC padding oracle	Yes	Disable SSL 3.0 server-side; TLS_FALLBACK_SCSV

Birthday Paradox — The Math Behind Hash Collisions

The unintuitive result: In a group of only 23 people, the probability that two share a birthday is approximately 50%. This seems low because most people think about the probability of matching one specific birthday — but the question is whether any two people match each other.

Why it scales this way: With 23 people, there are 23 × 22 / 2 = 253 possible pairs to check. Each pair has a 1/365 chance of sharing a birthday. With enough pairs, collisions become likely long before the group is large enough to guarantee a specific match.

Applied to hash functions: For a hash producing N possible output values, finding a collision between any two inputs takes approximately √N attempts — not N. This is the birthday bound:

Hash Algorithm	Output Size	Theoretical Collision Resistance	Birthday Attack Effort	Status
MD5	128 bits	2¹²⁸ possible digests	~2⁶⁴ operations (birthday bound) — but structural weaknesses allow far fewer	Broken — collisions practical
SHA-1	160 bits	2¹⁶⁰ possible digests	~2⁸⁰ (birthday bound) — SHAttered 2017 demonstrated with 2^63.1	Deprecated — collisions demonstrated
SHA-256	256 bits	2²⁵⁶ possible digests	~2¹²⁸ — computationally infeasible with current technology	Secure — current standard
SHA-512	512 bits	2⁵¹² possible digests	~2²⁵⁶ — far beyond any foreseeable computing capability	Secure — highest strength

Exam tip: The defense against birthday attacks is a large hash output size. More bits means a larger output space, which means more attempts are needed to find a collision.

MD5 Collision — Timeline

April 1992 — MD5 published by Ron Rivest; 128-bit output; designed to replace MD4; widely adopted for digital signatures, certificate signing, and password storage

1996 — Researchers identify structural weaknesses in MD5's compression function that suggest collision vulnerabilities; industry begins warning against MD5 for security-critical use

2004 — Wang et al. demonstrate practical MD5 collision generation; two different inputs producing identical MD5 hash created within hours on consumer hardware; collision resistance considered fully broken

December 2008 — Researchers use MD5 collisions to create a fraudulent CA certificate appearing legitimately signed by RapidSSL; the CA never signed the fraudulent certificate — the MD5 hash matched the hash of a legitimate certificate the CA did sign; the industry immediately stops using MD5 for certificate signing

Present — MD5 forbidden for any PKI or security-critical application by CA/Browser Forum policy; SHA-256 is the minimum acceptable hash for certificate signing; SHA-1 also deprecated (SHAttered collision demonstrated 2017)

SSL Stripping — Step-by-Step Flow

Prerequisite: Attacker has positioned themselves on the network path between the victim and the web server (via ARP poisoning, rogue AP, or compromised network device)

Step 1 — Victim sends HTTP GET: Victim types example.com (no HTTPS specified); browser sends GET http://example.com; attacker passes this through unchanged to the server

Step 2 — Server sends HTTPS redirect: Server responds 301 Moved Permanently → https://example.com; attacker intercepts this response and does NOT forward it to the victim

Step 3 — Attacker opens HTTPS to server: Attacker sends GET https://example.com directly to the server; establishes a full encrypted HTTPS session; has complete access to all decrypted server content

Step 4 — Attacker sends HTTP 200 OK to victim: Victim receives an HTTP (not HTTPS) OK response; victim's browser never sees the HTTPS redirect; believes the site is HTTP

Step 5 — Victim sends credentials over HTTP: Victim submits username and password via HTTP POST; credentials are plaintext; attacker reads them directly

Step 6 — Attacker forwards credentials over HTTPS: Attacker sends the captured credentials to the server over the encrypted HTTPS session; server authenticates successfully

Result: Victim ↔ Attacker: HTTP (plaintext — attacker reads everything). Attacker ↔ Server: HTTPS (encrypted). Server logs show a clean authenticated HTTPS session. Victim sees no error or warning.

POODLE Attack — How Downgrade Enables the Padding Oracle

Phase	What Happens	Why It Matters
Phase 1 — Downgrade	Attacker on the network path interferes with TLS handshake; injects errors causing the connection to fail; client and server retry; after enough failures the client offers SSL 3.0 as a fallback	Gets both parties onto SSL 3.0 — the vulnerable protocol; without this step, modern TLS 1.2/1.3 is used and the padding oracle technique cannot apply
Phase 2 — Padding Oracle	SSL 3.0 uses CBC mode encryption with padding; attacker sends modified ciphertext blocks to the server; server's response (accept/reject) reveals whether padding was valid; attacker uses this signal to deduce plaintext bytes one at a time	With enough modified requests, attacker reconstructs plaintext content — such as the session cookie — from the SSL 3.0 encrypted stream
Phase 3 — Session Theft	Attacker uses the recovered session cookie to impersonate the victim	Full session hijacking achieved without knowing the password or decrypting the TLS key

Algorithm vs. Implementation — Where Attacks Land

Cryptographic attacks fall into two categories, and the distinction matters for both defense and exam questions:

Algorithm attacks target mathematical weaknesses in the cryptographic design itself — independent of any specific implementation. The birthday attack against MD5 is an algorithm attack: it works against any correct implementation of MD5 because the vulnerability is in the hash function's mathematical structure. Defense: choose a stronger algorithm.

Implementation attacks target how a correct algorithm is used, configured, or negotiated. Downgrade attacks and SSL stripping are implementation attacks: TLS 1.3 is not broken — but if the implementation allows falling back to SSL 3.0, or if the HTTP redirect to HTTPS can be intercepted, the security fails. The algorithm is fine; the deployment is vulnerable. Defense: correct implementation (HSTS, disabling legacy protocols, proper cipher suite configuration).

Exam tip: When a question identifies a downgrade attack or SSL stripping, the answer is an implementation/protocol vulnerability — not a weakness in the TLS algorithm itself. When it describes a birthday attack or hash collision, the answer is an algorithm-level weakness.

Defense Stack — Cryptographic Attacks

Attack	Primary Defense	Secondary Defenses
Birthday attack / hash collision	Use SHA-256 or SHA-3 — large hash output provides collision resistance proportional to output size	Retire MD5 and SHA-1 from all security-critical contexts; audit existing certificates and signatures
SSL stripping	HSTS (HTTP Strict Transport Security) — browser refuses HTTP connections for the domain entirely	HSTS preloading; redirect all HTTP to HTTPS with 301; enforce HTTPS at load balancer/CDN level
POODLE / TLS downgrade	Disable SSL 3.0 and TLS 1.0/1.1 server-side — no fallback target means no downgrade possible	TLS_FALLBACK_SCSV extension; modern TLS 1.3 only where possible; web application firewall rules detecting downgrade attempts

Cryptographic Attack Concepts