), Message stream encryption
), or Protocol header encrypt
) are related features of some peer-to-peer file-sharing clients
, including BitTorrent clients
. They attempt to make traffic harder to identify by third parties including internet service providers
MSE/PE is implemented in Vuze, BitComet, BitTornado, Deluge, Halite Client, KTorrent, Mainline, µTorrent, Transmission (v0.90) and rTorrent. PHE was implemented in old versions of BitComet. Similar protocol obfuscation is supported in up-to-date versions of some other (non-BitTorrent) systems including eMule.
Peer-to-peer file-sharing traffic makes up more than a third of total internet traffic. Some ISPs deal with this traffic by increasing their capacity whilst others use specialised systems to throttle (i.e.
slow down) BitTorrent traffic. Obfuscation and encryption make traffic harder to detect and therefore harder to throttle. These systems are not designed to provide anonymity
Protocol header encryption (PHE) was conceived by RnySmile
and first implemented in BitComet
version 0.60 on 8 September
. Some software like IPP2P claims BitComet traffic is detectable even with PHE. PHE is detectable because only part of the stream is encrypted. Since there are no open specifications to this protocol implementation the only possibility to support it in other clients would have been via reverse engineering
Development of MSE/PE
In late January 2006 the developers of Azureus
, now known as Vuze, decided to design and simultaneously implement a new, open protocol obfuscation method, called message stream encryption (MSE). It was included in Azureus CVS snapshot 2307-B29 on 19 January
This first draft was heavily criticized since it lacked several key features. After negotiations between different BitTorrent developers a new proposal was written and then implemented into the Azureus and µTorrent betas within days. The developers were ludde, uau, The 8472, Parg and Nolar. In µTorrent, the new protocol was called protocol encryption (PE).
MSE/PE in BitTorrent client versions
supports the final spec since 25 January
(CVS snapshot 2307-B33). Azureus version 184.108.40.206 was released 10 February
, and was the first stable version of a client to support MSE/PE. However, glitches in Azureus' implementation resulted in improperly encrypted pieces that failed hash checking. The glitches were rectified as of version 220.127.116.11.
µTorrent premiered MSE/PE 4 days after Azureus with beta 1.4.1 build 407.. µTorrent version 1.5 (build 436) was released on 7 March, 2006; it was the first stable version of µTorrent with PE.
BitComet version 0.63 was released 7 March, 2006. It removed the old protocol header encryption and implemented the new MSE/PE to be compatible with Azureus and µTorrent.
KTorrent implemented MSE/PE in SVN version 535386 on April 29, 2006.
Mainline supports MSE/PE since version 4.9.2-beta on May 2, 2006.
BitTornado supports MSE/PE as of build T-0.3.18. As of January 5, 2007, this build is still marked "experimental" on the Download page.
rTorrent supports MSE/PE as of rTorrent-0.7.0.
Deluge supports MSE/PE as of Deluge-0.5.1.
Transmission supports MSE/PE as of Transmission-0.90.
aria2 supports MSE/PE as of aria2-0.13.0.
The BitComet PHE method used in versions 0.60 to 0.62 is neither published, nor is it compatible with MSE/PE.
MSE/PE uses key exchange combined with the infohash of the torrent to establish an RC4 encryption key. The key exchange helps to minimize the risk of passive listeners, and the infohash helps avoid man-in-the-middle attacks. RC4 is chosen for its speed. The first kilobyte of the RC4 output is discarded to prevent a particular 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.
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.
Supported clients propagate the fact that they have MSE/PE enabled through PEX and DHT.
The estimated strength of the encryption corresponds to about 60–80 bits for common symmetrical ciphers. 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 a 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 or require elliptic curve cryptography
Some ISPs are now using more sophisticated measures (e.g. pattern/timing analysis or categorizing ports based on side-channel data) to detect BitTorrent traffic. This means that even encrypted BitTorrent traffic can be throttled. However, with ISPs that continue to use simpler, less costly methods to identify and throttle BitTorrent, the current solution remains extremely effective.
Remains vulnerable to disrupted peer traffic
application uses a different approach to disrupt BitTorrent traffic that makes seeding impossible. The Sandvine application intercepts peer-to-tracker communication to identify peers based on the IP address and port numbers in the peer list returned from the tracker. When Sandvine later sees connections to peers in the intercepted peer lists, it may (according to policy) break these connections by sending counterfeit TCP resets. Various solutions exist to protect against Sandvine's attack including encrypting both peer-to-tracker and peer-to-peer communication, using Microsoft's Teredo
so that TCP connections are tunneled within UDP packets, filtering TCP resets before they reach the TCP layer in the end-host, or switching entirely from a TCP-based transport to a UDP-based transport. Each solution has its trade-offs. Filtering out TCP resets typically requires kernel access, and the participation of the remote peer since Sandvine sent the reset packet to the local and remote peers. Teredo is not available on all BitTorrent clients. Rewriting TCP reliability, in-order delivery and congestion control in a new UDP protocol represents a substantial engineering effort and would require upgrading both ends of any peer-to-peer connection. Increasing robustness to TCP resets solves Sandvine's attack, but it does not prevent internet applications from using the peer lists to perform other attacks such as blocking peer-to-peer connections completely. Encryption also won't stop a traffic shaping system configured to universally slow down all encrypted, unidentifiable or unknown protocols using a method as simple as packet loss. Encrypting tracker communications prevents eavesdropping on peer lists and does not require upgrading both ends of peer-to-peer connections, but it requires imposing computational overhead on the tracker.
, the inventor of BitTorrent
, opposed adding encryption to the BitTorrent protocol. Cohen stated he was worried that encryption could create incompatibility between clients. He also stressed the point that the majority of ISPs don't block the torrent protocol. Cohen wrote "I rather suspect that some developer has gotten rate limited by his ISP, and is more interested in trying to hack around his ISP's limitations than in the performance of the internet as a whole". Many BitTorrent community users responded strongly against Cohen's accusations.
Cohen later added the ability to receive but not originate encrypted connections on his Mainline client
. Notably, when µTorrent was purchased by BitTorrent, Inc. and then became the next mainline release, the ability to originate encrypted connections was not removed.
Notes and references