XeonCore

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About XeonCore

  • Rank
    New User
  1. We just standardized our peer ID in Popcorn Time (quite a large amount of users use Popcorn Time, our estimates put it at around 5 million to 10 million people) so we were wondering how we got a "friendly" name put into uTorrent/BitTorrent clients for the Peer ID we use in Popcorn Time. Regards, XeonCore
  2. 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
  3. 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...