* valdis kletnieks:
We negotiate a contract with terms favorable to you. You sign it (or more correctly, sign the SHA-1 hash of the document).
I then take your signed copy, take out the contract, splice in a different version with terms favorable to me. Since the hash didn't change, your signature on the second document remains valid.
I present it in court, and the judge says "you signed it, you're stuck with the terms you signed".
I think that would count as "invalidates documents signed by SHA-1", don't you?
The more immediate problem isn't that you get framed, but that someone is insinuating that you might be framing *them*, i.e. invalidation of existing signatures etc. Regarding your original scenario: You have both copies, and it is possible to analyze them and notice that they were carefully crafted to exhibit the SHA-1 collision. So it should be clear that the party who generated the document is up to to no good, and the question now is which party is responsible for the doctored document. This scenario isn't much different from abusing complex file formats to render the document differently in different contexts. There is more reliable evidence here than there is with your average disputed pen-and-paper signature. Automated processing of SHA-1-hashed data might be a problem, though. For example, a web page generator might skip proper HTML encoding if the hash of a document fragment has a known SHA-1 (assuming that this exact fragment has been checked earlier). Certification signatures (such as those found in X.509 and DNSSEC) are particularly at risk. For X.509, CAs can randomize the serial number and avoid the shared prefix, which stops these attacks AFAIK. For DNSSEC, you probably should verify that the DS records are meaningful before signing the DS RRset. If I recall correctly, there is no good way to inject randomness early into the signed data, maybe except using invalid DS records which get sorted first.