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 encrypt (PHE)[1], 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 proportion 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. [2] Since there are no open specifications to this protocol implementation the only possiblity to support it would have been via reverse engineering.
In late January 2006 the Azureus developers decided to design and simultanously implement a new, open protocol obfuscation method. It was included in Azureus CVS snapshot 2307-B29 on 19 January 2006. [3]
This first draft was heavily criticized since it lacked several key features. After negotations between different BitTorrent developers a new proposal was written and then implemented into the respective µTorrent and Azureus betas within days. The developers were ludde, uau, The_8472, Parg and Nolar.
Azureus supports the final spec since 25 January 2006 (CVS snapshot 2307-B33) [4] and µTorrent followed 4 days later with beta 1.4.1 build 407. The new protocol is called MSE in Azureus and PE in µTorrent.
Bram Cohen, the inventor of BitTorrent, recently commented disfavouring on the ongoing development to obfuscate the BitTorrent protocol. [5] Encrypted BitTorrent users quickly pointed out flaws in his reasoning. [6]
Operation
The BitComet PHE method is not published. It is incompatible with MSE/PE.
MSE/PE uses a D-H exchange combined with the infohash of the torrent to establish the key, then it uses RC4 to encrypt the data. The D-H exchange helps minimizing the risk of passive listeners, and the infohash helps avoiding man-in-the-middle attacks. RC4 is chosen for its speed. The first kilobyte of the RC4 output is discarded to prevent a Fluhrer, Mantin and Shamir attack.
The specification allows the users to choose between encrypting the headers only or the full connection. Encrypting the full connection provides more obfuscation but uses more CPU time. However, PE only supports full encryption for outgoing connections, but will accept both obfuscation levels for incoming connections.
To ensure compatibility with other clients that don't support this specification users may also choose whether unencrypted incoming or outgoing connections are still allowed.
The estimated strength of the encryption is around 60-80 bits symmetrical (see RFC3526 chapter 8). This is quite low for today's standards but one has to keep in mind that this protocol wasn't designed as a secure transport protocol but as fast and efficient obfuscation method. AES was proposed as the encryption method but not adopted because it is too slow.
Note
- ^ - It is usually referred to as the more correct protocol header encryption instead.