v2 doesn’t realistically add anything important for functionality. sha256 is nice to have, but the chances of an actual attack on a sha1 chunk are still bafflingly remote. sha1 might be technically broken but in order to actually attack a sha1 torrent you need to generate a collision that is not only the same sha1 (which is still extremely rare and hard, only the fact that it’s proven possible at all makes it “broken”) but also within the same expected length of the torrent, otherwise any decent client should reject it for being too long, and they must reject it because otherwise they would be vulnerable to a denial-of-service attack from any bad actor who sends infinite length chunks and copyright trolls would be having a field day. I’m not a security expert but I write enough software to be fairly confident that I’m not wildly off base. In the event that somebody comes up with an actual realistic sha1 attack on bittorrent probably because of some weak/stupid client, and proves me wrong, attitudes might change quickly but I also suspect it will quickly be patched or vulnerable clients banned. If it’s pretty widespread I’m sure it will light a fire to migrate to sha256 but the actual risk remains, as far as I can tell, infinitesimal.
Until then, the v2 protocol doesn’t add anything except compatibility headaches for private trackers. I’m sure they’ll get to it eventually, but there’s no urgency and there’s not going to be unless there’s a viable attack to drive that urgency. Latest version for latest version’s sake comes with its own set of risks.
that’s not the only feature of v2. it also hels a lot with swarm merging (which with v1 only biglybt implemented), and it has updatable torrents. it also stores torrent information more efficiently and the incoming pidces can be verified immediately. afaik today torrent clients don’t verify downloaded torrents by default. qbittorent has an option, default off, to verify after a torrent completed. this is slow because everything needs to be read again from disk. I’m not totally sure about this, but I think a malicious peer could be sending crafted pieces that contain something else and you wouldn’t know it.
v2 doesn’t realistically add anything important for functionality. sha256 is nice to have, but the chances of an actual attack on a sha1 chunk are still bafflingly remote. sha1 might be technically broken but in order to actually attack a sha1 torrent you need to generate a collision that is not only the same sha1 (which is still extremely rare and hard, only the fact that it’s proven possible at all makes it “broken”) but also within the same expected length of the torrent, otherwise any decent client should reject it for being too long, and they must reject it because otherwise they would be vulnerable to a denial-of-service attack from any bad actor who sends infinite length chunks and copyright trolls would be having a field day. I’m not a security expert but I write enough software to be fairly confident that I’m not wildly off base. In the event that somebody comes up with an actual realistic sha1 attack on bittorrent probably because of some weak/stupid client, and proves me wrong, attitudes might change quickly but I also suspect it will quickly be patched or vulnerable clients banned. If it’s pretty widespread I’m sure it will light a fire to migrate to sha256 but the actual risk remains, as far as I can tell, infinitesimal.
Until then, the v2 protocol doesn’t add anything except compatibility headaches for private trackers. I’m sure they’ll get to it eventually, but there’s no urgency and there’s not going to be unless there’s a viable attack to drive that urgency. Latest version for latest version’s sake comes with its own set of risks.
that’s not the only feature of v2. it also hels a lot with swarm merging (which with v1 only biglybt implemented), and it has updatable torrents. it also stores torrent information more efficiently and the incoming pidces can be verified immediately. afaik today torrent clients don’t verify downloaded torrents by default. qbittorent has an option, default off, to verify after a torrent completed. this is slow because everything needs to be read again from disk. I’m not totally sure about this, but I think a malicious peer could be sending crafted pieces that contain something else and you wouldn’t know it.
https://torrentfreak.com/libtorrent-adds-support-for-bittorrent-v2-a-potential-game-changer-200912/
Did not know that. This would be a very a useful feature.