 |
| “Basically, each PDF contains a single large (421,385-byte) JPG image” (comment) | ||
| recommended by 1 user | 2017 | nneonneo on: Announcing the first SHA-1 collision | cryptography | original thread | | ||
| nneonneo on Feb 23, 2017 | on: Announcing the first SHA-1 collision | view on HN | ||
| One user recommended this comment. What they said: |
|
Deregibus Feb 24, 2017 | on: SHA-1 collider: Make your own colliding PDFs | context
This was a good explanation of what's happening here from a previous thread: https://news.ycombinator.com/item?id=13715761 The key is that essentially all of the data for both images are in both PDFs, so the PDFs are almost identical except for a ~128 byte block that "selects" the image and provides the necessary bytes to cause a collision. Here's an diff of the 2 PDFs from when I tried it earlier: https://imgur.com/a/8O58Q Not to say that there isn't still something exploitable here, but I don't think it means that you can just create collisions from arbitrary PDFs. edit: Here's a diff of shattered-1.pdf released by Google vs. one of the PDFs from this tool. The first ~550 bytes are identical. |
The visual description of the colliding files, at http://shattered.io/static/pdf_format.png, is not very helpful in understanding how they produced the PDFs, so I took apart the PDFs and worked it out.
Basically, each PDF contains a single large (421,385-byte) JPG image, followed by a few PDF commands to display the JPG. The collision lives entirely in the JPG data - the PDF format is merely incidental here. Extracting out the two images shows two JPG files with different contents (but different SHA-1 hashes since the necessary prefix is missing). Each PDF consists of a common prefix (which contains the PDF header, JPG stream descriptor and some JPG headers), and a common suffix (containing image data and PDF display commands).
The header of each JPG contains a comment field, aligned such that the 16-bit length value of the field lies in the collision zone. Thus, when the collision is generated, one of the PDFs will have a longer comment field than the other. After that, they concatenate two complete JPG image streams with different image content - File 1 sees the first image stream and File 2 sees the second image stream. This is achieved by using misalignment of the comment fields to cause the first image stream to appear as a comment in File 2 (more specifically, as a sequence of comments, in order to avoid overflowing the 16-bit comment length field). Since JPGs terminate at the end-of-file (FFD9) marker, the second image stream isn't even examined in File 1 (whereas that marker is just inside a comment in File 2).
tl;dr: the two "PDFs" are just wrappers around JPGs, which each contain two independent image streams, switched by way of a variable-length comment field.