Developer tools · SHA hash calculator
SHA-1 Collisions Explained: What Is Still Safe and What Must Migrate
· Why it matters
sha-256 cryptography security
A scanner flags SHA-1 and management asks how urgent it is. This post explains what a collision attack does and does not break, where SHA-1 is still tolerated, and how to plan a migration.
The scanner says SHA-1 is broken — but broken for what? The question that decides the migration's urgency
A network security scanner flags SHA-1 on your infrastructure. Management asks how urgent it is. The answer depends entirely on what you are using SHA-1 for, and that question reveals whether you have a compliance issue, an active security problem, or simply a legacy artifact that must be catalogued. SHA-1 is cryptographically broken—academic demonstrations have proven collisions. But "broken" means different things depending on the role SHA-1 plays in your system.
A cryptographic hash serves different purposes in different contexts. Sometimes it is a checksum guarding against accidental corruption. Sometimes it is a commitment, like a published download checksum that lets users verify they received the file the publisher intended. Sometimes it is part of a signature or certificate chain, where an attacker with enough control can produce two documents, both meaningful, that share the same hash, and thereby forge authentication. The severity of a SHA-1 collision depends critically on which of these roles SHA-1 has in your system.
Collision versus preimage — why publicly demonstrated attacks target collisions, and what that means for an existing hash
A collision attack produces two different inputs with the same output. An attacker does not find a message that hashes to a predetermined value—that would be a preimage attack, and it remains infeasible for SHA-1. Instead, a collision attack means the attacker can create two documents that hash identically. If a system relies on a hash to prove two things are the same, a collision breaks that proof. The attacker must craft both inputs, which requires time and computation, but the result is two distinct things appearing identical under the hash.
A preimage attack would mean an attacker could take a published SHA-1 hash and find some input matching it. That is not how SHA-1 attacks work. If you have a repository of SHA-1 digests and worry about whether a file truly matches them, a collision attack is not the threat. The threat is whether someone with access to your repository could forge a different file to the same digest. In most cases, that is also not realistic without control of the hashing process itself. The specific attack model matters as much as the algorithm.
The 2017 demonstrations — two different files with the same SHA-1, described qualitatively, and the chosen-prefix work that followed
The SHAttered attack from 2017 demonstrated a practical collision: two different PDF files with the same SHA-1 digest. The researchers carefully constructed both files, crafting them to be valid PDFs while colliding. The work required substantial computational effort and specialized hardware. What matters is that it was possible at all: the collision resistance that justifies using SHA-1 for security is gone. The attack proved that two semantically different documents could share a digest, which breaks any system that trusts the digest as proof of identity.
The attack that followed in 2020, called "SHA-1 is a Shambles," took the next step: chosen-prefix collisions. This variant means an attacker can take two arbitrary documents, concatenate different suffixes to each, and produce a collision. This is the dangerous attack for signatures and certificates. An attacker does not have to start from scratch; they can collide two meaningful, distinct documents. That breaks the security model of any system that signs SHA-1 digests. The attacker can produce two documents that both hash the same and both mean something different.
Where SHA-1 is unacceptable — signatures, certificates and anything an attacker can influence both sides of
The distinction matters because SHA-1 is still tolerable in some roles and absolutely unacceptable in others. In Git, SHA-1 is used as a content address—a name for a particular snapshot of files. Git does not use SHA-1 for authentication; it is a naming scheme. An attacker could theoretically compute two different repository states with the same ID, but that requires controlling the entire content creation process and pushing both versions before anyone notices. For most teams, that level of attacker control is not the threat model. This is why Git is transitioning to SHA-256 deliberately rather than treating it as an emergency.
In a web download verification scenario, a publisher posts a file and its SHA-1 checksum on the same server. An attacker who compromises that server controls both the file and the checksum. They can upload a file and post its SHA-1, and no collision is required. If the checksum is posted elsewhere—on a secure VPN, printed in a signed email, published in different infrastructure—then the attacker must collide, and that becomes infeasible. The checksum is only as trustworthy as its channel. This is why download verification requires more than a hash.
Where it lingers with less risk — content identification in non-adversarial settings and Git's staged transition to SHA-256
For signatures and certificates, SHA-1 is indefensible. A certificate chains from a trusted root. If a CA signs two different certificates using the same SHA-1 digest, a collision attack lets an attacker forge either. This is not theoretical: attacks against intermediate CAs have been documented. Any signature scheme that relies on SHA-1 is potentially forgeable by an attacker with enough resources. Every major browser and OS vendor has deprecated SHA-1 in certificates. New certificates must use SHA-256. The platform vendors have spoken clearly because the threat is real and immediate.
NIST, the US standards body, has stated an explicit timeline. As of 2024, SHA-1 should not be used for any new applications. As of 2030, SHA-1 is expected to be retired entirely from federal systems. This is not a vague deprecation; it is a concrete mandate for government contractors and a signal to the industry. Following NIST's timeline ensures your systems stay ahead of the deprecation curve rather than scrambling after deadline.
Repository evidence supports SHA-1 deprecation, not an unread NIST publication or retirement date
The repository source documents SHA-1 as legacy interoperability and names demonstrated collision work, but it does not contain a standards-body retirement schedule. This section therefore corrects the outline by treating deprecation as an engineering inventory problem rather than quoting an unread publication number or compliance date.
For policy-controlled environments, consult the authority governing that deployment and record the exact document reviewed. Product evidence here supports a narrower action: keep SHA-1 available to reproduce existing values, label it as unsuitable for new security uses, and compute a SHA-256 replacement wherever the surrounding protocol permits migration.
Worked example — a migration checklist applied to a legacy download-verification page
A migration path from SHA-1 usually starts with an inventory: where is SHA-1 used? Certificates and signatures? Immediate priority. Git repositories and content addressing? Medium priority, follow the Git migration pace. Published checksums for downloads? Depends on the trust model. Internal checksums for deduplication or archival? Lower priority, more time for planning. The inventory phase reveals the true surface area and helps you prioritize based on actual risk rather than abstract urgency.
For each role, the migration looks different. Certificates upgrade to SHA-256 immediately. Git repositories phase in SHA-256 refs gradually while maintaining SHA-1 for backward compatibility. Download checksums start being published in both SHA-1 and SHA-256, then eventually only SHA-256. Legacy SHA-1 digests in a checksum database can be verified with the ToolAcre SHA hash calculator, and new entries should use SHA-256. The tool supports both sides of the transition, letting you verify old hashes and create new ones.
Takeaway: SHA-1 for comparison, SHA-256 for new work — the ToolAcre SHA hash calculator includes SHA-1 so legacy digests can be checked, not as an endorsement
For most organizations, the migration is not "turn off SHA-1 tomorrow." It is "understand where it is used, prioritize security-critical roles, and have a multi-year plan." A Git repository with years of SHA-1 commits should transition gradually, with tooling that handles both. A certificate infrastructure should have already migrated. Published checksums should be dual-algorithm during a transition window. Gradual migration reduces breaking changes and gives systems time to adapt to the new reality.
The ToolAcre SHA hash calculator provides both sides of that transition. You can verify existing SHA-1 digests from your legacy systems to confirm a file matches them. You can compute SHA-256 hashes to start publishing the migration path. The tool does not pretend SHA-1 is safe; it labels it as broken and explains why. But it lets you work with the legacy hashes you still need to maintain as you build the bridge to SHA-256 and plan your deprecation.