Type sha1sum or sha256sum into a terminal today and both commands still run without complaint. That’s part of the problem. Nine years after researchers proved SHA-1 could be broken for about the price of a used car, the algorithm still shows up in old certificates, legacy VPN configs, and – until very recently – every single Git repository on the planet. Meanwhile SHA-256 has become the quiet workhorse behind Bitcoin, TLS, and most modern code signing. This comparison walks through what actually separates the two hash functions in 2026: the math, the money it takes to break each one, the real throughput numbers, and what a sane migration off SHA-1 looks like if you’re still running it somewhere.

Both algorithms are free, public NIST standards – there’s no license fee attached to either one, and no vendor lock-in. The choice between them isn’t about cost of ownership, it’s about which one still holds up under attack. That distinction sounds academic until you notice how many everyday systems, from your browser’s padlock icon to the last git commit you ran, quietly depend on getting this call right.

What Is SHA-1?

SHA-1 (Secure Hash Algorithm 1) is a cryptographic hash function published by NIST in 1995 as part of the original Secure Hash Standard. It takes an input of any length and produces a fixed 160-bit (20-byte) digest, usually shown as 40 hexadecimal characters. Internally it processes data in 512-bit blocks through 80 rounds of bitwise operations, maintaining a 160-bit internal state across five 32-bit words.

For most of the 2000s, SHA-1 was the default choice for TLS certificates, Git commit hashes, code signing, and password-adjacent checksums. NIST itself flagged SHA-1 for deprecation as early as 2011, but it took an actual demonstrated attack, published by Google and CWI Amsterdam researchers in February 2017, to force the industry’s hand. That attack – nicknamed SHAttered – produced two different PDF files with an identical SHA-1 hash, proving in practice what cryptographers had warned about for over a decade: SHA-1’s collision resistance was no longer a safe bet.

According to NIST’s own hash function security-strength tables, SHA-1 offers less than 80-bit collision resistance in practice, well short of the 160 bits its digest length would suggest on paper. That gap between theoretical and practical security is exactly what SHAttered exploited.

Before 2017, SHA-1 wasn’t a niche choice – it was the internet’s default. It signed the majority of TLS certificates issued through the mid-2010s, formed the backbone of Git’s object model from the project’s creation in 2005, and appeared in early versions of PGP, SSH, and countless internal checksum tools. That ubiquity is exactly why the migration away from it has taken so long: SHA-1 isn’t buried in one obscure corner of the stack, it’s woven through nearly two decades of software that assumed a 40-character hex string was good enough.

What Is SHA-256?

SHA-256 is a member of the SHA-2 family, standardized by NIST in FIPS 180-2 (2001) and carried forward into the current FIPS 180-4 spec. It produces a 256-bit (32-byte) digest from 512-bit input blocks, using an 8-word internal state and a 64-round compression function – roughly double the state size of SHA-1 with 16 fewer rounds per block.

SHA-256 sits underneath a surprising amount of modern infrastructure. Bitcoin’s proof-of-work mining and block hashing both run on SHA-256. Every public TLS certificate issued since 2016 is signed with it (or something stronger). Windows code signing, package managers, and most Git tooling built after 2020 default to it as well. NIST’s current guidance puts SHA-256’s collision resistance at roughly 2^128 operations and its preimage resistance at 2^256 – numbers that remain firmly in “not happening with today’s compute” territory.

That doesn’t mean SHA-256 is untouched by research. Academic teams have chipped away at reduced-round versions of the algorithm – a 2024 paper from Fukang Liu and Yingxin Li, which won the ASIACRYPT best paper award, demonstrated the first practical collision on a 31-step reduced version of SHA-256 (out of its full 64 steps), solved in about 1.2 hours on 64 threads. Commentators at the time noted that at the pace of that kind of progress, a practical attack on the full 64-step algorithm would still be roughly 90 years away. Full SHA-256 remains unbroken.

The SHA-2 Family: SHA-256’s Siblings

SHA-256 doesn’t stand alone. FIPS 180-4 groups it under the SHA-2 family alongside SHA-224, SHA-384, SHA-512, SHA-512/224, and SHA-512/256 – seven approved hash algorithms in total, including the now-deprecated SHA-1. The family shares the same underlying Merkle–Damgård design philosophy but scales word size and internal state to trade off speed, digest length, and security margin.

  • SHA-224: A truncated variant of SHA-256 with a 224-bit output, useful when storage is tight and 256 bits of digest is more than needed.
  • SHA-384: Built on SHA-512’s 64-bit word size, producing a 384-bit digest with a larger security margin than SHA-256.
  • SHA-512: The 64-bit sibling of SHA-256, often faster on 64-bit server hardware because it processes data in larger words per round.
  • SHA-512/256: Runs the SHA-512 compression function internally but truncates output to 256 bits, sometimes chosen to resist length-extension attacks more cleanly than plain SHA-256.

None of this changes the core SHA-1 vs SHA-256 comparison, but it matters for context: when people say “move to SHA-2,” SHA-256 is usually the default recommendation, not the only option. Teams with specific performance or compliance needs sometimes land on SHA-512 or SHA-384 instead, without ever touching SHA-3 or newer designs.

SHA-1 vs SHA-256: Technical Specs Compared

The specs below come from NIST’s FIPS 180-4 Secure Hash Standard and NIST’s published hash-function security-strength tables. This is the fastest way to see where the two algorithms structurally diverge.

PropertySHA-1SHA-256
Digest (output) size160 bits (20 bytes)256 bits (32 bytes)
Block size512 bits512 bits
Internal word size32-bit words32-bit words
Internal state size5 x 32-bit words (160 bits)8 x 32-bit words (256 bits)
Compression rounds80 rounds64 rounds
StructureMerkle–Damgård, Davies–MeyerMerkle–Damgård, Davies–Meyer
Max message length2^64 – 1 bits2^64 – 1 bits
Collision resistance (practical)<80-bit (broken in practice)~2^128 operations
Preimage resistance~2^160 (theoretical, not practical anymore)~2^256
First published1995 (FIPS 180)2001 (FIPS 180-2)
Current NIST standard statusListed in FIPS 180-4, deprecated for digital signaturesFully approved and recommended
Hex digest length40 characters64 characters

The headline number is the collision resistance row. SHA-1’s practical security dropped well below its theoretical 80-bit birthday bound once researchers found shortcuts through its message schedule. SHA-256’s larger state and reduced-but-still-substantial round count have so far held up against every reduced-round attack published, including the 2024 31-step result.

The SHAttered Attack: How SHA-1 Actually Broke

In February 2017, a joint team from Google and the Centrum Wiskunde & Informatica (CWI) in Amsterdam published the first practical SHA-1 collision. Marc Stevens led the cryptanalysis, working with Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov. They produced two distinct PDF files that hashed to the exact same SHA-1 digest – proof that SHA-1’s collision resistance had moved from “theoretically weak” to “practically exploitable.”

The attack required roughly 9.2 quintillion SHA-1 computations. Stevens’ own paper estimated the cost of running that workload on rented cloud compute at approximately $110,000, assuming around 100 GPU-years of work at then-current spot pricing. That was the first time a SHA-1 collision had a real dollar figure attached to it, and it’s the number that finally pushed browser vendors and certificate authorities to move.

Three years later, a separate team – Gaëtan Leurent and Thomas Peyrin – went further with an attack called Shambles, which demonstrated the first practical chosen-prefix collision on SHA-1. Chosen-prefix collisions are more dangerous than the identical-prefix kind SHAttered used, because an attacker can pick two arbitrary, meaningful documents (say, two different X.509 certificates) and still force a hash collision between them. Leurent and Peyrin’s paper put the theoretical cost at $11,000 for a classical collision and $45,000 for a chosen-prefix collision using rented GPUs; in practice they spent about $75,000 because GPU rental prices were higher at the time and they lost time to experimentation.

Cost to Break SHA-1 vs SHA-256: The Money Trail

Neither algorithm has a licensing fee – both are open, patent-free NIST standards. The real “price” that matters here is what it costs an attacker to break each one, and that number has been falling fast for SHA-1 while staying essentially flat (and astronomically high) for SHA-256.

Year / SourceAttack TypeSHA-1 CostSHA-256 Cost
2017 – SHAttered (Stevens et al.)Identical-prefix collision~$110,000 (cloud GPU rental)No known practical attack
2020 – Shambles (Leurent & Peyrin)Chosen-prefix collision$75,000 actual spend; ~$45,000 optimized estimateNo known practical attack
2020 – Shambles (classical collision)Identical-prefix collision~$11,000 (rented GPUs)No known practical attack
2025 – Shambles team projectionChosen-prefix collisionUnder $10,000 (projected, cheaper GPU pricing)Not applicable
2025 – drand.love RTX 5090 analysisHome-built collision estimate~$5,468 (consumer GPU pricing)Not applicable
2026 – NIST security strength tablesFull collision (2^128 operations)N/AComputationally infeasible with any current hardware budget

That trend line matters more than any single number. A collision that cost $110,000 in 2017 was already inside the budget of a well-funded criminal group or nation-state actor. By 2025, published estimates put a chosen-prefix SHA-1 collision under $10,000 – closer to hobbyist territory than nation-state territory. SHA-256, by contrast, has no comparable cost figure to quote, because 2^128 operations isn’t a number any GPU cluster gets meaningfully closer to with faster hardware. It would take a fundamental cryptanalytic break, not a bigger budget, to change that math.

Benchmark Speed: SHA-1 vs SHA-256 Throughput

Speed is where SHA-1 still wins on paper, though the margin depends heavily on whether the CPU has SHA hardware extensions. Here’s what three independent benchmark sources report.

Source / HardwareBlock SizeSHA-1 ThroughputSHA-256 Throughput
OpenWrt OpenSSL benchmark, Intel N100 (OpenSSL 3.0.16)Large blocks~6,210 MB/s~5,344 MB/s
Microsoft Virtual Client, OpenSSL workload1,024 bytes~693 MB/s~359 MB/s
Legacy OpenSSL speed test (no SHA extensions)1,024 bytes~142 MB/s~45.7 MB/s
Kappakit 2026 hash benchmark (SHA acceleration enabled)1 MBNot directly reported2,709 MB/s

On hardware without dedicated SHA instructions, SHA-1 runs roughly 2-3x faster than SHA-256 because it has fewer rounds and a smaller internal state to shuffle. On newer x86-64 chips with Intel’s SHA extensions enabled, that gap narrows dramatically – the OpenWrt benchmark on an Intel N100 shows SHA-1 only about 1.16x faster than SHA-256, and some accelerated benchmarks show SHA-256 pulling ahead of unaccelerated SHA-1 entirely. In short: the raw speed advantage that once made SHA-1 attractive for high-throughput logging or checksumming has mostly evaporated on current hardware.

You can reproduce these numbers yourself with OpenSSL’s built-in benchmark tool:

openssl speed -evp sha1 -evp sha256

# Sample output shows bytes/sec across block sizes:
# type          16 bytes   64 bytes   256 bytes  1024 bytes  8192 bytes
# sha1          ...        ...        ...        ...         ...
# sha256        ...        ...        ...        ...         ...

Browser and Certificate Authority Deprecation Timeline

The move away from SHA-1 in public TLS wasn’t a single event – it played out over roughly five years across standards bodies, browser vendors, and Microsoft.

  • January 1, 2016 – The CA/Browser Forum’s Baseline Requirements banned public certificate authorities from issuing any new SHA-1-signed certificates.
  • January 2017 – Chrome 56 removed support for SHA-1 certificates chaining to a public CA; Chrome 57 followed in March 2017 by distrusting SHA-1 even for certificates chaining to locally installed roots, unless an enterprise policy explicitly overrode it.
  • February 2017 – Firefox’s SHA-1 phase-out plan, first announced by Mozilla’s security blog in 2015, reached full enforcement, showing “Untrusted Connection” errors for any SHA-1 certificate.
  • May 9, 2017 – Microsoft’s security advisory brought Windows, Edge, and Internet Explorer in line with Chrome and Firefox, blocking SHA-1-signed TLS certificates system-wide.
  • August 3, 2020 – Microsoft retired SHA-1-signed Windows content entirely, pulling it from the Download Center.
  • May 9, 2021 – Microsoft announced that all major internal processes – TLS certificates, code signing, and file hashing – would use SHA-2 exclusively going forward.
  • 2023 – Chrome 117 removed SHA-1 support from TLS 1.2 server signatures, closing one of the last protocol-level corners where SHA-1 could still appear in a live handshake.

By 2026, no mainstream browser will negotiate a connection secured with a SHA-1 certificate, and no public CA will issue one. The remaining SHA-1 footprint lives almost entirely outside the public web: internal corporate PKI, legacy VPN appliances, embedded firmware, and – until very recently – Git’s default object format.

Is SHA-256 Safe in 2026? What the Latest Cryptanalysis Says

Full 64-round SHA-256 has no known practical collision, preimage, or second-preimage attack as of 2026. That’s not the same as saying cryptographers have stopped trying. The most notable recent result is the 2024 collision on a 31-step reduced version of SHA-256, published by Fukang Liu and Yingxin Li and awarded best paper at ASIACRYPT 2024. Their attack ran with time complexity of 2^49.8 and memory complexity of 2^48, and took about 1.2 hours across 64 threads – a genuine cryptanalytic advance, but one that only reaches 31 of SHA-256’s 64 rounds.

Separate research has pushed semi-free-start collisions to 39 steps, and SAT-solver-based approaches have found pure collisions up to roughly 28 steps. None of these techniques currently extend to the full algorithm. As one Hacker News discussion of the 31-step result summarized it, extrapolating the pace of progress in reduced-round attacks suggests a practical full-round break would still be about 90 years out – which is another way of saying it isn’t a near-term planning concern for anyone deploying SHA-256 today.

NIST’s current guidance, reflected in FIPS 180-4 and its associated security-strength documentation, still lists SHA-256 as fully approved for digital signatures, HMAC, key derivation, and general integrity checking. Independent crypto references reach the same conclusion: SHA-256 has no known collision attack, no known second-preimage attack, and no known preimage attack against its full round count.

Neither Belongs in Password Hashing

This comparison is about general-purpose hashing – certificates, commit IDs, code signing, integrity checks. It is not an argument for using SHA-1 or SHA-256 to store passwords. Both are fast by design, which is exactly the wrong property for password storage: a hash function optimized to process gigabytes per second is also a hash function an attacker can brute-force at billions of guesses per second on commodity GPUs.

Password storage calls for a deliberately slow, memory-hard function like Argon2 or bcrypt, which make each guess expensive rather than cheap. If your system is hashing passwords with raw SHA-1 or SHA-256 (even salted), that’s a separate and more urgent problem than anything covered in this article – see our Argon2 vs bcrypt comparison for what an actual migration path looks like there.

Real-World Use: Where SHA-1 and SHA-256 Show Up Today

Five concrete examples make the divide between “legacy” and “current” clearer than any spec sheet. Taken together, they show a pattern: wherever an outside adversary can plausibly submit or forge data, SHA-256 has already won. Wherever the hash is mostly bookkeeping between trusted parties, SHA-1 has been slower to disappear.

  • Bitcoin and Bitcoin-derived blockchains run entirely on SHA-256 for both proof-of-work mining and block/transaction hashing. This is the single largest production deployment of SHA-256 by raw compute volume in the world.
  • Public web PKI has used SHA-256 (or stronger) exclusively since the 2016 CA/Browser Forum ban and the 2017 browser enforcement wave described above. Every certificate your browser trusts today is signed with SHA-256 or better.
  • Git is the most visible holdout. Git has supported SHA-256 repositories as an alternative object format since version 2.29 (2020), and Git 2.51, released in August 2025, expanded internal plumbing support for SHA-256. As of 2026, new repositories still default to SHA-1 – Git’s own breaking-changes documentation confirms a planned switch to SHA-256 as the default, targeted for the still-unreleased Git 3.0.
  • Microsoft’s code-signing and update infrastructure moved to SHA-2 exclusively starting May 9, 2021, after retiring SHA-1-signed Windows content from the Download Center the prior year. Anything downloaded from Microsoft’s official channels today is signed with SHA-256 or higher.
  • Legacy VPN and IPsec appliances are where SHA-1 lingers longest in enterprise networks. HMAC-SHA-1 remains a supported (and in some older configs, default) option in many IPsec and SSL VPN stacks, even though HMAC constructions are less directly threatened by collision attacks than digital signatures are. Security teams auditing these devices in 2026 still routinely find HMAC-SHA-1 enabled by default.

Git’s SHA-1 Problem and the Move to SHA-256

Git’s reliance on SHA-1 for commit, tree, and blob hashes predates SHAttered by over a decade, and it’s proven to be the hardest SHA-1 dependency to unwind precisely because so much tooling – hosting platforms, CI systems, package managers, scripts – assumes 40-character hex object IDs. Git’s own documentation is explicit about why the change is happening: SHA-1 was deprecated by NIST in 2011 and is recommended against under FIPS 140-2 and similar certifications, and practical attacks (SHAppening, SHAttered, birthday-near-collision research, and Shambles) have progressively weakened confidence in its cryptographic properties.

The rollout has been deliberately slow. Git 2.29 (2020) introduced SHA-256 as an opt-in object format. Git 2.51, released in August 2025, added further internal plumbing support, according to reporting from Help Net Security. The plan going forward, as described in community writeups of the Git roadmap, is multi-phase: quiet internal support first, then dual-hash acceptance, then a safer default, and only much later a full removal of SHA-1 fallback paths. As of today, SHA-1 remains Git’s default for new repositories.

If you want to create a SHA-256 repository right now, the option already exists:

git init --object-format=sha256 my-new-repo

# Check which hash format an existing repo uses:
git rev-parse --show-object-format

The catch is interoperability. Most major Git hosting platforms, and a large share of third-party tooling, still assume SHA-1 object IDs. A SHA-256 repository today is more of a forward-looking experiment than a drop-in production option – worth testing, not yet worth betting a team’s workflow on.

Common Misconceptions Worth Clearing Up

A few points get muddled often enough in forum threads and internal Slack debates that they’re worth addressing directly.

“SHA-256 is encryption.” It isn’t. Hashing is one-way; there’s no key and no way to recover the original input from the digest. SHA-256 verifies integrity and identity, it doesn’t protect confidentiality the way AES or ChaCha20 does.

“SHA-1 being faster makes it fine for internal-only use.” Speed and security are separate axes, and “internal-only” has a way of becoming “exposed to the internet” the moment a system gets integrated with something else. The CA/Browser Forum ban and browser-vendor rejections apply to public certificates specifically, but the underlying collision weakness doesn’t respect network boundaries.

“A SHA-256 collision is just a matter of time, same as SHA-1.” Not according to current cryptanalysis. SHA-1’s break came from structural weaknesses in its message schedule that researchers exploited methodically over more than a decade. SHA-256’s larger state and different round structure have resisted the same style of attack; the best public result still only reaches 31 of 64 rounds. That’s not a guarantee of eternal security, but it’s a fundamentally different risk profile than SHA-1 had by 2015.

“Git’s continued SHA-1 use means Git is insecure.” Git’s use of SHA-1 for object IDs is primarily about content-addressing and deduplication, not adversarial security in the way a TLS certificate is. That said, it’s still the right call for Git to move to SHA-256, and the project has said as much in its own documentation.

Migration Guide: Moving Off SHA-1

For teams that still have SHA-1 somewhere in their stack, here’s a practical order of operations. None of these steps require new hardware – this is almost entirely a configuration and process problem, not a budget problem.

  1. Inventory every SHA-1 touchpoint. Search TLS certificate chains, internal CA configurations, code-signing pipelines, VPN/IPsec HMAC settings, and any custom checksum logic in your codebase.
  2. Prioritize by exposure, not effort. Public-facing TLS certificates and code-signing keys carry the highest risk if a chosen-prefix collision is ever weaponized against them; fix those first even if they’re not the easiest items on the list.
  3. Reissue TLS certificates on SHA-256. If anything in your chain still references SHA-1 (common in old internal CAs), regenerate it. Public CAs have not issued SHA-1 certs since 2016, so this mostly affects private/internal PKI.
  4. Move code-signing pipelines to SHA-2. Confirm your build and release tooling signs binaries with SHA-256, following the same path Microsoft completed in May 2021.
  5. Update VPN and IPsec HMAC configurations. Replace HMAC-SHA-1 with HMAC-SHA-256 in IKE/IPsec policy definitions; most modern appliances support this without a hardware refresh.
  6. Evaluate Git’s SHA-256 object format for new, isolated projects. Don’t migrate existing shared repositories yet given the tooling interoperability gaps, but it’s reasonable to pilot --object-format=sha256 on new, self-contained repos.
  7. Verify with tooling, not assumptions. Run openssl s_client or equivalent to confirm the actual signature algorithm negotiated in production TLS connections, rather than trusting configuration files alone.
  8. Document the change for compliance. If you’re under PCI-DSS, FIPS 140-2/3, or similar frameworks, keep a record of the migration – auditors increasingly flag SHA-1 as a finding on its own.

Where SHA-3 and BLAKE3 Fit Into This Picture

SHA-1 and SHA-256 aren’t the only two options on the table in 2026, even though they’re the two most relevant for a direct legacy-versus-current comparison. NIST standardized SHA-3 in 2015 as a structurally different hash family (based on the Keccak sponge construction rather than Merkle–Damgård), specifically so the industry wouldn’t be entirely dependent on one design philosophy if SHA-2 ever suffered a serious break. SHA-3 hasn’t seen wide adoption to replace SHA-256 in practice – SHA-256 remains the default recommendation for most new systems – but it exists as a standardized fallback.

BLAKE3, by contrast, is not a NIST standard at all. It’s a newer, unstandardized design that trades formal government certification for speed, often benchmarking at multiple gigabytes per second thanks to heavy SIMD parallelism (AVX-512, AVX2, NEON). Some benchmark sources report BLAKE3 running 2-10x faster than SHA-256 depending on hardware and input size, though the gap narrows or even reverses on certain ARM64 platforms for very small inputs. Because it lacks FIPS 140-2/3 certification, BLAKE3 tends to show up in performance-critical, non-regulated tooling – backup software, content-addressed storage, build systems – rather than in TLS certificates or anything that needs to pass a compliance audit. If your workload is bound by compliance requirements, SHA-256 is still the practical choice regardless of what a raw speed benchmark shows.

Pros and Cons

SHA-1

Pros: Faster on hardware without SHA extensions; smaller 160-bit digest saves a little storage and bandwidth; still nearly universally implemented, so it works everywhere as a non-security checksum.

Cons: Practical collisions demonstrated since 2017; chosen-prefix collisions now estimated under $10,000; banned from public TLS certificate issuance since 2016; rejected by every major browser; unsuitable for digital signatures, code signing, or anything where an adversary controls part of the input.

SHA-256

Pros: No known practical attack against the full algorithm; NIST-approved for signatures, HMAC, and general integrity checking; near-universal support in modern TLS, code signing, and blockchain infrastructure; hardware acceleration on current CPUs closes most of the speed gap with SHA-1.

Cons: Roughly 1.2-3x slower than SHA-1 on hardware without SHA extensions; larger 256-bit digest means slightly more storage per hash; still a Merkle–Damgård construction, meaning it inherits length-extension attack risk unless used inside HMAC or a properly domain-separated scheme.

Best Use Cases for Each

  • Public TLS certificates and code signing: SHA-256 only. This isn’t optional – it’s mandated by CA/Browser Forum rules and enforced by every major browser and OS vendor.
  • New Git repositories with no legacy tooling dependency: Consider piloting SHA-256 object format now, ahead of Git 3.0 making it the default.
  • Blockchain and cryptocurrency protocols: SHA-256, following Bitcoin’s precedent, remains the standard choice for proof-of-work and block hashing.
  • VPN and IPsec HMAC configuration: Move to HMAC-SHA-256; most enterprise appliances already support it as a configuration change, not a hardware upgrade.
  • Legacy internal deduplication or non-adversarial checksums: SHA-1 can still technically function here since no attacker controls the input, but given the shrinking performance gap, there’s little reason to keep it over SHA-256 for new systems.
  • FIPS 140-2/140-3 or PCI-DSS regulated environments: SHA-256 or stronger is effectively required; SHA-1 will show up as an audit finding.

The Verdict

This isn’t a close call. SHA-1’s practical security has been degrading since 2017, and the cost to break it keeps dropping – from $110,000 for the original SHAttered proof-of-concept down to an estimated $5,000-10,000 range for a chosen-prefix collision by 2025. SHA-256, by contrast, has absorbed a decade of dedicated cryptanalysis and still has no attack against its full 64-round design, with the best published result reaching only 31 of those rounds.

The speed argument that once favored SHA-1 has also mostly disappeared. On hardware with SHA extensions, the gap between the two algorithms shrinks to roughly 15-20%, not the 2-3x difference you’d see on older silicon. There’s no longer a strong performance reason to reach for SHA-1 in a new system, and there’s a very strong security reason not to.

If you’re starting something new: use SHA-256, full stop. If you’re maintaining something old that still touches SHA-1 – an internal CA, a VPN config, a Git server – treat it as technical debt with a shrinking window before it becomes a real liability, not a permanent architectural decision.

The one place where SHA-1’s fate is genuinely still playing out is Git, and even there the direction is clear. Git 2.51 shipped in August 2025 with more SHA-256 plumbing in place, and the project’s own breaking-changes documentation already commits to flipping the default in a future Git 3.0 release. That’s not a maybe – it’s a migration in progress, just a slow one, for the same reason every other SHA-1 migration has been slow: too much depends on it to move fast without breaking things.

Frequently Asked Questions

Is SHA-1 still safe to use in 2026?

Not for anything security-sensitive. Practical collisions have existed since 2017, and chosen-prefix collisions are now estimated to cost under $10,000. It’s banned from public TLS certificate issuance and rejected by every major browser. It may still function as a non-adversarial checksum, but there’s little reason to prefer it over SHA-256 for new systems.

What replaced SHA-1?

SHA-256, part of the SHA-2 family, is the direct replacement across TLS, code signing, and most Git tooling going forward. Some newer systems also use SHA-3 or BLAKE3 depending on performance and standardization requirements, but SHA-256 remains the default recommendation.

How much does it cost to break SHA-1 today?

Published estimates from the Shambles research team put a chosen-prefix collision under $10,000 as of 2025, down from $110,000 for the original 2017 SHAttered attack. A separate 2025 analysis using consumer RTX 5090 GPUs estimated a home-built collision attack at roughly $5,468.

Has SHA-256 ever been broken?

No. Full 64-round SHA-256 has no known practical collision, preimage, or second-preimage attack as of 2026. Researchers have found collisions in reduced-round versions – the best published result reaches 31 of 64 rounds – but these techniques don’t extend to the full algorithm.

Does Git still use SHA-1?

Yes, by default. Git has supported SHA-256 as an alternative object format since version 2.29, and Git 2.51 (August 2025) expanded internal support further, but new repositories still default to SHA-1 as of 2026. A switch to SHA-256 as the default is planned for a future Git 3.0 release.

What’s the actual output size difference between SHA-1 and SHA-256?

SHA-1 produces a 160-bit digest (40 hex characters); SHA-256 produces a 256-bit digest (64 hex characters). That 96-bit difference in output size is a major reason SHA-256’s theoretical security margin is so much larger.

Is SHA-256 too slow for high-throughput applications?

Not on modern hardware. Benchmarks on CPUs with SHA extensions show SHA-256 throughput within roughly 15-20% of SHA-1, and some accelerated implementations report SHA-256 exceeding several gigabytes per second. For applications that need even more speed, newer non-standardized options like BLAKE3 exist, but SHA-256 is fast enough for the overwhelming majority of production workloads.

Should I still worry about SHA-1 in legacy VPNs?

Yes, it’s worth fixing. HMAC-SHA-1 is less directly exposed to collision attacks than digital signatures are, but it’s still flagged by most compliance frameworks and security audits. Most enterprise VPN and IPsec appliances support HMAC-SHA-256 as a configuration change, so there’s rarely a good reason to leave HMAC-SHA-1 enabled.

What is the SHAttered attack in one sentence?

SHAttered was the first practical SHA-1 collision, published in February 2017 by researchers from Google and CWI Amsterdam, producing two different PDF files with identical SHA-1 hashes for an estimated cloud-compute cost of $110,000. It remains the reference point every subsequent SHA-1 cost estimate gets measured against, precisely because it was the moment the attack stopped being theoretical.

Can I check which hash algorithm a certificate or file actually uses?

Yes. For a live TLS connection, openssl s_client -connect host:443 | openssl x509 -noout -text will show the signature algorithm in the certificate. For a local file, sha1sum file and sha256sum file will compute both digests directly so you can see exactly what a given tool is producing.

Sources: NIST Hash Functions project (CSRC), FIPS 180-4 Secure Hash Standard, Shambles: SHA-1 chosen-prefix collision research, Leurent & Peyrin, “SHA-1 is a Shambles” (IACR ePrint 2020/014), Chromium SHA-1 certificate deprecation notes, Mozilla Security Blog, SHA-1 phase-out plan, CA/Browser Forum TLS Baseline Requirements, Git Breaking Changes documentation, and Help Net Security on Git 2.51’s SHA-256 support.