Protocol header encrypt (PHE)[1], Message stream encryption (MSE), or Protocol encryption (PE) are features of some BitTorrent clients that attempt to make BitTorrent traffic hard to throttle. MSE and PE are two names for the same protocol.
Why
Some ISPs throttle BitTorrent traffic because it makes up a large proportion of total traffic and they don't want to spend money buying extra capacity. Instead, the ISPs spend money on hardware that looks for BitTorrent traffic and slows them down. Encryption makes BitTorrent traffic harder to detect and therefore harder to throttle. It is not designed to provide anonymity.
Right now only the MikroTik RouterOS routing system can successfully detect encrypted BitTorrent traffic (by uTorrent and Azureus) and deal with it from within it's firewall.
History
Protocol header encryption was conceived by RnySmile and first implemented in BitComet version 0.60 on 8 September 2005. Some software like IPP2P claims BitComet traffic is detectable even with PHE. [2] PHE is detectable because not the whole stream is encrypted. Since there are no open specifications to this protocol implementation the only possiblity to support it in other clients 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. [5] The new protocol is called MSE in Azureus and PE in µTorrent.
Azureus version 2.4.0.0 was released February 10th, 2006. This is the first full release version of a client to support MSE/PE.
Bram Cohen, the inventor of BitTorrent, commented disfavouring on the ongoing development to obfuscate the BitTorrent protocol. [6] Encrypted BitTorrent users were quick to disagree with his reasoning on many accounts. [7]
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 in µTorrent beta 1.4.1 build 417 or later 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.
All supported clients will enable encryption automatically if they receive an encrypted incoming connection even if outgoing encryption is disabled.
Supported clients propagate the fact that they have MSE/PE enabled through PEX and DHT. Other clients will then connect to them with encryption even if outgoing encryption is disabled.
Security
The estimated strength of the encryption corresponds to about 60-80 bits for commong symmetrical ciphers (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 consumed too much CPU time and the required D-H keys to achieve a security equal to AES would have been much bigger, making the handshake more expensive.
Note
- ^ - It is usually referred to as the more correct protocol header encryption instead.
External links
- Slyck News - BitTorrent End to End Encryption and Bandwidth Throttling - Part I (Inverview with µTorrent devs)
- Slyck News - BitTorrent End to End Encryption and Bandwidth Throttling - Part II (Inverview with Azureus devs)
- Slashdot | BitTorrent and End to End Encryption