Utorrent And Bittorrent Difference
Fonda Stacer
I'm in the middle of implementing my own dht for internal cluster. Since it will be used in file-sharing program like bittorrent, "Mainline DHT" was the first thing I was look at. After that I found "entangled" (python, dht using twisted matrix), congress (python, dht using pyev + libev) and of course original "kademlia".
2) mainline DHT and entangled use dynamic buckets. On start they have just 1 bucket covering whole space. After it will be filled with 8 alive nodes, bucket will be splitted to 2 new. But ONLY if our own id inside that bucket. If it is not -- bucket will be never splitted. So, soon we will have 160 closest to us buckets and few other.
congress and kademlia treat bucket bundaries as "minimum distance from us" and "maximum distance from us". So, our own ID will be ALWAYS in bucket0. Maximum 2 other ids in bucket1 (because it covers 2*1
The kademlia paper actually calls out the optimization of dynamically splitting buckets as the routing table grows. There is no logic difference between these two approaches, it's just an optimization to save some space. When implementing a fixed full sized routing table, you have to find k nodes to send requests to. If the bucket your target falls in is empty, or has fewer than k nodes in it, you have to pick from neighboring buckets. Given that, have the closest bucket to you not be split in the first place, makes that search simpler and faster.
as for your point (1), I think you may have misunderstood kademlia. The routing table bucket boundaries are always relative your own node ID. And the ID space the buckets span double for each bucket further away from you. Without this property (if, say each bucket covered an equal range of the ID space) you would not be able to do searches properly, and they would certainly not be log(n).
I'm downloading an .iso file that is offered through the main website, which recommends users to use BitTorrent. In addition, they offer the download via HTTP using different mirror sites that belong to different countries, and they claim that the downloads from an HTTP mirror are more prone to be intercepted to serve malicious downloads. I'm curious as to why these kinds of downloads would be more prone than the original downloads.
Furthermore, if the circumstances allow, HTTP is susceptible to a Man-in-the-Middle attack. Meaning, from your end it looks like you are connected to example.com, but actually you are connected to a third party which is intercepting the traffic, manipulating the network traffic, and only making it look like you are connected to example.com. You then request to download a certain file, but the attacker sends you a malicious file instead. (On a side note, correctly configured HTTPS, with S, prevents this.)
A file that is transmitted via BitTorrent, on the other hand is first divided into chunks. Each of those chunks is then hashed using SHA-1, i.e. a checksum is generated, by the torrent creator. The hashes are given to each BitTorrent client prior to the download - usually contained in a .torrent file. As the file chunks are then downloaded by the client, they are first hashed by the client itself, and compared with the previously received hash. Only if the hash matches, meaning that the chunk contains exactly the same bytes as the expected chunk, is it accepted. It is a practical impossibility to manufacture altered chunks that have malicious content, but retain their original hashsum.
Since these hashes are shared with you prior to the download, presumably from a trusted source, it is harder (to impossible) to manipulate the expected files in transit when received via BitTorrent compared to a HTTP download. The provider can distribute the torrent, which is a small file, from a single secured server via HTTPS under his own control, and the hashing mechanism will provide a validation for the actual download.
If on the other hand, your hashes or torrent file are tampered with prior to the download, or due to a MitM attack if downloading the torrent itself via HTTP, then the checksum validation offers no security.
Lastly, there is a way how the checksum mechanism can be circumvented by an attacker if he has access to the file prior to the hashsum generation, i.e. prior to the original creation of the torrent. It is then possible for an attacker to modify the file in such a way that some of the file's content can later be substitute with pre-engineered code during transmission of the torrent without being detected by the SHA-1 hashsum check, despite being different to the file that was originally checksummed.
If the adversary is trying to trick you into getting a malicious document, what's the difference between downloading the document via HTTP vs. downloading the document via BitTorrent using the .torrent file?
With HTTP, the power to intercept your internet connection is enough for the adversary to fool you into accepting a malicious forgery. This is because HTTP does nothing whatsoever to verify authenticity of data received on the internet: it is like a particularly naive clerk who lets the guys in high-visibility vests into the secret control room because they said they had a job to do.
With HTTP, the power to run a mirror is enough for the adversary to fool you into accepting a malicious forgery. They just serve you the forgery when you ask for it, and you have no way a priori to distinguish the forgery from the real document.
This may sound like a weird power to worry about, but consider how modern software development has evolved from the Stack Overflow style of copypasta to a cavalier reliance on npm packages like left-pad. The maintainer of a package like event-stream may tire of the task and sell ownership of the package name to an unsavory character who now has the power to influence what goes into newer versions of deployed software packages like an OS image you might distribute by BitTorrent. (More on games one can play with this power: [1], [2].)
Your assumption that this claim is true is flawed. They are both susceptible to interception. One could claim that BitTorrent is less so since it's decentralized, but simply downloading the .torrent manifest is enough to reconstruct what requests you will make to other peers anyway.
At least .torrent files have a cryptographic hash calculated over them to protect against corruption. This doesn't really support the assertion in your question though, because if this .torrent is served over HTTP, then it's equally susceptible to being manipulated over the wire.
As discussed in other answers, .torrent files contain a cryptographic digest of the file data. This means that they are as trustworthy as the files they describe, no more or less. (The hash function is SHA-1, so collision attacks are possible, but a collision attack requires that the files themselves be maliciously generated or modified, and I would say that the files and the .torrent are both equally untrustworthy in that case.)
The advantage of the .torrent file is just that it's much smaller. Web sites that provide Linux installation images and the like generally can't afford to serve disk images to everyone for free. When they do provide the option to download them directly, it's usually donated bandwidth on third-party servers that they don't control. In contrast, they can afford to provide .torrent files to everyone from their own server, which they may have better reason to trust.
If you download an image from a random third-party server (even if it's not an official mirror), and compute a cryptographic digest (ideally SHA-256 or better) of the image, and it matches the published digest on the official server, that's just as good from a security perspective as using a .torrent file downloaded from the same official server over the same protocol. If that protocol is really HTTP (as opposed to HTTPS), then both options are pretty insecure, but neither one is significantly worse than the other.
That's rather common, e.g. gaming services like Battle.net used to "steal" bandwidth by making their downloaders (unconscious) uploaders. Debian explicitly mentions reduced bandwidth usage on their servers as reason to use bittorrent.
Yes, BitTorrent has a reasonably secure mechanism to ensure you get what you're supposed to get. However, you're still downloading that torrent file via HTTP--if you're going to be MITMed they can just replace the torrent file with one that points to their malicious content.
uTorrent and BitTorrent are two veteran clients with huge, loyal followings. But what makes one better than the other? Is it a greater variety of settings, or a richer package of features? Maybe speed or practicality is the deciding factor?
While uTorrent and BitTorrent are in fact very much alike, there are some key distinctions between the two. This article will help you understand the similarities and differences, so you can make an educated choice.
While researching the differences between uTorrent and BitTorrent, we went the extra mile and actually tested the best VPNs that work with both. I got the best results with ExpressVPN thanks to its P2P-friendly servers, excellent performance, and strong privacy features. More importantly, you can test ExpressVPN completely risk-free for 30 days to see if it's right for you. Editors' Note: Transparency is one of our core values at vpnMentor, so you should know we are in the same ownership group as ExpressVPN. However, this does not affect our review process.
1. Size: uTorrent is much lighter than BitTorrent. At less than 1 MB, uTorrent is much less taxing on your operating system than many other torrenting clients. By comparison, BitTorrent is almost 3 MB.
As we've already said, when it comes to speed, there isn't a real difference between uTorrent and BitTorrent, and the same is true for your Android device. The two clients even have the exact same rating in Google Play (4.5 stars).
c80f0f1006