SHA1 collisions proven possisble

Florian Weimer fw at deneb.enyo.de
Fri Feb 24 13:06:12 UTC 2017


* 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.



More information about the NANOG mailing list