What I Just Learned About BT Encryption

For the longest time I had thought that BT encryption only encrypted the Headers of the packets. I found out today, to my elation, that the current clients (like utor 1.7) encrypt not onlye the header but also th message of the packet. It seems that header-only encryption has been outdated long ago. :unsure:

I was surprised, and my sense of BT security dramatically increased... my ISP can't monitor me :-). For the longest time I had thought the contrary. Anyway, I just wanted to share with you guys the relief I felt when I found this out. :)

Happy (free)leeching, Comcast users!

Quote:

---

Originally Posted by anak

For the longest time I had thought that BT encryption only encrypted the Headers of the packets. I found out today, to my elation, that the current clients (like utor 1.7) encrypt not onlye the header but also th message of the packet. It seems that header-only encryption has been outdated long ago. :unsure:

I was surprised, and my sense of BT security dramatically increased... my ISP can't monitor me :-). For the longest time I had thought the contrary. Anyway, I just wanted to share with you guys the relief I felt when I found this out. :)

Happy (free)leeching, Comcast users!

---

Yes...I read about this too and started using the setting. Works great! Trackers should start requiring it...IMHO.

what about version 1.6.1?

The key is to get everyone to do it...

Does µTorrent support Protocol Encryption (PE)?

Yes, as of version 1.4.1 beta build 407. It is compatible with Azureus 2.4.0.0 and BitComet 0.63.
Protocol Encryption (PE) is a joint specification between Azureus and µTorrent. It is designed to bypass throttling and/or blocking of BitTorrent traffic by an ISP.
You can choose Protocol Encryption's mode of operation in BitTorrent. Here is an explanation of the various options you can choose from:

• Disabled: Does not encrypt outgoing connections, but will accept encrypted incoming connections.
• Enabled: Attempts to encrypt outgoing connections, but will fall back to an unencrypted mode if the connection fails.
• Force: Attempts to encrypt outgoing connections, and will NOT fall back to an unencrypted mode if the connection fails.
• Allow legacy incoming connections enables or disables incoming legacy (non-encrypted) connections.

All modes will accept incoming encrypted connections (and the encryption is 2-way)!
It is NOT recommended to turn off "Allow legacy incoming connections", unless you cannot have any non-encrypted connections (typically in conjunction with Forced), in which case turning off "Allow legacy incoming connections" is acceptable.

Quote:

---

Originally Posted by arkiebrian

Trackers should start requiring it...IMHO.

---

Not a bad idea, really. I'm sure encryption is de facto by now.

Its good but doest the ISP still know that you are using bittorrent and they r throttling i enmasse without any thinking if torrent use is legitimate like downloading linux ISO or not...

Quote:

---

Originally Posted by apunpktun

Its good but doest the ISP still know that you are using bittorrent

---

Yeah, some (not all) comcast users report throttling even when encryption is fully enabled. I don' know how they can sill recognize the packets as BT, if this is even true.

I have used it for quite a while just because i was told to do so but does it really stop comcast from knowing what you are downloading ? or any other problem isp

Quote:

---

Originally Posted by apunpktun

Its good but doest the ISP still know that you are using bittorrent and they r throttling i enmasse without any thinking if torrent use is legitimate like downloading linux ISO or not...

---

But it can keep you from getting notices about specific DLs.

I believe the security implemented in most clients uses RC4.
I've never heard of a secure stream cipher, and RC4 is no exception.

people are caught on public bt from mpaa and riaa from their IP address. encrypting will not change that, only using a proxy will.

also, encryption will not stop your ISP from seeing what you are doing. They will see the bt protocol, but they will not be able to identify exactly what you download.

Quote:

---

Originally Posted by DanielleD87

people are caught on public bt from mpaa and riaa from their IP address. encrypting will not change that, only using a proxy will.

also, encryption will not stop your ISP from seeing what you are doing. They will see the bt protocol, but they will not be able to identify exactly what you download.

---

But these agencies have to be able to identify what is being downloaded. If it's all encrypted they wouldn't be able to do that.

that is why they only catch people on public torrents. they join the pool like any other peer on a public torrent and whoever sends them data from that torrents gets the letter. it doesn't matter if the data is encrypted or not because they can decrypt it on their end. decryption hides the data from the ISP not the mpaa or the riaa.

Quote:

---

Originally Posted by DanielleD87

people are caught on public bt from mpaa and riaa from their IP address. encrypting will not change that, only using a proxy will.

also, encryption will not stop your ISP from seeing what you are doing. They will see the bt protocol, but they will not be able to identify exactly what you download.

---

torrenting through encryption with any/most BT clients will not help in the case of ISP throttling/shaping(perhaps to some minor extent)---only way round this is through socks4/5 protocol using SSLv.3 encryption :yup:

as far as IP logging goes,,try to avoid public sites thats bout the best advice although i'm pretty sure the "organisations" have so many IP's already and it would be impossible to realistically prosecute "en-masse" public

interesting topic, proxying doesn't sound like a bad idea..

Quote:

---

Originally Posted by DanielleD87

that is why they only catch people on public torrents. they join the pool like any other peer on a public torrent and whoever sends them data from that torrents gets the letter. it doesn't matter if the data is encrypted or not because they can decrypt it on their end. decryption hides the data from the ISP not the mpaa or the riaa.

---

OK...I gotcha now. There's no way around that I suppose.

Comcast still throttles my connection despite encryption.

I worked at Comcast. They monitor users by how much traffic they are allocatting meaning how much bandwidth their taking up at one time. Even if your downloading big legit files, they still assume it could somehow be illegal if they see that bandwidth is being constantly tied up from your ip address.

They also use a software called sandvine, from a company with the same name, that uses advanced filters to track down certain users that they may suspect is trafficing BT content.

Best bet is to force encrypt all incoming data whether you use utorrent or other clients. Encrytion will not stop your isp from knowing that your hogging up bandwidth from BT downloads. they still know your downloading BT content they just don't know what your downloading. Use a proxy to be almost entirely safe. Even though you'll never be entirely safe. VPN tunnels are the most safe proof though.

Quote:

---

Originally Posted by DanielleD87

also, encryption will not stop your ISP from seeing what you are doing. They will see the bt protocol, but they will not be able to identify exactly what you download.

---

as long as they detect the protocol, they will stop you. and if what grimms says is true, then the best option would be to search for a new isp. comcast is stupid! what else would a home user do with a high speed net connection if not download movies, music, games etc??

i'm using comcrap. 100% through a proxy

Quote:

---

Originally Posted by pro267

I believe the security implemented in most clients uses RC4.
I've never heard of a secure stream cipher, and RC4 is no exception.

---

This is completely false.

RC4 isn't broken -- its implementation in WEP was (if thats what you are referring to)

TLS commonly uses RC4, and I haven't seen any recent attacks on it. If so, kiss your online banking goodbye.

AES in CTR mode functions like a stream cipher, and (i think) is used in WPA

Please tell me why you think stream ciphers are insecure.

Quote:

---

Originally Posted by grimms

I worked at Comcast.

(snip)

Encrytion will not stop your isp from knowing that your hogging up bandwidth from BT downloads. they still know your downloading BT content they just don't know what your downloading. Use a proxy to be almost entirely safe. Even though you'll never be entirely safe. VPN tunnels are the most safe proof though.

---

How can they tell my encrpyted traffic is BT? My only guess is that the Protocol Encryption used in bt clients has some estblishment messages sent in the clear, which the isp could 'grep'. Although I havent looked at the protocol so I cant say for sure.

In any case, tunneling your traffic via any method sucks -- be it a vpn tunnel, socks proxy, etc. It doubles my bandwidth usage(now traffic has to go from my home network to the proxy network, and from the proxy network to my destination) and often requires me to pay MORE to get the speeds my ISP is advertising in the first place (no one uses public proxies for bt I hope, we have to PAY for a seedbox or proxy, or some dedicated hardaware or know someone who will let us use their box as a stepping stone).

In other words, leave comcast.

they 'grep' for an ip or url from such en such address. like oink.cd. then from there they see multiple IP addresses connect that are reported in the data from such en such url. i'm not 100% sure on every detail of the process of how they identify the protocol, but I am 100% sure that if you turn off tracker announces in your bt client settings and manually add the IP addresses for that torrent then you will not be throttled, so the throttling is highly dependent on the tracker announce host name.

Quote:

---

Originally Posted by DanielleD87

they 'grep' for an ip or url from such en such address. like oink.cd. then from there they see multiple IP addresses connect that are reported in the data from such en such url. i'm not 100% sure on every detail of the process of how they identify the protocol, but I am 100% sure that if you turn off tracker announces in your bt client settings and manually add the IP addresses for that torrent then you will not be throttled, so the throttling is highly dependent on the tracker announce host name.

---

I like that idea.

alas, even if we do that _and_ use protocol encryption the ISP's can still do fingerprinting on the protocol encryption negotiation our clients use, and throttle based on that.

yep. that is why comcrap is being sued ^_^

Good stuff in here...thanks to all.

i think comcast is using something more basic, than grepping for URLs and all that(which won't scale very well and will need more processor cycles => n/w lag + money). they can use some AI stuff(neural networks) to identify traffic patterns of BT users. although it should be possible to completely encrypt all the BT traffic in a secure way. you still exhibit traffic patterns to your ISP as you and the internet is connected through your ISP. so he can do traffic shaping on that traffic. i don't think that they need to snoop into your packets for this.... generally snoopping in and reading traffic is a big overhead and i don't think comcast need that. because that would roast there routers, and create huge lags. the easiest way for them to control traffic would be to track patters. and once these neural n/w's are trained well they should identify BT usage/traffic pretty easily....

this also should be able to passed through, if your client can stimulate random patterns or something like that... but IMHO you should go to a ISP who lets you use BT... then your life and the programmer's life will be much easier...


cheers!

Quote:

---

Originally Posted by arkiebrian

Good stuff in here...thanks to all.

---

Yup.. very interesting, thanks.

what are the cons of encryption? does it slow down pc?

it would use a liitle more of the cpu I suppose.

Here's another thought:

If a user (you) that has enabled the encryption initiates the connection into a client that has encryption disabled, then the transfer would be encrypted, irrespective of when I have enabled or disabled encryption but if my client with disabled encryption initiates the connection to the client with the enabled encryption then the transfer would not be encrypted and therefore would also be shaped.

Quote:

---

Originally Posted by jayz707

i think comcast is using something more basic, than grepping for URLs and all that(which won't scale very well and will need more processor cycles => n/w lag + money).

---

packet inspection is actually not that expensive. Its when you need to modify the packet contents things get expensive (modifying the packet structure and calculating the checksums)

Quote:

---

Originally Posted by jayz707

they can use some AI stuff(neural networks) to identify traffic patterns of BT users.

---

I don't know anything about neural networks or AI, but I doubt that ISP's would employ such mechanisms (please explain to me why/how they would utilize these academic oriented (research) technologies.

Quote:

---

Originally Posted by jayz707

although it should be possible to completely encrypt all the BT traffic in a secure way.

---

There _must_ be some negotiation messages our clients send in the clear to establish encryption.

Quote:

---

Originally Posted by jayz707

you still exhibit traffic patterns to your ISP as you and the internet is connected through your ISP. so he can do traffic shaping on that traffic. i don't think that they need to snoop into your packets for this.... generally snoopping in and reading traffic is a big overhead and i don't think comcast need that. because that would roast there routers, and create huge lags.

---

No way man, enterprise intrusion detection devices do this kind of work all day, without breaking a sweat (albeit a hefty price tag)

Quote:

---

Originally Posted by jayz707

the easiest way for them to control traffic would be to track patters. and once these neural n/w's are trained well they should identify BT usage/traffic pretty easily....

---

THis would take a lot of training data, and I don't think I have seen an academic paper or commercial product out that can use 'neural networks' to identify usage patterns on a specific protocol given a set of users. Please prove me wrong here though, would be interesting.

Quote:

---

Originally Posted by jayz707

this also should be able to passed through, if your client can stimulate random patterns or something like that...

---

hmmm

Quote:

---

Originally Posted by jayz707

but IMHO you should go to a ISP who lets you use BT... then your life and the programmer's life will be much easier...

---

exactly :)

Quote:

---

Originally Posted by madbeer

Quote:

---

Originally Posted by jayz707

but IMHO you should go to a ISP who lets you use BT... then your life and the programmer's life will be much easier...

---

exactly :)

---

torrent protocol isnt frowned upon on its own I think. Its the content that shifts through the conveyor belts of the torrent world.

alot of false data posted in this thread
using encryption DOES stop ur isp seeing that ur using bittorrent
some companies have specifically developed techniques on breaking the encryption, and some isps have bought these products and actively use them.

comcast do a different method to other isps. they actually send a tcp stop message when uploading, so they fuck ur ability to upload on torrents. if ur with comcast, i recommend switching isps. to hell with using an isp that actually interferes with ur surfing activities. throttling protocols is bad enough, but allowing the protocl and meddling with it is even worse.

Quote:

---

Originally Posted by j0hn

alot of false data posted in this thread
using encryption DOES stop ur isp seeing that ur using bittorrent
some companies have specifically developed techniques on breaking the encryption, and some isps have bought these products and actively use them.

---

as already mentioned, the protocol encrpytion needs to send some negotion messages in the clear to establish session information. So the ISP's (or any other people snooping) _can_ tell you are using BT, but not _what_ you are sending.

I call bullshit on ISP's trying to break the encryption. Where do you get your info?

you're wrong j0hn.

wrongun92: the bt protocol is frowned upon. ISPs only care about money not what is being transfered. bt is frowned upon because it sends and receives data to and from everywhere in the planet using a lot more of the internet backbone where normal downloading usually connects to a server locally closer to you using less backbone. think of it like a road. if you load up a truck full of supplies and drive 30 mins vs driving 3 days. driving 30 mins will use less of the road but the same amount of supplies will be transfered then driving 3 days. on the internet grabbing data from farther away doesn't have much of a consequence to the end user like it does for an isp so we don't notice any problem with it. the more data being grabbed farther away the more 'road' or pipes are being used and the more it costs them. they would rather have their users download and upload data locally not across the planet. comcraps throttling cuts the users who are far away and lets you send to users who are local to you. this actually speeds up the download for comcast users on public bt sites because all of the seeds can't send to someone in europe so they have the spare bandwidth to send to you if you are on the comcrap network.


edit: also even if i hate comcast with a passion i do think they are on the right track just not there yet. what they need to do is not limit the speed of the user no matter how much bw they use. aka if you pay for 1megbit/s upload you get 124kB/s upload 24/7 regardless if you upload 1 kb or 1gb a day. All they need to do is use sandvine to identify who is geographically closer and give priority. aka if you're max upload is 30kB/s and everyone you are seeding to is in europe then it is split evenly but if 1 person is in the US and 5 are in europe then maybe you might end up seeding 20kB/s to the 1 person in the US and 2kB/s to each person in europe totaling 30kB/s so no one notices seeding or receiving except that the ISP saves money.

I meant frowned in the connotation of its legality.

I agree with the fact that it takes up a lot of bandwidth and the isps are probably wary of this.

Quote:

---

Originally Posted by madbeer

This is completely false.

---

Oh really?
You're welcome to search the web for attacks on RC4. I'll mention the Klein and FMS attacks as examples, but I'm sure you'll find many more. Here's a nice article which demonstrates some of the security issues and possible attacks on RC4:
http://cage.ugent.be/~klein/RC4/RC4-en.ps

Quote:

---

Originally Posted by madbeer

RC4 isn't broken -- its implementation in WEP was (if thats what you are referring to)

---

Don't even get me started about WEP..

Quote:

---

Originally Posted by madbeer

TLS commonly uses RC4, and I haven't seen any recent attacks on it. If so, kiss your online banking goodbye.

---

That's inaccurate. TLS/SSL are cryptographic protocols used to authenticate (mostly using PKI), setup encrypted sessions and exchange symmetric keys for different encryption protocols. In SSL/TLS, one of the peers offers cipher suites (basically all the encryption protocols it supports such as 3DES, AES, Camellia, RC4 etc.), and the other peer chooses one of them, typically the strongest one which it supports. In professional systems RC4 is rarely chosen and you would mostly see AES or 3DES.

Quote:

---

Originally Posted by madbeer

AES in CTR mode functions like a stream cipher, and (i think) is used in WPA

Please tell me why you think stream ciphers are insecure.

---

First of all, AES is primarily a block cipher that was "raped" to act like a stream cipher in CTR, with some security features neglected in the process. Secondly, please consider this: in recent years, the cryptographic community has been trying to find candidates for a standard stream cipher algorithm, in a similar process to the way Rijndael was selected as the standard algorithm for block ciphers (also known as AES). All candidates failed miserabely; they were all found to be insecure within 1.5 years or less from the time they were suggested. If that's not proof enough that current stream ciphers are not secure enough then I don't know what is..

to drunk to quote, a better response tomorrow:

both FMS's and Kleins cryptanalisis work contributed to destroying WEP. Show me an attack on RC4 as implemented in SSL/TLS (there are some attacks for older versions of SSL)

define "professional systems"? What cipher do normal users browsers often select? ( I don't know, and I was speculating when I made the previous statement about RC4)

So you think RC4 is broken?

Quote:

---

Originally Posted by madbeer

Quote:

---

Originally Posted by j0hn

alot of false data posted in this thread
using encryption DOES stop ur isp seeing that ur using bittorrent
some companies have specifically developed techniques on breaking the encryption, and some isps have bought these products and actively use them.

---

as already mentioned, the protocol encrpytion needs to send some negotion messages in the clear to establish session information. So the ISP's (or any other people snooping) _can_ tell you are using BT, but not _what_ you are sending.

I call bullshit on ISP's trying to break the encryption. Where do you get your info?

---

...but as Danielle pointed out if there's a mole in the private tracker and you're sharing with him then the specific files can be identified, of course.

RC4 is not broken, why do you suggest it is?