BitTorrent protocol encryption

This is an old revision of this page, as edited by F (talk | contribs) at 01:58, 15 February 2006 (+Why). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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. 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 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. Encryption makes BitTorrent traffic harder to detect and terefore harder to throttle.

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] 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. [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 the encryption.

Bram Cohen, the inventor of BitTorrent, recently 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 the other peer requests it even if outgoing encryption is disabled.

Security

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

  1. ^ - It is usually referred to as the more correct protocol header encryption instead.