Changeset 10560 for dotorg/trunk_fixed/html/beps/bep_0008.rst
- Timestamp:
- 02/06/2008 02:55:28 AM (11 months ago)
- Files:
-
- 1 modified
-
dotorg/trunk_fixed/html/beps/bep_0008.rst (modified) (18 diffs)
Legend:
- Unmodified
- Added
- Removed
-
dotorg/trunk_fixed/html/beps/bep_0008.rst
r10528 r10560 10 10 11 11 This extends the tracker protocol to support simple obfuscation of the 12 peers it returns, using the info 12 peers it returns, using the infohash as a shared secret between the 13 13 peer and the tracker. The obfuscation does not provide any security 14 14 against eavesdroppers that know the infohash of the torrent. The goal … … 22 22 to be interpreted as described in IETF `RFC 2119`_. 23 23 24 .. _`RFC 2119`: http://tools.ietf.org/html/rfc2119 25 26 27 announce parameter 24 25 Announce Parameter 28 26 ================== 29 27 … … 45 43 in the peer's announce. 46 44 47 announce response45 Announce Response 48 46 ================= 49 47 … … 56 54 These are discussed in the optimizations_ section. 57 55 58 peer list obfuscation56 Peer List Obfuscation 59 57 ===================== 60 58 … … 78 76 recovers the plaintext by generating the same pseudorandom string and 79 77 XOR'ing it with the ciphertext. In generating the pseudorandom 80 string, the tracker and client MUST discard the first 768 bytes. All 81 indices into the pseudorandom string ignore the first 768 bytes, i.e., 82 index 0 refers to the first undiscarded byte. 78 string, the tracker and client MUST discard the first 768 bytes. 83 79 84 80 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 91 87 initialization vector then the RC4 key is generated by appending the 92 vector to the infohash and then hashing with sha1. The first 64 bits 93 of the resulting hash are then used as the RC4 key. 88 vector to the infohash and then hashing with SHA-1. The first 64 bits 89 of the resulting hash are then used as the RC4 key. The string from 90 which the RC4 key is derived whether it be the infohash or the SHA-1 of 91 the initialization vector appended to the infohash is called the 92 *intermediate string*. 94 93 95 94 For example, given infohash ``aaf4c61ddcc5e8a2dabedef3b482cd9aea9434d`` … … 99 98 :: 100 99 101 hash= sha1( 'aaf4c61ddcc5e8a2dabedef3b482cd9aea9434dabcd' )102 key = hash[0:64]103 104 where [i:j] denotes the ith through jth bit including the ithbut105 excluding the jth. The resulting key in hex is ``f36e9cae87cf33e0``.100 intermediate = sha1( 'aaf4c61ddcc5e8a2dabedef3b482cd9aea9434dabcd' ) 101 key = intermediate[0:64] 102 103 where [i:j] denotes the ith through *jth* bit including the *ith* but 104 excluding the *jth*. The resulting key in hex is ``f36e9cae87cf33e0``. 106 105 107 106 A 64-bit key is used to avoid U.S. export restrictions. … … 111 110 interval. The reasoning for this is contained in the rationale. 112 111 113 optimizations112 Optimizations 114 113 ============= 115 114 116 115 The described optimizations are OPTIONAL for the tracker, but the 117 corresponding client-side MUST be implemented by thosethat support118 this extension. These extensions hobble the strength of the RC4116 corresponding client-side MUST be implemented by clients that support 117 this extension. These optimizations hobble the strength of the RC4 119 118 encryption in order to improve tracker performance. In the rationale_ 120 119 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 140 139 support this the tracker must pass two additional keys *i* and *n* 141 each with integer values. Decryption starts by XORing from *6i* bytes 142 for ipv4 (or *18i* for ipv6) into the pseudorandom string. Assuming 140 each with 32-bit integer values. If the tracker returns *i* and *n* 141 then we reserve the first 8 bytes of the RC4 pseudorandom string to 142 obscure *i* and *n*. We come back to this momentarily. Decryption 143 starts by XORing from *6i* bytes for ipv4 (or *18i* for ipv6) into the 144 pseudorandom string after the discarded and reserved bytes. Assuming 143 145 that the tracker encrypted the tracker peer list starting from the 144 first byte in the pseudorandom string then *i* also corresponds to the 145 *ith* ip-port pair in the tracker peer list and the starting point of 146 the copy into the returned request. 146 first byte after the discarded and reserved bytes in the pseudorandom 147 string then *i* also corresponds to the *ith* ip-port pair in the 148 tracker peer list and the starting point of the copy into the returned 149 request. 147 150 148 151 So that the client and the tracker do not have to generate an 149 152 arbitrarily long pseudorandom string to support large swarms, we 150 153 assume the tracker bounds the length of the pseudorandom string and 151 reports the length in ip-port pairs as the value to key *n*. We 152 RECOMMEND that *n* be equal to the length of the tracker peer list or 153 random but within constant factor of the longest peerlist returned by 154 the tracker, whichever is smaller. Thus the tracker encrypts the 155 *jth* byte of the *ith* ip-port pair in an ipv4 tracker peer list by 156 XORing with the byte *(6i+j)* `mod` *n* bytes into the pseudorandom 157 string. 158 159 Since providing *i* and *n* significantly reduces the cost for an 160 attacker to recover the pseudorandom string, the tracker MUST XOR the 161 value of *i* with the 32 bits beginning with the 8th least significant 162 byte of the infohash and *n* with the least significant 32 bits of the 163 infohash. We do not use the first 64 bits of the infohash since the 164 first 64 bits are used as the RC4 key when not specifying an 165 initialization vector. 166 154 reports the length in ip-port pairs as the value to key *n*. *n* 155 excludes reserved and discarded bytes. We RECOMMEND that *n* be equal 156 to the length of the tracker peer list or random but within constant 157 factor of the longest peerlist returned by the tracker, whichever is 158 smaller. Thus the tracker encrypts the *jth* byte of the *ith* 159 ip-port pair in an ipv4 tracker peer list by XORing with the byte 160 *(6i+j)* `mod` *n* bytes into the pseudorandom string. 161 162 Transmitting *i* and *n* as plaintext would significantly reduce the 163 cost for an attacker to recover the pseudorandom string. The tracker 164 MUST XOR the value of *i* with the first 32 bits of the pseudorandom 165 string. The tracker then XORs *n* with the next 32 bits from the 166 pseudorandom string (see Figure 1). 167 168 .. figure:: bep_0008_pseudo.png 169 170 **Figure 1:** The first 768 bytes of the RC4 pseudorandom 171 string are discarded. The key *i* in the tracker response has 172 value ``x xor i``. The key *n* has value ``y xor n``. 173 167 174 We describe encryption in the following example for an ipv4 tracker peer 168 175 list consisting of 3 ip-port pairs, and using an RC4 pseudorandom string … … 171 178 172 179 :: 180 173 181 Given the following peer list 174 182 (208.72.193.86, 6881), (209.81.173.15,14321), (128.213.6.8, 6881) … … 178 186 d048c1561ae1d151ad0f37f180d506081ae1 179 187 180 which we XOR with an RC4 pseudorandom string, e.g., 188 which we XOR with an RC4 pseudorandom string excluding discarded and 189 reserved bytes, e.g., 181 190 182 191 a496e5f9b83e835013d42226 … … 189 198 peer list, we wrap to the beginning of the pseudorandom string. 190 199 191 In the first response, the tracker would return 192 193 *peers=74de24afa2df5201bedb15d7*, *i=0*, *n=2*194 195 In the second response, the tracker would return 196 197 *peers=5201bedb15d72443e3f1a2df*, *i=1*, *n=2*200 In the first response, the tracker would return:: 201 202 peers=74de24afa2df5201bedb15d7, i=0, n=2 203 204 In the second response, the tracker would return:: 205 206 peers=5201bedb15d72443e3f1a2df, i=1, n=2 198 207 199 208 The tracker response MUST remain a valid bencoded message. 200 209 201 backwards compatibility 210 211 Backwards Compatibility 202 212 ======================= 203 213 … … 226 236 secret. 227 237 228 - any peer that reports a sha_ih is assumed to implement protocol encryption. 229 - tracker OPTIONALLY includes a ``flags`` key that contains one byte per 230 peer in the reported peer list. The first bit of each byte specifies 231 whether the peer support protocol encryption. (How do we protect 232 the flags field from modification?) 233 - if no flags field is present then all peers should be assumed to support protocol encryption 234 - if a flags field is present then those peers that support protocol 235 a 236 237 rationale 238 Any peer that requests with a ``sha_ih`` SHOULD implement Message 239 Stream Encryption (MSE) [#MSE]_. Any peer returned from the tracker 240 in response to a request with a ``sha_ih`` SHOULD be assumed to 241 support Message Stream Encryption. We include these provisions 242 because if a peer communicates with another peer without using MSE 243 then the BitTorrent protocol is trivially identified from the first 244 twenty bytes of the BitTorrent header and the ``info_hash`` appears in 245 plaintext as the next twenty bytes, hence also defeating the purpose 246 of the shared secret. 247 248 If the tracker does not know enough peers that support MSE to return 249 the desired number of peers then it MAY include peers that are not 250 assumed to support MSE. If a peer closes a connection in response to 251 an encrypted header then the initiating peer should try other peers in 252 the peer list returning to the peer that closed the connection only 253 when all other peers known or not yet known to support MSE have been 254 tried and have failed to provide "adequate performance." We 255 intentionally omit any definition of "adequate performance." 256 257 258 Rationale 238 259 ========= 239 260 … … 248 269 connections. 249 270 250 This hardware was presumably deployed to get around `BitTorrent251 Protocol Encryption`_. Peers implementing BitTorrent Protocol 271 This hardware was presumably deployed to get around BitTorrent 272 Message Stream Encryption [#MSE]_. Peers implementing BitTorrent Message Stream 252 273 Encryption obfuscate peer-to-peer connections by employing RC4 253 274 encryption on every byte from the first byte transferred. BitTorrent 254 ProtocolEncryption thus increases the difficulty for a device275 Message Stream Encryption thus increases the difficulty for a device 255 276 observing passing packets to identify BitTorrent peer-to-peer 256 277 connections. … … 268 289 The obfuscation method meets the following criteria: 269 290 270 - The entire plaintext of the peer list is not easily obtained 271 even if an eavesdropper identifies ip-port pairs from272 subsequent connections froma peer that has received a tracker response.291 - The entire plaintext of the peer list is not easily obtained even if 292 an eavesdropper identifies ip-port pairs from subsequent connections 293 initiated by a peer that has received a tracker response. 273 294 274 295 - Even when a subsequent connection from a peer that has received a … … 288 309 The objective is NOT to create a cryptographically secure protocol 289 310 that can survive unlimited observation of passing packets and 290 substantial computational resources on network timescales. The object 311 substantial computational resources on network timescales. The objective 291 312 is to raise the bar sufficiently to deter attacks based on observing 292 313 ip-port numbers in peer-to-tracker communications. … … 295 316 and subsequent connections, it is possible to attack the encryption. 296 317 RC4 is known to have a number of weaknesses especially in the way it 297 was used with WEP [and HERE]. However, with tracker peer obfuscation, the 298 number of bytes transferred between the tracker and a client is likely 299 significantly smaller than transfer between a wireless computer and a 300 basestation. An attacker faces a much larger task in obtaining 301 sufficient probable plaintext to directly break the encryption. 318 was used with WEP [#Borisov]_ [#Scott]_ [#Stubblefeld]_. However, 319 with tracker peer obfuscation, the number of bytes transferred between 320 the tracker and a client is likely significantly smaller than transferred 321 between a wireless computer and a basestation. An attacker faces a 322 much larger task in obtaining sufficient probable plaintext to 323 directly break the encryption. 302 324 303 325 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 329 351 of equal length, 2) the generated pseudorandom string is only *n* 330 bytes long where recommended *n* is within a small constant factor 331 larger than the largest response size and thus much smaller than the 332 tracker peer list for large swarms, and 3) the cost of the XOR 333 operation is lighter weight than performing a random shuffle. 334 352 ip-port pairs long where recommended *n* is within a small constant 353 factor larger than the largest *returned peer list* and thus much 354 smaller than the *tracker peer list* for large swarms, and 3) the cost 355 of the XOR operation is lighter weight than performing a random 356 shuffle. 357 358 References 359 ========== 335 360 336 361 .. _`RFC 2119`: http://tools.ietf.org/html/rfc2119 337 .. _`BitTorrent Protocol Encryption`: http://www.bittorrent.org/beps/bep_0013.html 362 363 .. [#MSE] BitTorrent Message Stream Encryption 364 (http://www.azureuswiki.com/index.php/Message_Stream_Encryption) 365 366 .. [#Borisov] Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting 367 mobile communications: the insecurity of 802.11. In ACM MobiCom 2001, 368 pages 180-189. ACM Press, 2001. 369 370 .. [#Scott] Scott R. Fluhrer, Itsik Mantin, and Adi 371 Shamir. Weaknesses in the key scheduling algorithm of RC4. In Serge 372 Vaudenay and Amr M. Youssef, editors, Selected Areas in 373 Cryptography 2001, volume 2259 of Lecture Notes in Computer 374 Science, pages 1-24. Springer, 2001. 375 376 .. [#Stubblefeld] Adam Stubblefeld, John Ioannidis, and Aviel 377 D. Rubin. A key recovery attack on the 802.11b wired equivalent 378 privacy protocol (WEP). ACM Transactions on Information and System 379 Security, 7(2):319-332, May 2004. 338 380 339 381
