7 ms·
None of what you mentioned is affected since this is a collision attack. They purposely created 2 files with the same hash. Creating a file with the same hash
by fivesigma 10y ago
None of what you mentioned is affected since this is a collision attack. They purposely created 2 files with the same hash.
Creating a file with the same hash as legit file is a preimage attack and is much more difficult to perform (many orders of magnitude more difficult).
This still doesn't mean that SHA-1 isn't dogshit however. It should have been phased out years ago.
- anilgulecha 10y agoCreate 2 torrents with the same hash. Release one into the wild. Wait. Infect.
- koolba 10y agoTorrents have a tree of hashes for the parts. That allows validating pieces without the entire file (which is also validated at the end). Probabilistically, the hashes of the parts would not match even if the top level hash matched.
- anilgulecha 10y agoThe initial torrent metadata is pulled from nothing but the first hash. This is the point where the rest of the data forks.. someone gets the movie, another gets the .exe.
- koolba 10y agoThat's not an issue with the torrent. That would be with the magnet link format. Also, and more importantly, this isn't a preimage attack so replacing an existing torrent's SHA-1 hash with a malicious one isn't computational possible.
- anilgulecha 10y agoMagnet URI hash is SHA1. A hash collision can still be used as an attack if you create 2 torrents with the same hash and then distribute.
- koolba 10y agoThat's not an issue with the torrents. It's an issue with the magnet URI format for referncing torrents. The "good" torrent would not be susceptible to attack via this receiving the entire torrent file directly (say over HTTPS) is fine.
- anilgulecha 10y agoTorrent files have been deprecated for a while. Magnet URI is the the preferred/default method of sharing. TPB did this in 2012[1]. [1] https://torrentfreak.com/the-pirate-bay-dumps-torrents-120228/ https://torrentfreak.com/the-pirate-bay-dumps-torrents-12022...
- koolba 10y agoLooks like it's time to update the magnet link format to use a newer hash.
- pgeorgi 10y agoYou 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. Then join the torrent with a client that doesn't download but only upload that block (there will be some that will pick it from you). Many legit copies, except for those that were so unlucky to fetch the block from you. If you manage to build such a block based on one in recurring content (eg. a distributor's logo at the beginning of the file), it could be reused, too.
- koolba 10y ago> 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.
- pgeorgi 10y agoOne of the good parts of doing it at the leaf hashes over the top level hash as proposed further up the thread is that quicktime/avi/etc are much more amenable to carrying some "junk" data than trying to figure out two colliding merkle tries with the same hash.
- jakeogh 10y agoOn the other hand it's useful for denial of service. If you want to disrupt a swarm feeding it bad data is 'good enough'.
- koolba 10y ago> 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 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.
- rakoo 10y agoIt's technically true to speak of a tree, but it's less misleading to say it's a list
- fivesigma 10y agoThis requires the addition of random garbage in the first file which someone will detect anyway. Why not release an infected file with a timebomb malware instead of colliding SHA1? Much cheaper. Still, none of this allows you to attack an already existing torrent.
- hvidgaard 10y agoIt was broken 12 years ago, so no serious software that require cryptographically secure hash functions should use it.
- mike_hearn 10y agoanilgulecha is correct. Consider the following attack: You wish to undermine the security of an important codebase managed by git. You write a valuable and useful contribution to the code. You also create another version of the commit that has the same SHA-1 as the first, which breaks the security of that code. You submit the first commit, it is accepted and merged. Now you wait for your target to do a git clone on the repository, perhaps because it's a build environment. You then MITM it (e.g. using infrastructure like QUANTUM INSERT) and redirect the clone to your own git server, which serves the bad commit. The target compares the top commit hashes of what it expected to get and what it actually got, and is none the wiser. They now compile the code and produce a backdoored binary.
- rocqua 10y agoYou need enough leeway in the first commit though. As this is a collision attack, you need to be able to tweak both commits in order to get their hashes to collide. The mangling in the first commit is probably going to look mighty-suspicious. You might be able to handle this if you get to mangle e.g. code comments. In any case, you need something similar like PDFs malleability where you can change one document without the change being noticeable.