Briefing
![Banner image showing two contrasting PDF documents - one with a blue background and one with a red background - with an identical 40-character SHA-1 hash fingerprint displayed beneath them, set against a dark cybersecurity-themed backdrop with subtle binary code and digital lock motifs.]
On 23 February 2017, Google published two PDFs. One had a blue background. The other had a red background. Open them side by side and the difference was immediately obvious - they were two visually distinct documents, clearly not the same file. Yet when both were fed into SHA-1, the cryptographic hashing algorithm that at that very moment was still protecting software installations, certificate authorities, and a substantial portion of the internet's identity infrastructure, the algorithm declared them identical. Same hash. Same 40-character fingerprint. Same cryptographic identity.
This was not supposed to happen. Not ever.
When SHA-1 was designed, cryptographers were confident that even if you threw every computing resource on Earth at generating random input files, creating two files with identical hashes - an event called a "collision" - would take so long that it was not even worth worrying about. GitHub once illustrated the odds this way: even if five million programmers each generated one commit per second, you would still only have about a 50% chance of seeing a collision before the Sun swallowed the Earth.
A team at Google did it in nine months.
The project, a collaboration between researchers at CWI Amsterdam and Google's security group, was called SHAttered. The headline practically wrote itself. Ars Technica ran what read like an obituary: "At death's door for years, widely used SHA-1 function is now dead." The Hacker News thread for the announcement racked up nearly 500 comments, with developers bouncing between dissecting the mathematics, arguing about which systems were actually exposed, and urgently warning each other to stop trusting SHA-1 in production. Bruce Schneier, who has been writing about cryptography since the 1990s, posted to his blog that the result was "important, expected, and even overdue." He had been calling SHA-1 broken since 2005.
This is the story of how one of the internet's most important security algorithms fell - and why its ghost still haunts the systems we rely on today.
The Announcement That Shook the Internet
The SHAttered team - five researchers in total - published a blog post alongside their two colliding PDFs, detailing an attack that produced exactly what no secure hash function should ever allow: two materially different documents sharing the same SHA-1 fingerprint. The cost? Approximately $110,000 worth of cloud compute, split across 6,500 years of CPU time and 110 years of GPU time. That sounds enormous until you remember that Google compressed all of that parallelisable work into just nine months by spreading it across clusters in eight different physical locations.
What made the announcement particularly significant was not just the technical achievement - it was the practical implications. Here was a collision that anyone with serious funding could plausibly replicate. Intelligence agencies, well-funded criminal organisations, nation-states: all of them had deeper pockets than Google's research team. If $110,000 and nine months could break SHA-1, what could an organisation with a $100 million budget accomplish?
Following Google's standard vulnerability disclosure policy, the team waited 90 days before releasing their collision-generation code to the public. In the interim, they provided something arguably more valuable: a free detection system. Hosted on the SHAttered website, anyone could upload a file and check whether it matched the known patterns of their collision attack. Remarkably, the detector did not even need both colliding files - it could analyse a single suspicious file and flag the telltale patterns that the attack had exploited.
Their message was unambiguous: stop using SHA-1. In their own words, "It's more urgent than ever for security practitioners to migrate to safer cryptographic hashes."
What Is a Hash Function, and Why Does It Matter?
To understand why SHAttered mattered so much, we need to understand what hash functions do.
A hash function takes any data input - a word, a PDF, a multi-gigabyte video - and produces a fixed-length string of characters. Feed "hello" into SHA-1 and you get back exactly 40 hexadecimal characters, every single time. Change one character, capitalise the "H", add a trailing space, and the output changes completely. Yet it is not random: "hello" always hashes to the same fingerprint. That determinism is what makes hashes so useful.
When you download software, your operating system hashes the file and compares it against the publisher's official hash. Match means authenticity. Mismatch means trouble - corruption, an update, or malware swapped in by an attacker. When Microsoft pushes Windows updates, code-signing signatures built on hash functions authenticate that the updates genuinely came from Microsoft. Wrong signature, no update. It is a fundamental pillar of modern software security.
Secure hash functions have four critical properties:
- Determinism: The same input always produces the same output.
- Speed: Fast to compute, even on modest hardware.
- One-wayness: You cannot reverse-engineer the input from the hash.
- Collision resistance: It should be practically impossible to find two different inputs producing the same output.
It is that fourth property - collision resistance - that the SHAttered team broke.
How the Attack Actually Worked
No, the SHAttered team did not simply brute-force their way through 2^160 possible combinations. They found a shortcut - and understanding it reveals a great deal about how modern cryptography gets broken.
The theoretical foundation lies in the pigeonhole principle. SHA-1 produces 160-bit hashes, which means there are 2^160 possible outputs - roughly 1.46 quindecillion. But the number of possible inputs is effectively infinite. More inputs than outputs means collisions must exist. The entire question is whether anyone can actually find one.
A naïve brute-force collision search would need to try roughly 2^80 inputs (the square root of the hash space). At a million hashes per second, that is about 38 billion years - longer than the universe has existed. So when cryptographers called SHA-1 "secure," they meant that finding a collision should take longer than the age of the cosmos.
The SHAttered team found a way to do it in just 2^63 computations - roughly 130,000 times faster than brute force.
Their technique was differential cryptanalysis. Rather than throwing random inputs at SHA-1 and hoping for a match, they studied how tiny, carefully chosen changes ripple through the algorithm's internal functions. SHA-1 processes data in blocks, feeding each through operations - bit rotations, truncations, XOR - where the output of one block feeds into the next. The key insight: find two specific changes that cancel each other out at exactly the right points, and you can make the internal states converge.
The SHAttered team constructed two files with an identical prefix, then diverged them into two different "collision blocks" of carefully calculated junk data. After those blocks, SHA-1's internal state was identical. Both files then shared the same suffix and landed on the same final hash. This was not random luck - it was mathematical precision applied to cryptographic engineering.
The Slow, Painful Death of SHA-1
If the 2017 SHAttered announcement felt like a sudden earthquake, the reality is that the fault lines had been forming for over a decade. SHA-1 did not die overnight. It suffered a long, slow decline that cryptographers had been watching with growing unease.
2005: The beginning of the end. Chinese cryptographer Xiaoyun Wang and her colleagues published a theoretical attack that reduced SHA-1's collision strength from 2^80 down to roughly 2^69. Within months, Wang's team refined it further to 2^63. Bruce Schneier wrote at the time that the result "pretty much put a bullet into SHA-1 for digital signatures." The math was now public, and further refinements would only make attacks faster and cheaper.
2012: Schneier published a back-of-the-envelope cost projection for a practical SHA-1 collision attack. It turned out to be remarkably accurate.
2014: Google Chrome announced it would begin "gradually sunsetting SHA-1," warning that HTTPS certificates signed with SHA-1 and expiring after 2017 would trigger security warnings and eventually hard errors.
2015: Cryptographer Marc Stevens and collaborators cracked a piece of SHA-1's internals in just ten days using rented GPUs, estimating the full attack would cost between $75,000 and $120,000 on Amazon EC2.
2017: SHAttered finally landed - and the only genuinely surprising thing was that anyone was still surprised.
By the time the collision was demonstrated, the cryptographic community had already moved on. SHA-2, particularly SHA-256, had been the recommended standard for years. The problem was not a lack of alternatives. The problem was everything that had already been built on SHA-1.
Why SHA-1 Is Still Lurking in Production
Here is where the story gets uncomfortable. Nearly a decade after SHAttered, SHA-1 has not disappeared. It has been banished from the public-facing internet - browser makers could force that issue by displaying scary warnings and eventually hard errors for SHA-1 certificates. But the internet runs far deeper than what you see in your browser.
Consider the landscape: corporate intranets, banking systems, government agencies, insurance companies, hospitals. These institutions run software written in the 1990s on hardware that nobody dares touch because the organisation cannot afford for it to stop working. The people maintaining these systems are almost never cryptographers. They are sysadmins trying to keep a £60 million mainframe from setting itself on fire, and the SHA-1 dependency is buried in a configuration file eight directories deep that has not been touched since the person who wrote it took early retirement.
For those teams, the migration plan is always "next quarter." And next quarter has been next quarter for the last seven years.
Even Microsoft - one of the largest companies on Earth with effectively infinite engineering resources - did not finish moving Windows Update signing fully to SHA-2 until 2019, over two years after SHAttered. They did not retire the last SHA-1-signed Windows content from their download centre until August 2020. Windows 7 users who had never installed Microsoft's SHA-2 patch literally stopped receiving security updates in 2019 because their machines could no longer verify the newer signatures.
If Microsoft moves that slowly, imagine the rest of the internet.
The January 2020 paper "SHA-1 is a Shambles" by Gaëtan Leurent and Thomas Peyrin demonstrated that the attack had only gotten cheaper. For an estimated $45,000 in rented GPU time, they crafted a pair of PGP keys with different identities but colliding SHA-1 certificates. At the time, GPG - the open-source implementation of OpenPGP used by journalists, activists, and Linux maintainers - still defaulted to SHA-1 for identity certifications. In a web-of-trust model, where users sign each other's keys rather than relying on a central certificate authority, forging the right certificate means you can impersonate someone inside that trust graph.
Then there is Git. Every Git commit, every file blob, every tag is identified by its SHA-1 hash. A collision theoretically means you could craft two different commits with the same identifier, swap malicious code into a repository, and not break the cryptographic chain that is supposed to prevent exactly that. When SHAttered dropped, GitHub responded quickly, deploying an SHA-1 collision detector - a modified version of SHA-1 that watches for the specific bit patterns used in collision attacks and rejects them. Git itself has been preparing for a transition for years, but that migration still is not finished. To be fair, Git hashes are everywhere, referenced in issue trackers, CI/CD pipelines, documentation, and developer muscle memory. There may not be a messier hash migration in all of software.
What Comes Next?
The answer to "what should we use instead?" is SHA-256. It is the standard-bearer of the SHA-2 family, and cryptographers do not believe a practical break is close. But "close" in cryptography is measured in decades, and we simply do not know what we do not know. The same confidence people once had in SHA-1 evaporated in nine months of GPU time.
For new projects, the choice is straightforward: use SHA-256 or SHA-3, or consider modern alternatives like BLAKE3. The difficulty is not choosing a replacement - it is everything already built on SHA-1. Every certificate authority, every embedded device with hash functions baked into firmware, every industrial controller, medical device, and obscure IoT widget in an oil refinery that nobody can find the source code for anymore.
Replacing a cryptographic algorithm is not a one-line code change. It is a cross-organisational infrastructure project touching every layer of the stack.
Should you panic the next time you push a Git commit or click the browser padlock? No. The padlock uses SHA-2, and most commit hashes are not direct attack vectors. But you should understand the tools you trust. Cryptographic algorithms age - they move through a lifecycle of safe, questionable, then dead - and the cost of breaking them drops every year, even when the algorithm itself has not changed.
What was secure in 2005 was questionable by 2015 and actively dangerous by 2026. That is the nature of cryptography itself.
Conclusion
SHAttered was a watershed moment in practical cryptography. It transformed SHA-1 from "theoretically broken but still widely trusted" to "demonstrably broken and actively exploitable" - all for a price tag within reach of well-funded adversaries. The two PDFs with their blue and red backgrounds became a symbol of how fragile our trust assumptions can be.
The deeper lesson is about infrastructure inertia. SHA-1's cryptographic death certificate was signed in 2005, when Xiaoyun Wang published her theoretical attack. It took twelve years for a practical demonstration to arrive, and even then, the internet only partially listened. The public-facing web moved on because browser vendors could force it. Everything underneath - corporate networks, legacy systems, embedded devices, Git repositories - has been far slower to change.
SHAttered is a reminder that security is not binary. It is a continuous process of evaluation, migration, and vigilance. The algorithms we trust today will not be trusted forever. The question is not whether they will eventually fall - it is whether we will be ready to move when they do.
Helpful Resources
Official SHAttered Project
- SHAttered Website (opens in a new tab) - The official project page with the colliding PDFs, hash values, and detection tool
- Google Security Blog: Announcing the first SHA-1 collision (opens in a new tab) - Official announcement from Google's security team
Research Papers
- "SHA-1 is a Shambles" by Leurent and Peyrin (2020) (opens in a new tab) - Demonstrates cheaper chosen-prefix collisions for $45,000
- The original SHAttered research paper - Technical details of the differential cryptanalysis attack
Key Tools and Detection
- GitHub's SHA-1 Collision Detection (opens in a new tab) - Open-source collision detection library
- GnuPG (GPG) (opens in a new tab) - OpenPGP implementation that previously defaulted to SHA-1 for identity certifications
Migration Resources
- SHA-2 and SHA-3 Family Specifications (opens in a new tab) - NIST hash function standards
- BLAKE3 (opens in a new tab) - A modern, fast cryptographic hash function alternative
- Boot.dev Cryptography Course (opens in a new tab) - Learn hash functions, AES encryption, and digital signatures (use code
bootstubefor 25% off)
