Hash Collision Attacks: MD5, SHA-1, and Safe Verification
Understand hash collisions, why MD5 and SHA-1 are unsafe for signatures, and how to verify files with SHA-256 and an authenticated source.
Primary source: authoritative reference
A hash collision exists when two different inputs produce the same digest. Collisions must exist because a fixed-size digest represents an unlimited set of possible inputs. A cryptographic hash is useful only when finding a collision is computationally impractical.
The practical rule is simple: do not use MD5 or SHA-1 where collision resistance protects a signature, certificate, update, or other security decision. Use an approved SHA-2 or SHA-3 algorithm and verify the expected digest through an authenticated source.
Check a downloaded file against its checksum
Select a file up to 32 MiB and compare its SHA-256 or SHA-512 digest in your browser. The file is not uploaded. Get the expected digest from a trusted publisher; matching checksums do not prove a file is safe.
Compare a file checksum →Collision resistance is not preimage resistance
These security properties answer different questions:
- Collision resistance: Can an attacker find any two different inputs with the same digest?
- Second-preimage resistance: Given one input, can an attacker find a different input with the same digest?
- Preimage resistance: Given a digest, can an attacker find an input that produces it?
A collision demonstration does not mean an attacker can reverse every digest or replace any arbitrary file with a chosen malicious file. It does mean the affected algorithm no longer provides its intended collision-security margin. That is enough to disqualify it from many signature and certificate uses.
For an ideal n-bit hash, generic collision search takes about 2n/2 work because of the birthday bound. Cryptanalysis can reduce the work for a specific algorithm, which is what happened to MD5 and SHA-1.
Why MD5 and SHA-1 should not protect security decisions
MD5 collision resistance is broken. RFC 6151 says MD5 is no longer acceptable where collision resistance is required, including digital signatures. Researchers also demonstrated a rogue certification authority certificate using an MD5 chosen-prefix collision, showing how a weak digest can undermine a signed structure.
SHA-1 also no longer provides adequate collision resistance:
- The 2017 SHAttered demonstration published two different PDF files with the same SHA-1 digest.
- The 2020 SHA-1 chosen-prefix collision research made it possible to choose different prefixes before constructing colliding files, a more flexible attack model.
- NIST announced its transition away from SHA-1 and recommends moving to SHA-2 or SHA-3.
Legacy systems may still expose MD5 or SHA-1 identifiers for compatibility. Do not treat those values as security evidence. Plan a migration and avoid creating new dependencies on them.
What a matching SHA-256 digest proves
If two byte sequences have the same SHA-256 digest, they are overwhelmingly likely to be identical. That comparison can detect accidental corruption or a changed file.
It does not prove who published the file. If an attacker can replace both the download and the checksum shown beside it, the values can still match. Obtain the expected digest from an authenticated channel, such as an HTTPS vendor page you trust, a signed release manifest, or a verified package-repository signature.
For signed software, verify the publisher's signature using the platform's supported tooling. A manually compared checksum is not a substitute for signature and trust-chain validation.
Calculate a digest locally
OpsecForge computes supported hashes in your browser. Compare the result with a digest obtained from an authenticated source; a matching hash alone does not prove publisher identity.
Open Hash Generator →Safe migration checklist
- Inventory the purpose, not only the algorithm. Separate non-security identifiers from signatures, certificates, integrity controls, password storage, and message authentication.
- Replace MD5 and SHA-1 in security-sensitive protocols. Select an algorithm permitted by the relevant platform and current standard, normally SHA-256 or stronger.
- Do not invent a signature or MAC construction. Use maintained libraries and the protocol's defined algorithm negotiation and key handling.
- Use password-hashing functions for passwords. Follow the OWASP Password Storage Cheat Sheet; fast general-purpose hashes such as SHA-256 are not password-storage schemes.
- Design a compatibility window. Version stored digests or signatures, verify old records only where necessary, and create new records with the approved algorithm.
- Test the complete verification path. Confirm that failure is explicit when a digest, signature, certificate chain, or trusted source does not match.