Thanks! What tools did you use to analyse the JPEG?
I used Hachoir ( https://github.com/haypo/hachoir3 ), a Python library that I've contributed to. Hachoir disassembles files using a library of parsers, with the intent of describing the function of every single bit in the file. You can see the resulting disassemblies (rendered with the hachoir-wx GUI) here: http://imgur.com/a/F1cnV
And here I'm refactoring a PHP application feeling like I've come so far. I love that I always have more to learn.
> If you use Chrome, you will be automatically protected from insecure TLS/SSL certificates, and Firefox has this feature planned for early 2017. No need to wait. The option to reject SHA-1 certificates on Firefox is `security.pki.sha1_enforcement_level` with value `1`. https://blog.mozilla.org/security/2016/01/06/man-in-the-midd... Other configs worth doing: `security.ssl.treat_unsafe_negotiation_as_broken` to `true…
Why chance with Firefox? Google has Chrome already safe and clearly on top of things. This is not a static thing as in there will be others with parts of the crypto tool chain or maybe stack?
It's kind of odd that over 9 months ago it was known that Microsoft would stop honoring SHA-1 certificates starting from 1 week ago. Anyone know if this is just a pure coincidence? See https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecat...
No. I don't know the details of the attack, but a third possibility (as I read it) is that both PDF documents are modified in the process until they arrive at a collision. PDF has the convenient property that you can inject arbitrary bogus data into the middle of it with a constant head and tail and it will still be valid. The tail of the file contains a trailer that points to the dictionary that describes where all…
Or, if you're really clever - and Ange Albertini is quite good at this kind of trick - you can design the PDF so that the different garbage in the middle causes the other, unchanged content to be interpreted differently in the two PDF files, possibly even designing it so that the intended contents of each PDF is treated as garbage and ignored entirely in the other PDF.
With many image formats, you can just concatenate whatever you want at the end of the file, and the OS and programs will obliviously read and copy the whole file, while the image libraries will happily ignore the extra data.
The PDF example given is somewhat ridiculous. "For example, by crafting the two colliding PDF files as two rental agreements with different rent, it is possible to trick someone to create a valid signature for a high-rent contract by having him or her sign a low-rent contract. " Talk about ridiculous scenarios only people living in a tech bubble could come up with. How many landlords do you imagine know what sha-1 ch…
This is not as far fetched as you think. In UK, rental contracts are often digitally signed by the renter and landlord. I am sure in finance world many other types of contracts are signed digitally, also under the assumption that both parties sign the same thing.
There's a difference between digital signatures and sha-1 checksums of the files, which is what they seem to have been demonstrating.
Mysteriously the text I quoted has now vanished from the original blog post.
> break SHA1 SSL certs. It's not possible to break existing SHA1 certificates because this attack is to generate collisions, not finding preimages.
You are thinking about this in a wrong way. It is in fact true that being able to generate collisions allows you to break SSL. What you do is this: generate two certificates with colliding hashes, one for google.com, the other for your own domain. Verisign will gladly sign the second one, since you own the domain, but since the hashes match, you can also use the same signature for the first one. Now you can impersona…
Those extra precautions are designed explicitly to prevent the ability to get a certificate using a collision attack. CA's now must explicitly introduce entropy into a certificate to prevent exactly this, and will not sign a certificate exactly to the specifications of a client.
There's a great deal of handwaving there saying that a collision attack alone is sufficient for breaking SSL.
Can someone help me understand what the major distinction is between this accomplishment (SHAttered) and the same team's The SHAppening (2015)? It looks like the did the same thing or something similar in 2^57.5 SHA1 calculations back then versus 2^63 SHA1 calculations this time.