[koolba]

Torrents 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.

[pgeorgi]

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.

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]

> 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.

[Natanael_L]

If you created the original torrent then you can do it

[jakeogh]

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'.

[koolba]

> 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.

[jakeogh]

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?

[koolba]

Yes that's my understanding of it. In the PDF example on the site, the file format allows enough tweaking to the raw data without impacting the content to make it feasible.

[pgeorgi]

One 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.

[anilgulecha]

The 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]

That'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]

Magnet 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]

That'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]

Torrent 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-12022...

[koolba]

Looks like it's time to update the magnet link format to use a newer hash.

[rakoo]

It's technically true to speak of a tree, but it's less misleading to say it's a list