The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A cryptographic hash function turns data of any size into a compact digest. The digest can help detect changes and support security systems, but hashing is not encryption—and its safety depends on the property an application needs. SHA-1 is no longer considered collision-resistant: in 2017, researchers showed that two different PDFs could have the same SHA-1 digest.
What is a cryptographic hash function?
A hash function processes an input—such as a document, file, or message—and returns a comparatively short value called a hash or digest. The digest is a compact representation of the input. A small change to the input normally produces a markedly different digest, so software can use hashes to check whether data has changed. Google’s explanation of the SHAttered result and NIST’s hash-function resources describe these uses.
A hash is not encryption. Encryption is designed to be reversed with the appropriate key; a cryptographic hash is not intended to reveal the original input, and the input cannot be reconstructed from the digest alone. Hashing can help protect or identify data, but the digest is not a secret copy of that data.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWhich security property matters?
Cryptographic hashes are expected to provide several security properties. SHAttered matters because it demonstrated a practical failure of collision resistance, a property relied on by applications including digital signatures.
#1 Best Overall
- Collision resistance: It should be computationally infeasible to find any two different inputs that produce the same digest.
- Change detection: If the input changes, its digest should normally change too. This is useful only while an attacker cannot feasibly substitute a different input with the same trusted digest.
A collision does not, by itself, recover a message, break every system that uses SHA-1, or automatically forge every signature. The risk depends on what a system trusts the hash to represent and how that hash is used.
What was the SHAttered collision?
On February 23, 2017, researchers from Google and CWI announced the first practical collision for full SHA-1. They published two PDFs with different contents but identical SHA-1 hashes. The result showed that SHA-1 could no longer be relied on to make finding a matching pair of inputs impractical. The researchers’ announcement used two insurance contracts with drastically different terms as an illustration of the potential risk—not as a report of an attack on an insurer.
The concern is substitution: if a system accepts a digest as proof of which document or object it has, an attacker who can create a different object with the same digest may undermine that assumption. Whether that leads to harm depends on the surrounding system, including what is signed, stored, or checked.
Recommended Free Tools
How much computation did the demonstration take?
Google reported that the attack involved 9,223,372,036,854,775,808 SHA-1 computations in total. The researchers described the first phase as equivalent to 6,500 years of CPU computation and the second as 110 years of GPU computation. These are computation-equivalent totals from the researchers’ report, not elapsed calendar time on one machine. Google also said the collision attack was “more than 100,000 times faster than a brute force attack,” while noting that brute force remained impractical. The figures describe that 2017 research effort; they are not a consumer hardware recipe or a current price estimate. Google’s announcement provides the reported figures and context.
Why is SHA-1 broken?
SHA-1 was specified in 1995. Its practical collision demonstrated that the algorithm no longer meets the collision-resistance expectation needed where security depends on distinct data having distinct digests. NIST announced in 2011 that SHA-1 was deprecated for generating new digital signatures and has advised against relying on it where collision attacks matter. NIST’s hash-function guidance explains the policy context.
“We recommend that anyone relying on SHA-1 for security migrate to SHA-2 or SHA-3 as soon as possible,” said Chris Celi, a NIST computer scientist, in NIST’s December 15, 2022 announcement. NIST’s statement recommends both families as alternatives.
What should replace SHA-1, and when?
For security uses, NIST recommends migrating from SHA-1 to SHA-2 or SHA-3. Its transition plan calls for moving away from SHA-1 for cryptographic protection across applications by December 31, 2030. NIST also recognizes that SHA-1 may still be needed to handle information protected before that date, so creating new protection and processing legacy material are not necessarily the same task. Check the applicable standards and guidance for the system involved. NIST’s transition announcement, updated February 3, 2025, describes the scope and deadline.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteSHA-2 and SHA-3 are both NIST-recommended options; the sources do not establish a universal performance winner. A practical choice should follow the application’s standards, approved implementations, interoperability requirements, and migration constraints. NIST’s policy does not require every application to move from SHA-2 to SHA-3.
Best Value
Why can migrating hash algorithms take planning?
Changing an algorithm can affect more than a setting. Systems may store hashes as identifiers, exchange them with other software, or rely on them in signatures and integrity checks. Older data may also need to remain verifiable. A migration therefore needs to account for the objects and relationships that existing identifiers represent.
What Git’s transition design illustrates
Git’s technical documentation describes a transition design from SHA-1 to SHA-256. Git uses hashes to name content-addressed objects, making lookup and integrity checking straightforward; security becomes especially relevant when signed object names are trusted. The design includes mappings between SHA-1 and SHA-256 identifiers during transition and notes compatibility implications for different Git versions. This is an example of one project’s approach, not a universal migration procedure. Git’s hash-function transition document explains the design.
What a SHA-1 migration should account for
For a system that still relies on SHA-1 for security, treat migration as a compatibility and policy task, not simply a digest replacement. Identify where hashes are created, checked, stored, signed, or exchanged; determine whether legacy material must remain verifiable; and select SHA-2 or SHA-3 according to the standards and interoperability requirements that apply. NIST’s transition guidance is the reference for its deadline and scope, while Git’s document shows why identifier mappings and version compatibility can matter in a real software project.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
