SHA-1 vs SHA-256: SHA-1 is dead, but Git still uses it

SHA-1 (160-bit output, 1995) and SHA-2 family (256/384/512-bit outputs, 2001) are both NIST-published cryptographic hash functions. SHA-1 was the dominant integrity hash through the 2000s. It’s now deprecated everywhere security matters — but not yet everywhere.

The headline

How SHA-1 broke

A cryptographic hash function should make it computationally infeasible to find two inputs that produce the same hash. SHA-1’s 160-bit output gave 2⁸⁰ collision resistance on paper — far beyond brute-force budgets at design time in 1995.

Three milestones eroded that:

1. 2005: Wang, Yin, and Yu published a theoretical attack reducing collision search to ~2⁶⁹ operations — still infeasible at the time but a clear warning shot.
2. 2017: Google’s SHAttered project demonstrated the first practical SHA-1 collision: two PDFs with the same SHA-1 hash. Cost: ~$110K of GPU compute and 9 quintillion SHA-1 evaluations.
3. 2020: Leurent and Peyrin published a chosen-prefix collision attack — given any two arbitrary file headers, append carefully crafted bytes and produce colliding files. Cost: ~$45K in cloud compute. This is the kind of attack that enables forged certificates and spoofed signatures in the wild.

After 2020, SHA-1 is unsuitable for any security purpose where forgery matters.

Where SHA-1 is still acceptable

Non-adversarial fingerprinting — where there’s no attacker incentive to forge collisions — is still fine with SHA-1:

• Git commit and tree object hashes. An attacker forging a collision would need to inject crafted commits and have them accepted into mainstream mirrors. Git also runs SHA-1 detection of known-attack patterns (the SHAttered detection) on every operation, making attack injection visible.
• Content-addressable storage where you control all the inputs (build caches, CDN deduplication).

Even in these cases, SHA-256 is the right default for new systems. The performance gap (SHA-256 is ~40% slower than SHA-1 on most modern CPUs) is irrelevant for almost every workload.

Where SHA-256 is mandatory

• TLS certificate signatures. Browsers stopped accepting SHA-1 in 2017.
• JWT signatures (HS256, RS256, ES256). The 256 is SHA-256.
• Code signing. Microsoft and Apple stopped accepting SHA-1 signatures around 2016-2017.
• Anywhere collision attacks would enable forgery. Document signatures, cryptocurrency, identity proofs.

The Git migration

Git has been migrating to SHA-256 since 2018. The migration is technically straightforward but takes time because every Git server, every CI/CD system, every dependency manager has to support both. Status as of 2026:

• SHA-256 repositories work end-to-end on modern Git.
• GitHub supports SHA-256 repos but defaults to SHA-1 for new repos.
• GitLab and Bitbucket: partial support, varies by version.
• Most CI integrations work with both.

Default behaviour for the Git CLI is still SHA-1. To create a SHA-256 repo: git init --object-format=sha256. Once migration completes — likely 2027-2028 timeframe — the default will flip.

The pragmatic rule

• For new systems: SHA-256. Always. The performance gap doesn’t matter.
• For legacy SHA-1 systems: migrate when feasible, but don’t panic — the threat is real but specific.
• For Git specifically: SHA-1 is fine for now. Watch for SHA-256 to become the default.
• For TLS, code signing, JWT, crypto: SHA-256 was already the only acceptable choice.

Compute both hashes via our hash generator.