Encrypting BitTorrent to take out traffic shapers
Written by Ernesto on February 05, 2006Over the past months more BitTorrent users noticed that their ISP is killing all BitTorrent traffic . ISP’s like Rogers are using bit-shaping applications to throttle the traffic that is generated by BitTorrent.
But, at the same time two of the most popular BitTorrent clients are working together to implement header and message stream encryption in order to take out these traffic shapers.
Currently both Azureus and uTorrent included this new form of encryption (specs) in their latest Beta’s. The fact that these two clients are actively working together to implement this new feature is promising and will make this form of encryption the new standard since the users of these two clients cover the majority of all BitTorrent users.
There are two “encryption modes” available.
The 2 different payload encryption methods plaintext transmission and RC4 provide a different degree of protocol obfuscation, security and speed. Where the plaintext mode only provides basic anti-shaping obscurity, no security and low CPU usage the RC4 encryption obfuscates the entire stream and not only the header and adds some cryptographic security at the price of spent CPU cycles.
The question now is.. Does it work? and how effective is it? If it works it will definitely offer a great solution to all BitTorrent users who suffer from traffic shaping ISP’s.
Bram Cohen, the creator of the BitTorrent protocol reacted quite negatively on these new developments. He questions the need for encryption since only a few ISP’s are actively shaping traffic. Among other things he also fears incompatibility between clients and increased cpu usage. Although these arguments can be countered quite easily, developers should keep them in mind.
But the fact is, if this new encryption method is launched successfully it will be a huge step forward for the BitTorrent community.
Previously: Speed up your torrents II
Next: Opera integrates BitTorrent in their Browser
162 Responses (Add yours or TrackBack)
Pages: [1] 2 3 4 5 6 7 » Show All
Yeah, it works, I had some friends use the feature, and according to them, it got them back on using torrents effectivly.
Kiltak
[Geeks Are Sexy]Tech. News
wow you have freinds that use torrent wish my friends knew even how to switch a pc on.
Brams gone commercial
Completely worthless. I’m extremely disappointed that people who know enough to develop BitTorrent clients don’t know enough about networking to realize that this is completely pointless. Sure, encrypting the stream may get around a few packet shapers, at the moment but, unless they reconfigure BitTorrent to run everything, incoming and outgoing, over port 80 or 443 then it will be trivial to block BitTorrent.
BitTorrent is far too reliant on specific ports and far too reliant on those ports being open inbound. Because of this, it is ridiculously simple to block BitTorrent traffic. Encrypting the stream will not hide the fact that it is BitTorrent traffic. It will only prevent someone from identifying what the BitTorrent traffic is transferring. This may be a good thing for pirates but, it won’t stop the network administrator from blocking BitTorrent ports completely.
The truly successful P2P app will allow multiplexed up/downloads over SSL port 443. This will be encrypted and will appear like most other https applications. It will also traverse most any firewall and be stupidly simple for the user to operate. The down side is that it would require a centralized server to make it work so, it isn’t desireable for piracy but, I think this is also a good thing. I’m sure you’ll disagree with me on this one though because you no doubt feel that “sharing” music is your God given right and is not stealing or piracy.
Bram Cohen’s BitTorrent is doomed because it doesn’t work as well as it should (multiplexed downloads should perform far better than BitTorrent), it relies too heavily on opening obscure inbound ports, it is too hard for the average AOLer to get working, it is too easy to block.
Bram now speaks for Hollywood so it’s hard to take anything he says seriously anymore.
well george…
bittorrent may not be working as well as it should, but right now there is none witch performs better, is as reliable, is open and as simple to use to the end user…
i’d be happy if someone gets out something better…
Bram now speaks for Hollywood so it’s hard to take anything he says seriously anymore.
George,
I’m sorry to say, but you are completely ignorant when it comes to this issue.
> BitTorrent is far too reliant on specific ports and
> far too reliant on those ports being open inbound. Because of this, it is ridiculously simple to block BitTorrent traffic.
Bittorrent is reliant on no specific port at all. Your free to use any port.
> Encrypting the stream will not hide the fact that it > is BitTorrent traffic. It will only prevent someone > from identifying what the BitTorrent traffic is transferring.
Unfortunately this article is poorly written, so this line is excused. It is only the headers that are being encrypted. This prevents the data from being identified as Bittorrent traffic. The actual “stream” of data being sent is not being encrypted and doesn’t have to be.
It does work. I am with Rogers and was getting no more than 5kb/s downloads with 50+ connected seeds. Installed uTorrent 1.4 beta with encryption and last night got 50+ kb/s from only 15 seeders. Future looks bright!
You want p2p that is military grade encrypted? You want privacy for your ip? try searching MUTE and Sourceforge- btw can use any port.
Ah, stop raggin’ on Bram people. He developed this kick-ass P2P thing and he’s actively advocating NOT to use it for piracy. Which makes sense for him because I imagine he would like NOT to be sued into oblivion, yes?
But encryption is the natural next step for P2P clients. After decentralisation comes obfuscation. Isn’t it funny to see how the RIAA and MPAA with their crazy lawsuit antics are actually propelling P2P technology forward faster than ever before?
BitComet has had this feature for a while now. As for port blocking, most ISPs can’t really justify that since Bittorrent does have legitimate uses. That’d be like blocking http://FTP. Of course, it’s not too difficult to make Bittorrent run entirely over port 80, but most people just stick to the default ports. As for inbound connections, BitComet also has a method of getting around that at times (UDP NAT bypass). It’s actually a really progressive client, I’m not sure why so many people hate it for the reason of the month. Sadly, I’d give it 5:1 odds that uTorrent and Azureus implement their own version of packet encryption so it isn’t compatible with the existing BitComet standard, and BitComet will eventually have to change their implementation (just like with tracker-less downloading).
@Former Rogers Subscriber
You might think that the article is poorly written but I maybe you’re just a poor reader.
If you take a look at the “specs” link you can see that there are two encryption methods. One encrypts the header and the other one also the stream
If they get this truely working… hurrah! I remain sceptical however. I mean, it’s pretty complex stuff to get everyone working together on an encrypted network, right?
What really needs to be made, instead of going around and making sure that every single bittorrent client out there is using encryption, is a sort of local proxy for bittorrent, that would add the encryption. That way, instead of adding the feature to every client, a single proxy could be made for each OS (Mac, Linux, Windows, etc.), and from there, give users to option of sticking with whichever client they want.
For the record, I use my laptop more than anything, and Azureus is too resource-intensive for this, and, because I’m running Linux, uTorrent isn’t an option.
Any takers?
im worried about intercompatability between clients, i run a command line perl torrent program on my server half way round the world (only way i can torrent, long story). if suddenly everyones becomes encrypted, my command line torrent program is going to be left behind.
Also there is the problem of several countries laws prohibiting civilian cryptography… so torrenters would be breaking the law in more ways than one?
For linux, if you don’t want to use azureus, your best bet is probably a curses based client. I recommend rtorrent, but you can also use bittornado (which also has a curses interface and a gui interface.)
I’m not sure that RC4 is good enough.
Quoting wikipedia: “RC4 falls short of the standards set by cryptographers for a secure cipher in several ways, and thus is not recommended for use in new applications.”
Bram has done a damn good job - every program has to start somewhere and there will always be room for development.And it still works.
Also your ISP can block any port they wish if they want to.I know my ISP blocks ports already as a security precaution but currently no bittorrent ports are being blocked.
I know you can select any port that you want but if your ISP sees your port 80 with gigs of traffic they will issue you with a please explain.
In Australia most broadband companies require you to sign a AUP - Acceptable Use Policy. If you violate this they suspend or disconnect you and no appeals.
I also use a mac and exposure to PC but as it stands bittorrent is incredibly easy to use and if you dont know how too use it you will only need to be shown once and you are on your way.
Also with some of the traffic stats listed above I have seen huge amounts of connected seeds but only getting 2 k/s. Some seeders throttle or stop their uploads but still appear as connected.
Hi:
This is something that is only going to get WORSE with end-providers over time. VOIP, BT, Http server, SMTP, etc.
The real way to work around this is to setup remote VPN to a IP provider who will not do any shaping on you.
get a block of 5 IP addresses remotely, and setup your router to talk encrypted VPN to the remote site. Then your end-provider will have no idea what you are doing over this encrypted tunnel. This could also be done with a poor-mans SSH tunnel to a remote host, as well.
Anyone have any docs on how this can be done?
There will be a cottage industry of remote IP providers springing up providing native IPv4 access, me thinks, much in the same way you have NNTP Usenet providers, as well. Possibly in countries with ‘less’ regulations over IP content.
– chex
Piracy or no piracy, if my ISP kills torrent it’s bad news anyway. Take something like OpenOffice. I don’t want to wait 4 weeks to download it because my ISP is an idiot. Encryption is heavy on the computer and will cause problems when different clients communicate, but until the ISP understands that BitTorrent is a serious protocol, just like HTTP and FTP, encryption is the best solution to the problem.
So long live uTorrent and Azureus :D
I am using Rogers as my ISP and noticed my bittorrent downloads struggling to get above 10kB. I changed to BitComet, set up some router port forwarding and followed the advice I read on a number of forums (especially the BitComet forums) and was downloading at 375kB this weekend. Sweet! How long it lasts, I don’t know…but for the moment, I’m loving it.
@ Izomiac
“It’s actually a really progressive client, I’m not sure why so many people hate it for the reason of the month.”
Anyone who hates it this month is late. Comet’s problems wth allowing DHT on any torrent was a good enough reason to dislike it imo. They did fix that problem, so no reason to hate a good program, which I agree is progressive.
“I’d give it 5:1 odds that uTorrent and Azureus implement their own version of packet encryption so it isn’t compatible with the existing BitComet standard, and BitComet will eventually have to change their implementation (just like with tracker-less downloading).”
I’ll agree with you on the first comment. The major BT clients can’t really ever get their act together in terms of protocol advancement. The comment on trackerless DHT doesn’t make sense. I thought uTorrent and BC accessed the same DHT layer, and Azureus used their own. Fill me in
2 references to this post
Pages: [1] 2 3 4 5 6 7 » Show All
Add your response