cleanup on the EntryGuards entry
Roger Dingledine

Roger Dingledine commited on 2011-02-05 07:11:26
Zeige 1 geänderte Dateien mit 25 Einfügungen und 21 Löschungen.

... ...
@@ -1372,8 +1372,8 @@ the same geographic location.
1372 1372
 <p>
1373 1373
 Tor (like all current practical low-latency anonymity designs) fails
1374 1374
 when the attacker can see both ends of the communications channel. For
1375
-example, suppose the attacker is watching the Tor relay you choose
1376
-to enter the network, and is also watching the website you visit. In
1375
+example, suppose the attacker controls or watches the Tor relay you choose
1376
+to enter the network, and also controls or watches the website you visit. In
1377 1377
 this case, the research community knows no practical low-latency design
1378 1378
 that can reliably stop the attacker from correlating volume and timing
1379 1379
 information on the two sides.
... ...
@@ -1381,31 +1381,34 @@ information on the two sides.
1381 1381
 
1382 1382
 <p>
1383 1383
 So, what should we do? Suppose the attacker controls, or can observe,
1384
-C relays. Suppose there are N relays total.  If you select new entry and
1385
-exit relays each time you use the network, the attacker will be able to
1386
-correlate all traffic you send with probability (c/n)^2^. But profiling
1387
-is, for most users, as bad as being traced all the time: they want to do
1388
-something often without an attacker noticing, and the attacker noticing
1389
-once is as bad as the attacker noticing more often. Thus, choosing many
1390
-random entries and exits gives the user no chance of escaping profiling
1391
-by this kind of attacker.
1384
+<i>C</i> relays. Suppose there are <i>N</i> relays total. If you select
1385
+new entry and exit relays each time you use the network, the attacker
1386
+will be able to correlate all traffic you send with probability
1387
+<i>(c/n)<sup>2</sup></i>. But profiling is, for most users, as bad
1388
+as being traced all the time: they want to do something often without
1389
+an attacker noticing, and the attacker noticing once is as bad as the
1390
+attacker noticing more often. Thus, choosing many random entries and exits
1391
+gives the user no chance of escaping profiling by this kind of attacker.
1392 1392
 </p>
1393 1393
 
1394 1394
 <p>
1395 1395
 The solution is "entry guards": each user selects a few relays at random
1396
-to use as entry points, and uses only those relays for entry.  If those
1397
-relays are not controlled or observed, the attacker can't win, ever,
1398
-and the user is secure.  If those relays *are* observed or controlled
1399
-by the attacker, the attacker sees a larger _fraction_ of the user's
1400
-traffic -- but still the user is no more profiled than before.  Thus,
1401
-the user has some chance (on the order of (n-c)/n) of avoiding profiling,
1402
-whereas she had none before.
1396
+to use as entry points, and uses only those relays for her first hop. If
1397
+those relays are not controlled or observed, the attacker can't win,
1398
+ever, and the user is secure. If those relays <i>are</i> observed or
1399
+controlled by the attacker, the attacker sees a larger <i>fraction</i>
1400
+of the user's traffic &mdash; but still the user is no more profiled than
1401
+before. Thus, the user has some chance (on the order of <i>(n-c)/n</i>)
1402
+of avoiding profiling, whereas she had none before.
1403 1403
 </p>
1404 1404
 
1405 1405
 <p>
1406
-You can read a bit more at http://freehaven.net/anonbib/#wright02,
1407
-http://freehaven.net/anonbib/#wright03, or
1408
-http://freehaven.net/anonbib/#hs-attack06.
1406
+You can read more at <a href="http://freehaven.net/anonbib/#wright02">An
1407
+Analysis of the Degradation of Anonymous Protocols</a>, <a
1408
+href="http://freehaven.net/anonbib/#wright03">Defending Anonymous
1409
+Communication Against Passive Logging Attacks</a>, and especially
1410
+<a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
1411
+Servers</a>.
1409 1412
 </p>
1410 1413
 
1411 1414
 <p>
... ...
@@ -1413,7 +1416,8 @@ Restricting your entry nodes may also help against attackers who want
1413 1416
 to run a few Tor nodes and easily enumerate all of the Tor user IP
1414 1417
 addresses. (Even though they can't learn what destinations the users
1415 1418
 are talking to, they still might be able to do bad things with just a
1416
-list of users.)
1419
+list of users.) However, that feature won't really become useful until
1420
+we move to a "directory guard" design as well.
1417 1421
 </p>
1418 1422
 
1419 1423
     <hr>
1420 1424