How the Hash Functions Broke in Real Life: MD5, Flame, SHATTERED, and the Long Death of SHA-1

noreply@paragmali.com (Parag Mali) — Fri, 17 Jul 2026 00:00:00 GMT

**MD5 and SHA-1 -- the two hashes that once fingerprinted the entire internet -- are genuinely, mathematically broken.** Their collision resistance fell to cryptanalysis between 2004 and 2020. But every real breach they enabled -- the 2008 rogue certificate authority, 2012's Flame espionage malware, 2017's SHATTERED, 2020's Shambles -- needed a *second* failure beside the broken math: a deployment that had not yet stopped trusting the dead algorithm. That empirical record is the base rate that justifies migrating to SHA-2 and SHA-3, and it is why "broken" is narrower than you think: HMAC-SHA-1 is still fine, and preimage resistance held. Here is exactly what fell, what did not, and how to audit and migrate your own systems.

1. The Forged Certificate That Rode Windows Update

In the spring of 2012, espionage malware called Flame spread through the Middle East wearing a disguise almost nothing could see through: it arrived signed by Microsoft, and reached some targets through Windows Update itself [@kaspersky-flame-gadget]. To a defending machine, it looked like a legitimate patch from the one vendor it trusted most. To forge that signature, its operators did something the open cryptographic literature had not yet published. They engineered a chosen-prefix collision in MD5 -- a hash academics had called broken since 2004 [@wang2004-md5-eprint] -- and counterfeited a certificate that chained up to Microsoft's own root of trust [@stevens-counter-crypto-c13].

The certificate they forged was not a plainly-issued code-signing certificate. It was a Terminal Server Licensing Service certificate living inside Microsoft's Enforced Licensing public-key infrastructure -- an obscure corner of Microsoft's PKI that the company was, in 2012, still signing with MD5. When Microsoft published Security Advisory 2718704 on 3 June 2012, the fix was to revoke exactly those certificates: the "Microsoft Enforced Licensing Intermediate PCA" and the "Microsoft Enforced Licensing Registration Authority CA" [@ms-advisory-2718704].

A deterministic function that compresses a message of any length into a short, fixed-length string called a digest (or hash). The same input always yields the same digest, a different input almost always yields a different one, and the function is designed to be one-way: easy to compute forwards, infeasible to invert.

The unsettling part of Flame is not that the math failed. It is that the math had failed nearly a decade earlier, in a Chinese cryptographer's paper read at a 2004 conference, and Microsoft's licensing servers were still signing with it eight years later. A broken primitive sat, patiently, underneath a live production certificate authority until someone with a nation-state budget decided to point a collision at it.

Now hold one more artifact in your head, because you will learn to read it by the end of this article. It is a SHA-1 digest:

38762cf7f55934b34d179ae6a4c80cadccbb7f0a

In February 2017, researchers at CWI Amsterdam and Google published two different PDF files that both hash to exactly that value [@shattered-2017]. Two distinct documents, one fingerprint -- a thing that was supposed to be computationally impossible for the hash guarding TLS certificates, Git commits, and software signatures across the internet.

Note: Every break in this story needed two failures at once: a hash whose collision resistance had already fallen, and a deployment that had not yet stopped trusting it. Cryptanalysis was necessary. It was never, by itself, sufficient.

That diagnostic sentence is the spine of everything that follows. It is also why this article is the honest exception in a series otherwise arguing that the deployment breaks, not the math. Here the math genuinely broke. And even here, on the one topic where the primitive itself fell, no attacker ever won on cryptanalysis alone. They won where broken math met a system still trusting it.

So if MD5 was known-broken years before Flame, why was anything still signing with it? To answer that, we have to be precise about what a hash actually promises -- because only one of its promises is fragile, and it is the exact one a certificate leans on.

2. What a Hash Promises, and Which Clause Is Fragile

A cryptographic hash function makes three separate promises. They sound similar, they are routinely confused, and telling them apart is the difference between understanding this whole story and mis-stating it. Only one of the three is fragile, and it is the one certificates depend on.

Given a target digest `h`, it is infeasible to find any message `m` such that `hash(m) = h`. This is the "one-way" promise: you cannot run the function backwards from an output to an input. Given a specific message `m1`, it is infeasible to find a *different* message `m2` with the same digest. The attacker is handed one input and must match its fingerprint with another. It is infeasible to find *any* two messages `m1` and `m2`, both of the attacker's choosing, that produce the same digest. Nobody hands the attacker a target. They get to pick both sides. This is the weakest promise to keep, and the one every certificate and signature quietly relies on.

The gap between those last two properties is not cosmetic; it is exponential, and it has a name.

For an `n`-bit digest, finding a collision takes only about `2^(n/2)` work, not `2^n`. The name comes from the birthday paradox: in a room of just 23 people, two probably share a birthday, because what matters is the number of *pairs*, which grows quadratically. Collisions among many hashes are similarly cheap.

That square-root haircut is brutal. By that bound, a 128-bit MD5 digest [@rfc1321-md5] offers only about $2^{64}$ collision security, and a 160-bit SHA-1 digest only about $2^{80}$. Preimage and second-preimage attacks still cost close to the full $2^{128}$ or $2^{160}$, which is why -- spoiler for Section 8 -- those properties survived while collision resistance did not. When you hear "MD5 is broken," the precise statement is "MD5's roughly $2^{64}$ collision barrier fell far below $2^{64}$." It is not "you can invert an MD5 hash."

Property	Informal promise	Generic attack cost	What it protects
Preimage resistance	Cannot find any message for a given digest	about `2^n`	Password storage, commitments
Second-preimage resistance	Cannot match a given message's digest with another	about `2^n`	Integrity of one known file
Collision resistance	Cannot find any two messages sharing a digest	about `2^(n/2)`	Certificates, signatures, content addressing

One construction under all of them

MD5, SHA-1, and SHA-2 are not three unrelated designs. They are three members of one family, built from the same skeleton.

A design that turns a fixed-size compression function into a hash for arbitrary-length messages. You start from a fixed initial value (the IV), split the padded message into blocks, and feed each block plus the running state through the compression function. The final state is the digest. flowchart LR IV["Fixed IV"] --> F1["Compress"] M1["Block 1"] --> F1 F1 --> F2["Compress"] M2["Block 2"] --> F2 F2 --> F3["Compress"] M3["Block 3 plus length padding"] --> F3 F3 --> D["Digest"]

Ronald Rivest published MD5 in April 1992 as RFC 1321, producing a 128-bit digest [@rfc1321-md5].Rivest is the "R" in RSA. MD5 was his hardened successor to MD4, and RFC 1321 says it "backs off" from MD4's speed for a "greater likelihood of ultimate security." The US government's SHA lineage followed a parallel path: SHA (retroactively SHA-0) arrived in FIPS 180 in 1993, and SHA-1 replaced it in FIPS 180-1 on 17 April 1995 with a 160-bit digest [@fips-180-1].SHA-0 was withdrawn within about two years for an undisclosed weakness. SHA-1 differs from it by a single added one-bit rotation in the message schedule -- a fix whose importance Section 3 makes concrete.

Why a collision is a forgery

Here is the load-bearing fact that ties the fragile clause to the real world. A digital signature does not sign your whole message. It signs the hash of your message, because the message may be gigabytes and the signing math is slow. The signer computes a digest, then encrypts that short digest with a private key.

flowchart TD M1["Message A, benign"] --> H["Hash function"] M2["Message B, malicious"] --> H H --> D["One shared digest"] D --> S["Signer signs the digest"] S --> Sig["A single signature"] Sig --> Cover["Valid for A and for B"]

Follow the consequence. If an attacker finds two messages with the same digest, and persuades someone to sign the harmless one, that same signature is automatically valid on the malicious one. The certificate authority signs a benign-looking certificate request; the attacker walks away with a valid signature on a forged certificate that shares its hash. Collision resistance is the only thing standing between "sign this document" and "you just signed a document you never saw."

const safe = ["hmac", "checksum", "legacy-verify", "kdf"];

if (collisionDependent.includes(use)) { return "MIGRATE -- collision-dependent, move to SHA-2 or SHA-3"; } if (safe.includes(use)) { return "OK -- collision resistance is not relied on"; } return "REVIEW -- ask: can an adversary supply both inputs and profit?"; }

["certificate", "hmac", "git-object", "checksum", "code-signing"].forEach(function (u) { console.log(u, "->", auditHashUse(u)); }); `}

Choosing a target

Once you know a use must move, pick the destination by requirement, not by fashion. SHA-256 is the FIPS default and the safe first answer: NIST tells designers to implement it at a minimum, and it is hardware-accelerated on modern CPUs [@fips-180-4-sha2, @nist-policy-hash]. Want length-extension resistance for free? SHA-512/256 truncates a wider computation and never leaks its full state [@fips-180-4-sha2]. Want structural diversity or an extendable-output function? Reach for SHA-3 or SHAKE [@fips-202-sha3].

If raw speed dominates and a FIPS stamp is not required, BLAKE3 is the fastest of the group and length-extension-immune [@blake3-repo]. And if you are stuck on a SHA-1 you cannot rip out this quarter, deploy sha1dc collision detection the way Git did, then schedule the real migration behind it [@sha1dc-stevens-shumow-2017].

The mistakes, mapped to the breaks

Every common hashing mistake is a small echo of one of the four incidents. Naming the echo makes the fix obvious.

The mistake	The break it echoes	The fix
MD5 or SHA-1 for certificates or code signing	Rogue CA (2008), Flame (2012)	SHA-256 signatures [@fips-180-4-sha2]
SHA-1 as a content-address or dedup key	SHATTERED (2017)	SHA-256 objects, `sha1dc` as a stopgap [@sha1dc-stevens-shumow-2017]
SHA-1 for identity or Web-of-Trust signatures	Shambles (2020), CVE-2019-14855	Modern GnuPG on SHA-256 [@shambles-2020]
`H(secret \|\| message)` used as a MAC	Length extension	HMAC, or KMAC on SHA-3 [@rfc2104-hmac]
Assuming a collision break means a preimage break	--	Keep salted preimage and HMAC uses; migrate only collision-dependent ones [@nist-policy-hash]

Two pitfalls deserve their own warning because they masquerade as fixes. Swapping Ethereum's Keccak-256 for standardized SHA3-256 silently changes your digests [@fips-202-sha3]. And treating sha1dc as a migration rather than a stopgap leaves you permanently one clever attack away from trouble; detection buys time, it does not end the dependency.

Note: Whatever legacy you must tolerate, draw one hard line: never generate a new MD5 or SHA-1 signature, certificate, or code-signing object. Every incident in this article began where a system was still willing to sign with a dead hash.

Internalize that audit question and these habits, and you have absorbed the base rate this whole history was written to establish. It remains only to name it.

11. The Base Rate

Return to the digest from the opening: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a. You can read it now. It is a SHA-1 value shared by two different PDFs -- an identical-prefix collision from SHATTERED, which means it proved SHA-1 dead for content addressing but could not, on its own, forge a certificate for a chosen identity [@shattered-2017]. That one artifact contains the whole argument in miniature: a real mathematical break, precisely scoped, whose damage depended entirely on what still trusted it.

Stretch that artifact across nearly four decades. From MD5's publication in 1992 to the federally mandated retirement of its successor SHA-1 in 2030 is a thirty-eight-year empirical record [@rfc1321-md5, @nist-sha1-retire-2022]. Inside it sit four undisputed, reproducible, weaponized breaks -- the 2008 rogue CA, 2012's Flame, 2017's SHATTERED, 2020's Shambles. Four in twelve years, on two primitives that fell the same way, is not a scare story. It is a measured base rate, and it is the entire justification for migrating to SHA-2 and SHA-3.

Every break in this story needed two failures at once: a hash whose math had fallen, and a deployment that had not yet stopped trusting it.

That is how this article honors the series' thesis without lying about the mathematics. This is the one topic where the primitive genuinely fell -- and even here, cryptanalysis was necessary and never sufficient. RapidSSL had to still be signing with MD5. Microsoft's licensing PKI had to still be signing with MD5. GnuPG had to still default to SHA-1. The math was the loaded chamber; the still-live deployment pulled the trigger.

And keep the boundary honest, because the slogan overreaches in both directions. "Broken" is scoped to collision-dependent uses: HMAC-SHA-1 survives on a proof, and preimage resistance held [@rfc2104-hmac, @nist-policy-hash]. The successors do not stand in a line of succession at all -- SHA-2 and SHA-3 coexist by diversification, one construction covering the other's structural blind spot.

For the mechanisms of how the successors themselves could someday be attacked -- Merkle-Damgard collisions, length extension, and the sponge's algebraic frontier -- see the structural sibling to this piece, How SHA-2 and SHA-3 Would Break, along with the series' dedicated hash and X.509/PKI field guides. The migration itself is not a debate. It is an argument the evidence already won. The only open question left is how fast the still-live tail catches up before the next drop in attack cost reaches the systems that forgot to.

12. Frequently Asked Questions

Yes, for collision-dependent uses such as signatures and certificates, where its collision resistance has fallen far below the birthday bound. No, for its other promises: SHA-1 preimage resistance remains intact, and HMAC-SHA-1 is not broken by any collision attack [@rfc2104-hmac, @nist-policy-hash]. "Broken" is a statement about one property, not the whole function. No, and the difference is the whole game. SHATTERED (2017) is an identical-prefix collision: it proved SHA-1 dead for content addressing but cannot forge a chosen identity [@shattered-2017]. Shambles (2020) is a chosen-prefix collision: strictly more powerful, and the capability that actually forges certificates and impersonates identities [@shambles-2020]. No. Git added `sha1dc` collision detection and an opt-in SHA-256 object format, but SHA-1 is still the default object format for most repositories [@sha1dc-stevens-shumow-2017, @git-hash-transition]. The transition is staged and largely unfinished; do not assume your repository has migrated. Yes. HMAC's security reduces to the compression function acting as a pseudorandom function, not to collision resistance, so the collision attacks in this article do not apply. RFC 2104 stated this in 1997, and later proofs formalized it [@rfc2104-hmac]. You do not need to rip HMAC-SHA-1 out on account of SHATTERED or Shambles. No. Antoine Joux showed in 2004 that multicollisions in iterated hashes make a concatenation only about as strong as its stronger component, not the sum of the two [@joux-multicollisions-c04]. Cascading broken hashes is a dead end; migrate to a single strong hash instead. No. Ethereum uses the original Keccak padding, finalized before FIPS 202 changed the padding rule for standardized SHA-3. The two produce different digests for the same input, so the libraries are not interchangeable [@fips-202-sha3]. Yes, but narrowly. Non-adversarial checksums that detect accidental corruption, HMAC, key derivation, and verification of already-trusted legacy data are all acceptable, because none relies on an adversary being unable to find a collision [@nist-policy-hash]. Never use either for a new signature, certificate, or code-signing operation.

Parag Mali - tag: collision-attack