Show
Ignore:
Timestamp:
02/19/2008 03:44:01 PM (8 months ago)
Author:
dave
Message:

ip and port number in announce is now also obscured.

Files:
1 modified

Legend:

Unmodified
Added
Removed
  • dotorg/trunk/html/beps/bep_0008.rst

    r10851 r10891  
    2323 
    2424 
    25 Announce Parameter 
    26 ================== 
     25Announce Parameters 
     26=================== 
    2727 
    2828When using this extension, instead of passing the ``info_hash`` parameter 
     
    3939``sha_ih`` above when url encoded becomes 
    4040``kO%89%A5N-%27%EC%D7%E8%DA%05%B4%AB%8F%D9%D1%D8%B1%19``. 
     41 
     42If the ``sha_ih`` is passed then the value for the ``port`` parameter 
     43should be treated as a 16 bit integer and must be obscured in the same 
     44manner as the peer list as described in the `Obfuscation Method`_ 
     45section.  Similarly if the optional ``ip`` parameter is passed in the 
     46announce then its value MUST also be so oscured. 
    4147 
    4248This extension does not change the semantics of any parameter passed 
     
    5561These are discussed in the optimizations_ section. 
    5662 
    57 Peer List Obfuscation 
    58 ===================== 
     63Obfuscation Method 
     64================== 
     65 
     66The values for the``ip`` and ``port`` announce parameters, the 
     67*returned peer list* and any other values that contain peer 
     68information are obscured using the method described in this section. 
    5969 
    6070We distinguish between the *tracker peer list* and the *returned peer 
     
    6878of the ip-port pairs in the *tracker peer list*. 
    6979 
    70 The returned peer list is encrypted using RC4-drop768 encryption using 
    71 the infohash as a shared secret and optionally employing an 
    72 initialization vector. 
     80When a parameter is obscured, it is encrypted using RC4-drop768 
     81encryption using the infohash as a shared secret and optionally 
     82employing an initialization vector.   
    7383 
    7484For the remainder of this document RC4 refers to RC4-drop768.  In the 
     
    8292 
    8393To communicate an initialization vector, the tracker includes in the 
    84 bencoded response the key ``iv`` with value set to a byte string 
     94bencoded response the parameter ``iv`` with value set to a byte string 
    8595containing the initialization vector.  The initialization vector can 
    86 be of arbitrary length and is sent in plaintext. 
     96be of arbitrary length and is sent in plaintext.  Initialization 
     97vectors can only be applied to parameters in tracker responses and NOT 
     98to announces. 
    8799 
    88100If the tracker sends no initialization vector then the infohash is 
     
    134146 
    135147The tracker MAY also cache the encrypted tracker peer list.  To 
    136 support this the tracker MUST pass two additional keys *i* and *n* 
     148support this the tracker MUST pass two additional parameters *i* and *n* 
    137149each with 32-bit integer values, except the tracker MAY omit *i* and 
    138150*n* when *i=0* and the *returned peer list* is the entire *tracker peer 
     
    149161arbitrarily long pseudorandom string to support large swarms, we 
    150162assume the tracker bounds the length of the pseudorandom string and 
    151 reports the length in ip-port pairs as the value to key *n*.  *n* 
     163reports the length in ip-port pairs as the value to parameter *n*.  *n* 
    152164excludes reserved and discarded bytes.  We RECOMMEND that *n* be equal 
    153165to the length of the tracker peer list or random but within constant 
     
    166178 
    167179   **Figure 1:** The first 768 bytes of the RC4 pseudorandom 
    168    string are discarded.  The key *i* in the tracker response has 
    169    value ``x xor i``.  The key *n* has value ``y xor n``. 
     180   string are discarded.  The parameter *i* in the tracker response has 
     181   value ``x xor i``.  The parameter *n* has value ``y xor n``. 
    170182 
    171183We describe encryption in the following example for an ipv4 tracker peer  
     
    216228Trackers that support obfuscation are identified in the .torrent file 
    217229by the inclusion of an ``obfuscate-announce-list`` which otherwise has the  
    218 same semantics as the ``announce-list`` key.  Peers that do not support 
     230same semantics as the ``announce-list`` parameter.  Peers that do not support 
    219231obfuscation simply ignore the ``obfuscate-announce-list``.   
    220232 
     
    289301 
    290302- The entire plaintext of the peer list is not easily obtained even if 
    291   an eavesdropper identifies ip-port pairs from subsequent connections 
    292   initiated by a peer that has received a tracker response. 
     303  an eavesdropper identifies one or more subsequent connections as 
     304  using BitTorrent and the corresponding ip-port pairs appeared in the 
     305  ciphertext of the tracker response. 
    293306 
    294307- Even when a subsequent connection from a peer that has received a  
     
    315328and subsequent connections, it is possible to attack the encryption. 
    316329RC4 is known to have a number of weaknesses especially in the way it 
    317 was used with WEP [#Borisov]_ [#Scott]_ [#Stubblefeld]_.  However, 
    318 with tracker peer obfuscation, the number of bytes transferred between 
    319 the tracker and a client is likely significantly smaller than transferred 
     330is used with WEP [#Borisov]_ [#Scott]_ [#Stubblefeld]_.  However, with 
     331tracker peer obfuscation, the number of bytes transferred between the 
     332tracker and a client is likely significantly smaller than transferred 
    320333between a wireless computer and a basestation.  An attacker faces a 
    321 much larger task in obtaining sufficient probable plaintext to 
    322 directly break the encryption. 
     334much larger task in obtaining sufficient ciphertext to directly break 
     335the encryption. 
    323336 
    324337Hobbling the RC4 encryption by using a bounded-length RC4 pseudorandom 
     
    336349peer-to-peer communication is available to network operators. 
    337350 
    338 For larger swarms, hobbling RC4 may more significantly impact breaking 
    339 the encryption since the same pseudorandom string is used repeatedly 
    340 across the peer list.  Some study is in order on this point taking 
    341 into account that the tracker can periodically change intiailization 
    342 vectors. 
     351For larger swarms, hobbling RC4 may simplify breaking the encryption 
     352since the same pseudorandom string is used repeatedly across the peer 
     353list.  Some study is in order taking into account that the tracker can 
     354periodically change intiailization vectors. 
    343355 
    344356We know from experience that periodically reshuffling peer lists on