SHA-1 Was Shattered | Boot.devWe're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.<br>Categories<br>All NewsGolangPythonComputer ScienceBackendJobsJavaScriptDevOpsSecurityEducationVueRust

SHA-1 Was Shattered<br>Boot.dev TeamProgramming course authors and video producers<br>Last published June 16, 2026

A couple of weeks ago I downloaded a copy of OBS, and my operating system yelled at me. Told me I shouldn't trust it. And it was right, I shouldn't have been trying to download from fastandrealobsfree.ru.

But what if one of the most important algorithms that keeps you safe from stuff like that just stopped working?

Well, that happened. Worldwide.

Interactive example available with JavaScript enabled.

On February 23rd, 2017, Google published two PDFs.

One has a blue background, the other red. Open them side by side, and it's pretty easy to see that they're not the same document.

But, if you feed both files into SHA-1, the hashing algorithm that, at the time, still protected software installs, certificate authorities, and a good chunk of the internet's identity infrastructure [3], the algorithm claims the two files are identical.

This is impossible.

At least, it should be impossible. Back when SHA-1 was designed, everyone thought that even if you used code to generate as many random input files as you possibly could, creating two files with identical hashes, called a "collision", would take so long that it wasn't even worth worrying about.

See, every git commit has its own SHA-1 hash associated with it, and GitHub put the odds of an accidental SHA-1 collision this way: even if five million programmers each generated one commit per second, you'd only have about a 50% chance of seeing one before the sun swallowed the Earth [5].

Turns out, it took a team at Google about nine months to do it [1].

The team, a collaboration between researchers at CWI Amsterdam and Google's security group, called the project "SHAttered" [3].

Ars Technica ran an obituary-like headline: "At death's door for years, widely used SHA1 function is now dead" [9]. The Hacker News thread for the announcement racked up nearly five hundred comments, with developers ping-ponging between dissecting the math, arguing about which systems were actually exposed, and warning each other to stop trusting SHA-1 in production. Like, immediately [10].

Bruce Schneier, who's been writing about cryptography since the 90s, posted to his blog that, actually, the result was important, expected, and overdue [8]. He'd been calling SHA-1 broken since 2005 [12], and in 2012 he published a back-of-the-envelope cost projection on his blog that turned out to be pretty accurate [19][8]. It only took about $110,000 worth of compute, split across 6,500 years of CPU time and 110 years of GPU time [1][9].

Now, that sounds like a lot, but they compressed it into nine months by using Google-hosted hardware clusters spread across eight physical locations [9]. That 6,500 years of CPU time could be parallelized across thousands of machines, bringing the real-world time down to less than a year [1].

So people suspected SHA-1 could be on its last legs before 2017, and a collision had been theorized about, but it had never been practical to try to create one.

And it's important to understand, SHA-1 isn't just an academic algorithm - something like bubble sort that you study in school but never use in your own software. It was load-bearing. It was holding up installation signatures, version control, and deduplication systems - mostly boring technical plumbing to be fair, but important technical plumbing. And five researchers had just proven they could fool it for the price of a luxury car.

So in this post, we'll answer three important questions:

What even is a hash function?

How did SHA-1 actually die?

And why are people still using it?

Now, before we answer those 3 questions, let's finish the story.

Marc Stevens, Pierre Karpman, Elie Bursztein, Ange Albertini and Yarik Markov put out a blog post detailing that now-famous attack on SHA-1 [1] which produced what no good hash function should allow: two materially different PDFs with identical hashes.

And this part caught me by surprise: to keep with Google's vulnerability disclosure policies, they had to wait 90 days before releasing their code to the public that allowed them to create the collision. But in the meantime, they did at least provide a free detection system to the public to help protect them from the same kind of attack [1].

The public detection tool was a file tester on the SHAttered website: upload a file, and it checked whether the file looked like part of the collision attack they'd discovered [3]. The detector didn't even need both colliding files. It could look at one suspicious file and catch the patterns they had associated with the problem [3]. We'll get to how that all works in a second.

But the main takeaway of the project was very simple: stop...