Search Slyck  
BitTorrent End to End Encryption and Bandwidth Throttling - Part I
February 6, 2006
Thomas Mennecke
Font Bigger Font Smaller
No one will ever take away the enormous contribution Bram Cohen has given to the file-sharing community. Much like the revolution of file-sharing under Napster in 1999, BitTorrent has redefined the way people share and search for information. Initially, BitTorrent evolved largely under the direction of its creator. More recently however, this protocol is shifting further away from the direction of Bram Cohen and more towards independent developers.

One of the key focuses currently facing members of the BitTorrent community is traffic shaping (or bandwidth throttling.) Since its inception, BitTorrent has become the unquestioned consumer of bandwidth, as CacheLogic reports over 60% of all Internet traffic is attributable to this protocol. Some ISPs have simply reinvested in their networks and allowed BitTorrent to flourish, while others report that Shaw Cable and Rogers Cable in Canada have made their BitTorrent experience excessively slow and intolerable.

In response, BitTorrent developers have introduced “end to end” encryption in an effort to counter these policies. By fooling traffic shaping software, this has become very welcomed news from those who experience bandwidth throttling. Interestingly enough, Bram Cohen, the founder of BitTorrent, has not supported this direction. Yet as the course of BitTorrent evolution changes, the needs of the populace are instead being addressed by community oriented developers.

In today's interview, Slyck speaks with the developer of µTorrent, Ludvig Strigeus, with additional information provided by the administrator of daily operations, "Firon." First and foremost, how effective has this feature proven to be?

µTorrent: I don't really know how effective this option is yet, it's only been tested in a limited environment. We haven't been able to do any significant tests with users of ISPs that shape. But so far, it seems to be helping shaped users in swarms that have PE-enabled clients. What is your motivation and philosophy behind this feature? Why are you working on it and what do you hope the benefit for the BitTorrent community will be?

µTorrent: I'd like all users to be able to use BitTorrent and be able to upload and download. After all, BT is being used in many legal things, including distribution of public domain content, patches for games, and so on. An ISP shouldn't be able to block a legitimate protocol. Could you spend a moment to explain how end to end encryption works?

µTorrent: The encryption uses a shared secret (the torrent info hash), which is different for each torrent, in combination with Diffie-Hellman keys that are generated when the connection is set up. The Diffie-Hellman helps minimizing the risk of passive listeners, and the shared secret helps avoiding man-in-the-middle attacks. Recently, Bram Cohen brought up several arguments against end to end encryption. What is your reaction to these arguments, and how valid do you believe they are? Do you think perhaps they are being made to further his effort to make BitTorrent more legitimate?

µTorrent: I don't really agree with his arguments. He seems to be a bit out of touch with the reality of the situation. There's a significant number of severely throttled users (or that have BT blocked outright)out there, and ISPs need to realize that the internet is not port 80, 443 and e-mail. Very, very few ISPs cache BT, even less so than those that shape, so that's a fairly lousy argument to counter encryption.

His argument to let the tracker handle which peers are PE-enabled isn't very good either, since it's trivial for an ISP to block or alter the tracker request/response to achieve their desired effect of saving bandwidth because they can't cope with non-HTTP traffic. And one of the main problems with ISPs that shape is that they don't shape reasonably (say to maintain network quality and not interfere with VoIP or some such), but always throttle it down to a grinding halt. This is unfair, and users should be able to use the bandwidth they paid for. How dynamic is your approach to end to end encryption? For example, will you be able to maintain a likely technological arms race with ISPs?

µTorrent: If some severe flaw were discovered with PE, it would be significantly easier for us to update the clients with a fix than it would be for an ISP to update their hardware/software to detect any such changes we make. Bram Cohen stated "Most ISPs don't do such shaping", yet the reaction from Shaw and Rogers broadband customers reflects differently. How many other ISPs do you know of shape traffic, and do you believe that the number will increase in months and years to come?

µTorrent: I think he's wrong, a significant number of Canadian users seem to be shaped, and there's various ISPs in Singapore doing similarly.

There's ISPs in the US, Israel, and Australia, Belgium, and many others (some are listed on Azureus'wiki). It seems to be a growing trend, since the list of ISPs that users report are shaping seems to be growing. Is the encryption static or is it dynamic (does it change according to some parameters)?

µTorrent: The parameter that changes per-connection is the Diffie-Hellman key. The info hash also influences the encryption, but it's not different for each connection (obviously). What has been the feedback from end users? For example, are people complaining the decryption of Diffie-Hellman is resource hungry?

µTorrent: We have not had any feedback yet. The amount of resources for Diffie-Hellman is quite small, we're talking much less than a percent of CPU time for normal users. The data stream is encrypted with RC4.

My Pentium 4 can encrypt at 300MB/s (with optimized assembly code), so even if you download at a very fast speed, the RC4 encryption would just use a percent or two of CPU time, which is much less than the time required to compute SHA hashes of all downloaded pieces. Encryption is a tool better known for securing the transfer of private information. Are there any benefits of securing the transfer of information that is being offered publicly, or is the encryption soley to circumvent ISP throttling?

µTorrent: The major goal of the protocol was to circumvent throttling, however it was designed with the idea in mind, that it should be hard for a passive listener to detect what traffic is transmitted. By encrypting the data, is there a risk BitTorrent will lose some of its acceptance, hence encouraging more ISPs to throttle?

µTorrent: I don't know, did HTTP lose acceptance when HTTPS was invented? I don't think so.

Like the eDoneky2000 network, BitTorrent’s control and direction is slowly morphing towards the open source community. MetaMachine, the original creative force behind eDonkey2000 has seen the direction of this network forever replaced by eMule. This evolution of events is nearly impossible for original talents to reverse, and the future of BitTorrent is little different.

This story is filed in these Slyck News categories
BitTorrent :: BitTorrent Clients
File-Sharing/P2P Related :: Reviews
File-Sharing/P2P Related :: Interviews

You can discuss this article here - 64 replies

© 2001-2019