BitTorrent protocol encryption

From CryptoDox, The Online Encyclopedia on Cryptography and Information Security

Jump to: navigation, search

Protocol encryption (PE), Message stream encryption (MSE), or Protocol header encrypt (PHE)<ref name="name">It is usually referred to as the more correct protocol header encryption instead.</ref> are related features of some peer-to-peer file-sharing clients, including BitTorrent. They attempt to make traffic harder to identify by third parties including internet service providers (ISPs).

MSE/PE is implemented in Azureus, BitComet, BitTornado, KTorrent, Mainline (incoming only), µTorrent, 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.

Contents

Purpose

Peer-to-peer file-sharing traffic makes up more than a third of total internet traffic.<ref>Wired: The Bittorrent Effect</ref> 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.

History

Early approach

Protocol header encryption (PHE) 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.<ref>IPP2P homepage - News</ref> 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 Azureus developers 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, 2006.<ref>CVS Snapshot Azureus2307-B29.jar has been released !</ref>

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

Azureus supports the final spec since 25 January, 2006 (CVS snapshot 2307-B33)<ref>CVS Snapshot Azureus2307-B33.jar has been released !</ref>. Azureus version 2.4.0.0 was released 10 February, 2006, 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 2.4.0.2.<ref>Azureus : Java BitTorrent Client - Changelog</ref>

µTorrent premiered MSE/PE 4 days after Azureus with beta 1.4.1 build 407.<ref>µTorrent 1.4.2 beta 435</ref>. µ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.<ref>BitComet Client Release Notes</ref>

KTorrent implemented MSE/PE in SVN version 535386<ref name="ktorrent">The SVN server is at svn://anonsvn.kde.org/home/kde/trunk/extragear/network/ktorrent</ref> on April 29, 2006.<ref>Encryption has been added !</ref>

Mainline supports MSE/PE since version 4.9.2-beta on May 2, 2006.<ref>Version Notes</ref>

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.<ref>BitTornado T-0.3.18</ref>

rTorrent supports MSE/PE as of rTorrent-0.7.0.<ref>Announcement of rTorrent-0.7.0</ref>

Deluge supports MSE/PE as of Deluge-0.5.1.<ref>Deluge 0.5.1 Release Announcement</ref>

Operation

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 a D-H key exchange combined with the infohash of the torrent to establish the key, then it uses RC4 to encrypt the data. The D-H 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. However, only Azureus and µTorrent beta 1.4.1 build 413 or older lets the user choose. All other clients default to full encryption.

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 common symmetrical ciphers<ref>RFC 3526 chapter 8</ref>. 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, making the handshake more expensive in terms of used CPU time.

Effectiveness

Many 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, whilst most ISPs use the simpler, less costly, methods to identify and throttle BitTorrent, the current solution remains extremely effective.

A fatal flaw where encryption doesn't matter

The Sandvine net appliance uses a different approach to throttling BitTorrent traffic that makes seeding impossible, by sending counterfeit protocol hangup packets. Multiple secure VPNs between clients have become necessary (in order for the Sandvine hack to be disabled).

Using Tor as a secure tunnel (as it is not a true VPN) to exit one's traffic from one's ISP is the only semi-workable solution at the moment. It must be assumed that Sandvine throttles Tor traffic less severely than BitTorrent traffic.

This link gives a more technical explaination of the above

Criticism

Bram Cohen, 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".<ref>Obfuscating BitTorrent</ref> Many BitTorrent community users responded strongly against Cohen's accusations.<ref>Debate over Protocol Encryption</ref> Cohen later added the ability to receive encrypted connections but not send out encrypted data on his Mainline client.<ref>BitTorrent Mainline Version History</ref>

BBC claims

In 2006, a Newsnight episode claimed that the use of encrypted BitTorrent helps terrorists and paedophiles because any increase in encrypted traffic makes it more difficult for law enforcement to monitor the InternetTemplate:Fact.

Many BitTorrent users were outraged and complained.<ref>Feedback - February 2006 (2)</ref> BBC stood by its claim about paedophiles and terrorists, but it did admit that such references are often used by others as a way to sell copy, and that traditional media like television are under threat from new media like BitTorrent.Template:Fact BBC apologised for saying that peer to peer file sharing was "theft"<ref>A bit of BitTorrent bother</ref>

As the UK does not have a program like Australia's ABC Mediawatch -- there is no neutral entity to challenge the quality of journalism in this case. It must also be pointed out that probably some 5% of global BitTorrent traffic (where the end content is in English) may indeed by BBC programmes.

Notes and references

<references/>

External links

Template:BitTorrent