Changeset 10560

Timestamp:

02/06/08 02:55:28 (2 years ago)

Author:

dave

Message:

Clarify some issues in the "Tracker Peer Obfuscation" BEP.

In particular it is now clear that peers returned in response to a request with sha_ih
can be assumed to implement Message Stream Encryption.

Also the index and RC4 pseudorandom string length are now randomized and obscured.

Aslo some wordsmithing.

Location:

dotorg/trunk_fixed/html

Files:

• beps/bep_0008.html (modified) (15 diffs)
• beps/bep_0008.rst (modified) (18 diffs)
• beps/bep_0008_figures.ppt (added)
• beps/bep_0008_pseudo.png (added)
• css/bep.css (modified) (4 diffs)

dotorg/trunk_fixed/html/beps/bep_0008.html

@@ -58 +58 @@
 <p class="topic-title first">Contents</p>
 <ul class="simple">
-<li><a class="reference internal" href="#announce-parameter" id="id7">announce parameter</a></li>
-<li><a class="reference internal" href="#announce-response" id="id8">announce response</a></li>
-<li><a class="reference internal" href="#peer-list-obfuscation" id="id9">peer list obfuscation</a></li>
-<li><a class="reference internal" href="#optimizations" id="id10">optimizations</a></li>
-<li><a class="reference internal" href="#backwards-compatibility" id="id11">backwards compatibility</a></li>
-<li><a class="reference internal" href="#rationale" id="id12">rationale</a></li>
-<li><a class="reference internal" href="#id2" id="id13">References</a></li>
+<li><a class="reference internal" href="#announce-parameter" id="id8">Announce Parameter</a></li>
+<li><a class="reference internal" href="#announce-response" id="id9">Announce Response</a></li>
+<li><a class="reference internal" href="#peer-list-obfuscation" id="id10">Peer List Obfuscation</a></li>
+<li><a class="reference internal" href="#optimizations" id="id11">Optimizations</a></li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id12">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#rationale" id="id13">Rationale</a></li>
+<li><a class="reference internal" href="#references" id="id14">References</a></li>
 </ul>
 </div>
 <p>This extends the tracker protocol to support simple obfuscation of the
-peers it returns, using the info hash as a shared secret between the
+peers it returns, using the infohash as a shared secret between the
 peer and the tracker. The obfuscation does not provide any security
 against eavesdroppers that know the infohash of the torrent.  The goal
@@ -77 +77 @@
 <p>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;,
 &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are
-to be interpreted as described in IETF <a class="reference external" href="http://tools.ietf.org/html/rfc2119">RFC 2119</a> <a class="footnote-reference" href="#id3" id="id4">[1]</a>.</p>
+to be interpreted as described in IETF <a class="reference external" href="http://tools.ietf.org/html/rfc2119">RFC 2119</a> <a class="footnote-reference" href="#id6" id="id7">[5]</a>.</p>
 <div class="section" id="announce-parameter">
-<h1>announce parameter</h1>
+<h1>Announce Parameter</h1>
 <p>When using this extension, instead of passing the <tt class="docutils literal"><span class="pre">info_hash</span></tt> parameter
 to the tracker, an <tt class="docutils literal"><span class="pre">sha_ih</span></tt> is passed.</p>
@@ -94 +94 @@
 </div>
 <div class="section" id="announce-response">
-<h1>announce response</h1>
+<h1>Announce Response</h1>
 <p>If the tracker supports this extension, the response should be exactly the
 same as if the <tt class="docutils literal"><span class="pre">info_hash</span></tt> was passed, except that any field that contains
@@ -103 +103 @@
 </div>
 <div class="section" id="peer-list-obfuscation">
-<h1>peer list obfuscation</h1>
+<h1>Peer List Obfuscation</h1>
 <p>We distinguish between the <em>tracker peer list</em> and the <em>returned peer
 list</em>.  The <em>tracker peer list</em> contains the ip-port pairs of all
@@ -121 +121 @@
 recovers the plaintext by generating the same pseudorandom string and
 XOR'ing it with the ciphertext.  In generating the pseudorandom
-string, the tracker and client MUST discard the first 768 bytes.  All
-indices into the pseudorandom string ignore the first 768 bytes, i.e.,
-index 0 refers to the first undiscarded byte.</p>
+string, the tracker and client MUST discard the first 768 bytes.</p>
 <p>To communicate an initialization vector, the tracker includes in the
 bencoded response the key <tt class="docutils literal"><span class="pre">iv</span></tt> with value set to a byte string
@@ -131 +129 @@
 of the infohash are used as the RC4 key.  If the tracker provides an
 initialization vector then the RC4 key is generated by appending the
-vector to the infohash and then hashing with sha1.  The first 64 bits
-of the resulting hash are then used as the RC4 key.</p>
+vector to the infohash and then hashing with SHA-1.  The first 64 bits
+of the resulting hash are then used as the RC4 key.  The string from
+which the RC4 key is derived whether it be the infohash or the SHA-1 of
+the initialization vector appended to the infohash is called the
+<em>intermediate string</em>.</p>
 <p>For example, given infohash <tt class="docutils literal"><span class="pre">aaf4c61ddcc5e8a2dabedef3b482cd9aea9434d</span></tt>
 and initialization vector <tt class="docutils literal"><span class="pre">abcd</span></tt> both represented in hex, the RC4 key
 is derived as follows:</p>
 <pre class="literal-block">
-hash = sha1( 'aaf4c61ddcc5e8a2dabedef3b482cd9aea9434dabcd' )
-key = hash[0:64]
+intermediate = sha1( 'aaf4c61ddcc5e8a2dabedef3b482cd9aea9434dabcd' )
+key = intermediate[0:64]
 </pre>
-<p>where [i:j] denotes the ith through jth bit including the ith but
-excluding the jth.  The resulting key in hex is <tt class="docutils literal"><span class="pre">f36e9cae87cf33e0</span></tt>.</p>
+<p>where [i:j] denotes the ith through <em>jth</em> bit including the <em>ith</em> but
+excluding the <em>jth</em>.  The resulting key in hex is <tt class="docutils literal"><span class="pre">f36e9cae87cf33e0</span></tt>.</p>
 <p>A 64-bit key is used to avoid U.S. export restrictions.</p>
 <p>It is RECOMMENDED that the tracker use the initialization vector, and
@@ -148 +149 @@
 </div>
 <div class="section" id="optimizations">
-<h1>optimizations</h1>
+<h1>Optimizations</h1>
 <p>The described optimizations are OPTIONAL for the tracker, but the
-corresponding client-side MUST be implemented by those that support
-this extension.  These extensions hobble the strength of the RC4
+corresponding client-side MUST be implemented by clients that support
+this extension.  These optimizations hobble the strength of the RC4
 encryption in order to improve tracker performance.  In the <a class="reference internal" href="#rationale">rationale</a>
 section we discuss why hobbling RC4 is reasonable and in many cases
@@ -170 +171 @@
 <p>The tracker MAY also cache the encrypted tracker peer list.  To
 support this the tracker must pass two additional keys <em>i</em> and <em>n</em>
-each with integer values.  Decryption starts by XORing from <em>6i</em> bytes
-for ipv4 (or <em>18i</em> for ipv6) into the pseudorandom string.  Assuming
+each with 32-bit integer values.  If the tracker returns <em>i</em> and <em>n</em>
+then we reserve the first 8 bytes of the RC4 pseudorandom string to
+obscure <em>i</em> and <em>n</em>.  We come back to this momentarily.  Decryption
+starts by XORing from <em>6i</em> bytes for ipv4 (or <em>18i</em> for ipv6) into the
+pseudorandom string after the discarded and reserved bytes.  Assuming
 that the tracker encrypted the tracker peer list starting from the
-first byte in the pseudorandom string then <em>i</em> also corresponds to the
-<em>ith</em> ip-port pair in the tracker peer list and the starting point of
-the copy into the returned request.</p>
+first byte after the discarded and reserved bytes in the pseudorandom
+string then <em>i</em> also corresponds to the <em>ith</em> ip-port pair in the
+tracker peer list and the starting point of the copy into the returned
+request.</p>
 <p>So that the client and the tracker do not have to generate an
 arbitrarily long pseudorandom string to support large swarms, we
 assume the tracker bounds the length of the pseudorandom string and
-reports the length in ip-port pairs as the value to key <em>n</em>.  We
-RECOMMEND that <em>n</em> be equal to the length of the tracker peer list or
-random but within constant factor of the longest peerlist returned by
-the tracker, whichever is smaller.  Thus the tracker encrypts the
-<em>jth</em> byte of the <em>ith</em> ip-port pair in an ipv4 tracker peer list by
-XORing with the byte <em>(6i+j)</em> <cite>mod</cite> <em>n</em> bytes into the pseudorandom
-string.</p>
-<p>Since providing <em>i</em> and <em>n</em> significantly reduces the cost for an
-attacker to recover the pseudorandom string, the tracker MUST XOR the
-value of <em>i</em> with the 32 bits beginning with the 8th least significant
-byte of the infohash and <em>n</em> with the least significant 32 bits of the
-infohash.  We do not use the first 64 bits of the infohash since the
-first 64 bits are used as the RC4 key when not specifying an
-initialization vector.</p>
+reports the length in ip-port pairs as the value to key <em>n</em>.  <em>n</em>
+excludes reserved and discarded bytes.  We RECOMMEND that <em>n</em> be equal
+to the length of the tracker peer list or random but within constant
+factor of the longest peerlist returned by the tracker, whichever is
+smaller.  Thus the tracker encrypts the <em>jth</em> byte of the <em>ith</em>
+ip-port pair in an ipv4 tracker peer list by XORing with the byte
+<em>(6i+j)</em> <cite>mod</cite> <em>n</em> bytes into the pseudorandom string.</p>
+<p>Transmitting <em>i</em> and <em>n</em> as plaintext would significantly reduce the
+cost for an attacker to recover the pseudorandom string.  The tracker
+MUST XOR the value of <em>i</em> with the first 32 bits of the pseudorandom
+string.  The tracker then XORs <em>n</em> with the next 32 bits from the
+pseudorandom string (see Figure 1).</p>
+<div class="figure">
+<img alt="bep_0008_pseudo.png" src="bep_0008_pseudo.png" />
+<p class="caption"><strong>Figure 1:</strong> The first 768 bytes of the RC4 pseudorandom
+string are discarded.  The key <em>i</em> in the tracker response has
+value <tt class="docutils literal"><span class="pre">x</span> <span class="pre">xor</span> <span class="pre">i</span></tt>.  The key <em>n</em> has value <tt class="docutils literal"><span class="pre">y</span> <span class="pre">xor</span> <span class="pre">n</span></tt>.</p>
+</div>
 <p>We describe encryption in the following example for an ipv4 tracker peer
 list consisting of 3 ip-port pairs, and using an RC4 pseudorandom string
 of length <em>n=2</em>. <em>n</em> is small for purposes of illustration.  Also, for the
 purpose of illustration, the tracker returns only 3 peers at a time.</p>
-<dl class="docutils">
-<dt>::</dt>
-<dd><p class="first">Given the following peer list
-(208.72.193.86, 6881), (209.81.173.15,14321), (128.213.6.8, 6881)</p>
-<p>As a packed array represented in hex it becomes</p>
-<p>d048c1561ae1d151ad0f37f180d506081ae1</p>
-<p>which we XOR with an RC4 pseudorandom string, e.g.,</p>
-<p>a496e5f9b83e835013d42226</p>
-<p>to generate</p>
-<p class="last">74de24afa2df5201bedb15d72443e3f1a2df</p>
-</dd>
-</dl>
+<pre class="literal-block">
+Given the following peer list
+(208.72.193.86, 6881), (209.81.173.15,14321), (128.213.6.8, 6881)
+
+As a packed array represented in hex it becomes
+
+d048c1561ae1d151ad0f37f180d506081ae1
+
+which we XOR with an RC4 pseudorandom string excluding discarded and
+reserved bytes, e.g.,
+
+a496e5f9b83e835013d42226
+
+to generate
+
+74de24afa2df5201bedb15d72443e3f1a2df
+</pre>
 <p>Because the RC4 pseudorandom string is shorter than the tracker
 peer list, we wrap to the beginning of the pseudorandom string.</p>
-<blockquote>
-<p>In the first response, the tracker would return</p>
-<p><em>peers=74de24afa2df5201bedb15d7</em>, <em>i=0</em>, <em>n=2</em></p>
-<p>In the second response, the tracker would return</p>
-<p><em>peers=5201bedb15d72443e3f1a2df</em>, <em>i=1</em>, <em>n=2</em></p>
-</blockquote>
+<p>In the first response, the tracker would return:</p>
+<pre class="literal-block">
+peers=74de24afa2df5201bedb15d7, i=0, n=2
+</pre>
+<p>In the second response, the tracker would return:</p>
+<pre class="literal-block">
+peers=5201bedb15d72443e3f1a2df, i=1, n=2
+</pre>
 <p>The tracker response MUST remain a valid bencoded message.</p>
 </div>
 <div class="section" id="backwards-compatibility">
-<h1>backwards compatibility</h1>
+<h1>Backwards Compatibility</h1>
 <p>Trackers that support obfuscation are identified in the .torrent file
 by the inclusion of an <tt class="docutils literal"><span class="pre">obfuscate-announce-list</span></tt> which otherwise has the
@@ -240 +256 @@
 in the same request, since that would defeat the purpose of the shared
 secret.</p>
-<ul class="simple">
-<li>any peer that reports a sha_ih is assumed to implement protocol encryption.</li>
-<li>tracker OPTIONALLY includes a <tt class="docutils literal"><span class="pre">flags</span></tt> key that contains one byte per
-peer in the reported peer list.  The first bit of each byte specifies
-whether the peer support protocol encryption. (How do we protect
-the flags field from modification?)</li>
-<li>if no flags field is present then all peers should be assumed to support protocol encryption</li>
-<li>if a flags field is present then those peers that support protocol
-a</li>
-</ul>
+<p>Any peer that requests with a <tt class="docutils literal"><span class="pre">sha_ih</span></tt> SHOULD implement Message
+Stream Encryption (MSE) <a class="footnote-reference" href="#mse" id="id1">[1]</a>.  Any peer returned from the tracker
+in response to a request with a <tt class="docutils literal"><span class="pre">sha_ih</span></tt> SHOULD be assumed to
+support Message Stream Encryption.  We include these provisions
+because if a peer communicates with another peer without using MSE
+then the BitTorrent protocol is trivially identified from the first
+twenty bytes of the BitTorrent header and the <tt class="docutils literal"><span class="pre">info_hash</span></tt> appears in
+plaintext as the next twenty bytes, hence also defeating the purpose
+of the shared secret.</p>
+<p>If the tracker does not know enough peers that support MSE to return
+the desired number of peers then it MAY include peers that are not
+assumed to support MSE.  If a peer closes a connection in response to
+an encrypted header then the initiating peer should try other peers in
+the peer list returning to the peer that closed the connection only
+when all other peers known or not yet known to support MSE have been
+tried and have failed to provide &quot;adequate performance.&quot;  We
+intentionally omit any definition of &quot;adequate performance.&quot;</p>
 </div>
 <div class="section" id="rationale">
-<h1>rationale</h1>
+<h1>Rationale</h1>
 <p>This extension directly addresses a known attack on the BitTorrent
 protocol performed by some deployed network hardware.  By obscuring
@@ -262 +285 @@
 performed such as severely rate limiting or blocking these
 connections.</p>
-<p>This hardware was presumably deployed to get around <a class="reference external" href="http://www.bittorrent.org/beps/bep_0013.html">BitTorrent
-Protocol Encryption</a> <a class="footnote-reference" href="#id5" id="id6">[2]</a>.  Peers implementing BitTorrent Protocol
+<p>This hardware was presumably deployed to get around BitTorrent
+Message Stream Encryption <a class="footnote-reference" href="#mse" id="id2">[1]</a>.  Peers implementing BitTorrent Message Stream
 Encryption obfuscate peer-to-peer connections by employing RC4
 encryption on every byte from the first byte transferred. BitTorrent
-Protocol Encryption thus increases the difficulty for a device
+Message Stream Encryption thus increases the difficulty for a device
 observing passing packets to identify BitTorrent peer-to-peer
 connections.</p>
@@ -280 +303 @@
 <p>The obfuscation method meets the following criteria:</p>
 <ul class="simple">
-<li>The entire plaintext of the peer list is not easily obtained
-even if an eavesdropper identifies ip-port pairs from
-subsequent connections from a peer that has received a tracker response.</li>
+<li>The entire plaintext of the peer list is not easily obtained even if
+an eavesdropper identifies ip-port pairs from subsequent connections
+initiated by a peer that has received a tracker response.</li>
 <li>Even when a subsequent connection from a peer that has received a
 tracker response is observed by an eavesdropper, it is difficult to
@@ -297 +320 @@
 <p>The objective is NOT to create a cryptographically secure protocol
 that can survive unlimited observation of passing packets and
-substantial computational resources on network timescales.  The object
+substantial computational resources on network timescales.  The objective
 is to raise the bar sufficiently to deter attacks based on observing
 ip-port numbers in peer-to-tracker communications.</p>
@@ -303 +326 @@
 and subsequent connections, it is possible to attack the encryption.
 RC4 is known to have a number of weaknesses especially in the way it
-was used with WEP [and HERE].  However, with tracker peer obfuscation, the
-number of bytes transferred between the tracker and a client is likely
-significantly smaller than transfer between a wireless computer and a
-basestation.  An attacker faces a much larger task in obtaining
-sufficient probable plaintext to directly break the encryption.</p>
+was used with WEP <a class="footnote-reference" href="#borisov" id="id3">[2]</a> <a class="footnote-reference" href="#scott" id="id4">[3]</a> <a class="footnote-reference" href="#stubblefeld" id="id5">[4]</a>.  However,
+with tracker peer obfuscation, the number of bytes transferred between
+the tracker and a client is likely significantly smaller than transferred
+between a wireless computer and a basestation.  An attacker faces a
+much larger task in obtaining sufficient probable plaintext to
+directly break the encryption.</p>
 <p>Hobbling the RC4 encryption by using a bounded-length RC4 pseudorandom
 string for small swarms is likely to have negilgible impact on
@@ -333 +357 @@
 small constant factor more expensive than a shuffle on an input string
 of equal length, 2) the generated pseudorandom string is only <em>n</em>
-bytes long where recommended <em>n</em> is within a small constant factor
-larger than the largest response size and thus much smaller than the
-tracker peer list for large swarms, and 3) the cost of the XOR
-operation is lighter weight than performing a random shuffle.</p>
+ip-port pairs long where recommended <em>n</em> is within a small constant
+factor larger than the largest <em>returned peer list</em> and thus much
+smaller than the <em>tracker peer list</em> for large swarms, and 3) the cost
+of the XOR operation is lighter weight than performing a random
+shuffle.</p>
+</div>
+<div class="section" id="references">
+<h1>References</h1>
+<table class="docutils footnote" frame="void" id="mse" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[1]</td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id2">2</a>)</em> BitTorrent Message Stream Encryption
+(<a class="reference external" href="http://www.azureuswiki.com/index.php/Message_Stream_Encryption">http://www.azureuswiki.com/index.php/Message_Stream_Encryption</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="borisov" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3">[2]</a></td><td>Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting
+mobile communications: the insecurity of 802.11. In ACM MobiCom 2001,
+pages 180-189. ACM Press, 2001.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="scott" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4">[3]</a></td><td>Scott R. Fluhrer, Itsik Mantin, and Adi
+Shamir. Weaknesses in the key scheduling algorithm of RC4. In Serge
+Vaudenay and Amr M. Youssef, editors, Selected Areas in
+Cryptography 2001, volume 2259 of Lecture Notes in Computer
+Science, pages 1-24. Springer, 2001.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="stubblefeld" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5">[4]</a></td><td>Adam Stubblefeld, John Ioannidis, and Aviel
+D. Rubin. A key recovery attack on the 802.11b wired equivalent
+privacy protocol (WEP). ACM Transactions on Information and System
+Security, 7(2):319-332, May 2004.</td></tr>
+</tbody>
+</table>
 <!-- Local Variables:
 mode: indented-text
@@ -344 +406 @@
 coding: utf-8
 End: -->
-</div>
-<div class="section" id="id2">
-<h1>References</h1>
-<table class="docutils footnote" frame="void" id="id3" rules="none">
+<table class="docutils footnote" frame="void" id="id6" rules="none">
 <colgroup><col class="label" /><col /></colgroup>
 <tbody valign="top">
-<tr><td class="label"><a class="fn-backref" href="#id4">[1]</a></td><td><a class="reference external" href="http://tools.ietf.org/html/rfc2119">http://tools.ietf.org/html/rfc2119</a></td></tr>
-</tbody>
-</table>
-<table class="docutils footnote" frame="void" id="id5" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a class="fn-backref" href="#id6">[2]</a></td><td><a class="reference external" href="http://www.bittorrent.org/beps/bep_0013.html">http://www.bittorrent.org/beps/bep_0013.html</a></td></tr>
+<tr><td class="label"><a class="fn-backref" href="#id7">[5]</a></td><td><a class="reference external" href="http://tools.ietf.org/html/rfc2119">http://tools.ietf.org/html/rfc2119</a></td></tr>
 </tbody>
 </table>

dotorg/trunk_fixed/html/beps/bep_0008.rst

@@ -10 +10 @@
 
 This extends the tracker protocol to support simple obfuscation of the
-peers it returns, using the info hash as a shared secret between the
+peers it returns, using the infohash as a shared secret between the
 peer and the tracker. The obfuscation does not provide any security
 against eavesdroppers that know the infohash of the torrent.  The goal
@@ -22 +22 @@
 to be interpreted as described in IETF `RFC 2119`_. 
 
-.. _`RFC 2119`: http://tools.ietf.org/html/rfc2119
-
-
-announce parameter
+
+Announce Parameter
 ==================
 
@@ -45 +43 @@
 in the peer's announce.
 
-announce response
+Announce Response
 =================
 
@@ -56 +54 @@
 These are discussed in the optimizations_ section.
 
-peer list obfuscation
+Peer List Obfuscation
 =====================
 
@@ -78 +76 @@
 recovers the plaintext by generating the same pseudorandom string and
 XOR'ing it with the ciphertext.  In generating the pseudorandom
-string, the tracker and client MUST discard the first 768 bytes.  All
-indices into the pseudorandom string ignore the first 768 bytes, i.e.,
-index 0 refers to the first undiscarded byte.
+string, the tracker and client MUST discard the first 768 bytes.  
 
 To communicate an initialization vector, the tracker includes in the
@@ -90 +86 @@
 of the infohash are used as the RC4 key.  If the tracker provides an
 initialization vector then the RC4 key is generated by appending the
-vector to the infohash and then hashing with sha1.  The first 64 bits
-of the resulting hash are then used as the RC4 key.
+vector to the infohash and then hashing with SHA-1.  The first 64 bits
+of the resulting hash are then used as the RC4 key.  The string from
+which the RC4 key is derived whether it be the infohash or the SHA-1 of
+the initialization vector appended to the infohash is called the
+*intermediate string*.
 
 For example, given infohash ``aaf4c61ddcc5e8a2dabedef3b482cd9aea9434d``
@@ -99 +98 @@
 ::
  
-   hash = sha1( 'aaf4c61ddcc5e8a2dabedef3b482cd9aea9434dabcd' )
-   key = hash[0:64]
-
-where [i:j] denotes the ith through jth bit including the ith but
-excluding the jth.  The resulting key in hex is ``f36e9cae87cf33e0``.
+   intermediate = sha1( 'aaf4c61ddcc5e8a2dabedef3b482cd9aea9434dabcd' )
+   key = intermediate[0:64]
+
+where [i:j] denotes the ith through *jth* bit including the *ith* but
+excluding the *jth*.  The resulting key in hex is ``f36e9cae87cf33e0``.
 
 A 64-bit key is used to avoid U.S. export restrictions. 
@@ -111 +110 @@
 interval.  The reasoning for this is contained in the rationale.
 
-optimizations
+Optimizations
 =============
 
 The described optimizations are OPTIONAL for the tracker, but the
-corresponding client-side MUST be implemented by those that support
-this extension.  These extensions hobble the strength of the RC4
+corresponding client-side MUST be implemented by clients that support
+this extension.  These optimizations hobble the strength of the RC4
 encryption in order to improve tracker performance.  In the rationale_
 section we discuss why hobbling RC4 is reasonable and in many cases
@@ -139 +138 @@
 The tracker MAY also cache the encrypted tracker peer list.  To
 support this the tracker must pass two additional keys *i* and *n*
-each with integer values.  Decryption starts by XORing from *6i* bytes
-for ipv4 (or *18i* for ipv6) into the pseudorandom string.  Assuming
+each with 32-bit integer values.  If the tracker returns *i* and *n*
+then we reserve the first 8 bytes of the RC4 pseudorandom string to
+obscure *i* and *n*.  We come back to this momentarily.  Decryption
+starts by XORing from *6i* bytes for ipv4 (or *18i* for ipv6) into the
+pseudorandom string after the discarded and reserved bytes.  Assuming
 that the tracker encrypted the tracker peer list starting from the
-first byte in the pseudorandom string then *i* also corresponds to the
-*ith* ip-port pair in the tracker peer list and the starting point of
-the copy into the returned request.  
+first byte after the discarded and reserved bytes in the pseudorandom
+string then *i* also corresponds to the *ith* ip-port pair in the
+tracker peer list and the starting point of the copy into the returned
+request.
 
 So that the client and the tracker do not have to generate an
 arbitrarily long pseudorandom string to support large swarms, we
 assume the tracker bounds the length of the pseudorandom string and
-reports the length in ip-port pairs as the value to key *n*.  We
-RECOMMEND that *n* be equal to the length of the tracker peer list or
-random but within constant factor of the longest peerlist returned by
-the tracker, whichever is smaller.  Thus the tracker encrypts the
-*jth* byte of the *ith* ip-port pair in an ipv4 tracker peer list by
-XORing with the byte *(6i+j)* `mod` *n* bytes into the pseudorandom
-string.
-
-Since providing *i* and *n* significantly reduces the cost for an
-attacker to recover the pseudorandom string, the tracker MUST XOR the
-value of *i* with the 32 bits beginning with the 8th least significant
-byte of the infohash and *n* with the least significant 32 bits of the
-infohash.  We do not use the first 64 bits of the infohash since the
-first 64 bits are used as the RC4 key when not specifying an
-initialization vector.
- 
+reports the length in ip-port pairs as the value to key *n*.  *n*
+excludes reserved and discarded bytes.  We RECOMMEND that *n* be equal
+to the length of the tracker peer list or random but within constant
+factor of the longest peerlist returned by the tracker, whichever is
+smaller.  Thus the tracker encrypts the *jth* byte of the *ith*
+ip-port pair in an ipv4 tracker peer list by XORing with the byte
+*(6i+j)* `mod` *n* bytes into the pseudorandom string.
+
+Transmitting *i* and *n* as plaintext would significantly reduce the
+cost for an attacker to recover the pseudorandom string.  The tracker
+MUST XOR the value of *i* with the first 32 bits of the pseudorandom
+string.  The tracker then XORs *n* with the next 32 bits from the
+pseudorandom string (see Figure 1).
+
+.. figure:: bep_0008_pseudo.png
+
+   **Figure 1:** The first 768 bytes of the RC4 pseudorandom
+   string are discarded.  The key *i* in the tracker response has
+   value ``x xor i``.  The key *n* has value ``y xor n``.
+
 We describe encryption in the following example for an ipv4 tracker peer 
 list consisting of 3 ip-port pairs, and using an RC4 pseudorandom string 
@@ -171 +178 @@
 
 ::
+
   Given the following peer list
   (208.72.193.86, 6881), (209.81.173.15,14321), (128.213.6.8, 6881)
@@ -178 +186 @@
   d048c1561ae1d151ad0f37f180d506081ae1 
 
-  which we XOR with an RC4 pseudorandom string, e.g.,
+  which we XOR with an RC4 pseudorandom string excluding discarded and
+  reserved bytes, e.g.,
 
   a496e5f9b83e835013d42226
@@ -189 +198 @@
 peer list, we wrap to the beginning of the pseudorandom string.
 
-  In the first response, the tracker would return
-
-  *peers=74de24afa2df5201bedb15d7*, *i=0*, *n=2*
-
-  In the second response, the tracker would return
-
-  *peers=5201bedb15d72443e3f1a2df*, *i=1*, *n=2*
+In the first response, the tracker would return::
+
+  peers=74de24afa2df5201bedb15d7, i=0, n=2
+
+In the second response, the tracker would return::
+
+  peers=5201bedb15d72443e3f1a2df, i=1, n=2
 
 The tracker response MUST remain a valid bencoded message.
 
-backwards compatibility
+
+Backwards Compatibility
 =======================
 
@@ -226 +236 @@
 secret.
 
-- any peer that reports a sha_ih is assumed to implement protocol encryption.
-- tracker OPTIONALLY includes a ``flags`` key that contains one byte per
-  peer in the reported peer list.  The first bit of each byte specifies
-  whether the peer support protocol encryption. (How do we protect
-  the flags field from modification?)
-- if no flags field is present then all peers should be assumed to support protocol encryption
-- if a flags field is present then those peers that support protocol
-  a 
-
-rationale
+Any peer that requests with a ``sha_ih`` SHOULD implement Message
+Stream Encryption (MSE) [#MSE]_.  Any peer returned from the tracker
+in response to a request with a ``sha_ih`` SHOULD be assumed to
+support Message Stream Encryption.  We include these provisions
+because if a peer communicates with another peer without using MSE
+then the BitTorrent protocol is trivially identified from the first
+twenty bytes of the BitTorrent header and the ``info_hash`` appears in
+plaintext as the next twenty bytes, hence also defeating the purpose
+of the shared secret.
+
+If the tracker does not know enough peers that support MSE to return
+the desired number of peers then it MAY include peers that are not
+assumed to support MSE.  If a peer closes a connection in response to
+an encrypted header then the initiating peer should try other peers in
+the peer list returning to the peer that closed the connection only
+when all other peers known or not yet known to support MSE have been
+tried and have failed to provide "adequate performance."  We
+intentionally omit any definition of "adequate performance."
+
+
+Rationale
 =========
 
@@ -248 +269 @@
 connections.
 
-This hardware was presumably deployed to get around `BitTorrent
-Protocol Encryption`_.  Peers implementing BitTorrent Protocol
+This hardware was presumably deployed to get around BitTorrent
+Message Stream Encryption [#MSE]_.  Peers implementing BitTorrent Message Stream
 Encryption obfuscate peer-to-peer connections by employing RC4
 encryption on every byte from the first byte transferred. BitTorrent
-Protocol Encryption thus increases the difficulty for a device
+Message Stream Encryption thus increases the difficulty for a device
 observing passing packets to identify BitTorrent peer-to-peer
 connections.
@@ -268 +289 @@
 The obfuscation method meets the following criteria:
 
-- The entire plaintext of the peer list is not easily obtained
-  even if an eavesdropper identifies ip-port pairs from
-  subsequent connections from a peer that has received a tracker response.
+- The entire plaintext of the peer list is not easily obtained even if
+  an eavesdropper identifies ip-port pairs from subsequent connections
+  initiated by a peer that has received a tracker response.
 
 - Even when a subsequent connection from a peer that has received a 
@@ -288 +309 @@
 The objective is NOT to create a cryptographically secure protocol
 that can survive unlimited observation of passing packets and
-substantial computational resources on network timescales.  The object
+substantial computational resources on network timescales.  The objective
 is to raise the bar sufficiently to deter attacks based on observing
 ip-port numbers in peer-to-tracker communications.
@@ -295 +316 @@
 and subsequent connections, it is possible to attack the encryption.
 RC4 is known to have a number of weaknesses especially in the way it
-was used with WEP [and HERE].  However, with tracker peer obfuscation, the
-number of bytes transferred between the tracker and a client is likely
-significantly smaller than transfer between a wireless computer and a
-basestation.  An attacker faces a much larger task in obtaining
-sufficient probable plaintext to directly break the encryption.
+was used with WEP [#Borisov]_ [#Scott]_ [#Stubblefeld]_.  However,
+with tracker peer obfuscation, the number of bytes transferred between
+the tracker and a client is likely significantly smaller than transferred
+between a wireless computer and a basestation.  An attacker faces a
+much larger task in obtaining sufficient probable plaintext to
+directly break the encryption.
 
 Hobbling the RC4 encryption by using a bounded-length RC4 pseudorandom
@@ -328 +350 @@
 small constant factor more expensive than a shuffle on an input string
 of equal length, 2) the generated pseudorandom string is only *n*
-bytes long where recommended *n* is within a small constant factor
-larger than the largest response size and thus much smaller than the
-tracker peer list for large swarms, and 3) the cost of the XOR
-operation is lighter weight than performing a random shuffle.
-
+ip-port pairs long where recommended *n* is within a small constant
+factor larger than the largest *returned peer list* and thus much
+smaller than the *tracker peer list* for large swarms, and 3) the cost
+of the XOR operation is lighter weight than performing a random
+shuffle.
+
+References
+==========
 
 .. _`RFC 2119`: http://tools.ietf.org/html/rfc2119
-.. _`BitTorrent Protocol Encryption`: http://www.bittorrent.org/beps/bep_0013.html
+
+.. [#MSE] BitTorrent Message Stream Encryption
+   (http://www.azureuswiki.com/index.php/Message_Stream_Encryption)
+
+.. [#Borisov] Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting 
+   mobile communications: the insecurity of 802.11. In ACM MobiCom 2001, 
+   pages 180-189. ACM Press, 2001.
+
+.. [#Scott] Scott R. Fluhrer, Itsik Mantin, and Adi
+   Shamir. Weaknesses in the key scheduling algorithm of RC4. In Serge
+   Vaudenay and Amr M. Youssef, editors, Selected Areas in
+   Cryptography 2001, volume 2259 of Lecture Notes in Computer
+   Science, pages 1-24. Springer, 2001.
+
+.. [#Stubblefeld] Adam Stubblefeld, John Ioannidis, and Aviel
+   D. Rubin. A key recovery attack on the 802.11b wired equivalent
+   privacy protocol (WEP). ACM Transactions on Information and System
+   Security, 7(2):319-332, May 2004.
 
 

dotorg/trunk_fixed/html/css/bep.css

@@ -1 +1 @@
 /*
-   BitTorrent.org Screen CSS
-   2006 Apr 6, bri
+   BitTorrent.org BEP CSS
 */ 
 
@@ -12 +11 @@
         text-align:center; 
         }
-    
+
 #upper {
     margin:0;
@@ -73 +72 @@
     }
 
+#first p {
+        font-size:3pt;
+        line-height:80pt;
+}
+    
+
 #second li,
 #second dt {
@@ -286 +291 @@
         }
 
+.literal-block {
+        margin-left:4em;
+}
+
+div.figure {
+        margin:2em 4em 1em 4em;
+        text-align: center;
+        font-size: 7pt;
+}
+
+p.caption {
+        text-align: left;
+}
+