Sign with SHA-256 or stronger, or SHA-3, and make every verifier reject MD5 and SHA-1 signatures, not just the signers stop producing them. A collision lets an attacker who controls both documents make one signature valid for both; it does not reveal private keys or forge arbitrary existing documents. SHA-1 chosen-prefix collisions have been practical since 2020, and NIST will retire SHA-1 by 31 December 2030.
- Collision, second preimage and preimage are different attacks; published MD5 and SHA-1 breaks are collisions.
- A chosen-prefix collision lets an attacker pair two meaningful documents under one signature.
- Verifiers matter most: one that still accepts SHA-1 keeps the attack open after signers move on.
- HMAC and password hashing have different requirements; a collision is not an HMAC forgery.
- Since 15 September 2026, publicly trusted CAs may not use SHA-1 anywhere in certificates or CRLs.
- Run
openssl x509 -in cert.pem -noout -texton each certificate in your chains and confirm no signature algorithm uses MD5 or SHA-1. - Submit an artifact signed with SHA-1 to each verifier and confirm it is rejected by policy, not by an unrelated error.
- Change one signed byte of a valid artifact and confirm verification fails.
- Confirm the verifier rejects a valid signature from an issuer or purpose it should not trust.
- Applies to
Signature systems that bind structured data through a hash. Collision attacks do not reveal arbitrary private keys.
- Part of
- Learning path: Cryptography without shortcuts (step 11 of 12)
Tested fixes: the vulnerable code, the fix, a plausible fix that still fails, and the regression tests that tell them apart.
Learning goals and prerequisites
What you will learn
- Distinguish three hash attack goals.
- Trace a collision through a signing workflow.
- Separate algorithm migration from historical authenticity.
Before you start
Engineers who sign or verify artifacts, certificates or messages, and reviewers who assess hash algorithm choices.
- Distinguish a hash digest from a signature and collision resistance from preimage resistance.
Many signature schemes sign a representation derived from a message digest. A collision is a pair of different messages M and M′ with H(M) = H(M′). If the signature construction and verification treat these messages through the same digest representation, a signature obtained for one can also validate the other. The adversary has not necessarily recovered the signer’s private key; the substitution defeats the binding between signature and meaning.
A generic collision lets the attacker choose both messages. A second-preimage attack starts with one already fixed message and seeks another with its digest. A preimage attack starts from a digest and seeks any matching message. These are different capabilities. A published collision pair is not a magic tool for altering an arbitrary existing signed contract.
Chosen-prefix collisions add control: the attacker chooses distinct meaningful prefixes and constructs suffixes that bring their hash computations together. For certificates or documents, the format must still parse, and the attacker often needs influence over fields or issuance timing. The cryptanalysis and the surrounding workflow jointly determine whether an otherwise academic collision can become a valid substituted artifact.
A toy checksum H(a,b) = (a+b) mod 256 maps both [10,20] and [11,19] to 30. Imagine that the first byte is a recipient and the second an amount. Signing only this checksum cannot distinguish the two instructions. This deliberately weak construction demonstrates the reasoning, not the difficulty of finding a collision in a modern cryptographic hash.
For a real signed artifact, inspect what bytes are signed, which algorithm identifies the digest, whether canonicalization changes those bytes, and whether verifiers enforce the intended artifact type. SHA-256 over one serialization and a signature over another is a serialization bug even without a hash collision. Likewise, accepting an attacker-supplied algorithm because it appears in the artifact can undermine an otherwise strong default.
MD5 collisions have been practical since 2004, and the 2008 rogue CA certificate and the 2012 Flame malware (/domains/identity-crypto/key-management-pki/flame-md5-certificate-forgery/) used them against real PKIs. SHA-1 followed: the first full collision (SHAttered) came in 2017, and in January 2020 the first practical chosen-prefix collision (“SHA-1 is a Shambles”) cost about 75,000 US dollars of computing and forged a PGP key certification (CVE-2019-14855). NIST announced in December 2022 that SHA-1 will be phased out by 31 December 2030. These results do not mean every use of a hash fails identically: HMAC has a keyed construction and a different security analysis, and password storage needs deliberately slow hashing, not collision resistance.
Select a maintained signature profile with an approved modern hash and enforce it on verification. Changing only the signing default leaves old weak algorithms acceptable to an attacker. Preserve the algorithm identifier and exact byte representation so verification is deterministic. Treat the permitted purpose, issuer, and trust path as part of validation; the release verification policy at /domains/supply-chain/provenance/artifact-signature-policy/ applies this to signed artifacts.
Long-lived archives create a different problem from new online messages. An old signature may require historical trust and timestamp evidence. Decide which artifacts need trusted re-signing, countersigning, or preservation evidence before the obsolete algorithm is removed. Merely rehashing an untrusted artifact today proves possession of today’s bytes; it does not establish who originally approved them.
- List every verifier that still accepts MD5 or SHA-1 signatures: certificate chains, code signing, package and update verification, SAML and XML signatures, PGP and DNSSEC.
- Configure those verifiers to reject them, then remove them from signers; signing with SHA-256 alone leaves the verifier open.
- Use SHA-256, SHA-384 or SHA-3 for signatures, and keep artifacts and their digests bound to an explicit algorithm identifier.
- For long-lived archives, re-sign or countersign with a modern algorithm and a trusted timestamp before the old algorithm is removed.
- Keep MD5 or SHA-1 only for non-security checksums, such as cache keys, and name them as such.
Use a valid artifact under the accepted profile as the ordinary case. Change one signed byte and require verification failure. Supply an otherwise correctly constructed artifact using a disallowed digest and require policy rejection. Also test an artifact whose signature is mathematically valid but whose purpose or trust path is wrong. Those are distinct failures and should be visible in internal review evidence.
An equal checksum in the exercise proves the weakness of the toy mapping only. When assessing a real collision claim, require the actual distinct files, their computed digests, the relevant algorithm, and an explanation of who controlled each file. Keep a demonstration’s publication date separate from the date a product stopped trusting that algorithm.
Guided practice
A signing service approves one toy payment record and signs only its supplied one-byte checksum.
Supplied scenario material
Record A: recipient=10, amount=20; encoded bytes [10,20].
Record B: recipient=11, amount=19; encoded bytes [11,19].
Record C: recipient=10, amount=21; encoded bytes [10,21].
Toy H(bytes)=sum(bytes) mod 256.
Verifier accepts a supplied signature whenever its signed checksum equals H(record).1. Compute all three checksums
Calculate H(A), H(B), and H(C).
Expected result and reasoning
A=30, B=30, C=31. A and B collide while carrying different payment meaning.
2. Predict verification
Decide which records accept A’s signature under the stated verifier.
Expected result and reasoning
A and B accept; C rejects. No private-key recovery is needed in this model.
3. Classify the evidence
Decide whether this proves an arbitrary existing SHA-256 contract can be forged.
Expected result and reasoning
It does not. The fixture is a toy collision with both messages supplied. A fixed-target substitution would require additional capability and a real vulnerable signature workflow.
No modern hash collision or digital signature is computed; the fixture supplies an intentionally insecure signing abstraction.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
Sources & further reading
The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.
- RFC 6151: Security Considerations for MD5 and HMAC-MD5. March 2011.
- The First Collision for Full SHA-1 (SHAttered research paper). February 2017.
- NIST Policy on Hash Functions
- Leurent and Peyrin: SHA-1 is a Shambles, the first chosen-prefix collision for SHA-1 (2020)
- NIST retires SHA-1 (December 2022)
- CA/Browser Forum Baseline Requirements (SHA-1 sunset, September 2026). Version 2.3.1 (4 October 2026).
Reference information
- SDLC phase
- Maintenance
- Role
- Developers
- ASVS 5.0.0 requirements
- v5.0.0-11.4.1 · v5.0.0-11.4.3