What SHA-1 was designed for
SHA-1 (1995, NSA-designed, published by NIST) produces a 160-bit (40 hex character) digest and was, for nearly two decades, the standard choice for digital signatures, certificate fingerprints, and version control (it's still Git's default object-hashing algorithm). Like any cryptographic hash, it was meant to make finding two different inputs with the same digest computationally infeasible.
The 2017 "SHAttered" attack
In February 2017, Google and CWI Amsterdam publicly demonstrated a real, practical SHA-1 collision — two genuinely different PDF files that produce the identical SHA-1 digest. This wasn't a theoretical weakness anymore; it was a working proof that an attacker with enough compute could construct two different documents (or certificates, or software packages) that hash identically, defeating any integrity check relying purely on SHA-1 matching. This is what pushed SHA-1 from "aging but tolerated" to actively deprecated across browsers, certificate authorities, and most security-sensitive tooling.
Why Git still uses SHA-1 (mostly safely)
Git's use of SHA-1 is a narrower case than signing certificates or verifying downloads: Git primarily needs to detect accidental corruption and uniquely identify content, not resist a deliberate, targeted collision attack from an adversary trying to substitute one specific commit for another with matching hash. Git has also adopted specific collision-detection mitigations in response to SHAttered, and newer Git versions support migrating to SHA-256 object hashing — the direction of travel is still away from SHA-1, just on a longer timeline given Git's massive existing installed base.
Where SHA-1 is genuinely unacceptable now
- TLS/SSL certificates — modern browsers reject SHA-1-signed certificates outright.
- Code signing and software integrity verification — a forged collision could let malicious code pass a SHA-1 integrity check undetected.
- Any context where an adversary might deliberately construct a colliding input — this is precisely the scenario SHAttered proved practical.
Common mistakes
- Treating "still works" as "still secure." SHA-1 still produces a digest and can still detect accidental changes — that's different from being safe against a deliberate, targeted collision attempt.
- Using SHA-1 for anything customer- or security-facing today, when SHA-256 is a drop-in replacement with no known practical collision attack.
- Assuming Git's continued use of SHA-1 means it's broadly fine everywhere. Git's threat model (mostly accidental corruption, with added mitigations) is meaningfully different from signing certificates or verifying software downloads.
FAQ
Is SHA-1 completely broken?
Practically, for security purposes — a real collision attack was demonstrated in 2017 (SHAttered), meaning an adversary can construct two different inputs with the same digest, which defeats SHA-1's use in signatures and certificates.
Why does Git still use SHA-1 if it's broken?
Git's primary need is detecting accidental corruption and uniquely identifying content, not resisting deliberate attacker-constructed collisions — Git has added specific mitigations and is moving toward SHA-256 support over time.
What should replace SHA-1 for integrity checks?
SHA-256 — no known practical collision attack exists against it, and it's a straightforward drop-in replacement for most SHA-1 use cases.
Generate SHA-1 and SHA-256 digests to compare directly with the Hash Generator — entirely client-side.