BitTorrent protocol encryption: Difference between revisions

Revision as of 10:38, 6 February 2006

Revision as of 04:42, 7 February 2006

Line 3:

==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. [http://www.ipp2p.org/news_en.html] 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]].

[http://sourceforge.net/mailarchive/forum.php?thread_id=9517694&forum_id=40629]

This first draft was heavily critizied 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) [http://sourceforge.net/mailarchive/message.php?msg_id=14596518] 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.

Line 17:

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 specificationD-H allowsexchange helps minimizing the usersrisk toof choosepassive betweenlisteners, encryptingand the headersinfohash onlyhelps oravoiding [[man-in-the-middle fullattack]]s. connectionRC4 tois performchosen a CPUfor time/obfuscationits tradeoffspeed. However,The PEfirst onlykilobyte supportsof fullthe encryptionRC4 foroutput outgoingis connections,discarded butto willprevent accepta bothFluhrer, obfuscationMantin levels forand incomingShamir connectionsattack.

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 [http://www.faqs.org/rfcs/rfc3526.html 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. [[Advanced Encryption Standard|AES]] was proposed as the encryption method but not adopted because it is too slow.

==Note==

#{{note|name}} - It is usually referred to as the more correct ''protocol header encryption'' instead of the official name.

==External link==

*[http://azureus.aelitis.com/wiki/index.php/Message_Stream_Encryption Description on the official Azureus wiki]

*[http://azureus.aelitis.com/wiki/index.php/Bad_ISPs ISPs that shape BitTorrent on the official Azureus wiki]

*[http://www.slyck.com/news.php?story=1083 Slyck News - BitTorrent End to End Encryption and Bandwidth Throttling - Part I]

*[http://yro.slashdot.org/yro/06/02/06/2039241.shtml Slashdot | BitTorrent and End to End Encryption]

[[Category:BitTorrent]]

[[Category:Cryptographic protocols]]