Minor problems? Isn't this a security issue? Somebody can modify a binary and still have it return the same hash and distribute it to people who think that they are receiving an authentic file. Is it even an option to keep going with SHA1? Even Git, which this is less of an issue, has a plan for migrating to SHA2. https://git-scm.com/docs/hash-function-transition/

This isn't really true, sha1's weakness would require you to be the creator of the torrent, which if you are, you can just make the binary malicious to begin with.

The issue is that you can change it later on - after people have reviewed your torrent, breaking the immutability property of bittorrent.

I'm not an expert here, but I'm thinking about it like this:

Creating a SHA-1 collision is doable, but it's still hard. If you want to serve someone a malicious piece of data, that's already one hash of the two colliding hashes that you've used up. Now you have to create harmless or "benevolent" data that collides with the hash of your malicious data so that you can create a positive reputation for your file from users who aren't your targets. That way, when your target inevitably goes to download the file, you wrestle into the protocol with a lot of speed and/or nodes, and you serve the malicious data to your target instead of the data you've been serving to everyone else.

If you don't need the positive reputation, and someone will just download and run whatever you put in the torrent, you don't need the collision in the first place.

It sounds like the perfect scenario for movie companies to target pirates.

if you feel like using centuries of computer time per torrent that nobody will download.

because you can create two hashes that match, but you cannot create a hash that matches an arbitrary hash you do not control.

That is a much more serious weakness called a "second pre-image attack"

So, as I understand, that's expected to happen in foreseeable future. Otherwise, why switch from SHA1 if you can't create a collision with unaltered data?

It is not expected to happen in the foreseeable future, MD5 for instance hasn't broken in a second pre-image way, more than a decade after it was known to be weak.

This class of attacks is MUCH harder to construct against a cryptographic hash.

Then, why did BitTorrent work on such a costly change if it's not vulnerable against it?

For the purpose of operating a bait and switch on the files, the torrent creators controls the two hashes somewhat, so it's an easier to pull attack.

If you have control over the bait, I don't understand the reason to switch at all. Just make the bait evil and be done with it?

I don’t know much about protocol version pacing, but was lack of substantial changes part of the reason it has taken 12 full years to get a client to support v2?

http://bittorrent.org/beps/bep_0052.html

3 years, not 12. BEP 52 was based on BEP 3 and kept the same metadata, including the creation date.

http://bittorrent.org/beps/bep_0003.html

No. It is still a draft proposal.

If a couple major players adopt a hybrid system then it could perhaps

libtorrent backs a number of popular clients (Deluge, qBittorrent), so that's a good start.

From the perspective of the client would it be a drop in replacement like changing a static library or a from the ground up rework?

If they used libtorrent, then it would be easy. If they wrote their own system, then it would require a moderate amount of work to chance to v2.

I am going to take a guess, Most people on Mac would be using transmission, and People on Windows would be using Classic Utorrent.

Both are not based on Libtorrent.

uTP seemed like a small improvement to me but it happened.

It's backward compatible.

The use of SHA-1 in v1 seems like a major problem.

[edit]

That doesn't imply that BTv2 is the right successor protocol.

It’s not currently - collisions are very expensive and only in limited contexts. If you wanted to distribute malware via torrents your efforts are better spent elsewhere.

Attacks only get better with time.

Also, this seems quite bad: https://en.wikipedia.org/wiki/Collision_attack#Chosen-prefix...

That attack isn't relevant to bittorrent swarms. What you want is a preimage attack on SHA1.

Yeah this definitely feels like a Python 2/3 type situation. They solved one minor issue but require the whole world to update.

I'm not even convinced they couldn't have done it in a backwards compatible way. Why not stick with SHA-1 but also add SHA-256 for verification for clients that support it?

> Why not stick with SHA-1 but also add SHA-256 for verification for clients that support it?

Apparently you can do that with 'hybrid' magnet links.

The problem is the two swarms are different so as more people move over to v2 the v1 swarms will become smaller and smaller -- thus giving people an incentive to upgrade, I suppose.

...and they seem to have solved more than one minor issue since they were breaking things anyway...

Surely people will just sit in both swarms?

That's an interesting comparison, given that the first BitTorrent client was written in Python (2).