> In practice, collisions should never occur for secure hash functions.
That is mathematically impossible when reducing an N bit string to an M bit string, where N > M.
All hashes have collisions; it's just how hard are they to find.
Announcing the first SHA-1 collision
211–220 of 524 posts
Re: Announcing the first SHA-1 collision
#212Earlier quoted context omitted.
You could just do this with a video you release anyways, and skip the century of GPU runtime. This break requires you control/generate both the original and the evil file.
My thought exactly, although you would need your malware to incubate for some time to allow it to spread properly first.
Couldn't you get nearly the same intermittent-attack behavior just by saying something like "break out of codec, only do malicious behavior one time in 1,000"?
Re: Announcing the first SHA-1 collision
#213Earlier quoted context omitted.
You could have a buffer overflow attack talking advantage of a specific popular video player out there. Since video players are usually not very security focused, someone determined could do it. And since video torrents are unzipped, a single chunk can be replaced with the malicious chunk with the attack code. It can look like a tiny jitter depending on the chunk size/total video size.
You could just do this with a video you release anyways, and skip the century of GPU runtime. This break requires you control/generate both the original and the evil file.
Yep, and even if you feel the need for low-frequency attacks to keep seeding high, you could probably just fix a low chance of actually executing malicious behavior.
Re: Announcing the first SHA-1 collision
#214Earlier quoted context omitted.
> You could (try to) collide one of the blocks at the end of the tree. The tree of hashes will still be the same since the hash of the block didn't change. Except you can't do that as this isn't a preimage attack. You can't create an arbitrary bad file matching an existing SHA-1 with this.
On the other hand it's useful for denial of service. If you want to disrupt a swarm feeding it bad data is 'good enough'.
> On the other hand it's useful for denial of service. If you want to disrupt a swarm feeding it bad data is 'good enough'.
No you can't do that either. Again, this is not a preimage attack: https://en.wikipedia.org/wiki/Preimage_attack
That means you can't use this to match an arbitrary SHA-1. That means you can't use it to generate bad parts of a larger file.
What you're describing is already possible by having clients connect to a swarm, pretend they have parts of a file, and send gibberish. The receiver won't know until they finished downloading the part and hence waste the part-size in download capacity (i.e. DOS). I bet with IPv6 it'd be really easy to have a single malicious client pretend to be a world of swarm members.
Re: Announcing the first SHA-1 collision
#21510 million GPUs is not insane when you have a billion dollar security cracking infrastructure budget. Especially when you compare it to the rest of the cyber warfare budget.
Re: Announcing the first SHA-1 collision
#216Seeing how they ridicule MD5, I think they should have spent a bit more time on the proof PDFs, and have their MD5 digests collide also.
Re: Announcing the first SHA-1 collision
#217Earlier quoted context omitted.
On the other hand it's useful for denial of service. If you want to disrupt a swarm feeding it bad data is 'good enough'.
> On the other hand it's useful for denial of service. If you want to disrupt a swarm feeding it bad data is 'good enough'. No you can't do that either. Again, this is not a preimage attack: https://en.wikipedia.org/wiki/Preimage_attack That means you can't use this to match an arbitrary SHA-1. That means you can't use it to generate bad parts of a larger file. What you're describing is already possible by having cli…
Thanks, so it can gen 2 same size colliding chunks, but it can not take an arb chunk and generate a collision for it. Right?
Re: Announcing the first SHA-1 collision
#218One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…
this isn't quite true, bittorrent have checksums for each piece in the torrent, I not saying its impossible to do but its significantly harder than just finding 2 files with the same hash.
Okay, so the challenge gets broken down into creating a single piece that hides the malware. Even better really, I can join the network with a fleet of hosts all sharing that particular piece at a very high rate- but it's my bad version of it. Those hosts can focus on just distributing the malware, rather than the whole file.
Re: Announcing the first SHA-1 collision
#219Earlier quoted context omitted.
Git stores the files as so-called blob objects, they're prefixed with a simple header. So even if sha1(file1)==sha1(file2), your git will still get different hashes, because it's doing sha1(prefix+file1), sha1(prefix+file2). You'd need a file that collides with this prefix. This is certainly possible, but not sure if it may mean you need to pay for that several thousand cpu/gpu cluster google used to make it feasible…
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?)
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.pdfRe: Announcing the first SHA-1 collision
#220Earlier quoted context omitted.
Git stores the files as so-called blob objects, they're prefixed with a simple header. So even if sha1(file1)==sha1(file2), your git will still get different hashes, because it's doing sha1(prefix+file1), sha1(prefix+file2). You'd need a file that collides with this prefix. This is certainly possible, but not sure if it may mean you need to pay for that several thousand cpu/gpu cluster google used to make it feasible…
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?)
[deleted]