4 ms·

Why wouldn't the header be the same? The files have the same size and same name here? Does it have anything to do with zlib compression (I'd imagine the two fil

by 0x0 10y ago

Why wouldn't the header be the same? The files have the same size and same name here? Does it have anything to do with zlib compression (I'd imagine the two files compress differently since they are actually different?)

simias 10y ago
Even if you use exactly the same headers it means that at the moment the SHA1 algorithm encounters the specially crafted data that creates the collision it's in a different state than with the "naked" files, so the collision (very probably) won't happen. Adding more content at the end of the file would work though, since at this point the SHA1 state machine would be in the same state on both sides. You can test that easily with the files provided: $ sha1sum shattered-* 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf $ echo 'more content at the end' >> shattered-1.pdf $ echo 'more content at the end' >> shattered-2.pdf $ sha1sum shattered-* 42cfb194d7e7d557c00d9f2c8d590641ee8f871c shattered-1.pdf 42cfb194d7e7d557c00d9f2c8d590641ee8f871c shattered-2.pdf $ echo 'more content at the start' > other-1.pdf; cat shattered-1.pdf >> other-1.pdf $ echo 'more content at the start' > other-2.pdf; cat shattered-2.pdf >> other-2.pdf $ sha1sum other-* ed2ab5fc6c7109a7c7da13fdc05585e4d9e4fe0c other-1.pdf a41e3539ca0e317a4097bb26ae978e79119d09c8 other-2.pdf
- consp 10y ago
  True, but the attack already builds upon modifying the state machine to get the same end result, creating data to allow for a specific prefix (e.g. always getting the desired intermediary state) should also be doable in some form of this attack.
  - 0x0 10y ago
    Would it help if we padded the prefix so that the rest of the files are aligned to the block size of SHA1 (512bits), so that the crafted blocks are still block-aligned? Or does the different initial state (due to a different prefix) break any chance of re-colliding with these specific files? (i.e. you'll have to run the full brute force attack again with a valid git blob header as a common prefix?)
    - Klathmon 10y ago
      It's content specific. Changing anything before that point ruins the whole attack. So yeah you'd need to do the whole attack again but with the prefix.
deleted 10y ago
[deleted]

by 0x0 10y ago

simias 10y ago

Even if you use exactly the same headers it means that at the moment the SHA1 algorithm encounters the specially crafted data that creates the collision it's in a different state than with the "naked" files, so the collision (very probably) won't happen. Adding more content at the end of the file would work though, since at this point the SHA1 state machine would be in the same state on both sides. You can test that easily with the files provided: $ sha1sum shattered-* 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf $ echo 'more content at the end' >> shattered-1.pdf $ echo 'more content at the end' >> shattered-2.pdf $ sha1sum shattered-* 42cfb194d7e7d557c00d9f2c8d590641ee8f871c shattered-1.pdf 42cfb194d7e7d557c00d9f2c8d590641ee8f871c shattered-2.pdf $ echo 'more content at the start' > other-1.pdf; cat shattered-1.pdf >> other-1.pdf $ echo 'more content at the start' > other-2.pdf; cat shattered-2.pdf >> other-2.pdf $ sha1sum other-* ed2ab5fc6c7109a7c7da13fdc05585e4d9e4fe0c other-1.pdf a41e3539ca0e317a4097bb26ae978e79119d09c8 other-2.pdf

consp 10y ago
True, but the attack already builds upon modifying the state machine to get the same end result, creating data to allow for a specific prefix (e.g. always getting the desired intermediary state) should also be doable in some form of this attack.
- 0x0 10y ago
  Would it help if we padded the prefix so that the rest of the files are aligned to the block size of SHA1 (512bits), so that the crafted blocks are still block-aligned? Or does the different initial state (due to a different prefix) break any chance of re-colliding with these specific files? (i.e. you'll have to run the full brute force attack again with a valid git blob header as a common prefix?)
  - Klathmon 10y ago
    It's content specific. Changing anything before that point ruins the whole attack. So yeah you'd need to do the whole attack again but with the prefix.

deleted 10y ago

[deleted]