SHA1 collisions proven possisble

Jon Lewis jlewis at lewis.org
Fri Feb 24 00:28:44 UTC 2017


On Thu, 23 Feb 2017, valdis.kletnieks at vt.edu wrote:

> On Thu, 23 Feb 2017 17:40:42 -0500, "Ricky Beam" said:
>
>> cost! However this in no way invalidates SHA-1 or documents signed by
>> SHA-1.
>
> 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?

Depends on the format of the document.  As was just pointed out, and I 
almost posted earlier today, that there are collisions in SHA-1, or any 
hash that takes an arbitrary length input and outputs a fixed length 
string, should be no surprise to anyone.  Infinite inputs yielding a fixed 
number of possible outputs.  There have to be collisions.  Lots of them. 
The question then becomes how hard is it find or craft two inputs that 
give the same hash or one input that gives the same hash as another? 
Doing this with PDFs that look similar, which can contain arbitrary 
bitmaps or other data is kind of a cheat / parlor trick.

Doing it with an ASCII document, source code, or even something like a 
Word document (containing only text and formatting), and having it not be 
obvious upon inspection of the documents that the "imposter" document 
contains some "specific hash influencing 'gibberish'" would be far more 
disturbing.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
                              |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



More information about the NANOG mailing list