Yes, there isn't much. The two files have PDF headers; so I presume they were messing around with some PDF exploit experiments? or signed PDF documents?
I wonder if we'll get more information; or if they're holding back until people take it seriously and attempt to get off SHA-1 for critical stuff?
Asking the liklihood is kind of the wrong question.
The problem with sha-1 is the possibility that a malicious person could intentionally make two files with the same hash (in order to do evil). The probability of this happening if someone decides to do it and has sufficient resources to pull it off, is 1. The probability of it happening accidentally hasn't changed and is so small it might as well be 0.
UUID don't "collide", they're just the same, or not.
They're not generated from any business relevant input, there is nothing to "confuse" in the first place, and the whole concept of uuid "colliding" doesn't make sense.
v5 UUIDs are generated from SHA-1 hashes of their input, so they can collide in exactly the same way a normal SHA-1 can collide: two different inputs yield the same output.
But even for v4 (randomly generated) UUIDs, I would say "collide" is appropriate, if you're asking about the chance of two or more randomly generated v4 UUIDs colliding is. (That is, generating the same UUID twice. Infinitesimal, but the use of "colliding" to ask is still valid.)
Yes. It also isn't the "second" sha-1 collision, by any means -- you could already trivially use the prefix and colliding blocks from the shattered example and append any suffix you want to generate more collisions: https://news.ycombinator.com/item?id=13723892
A true second collision wouldn't start with the same 320 bytes. A more interesting one might use fewer bits to achieve the collision.
Once the two sha1 states are synchronized, after the first 320 bytes, they will remain in sync as long as you extend them with the same data. (BTW This is why hmac exists, to prevent extension attacks.)
It doesn’t get mentioned enough: this is with the exact same filesize.
Most collision mitigations (such as git’s) revolve around using hash combined with filesize as a collision is inevitable, but a collision with the same filesize is much harder.
27 comments
[ 3.3 ms ] story [ 70.9 ms ] threadI wonder if we'll get more information; or if they're holding back until people take it seriously and attempt to get off SHA-1 for critical stuff?
Authors home page is here: https://phor.net/
Has anyone seen a collision happening in the wild? What's the likelihood? Vs UUID?
The problem with sha-1 is the possibility that a malicious person could intentionally make two files with the same hash (in order to do evil). The probability of this happening if someone decides to do it and has sufficient resources to pull it off, is 1. The probability of it happening accidentally hasn't changed and is so small it might as well be 0.
They're not generated from any business relevant input, there is nothing to "confuse" in the first place, and the whole concept of uuid "colliding" doesn't make sense.
v5 UUIDs are generated from SHA-1 hashes of their input, so they can collide in exactly the same way a normal SHA-1 can collide: two different inputs yield the same output.
But even for v4 (randomly generated) UUIDs, I would say "collide" is appropriate, if you're asking about the chance of two or more randomly generated v4 UUIDs colliding is. (That is, generating the same UUID twice. Infinitesimal, but the use of "colliding" to ask is still valid.)
First one, for reference: https://shattered.it/
https://www.schneier.com/blog/archives/2012/10/when_will_we_...
A true second collision wouldn't start with the same 320 bytes. A more interesting one might use fewer bits to achieve the collision.
https://imgur.com/a/uZttSbD