pallas Posted August 5, 2014 Report Share Posted August 5, 2014 SHA-1 is showing signs of weakness, and given magnet links, there's a greater risk that collisions could be used to spread malware by organized crime, if a practical SHA-1 collision is discovered. Migrating to SHA-3-224 would provide a decent security margin. Link to comment Share on other sites More sharing options...
Harold Feit Posted August 6, 2014 Report Share Posted August 6, 2014 Given the age of the protocol and the setup of .torrent files, coupled with the additional requirements beyond just content to cause a collision (specific known characters in infohashes coupled with the known piece sizes for actual piece data) a collision within a torrent is measurably harder to generate than a general sha-1 collision. Additionally, the .torrent metadata and identifier structure would cause a major compatibility break by changing hash algorithms. Link to comment Share on other sites More sharing options...
pallas Posted August 6, 2014 Author Report Share Posted August 6, 2014 Given the age of the protocol and the setup of .torrent files, coupled with the additional requirements beyond just content to cause a collision (specific known characters in infohashes coupled with the known piece sizes for actual piece data) a collision within a torrent is measurably harder to generate than a general sha-1 collision.Additionally, the .torrent metadata and identifier structure would cause a major compatibility break by changing hash algorithms.That's true, in the case of bittorrent, the difficulty is probably 2^10 harder. But I disagree with major compatibility break. Just call this version N of the bittorrent protocol. There is plenty of time for people to slowly upgrade. And besides, it encourages people to use the version of bittorrent that includes advertisements. Link to comment Share on other sites More sharing options...
XeonCore Posted November 3, 2014 Report Share Posted November 3, 2014 That's true, in the case of bittorrent, the difficulty is probably 2^10 harder. But I disagree with major compatibility break. Just call this version N of the bittorrent protocol. There is plenty of time for people to slowly upgrade. And besides, it encourages people to use the version of bittorrent that includes advertisements. Its not that straightforward. The hashing isn't something implemented directly in the BitTorrent protocol but something implemented in the .torrent file format. Sadly, the location in the file format that hashes are stored isn't directly extendable without breaking every client that doesn't support SHA-3 hashes. It might be possible to implement an extension to the format but it would be more of a hack than an upgrade and I'm sure there are already enough "hacks" out there, we don't need another. At the end of the day the only thing you would achieve in colliding piece hashes would be a corrupt file at the end, which doesn't really gain you much considering the trouble you'd have to go to in the first place to find the collision. The hashing in torrents isn't designed to be a proof of authenticity, its suppose to be a simple check to make sure you've received a chunk of a file correctly. Ideally there should have been a place for an overall hash to be stored for each file. This would thwart any attempt at tampering with a file because it would be almost impossible to generate a piece that has the same hash by itself, but also hashes to the same hash when hashed as part of the overall file. Even if you could collide a piece so that it had the same hash, once that piece was incorporated into the entire file and you hashed the overall file, the hash wouldn't match. (Note: This wouldn't be of much use apart from an indicator that someone has deliberately tampered with a chunk as you have no way of determining which chunk was tampered with in the file. The only resolution would be to download the entire file again) I will say however that you have probably managed to stumble across one of the many "security" flaws in the current way BitTorrent works. The only real use case for this sort of attack would be one that was deliberately designed to disrupt a swarm. Take the following scenario for example: - A creates a torrent of content X and shares the torrent on notorious torrent site.- B wishes to download said content and starts the download- C doesn't like that content X is being shared on the internet (lets say its copyrighted material or whatever)- C manages to compute a hash collision for a chunk of content X- C seeds content X with modified chunk in it to peer B- B now has content X with modified chunk from peer C- D now want content X too and receives modified chunk from peer B or C--- Etc. Etc. Because of the shared nature of BitTorrent and the fact that a modified piece can't be detected eventually the modified version peer C is seeding will propagate throughout the swarm and could lead to the modified version of content X being the version that has the majority of seeds behind it. Peer C has now successfully disrupted the swarm for content X because any use of it is most likely going to end up useless as you will have a corrupt file. Whilst this may seem farfetched and I haven't really heard of any in the wild cases, its most certainly a valid, easy and reasonably cheap way to disrupt the distribution of content via BitTorrent. Until I see an example of it tho, I'm gonna put it in the "theoretical" bin as it seems a little difficult to pull off... Link to comment Share on other sites More sharing options...
pallas Posted December 16, 2014 Author Report Share Posted December 16, 2014 http://arstechnica.com/tech-policy/2014/12/sony-fights-spread-of-stolen-data-by-using-bad-seed-attack-on-torrents/?q=1 well, no protocol should be used longer than ten years anyway Sadly, the location in the file format that hashes are stored isn't directly extendable without breaking every client that doesn't support SHA-3 hashes.That way, everyone has to upgrade to the latest version of bittorrent, the one with ads. Link to comment Share on other sites More sharing options...
XeonCore Posted December 29, 2014 Report Share Posted December 29, 2014 http://arstechnica.com/tech-policy/2014/12/sony-fights-spread-of-stolen-data-by-using-bad-seed-attack-on-torrents/?q=1 well, no protocol should be used longer than ten years anyway That way, everyone has to upgrade to the latest version of bittorrent, the one with ads. That article is misleading in the fact that they didn't break the hash algorithm. All that Sony did was flood the swarm with random data that when the peer downloaded failed a hash check, so they discarded it and tried again. Sony setup thousands of "seeders" doing this so it slowed down the spread of the torrent a lot, not due to real "fake pieces" like I detailed above, but by causing clients to have to continuously redownload pieces. You do realise uTorrent/BitTorrent aren't the only torrent clients on the internet? Why does BitTorrent get to decide that everyone has to use SHA3? All they'd end up doing is limiting their potential peers, which would then just make their own clients slower. Whilst I understand SHA-1 is an older hash algorithm, it has yet to be used to create collisions, and even when they do, we are a long way away from being able to create them whenever we want so we can disrupt the BitTorrent network Link to comment Share on other sites More sharing options...
GregoryPSmith Posted February 23, 2017 Report Share Posted February 23, 2017 Relevant: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html Link to comment Share on other sites More sharing options...
Harold Feit Posted February 23, 2017 Report Share Posted February 23, 2017 There are a lot of factors in the BitTorrent protocol that make such collisions not actually possible within the protocol including but not limited to the known hash segment length. If those collisions aren't same-length or known-content aware, they are not relevant to BitTorrent. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.