This article documents a current event. Information may change rapidly and initial news reports may be unreliable. The latest updates to this article may not reflect the most current information. |
Protocol header encryption (PHE), Message stream encryption (MSE), or Protocol encryption (PE) are features of some BitTorrent clients that attempt to make BitTorrent hard to throttle. Some ISPs throttle BitTorrent traffic because it makes up a large porportion of total traffic and the ISPs don't want to spend money buying extra capacity. Instead, the ISPs spend money on hardware that look for BitTorrent traffic and slow them down.
History
Protocol header encryption was conceived by RnySmile and first implemented in the BitComet client version 0.60 on 8 September 2005. Some software like IPP2P claims BitComet is detectable even with PHE[1]. Since there are no open specifications to this protocol implementation the only possiblity to support it would have been reverse engineering.
In the late January of 2006 the Azureus developers decided to design and simultanously implement a new protocol obfuscation method that was openly specified. This first draft was heavily critizied since it lacked several key features the later version should include. After negotations between different BitTorrent developers a new proposal was written and then implemented into the respective µTorrent and Azureus betas within days.
Azureus supports the final spec since 25 January 2006 (version 2.3.0.7 B33) and µTorrent followed 4 days later with Beta 1.4.1 build 407
Bram Cohen, the inventor of BitTorrent, recently commented disfavouring on the ongoing development to obfuscate the BitTorrent protocol. [2]
Operation
The BitComet PHE method is not published and incompatible with MSE/PE
MSE/PE uses a D-H exchange to establish the key, then it uses RC4 to encrypt the data. The specification allows the users to choose between header-only and a fullblown stream encryption to perform a CPU time/obfuscation tradeoff. To ensure compatibility with other clients that don't support this specification a user may also choose whether unencrypted incoming or outgoing connections are still allowed.
The estimated strength of the encryption lies around 60-80bit (see RFC3526 chapter 8) of common symmetric encryption algorithms, which is quite low for todays cryptographic standards but one has to keep in mind that this protocol wasn't designed as a secure transport protocol like SSL or SSH but as fast and efficient mean to obfuscated the transported content.