5 ms·

Make your own colliding PDFs: https://alf.nu/SHA1 https://alf.nu/SHA1

deleted 10y ago
[deleted]
rcar 10y ago
Interestingly, Gmail labeled PDFs generated through that tool as viruses. Anyone happen to know the mechanism behind that?
- deleted 10y ago
  [deleted]
- tyingq 10y ago
  The git mailing list talked about using ubc_check() from here: https://github.com/cr-marcstevens/sha1collisiondetection/blob/40ccf5e3537ff6b2e5ceac5747f376a2ef430bec/lib/ubc_check.c https://github.com/cr-marcstevens/sha1collisiondetection/blo...
- arnarbi 10y ago
  See "Mitigating the risk..." at https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...
tlrobinson 10y ago
Wow, I didn't realize you could re-use the same collision to produce new colliding PDFs. And so much for Google's 90 day disclosure period.
- avar 10y ago
  What would be the point of a disclosure period? Nobody's going to fix SHA-1 in the next 90 days, or ever.
  - tyingq 10y ago
    There is the "hardened sha-1" implementation that was released along with the sample collisions. It supposedly detects this type of attack and returns unique SHA-1 hashes. Not sure that's really a fix, but perhaps something someone would want to use short term.
    - deleted 10y ago
      [deleted]
    - xorblurb 10y ago
      The description seems curious. I'm not sure what the need for that would be? Retro-compat with existing stores/caches (but only in one direction) + mitigation against some collision attacks? hm I don't see the point. If you switch the hash function, I guess in the vast majority of cases you can switch it completely for something that is known to be really better, not a weird hack. Must fit a purpose in some Google software as a better than nothing quick&dirty temporary hack -- and I would not advice doing it in other contexts unless you know for sure you have no other choice.
      - tyingq 10y ago
        I think that's roughly it. Temporary quick and dirty mitigation for anything where recomputing existing hashes is painful.

deleted 10y ago

[deleted]

rcar 10y ago

Interestingly, Gmail labeled PDFs generated through that tool as viruses. Anyone happen to know the mechanism behind that?

deleted 10y ago
[deleted]
tyingq 10y ago
The git mailing list talked about using ubc_check() from here: https://github.com/cr-marcstevens/sha1collisiondetection/blob/40ccf5e3537ff6b2e5ceac5747f376a2ef430bec/lib/ubc_check.c https://github.com/cr-marcstevens/sha1collisiondetection/blo...
arnarbi 10y ago
See "Mitigating the risk..." at https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...

tlrobinson 10y ago

Wow, I didn't realize you could re-use the same collision to produce new colliding PDFs. And so much for Google's 90 day disclosure period.

avar 10y ago
What would be the point of a disclosure period? Nobody's going to fix SHA-1 in the next 90 days, or ever.
- tyingq 10y ago
  There is the "hardened sha-1" implementation that was released along with the sample collisions. It supposedly detects this type of attack and returns unique SHA-1 hashes. Not sure that's really a fix, but perhaps something someone would want to use short term.
  - deleted 10y ago
    [deleted]
  - xorblurb 10y ago
    The description seems curious. I'm not sure what the need for that would be? Retro-compat with existing stores/caches (but only in one direction) + mitigation against some collision attacks? hm I don't see the point. If you switch the hash function, I guess in the vast majority of cases you can switch it completely for something that is known to be really better, not a weird hack. Must fit a purpose in some Google software as a better than nothing quick&dirty temporary hack -- and I would not advice doing it in other contexts unless you know for sure you have no other choice.
    - tyingq 10y ago
      I think that's roughly it. Temporary quick and dirty mitigation for anything where recomputing existing hashes is painful.