Jump to content

We need bitcomet's protocol header encrypt option please


Recommended Posts

ISPs, of which mine is one, are doing traffic shaping now (proven) and while I worked around it by using a specific port (1720) I don't think it's 100% because a lot of peers just don't connect to me but once they do my uls go full speed.

On the isp support board I'm on, a lot of people are talking about using bitcomet's protocol header encrypt option to work around things..

Why not add that too for the next release? Can't be too hard and would go a long way towards making stuff work better for everyone.


Link to comment
Share on other sites

If the code was open-source, wouldn't that also make it easier for ISPs to shape even encrypted packets?

I imagine that there has to be some sort of detectable flag in the header that tells BC to decrypt it. Would it be possible for ISPs to work with this to continue shaping BT traffic even with encrypted headers?

Link to comment
Share on other sites

Making it open source or documenting the protocol wont make it less secure !!!

It will make it's DETECTION easier. Firon, the ISP-s dont really care what inside the packets, all they care is about detecting the protocol as a modified bittorent one. Take it or leave it, but making such a detector is MUCH easier if you have every bit in your headers/negotiation process/whatever documented.

Link to comment
Share on other sites

How much good will the encryption do if only one client supports it, so that BitComet users will have to send unencrypted headers to peers not using BitComet? That way, the ISPs can easily track the port the unencrypted packets are sent on and throttle it.

Link to comment
Share on other sites


You are wrong. It will only make the detection easier if the encryption protocol is implemented in a WRONG way.

For standard applications that require encryption, for example a VPN, it's the SECURITY that you have to keep in mind in the first place when you implement the protocol, and not how easy it is to DETECT that it's encrypted VPN traffic.

But when you implement a protocol for a BT client, the first thing you have to keep in mind is to make it hard to DETECT that the traffic is encrypted BT traffic, and the SECURITY comes in second place.


Even if the protocol is very well documentated there is NO WAY for the ISP to detect that the encrypted packets are encrypted BT packets unless they know the key for that connection. And the key will never be sent over the connection since it will use for example the torrents hash as key since both clients has this key. So there will be no "exchange key handshake" or "unencrypted handshake", and because of that, it will be very hard for the ISP to detect that it's encrypted BT packets. Even the first packet in the connection will be encrypted, so the only thing the ISP will see is "random bytes" with a "random length".

So it doesn't make it easier for the ISP to detect that it's encrypted BT traffic if the protocol is well documentated, IF the protocol is implemented in the correct way. If BitComet decide not to make the protocol public, then they might have implemented it in the wrong way, so it's easy to detect that it's encrypted BT traffic if the protocol is public. And in that case, there's no reason for uTorrent to use thier implementation.

Maybe uTorrent should code its own protocol encryption that is implemented in a correct way, with the philosofy to make it hard to detect even the protocol is public. And make it public for other clients to use.

Link to comment
Share on other sites

First, i was, indeed, talking about torrent, not VPN-s. In torrent security is not important at all, not even at second place, what important is how easy is to detect it's traffic.

Even the first packet in the connection will be encrypted, so the only thing the ISP will see is "random bytes" with a "random length".

How about starting to throttle unrecognized packets with content that looks like a white noise ? Come on, as long as someone finds a single non-random feature of your random bytes with a random length, he will make a detector for it. And it IS easier when you have everything documented.

Link to comment
Share on other sites

If every packet were encrypted, then it would indeed be nigh impossible for the ISPs to determine that bittorrent traffic was contained. However, how would you go about encrypting everything -- including bittorrent's handshake packet containing the info hash (the decryption key). All the client would see when recieving the packet is random data that it has no idea what to do with (it could try decryption, but with what key?)

The only solution I can think of would be to attempt to decrypt it with EVERY info hash -- quite ineligant considering you'd need to do it with millions of packets. The program could note that it needs to decrypt each packet from a specific IP with a specific hash (of the torrent it's connected to), but what if the IP is connected for multiple torrents? Furthermore, how are you going to deal with the possibility of a packet decrypting validly for a different torrent?

@Inf - I was going to say the same thing, but encrypting "white noise" packets would throttle more than just BitTorrent, so I would think ISPs wouldn't filter based on that.


Link to comment
Share on other sites

I would really like to see the encrypted headers option on uTorrent, yet i admit that it may be pointless in the long run, cause the bottom line is, the torrent traffic is bad for ISP-s, they dont want it, and they WILL find a way to throttle it down. Even if there will be absolutely no way to detect the uTorrent perfectly designed encrypted protocol, a single home network IP making hundreds of connections to other IP-s scattered around the world, and also accepting a hundreds of incoming connections from others, looks like a p2p network participant, and hence a target for throttling, no matter encrypted or not, bittorrent or something else. Theres is nothing else but p2p apps behaves that way, and p2p is bad for ISPs.

Link to comment
Share on other sites


As I said, the VPN example was just an example.

And an ISP would never throttle traffic that looks like "a white noise". They will never throttle any traffic just because they don't know what it is. It will cause far more problems than it's worth for the ISP. Since they will have tons of complains because other "legal" applications also will be affected by this.

The current goal is not to make an encrypted protocol that will never be detected. The goal is to make a protocol that is hard enough to detect so the ISP's rather choose to let the traffic pass instead of investing million dollar equipment required to detect that it's encrypted BT traffic.

The unencrypted BT protocol is very easy to detect, so ISP's earn money by shaping this traffic since it use a lot of bandwidth which reduce thier bandwidth cost. But if they would need to invest in million dollar equipment to detect the traffic, then they would earn more by letting the traffic pass.

The expensive part for ISP's is NOT how to figure out how to detect the traffic. The EXPENSIVE part is to buy custom made equipment that can detect the encrypted BT traffic over millions of connections. So therefore it DOES NOT matter if the protocol is documentated if it's implemented in a way so it's hard to detect.

P2P will always be a rat and mouse game. And this is no exception. When encrypted bt traffic is implemented in utorrent it will be possible to detect it. But it will maybe take a few years before the ISP's want to invest in the equipment required to detect it. And if they invest million of dollar in equipment to detect it, then utorrent can just release a new encryption method sent out via the auto-update feature and all the equipment they invested to detect the old encrypted BT traffic will be useless.

ISP's doesn't block BT traffic because they think it's fun. ISP's block BT traffic because they earn money by doing it in reduced bandwidth costs. And what the BT community need to do is to make the equipment required to detect the encrypted BT traffic expensive enough so they won't invest in it, and therefore earn money by letting the traffic pass.

Everything is about money.

ISP's will NEVER win the P2P "war". Because the P2P community will always be one step ahead. What they need to do to win the P2P war is to shutdown the whole philosofy behind Internet. And I doubt that this will happen.

So as I said above, it DOES NOT matter if the protocol is documentated if it's implemented in a way so it's hard enough to detect.

I can't wait for the day when multicasting is supported by the ISP's ;)

Link to comment
Share on other sites

I just have one question

Why are we always trying to implement BITCOMET protocol header ?

I mean as far as i know the number of client that use this protocaol can be counted one one finger.

They where the first ? and ?

Let be the first to implement a open source implementation

(or a least well documented)

As far as i know utorrent forums isnt the first one to request such a feature

and on pretty much all forums they have about the same discution

it's not documented we cannot do it etc ...

now ... What if we do it ?

now there are two implementation of an encripted protocol

and other client will have to choose between the first and original

or the well documented ...

guess how hard the choise will be!

now a word word to those against open source / documnetation

a least try ! of course the first time isp will find a way

but while they are spending money to decipher the whole thing we can innovate the next generation of encryption

we as the devlopper will alwais be one step behind. And in matter of encryption this is the important thing.

what can be a good handshake ?

let say A is the peer that need to avoid bandwidth trotling.

and B is a "receiver"

A and B open a connection

A send a 16 bit password to B, this will be the root key

B ressend the word "BitTorrent" encripted whit the password sent by A

at that point ... A will know that B support the encrypted protocol.

A send a new encryption key encrypted with the first key.

A will send the normal protocol encrypted with that new key

B respond with the normal protocol with the new key

and there will be some sort of way to change the root key.

this is very basic but can still be tried.

sorry for my english. But i hope you still get the picture.

Link to comment
Share on other sites

I got burnt.

Have'nt I ?

Actually i do not know alot of thing.

But i am in the ones who believe the important is not to know rigth now, but to know how to learn.

I can be a fun project however i'm pretty sure the best i could do is double the memory usage and size of uT

(well pretty much any coder will end up doing that lol)

I'm more than happy to know that Ludde worked on something and all my respect fly to him.

Link to comment
Share on other sites

bittorrent a disaster with Rogers.com!

I have done some investigation.

It appears that rogers is using the Cisco P-CUBE SCE 1000


But they have also trialed the ellacoya device E30 too (»www.ellacoya.com/products/e30.shtml)

The system is harder to defeat than changing the default port numbers etc.

They are actually looking for the download (via HTTP!) of a .torrent, and blocking that.

The solution is to make the signature go across two distinct TCP packets, the devices are both too dumb to match that!

One way to do this is to change the MTU size to be low, and TCP's path mtu discovery will then take affect, e.g. 150 bytes. But this yields quite low performance.

A better solution will be to modify the bittorrent client to do a 'write' of the first part of the connect, wait a small bit, then the second part, with a flush in between (or TCP_NODELAY option).

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...