Browse code

import EntryGuards faq entry

Roger Dingledine authored on 05/02/2011 07:04:03
Showing 1 changed files
... ...
@@ -79,6 +79,7 @@
79 79
     <p>Anonymity and Security:</p>
80 80
     <ul>
81 81
     <li><a href="#KeyManagement">Tell me about all the keys Tor uses.</a></li>
82
+    <li><a href="#EntryGuards">What are Entry Guards?</a></li>
82 83
     </ul>
83 84
 
84 85
     <p>Alternate designs that we don't do (yet):</p>
... ...
@@ -1363,6 +1364,60 @@ the same geographic location.
1363 1364
 
1364 1365
     <hr>
1365 1366
 
1367
+[https://www.torproject.org/docs/faq#EntryGuards Answer moved to our new FAQ page]
1368
+
1369
+<a id="EntryGuards"></a>
1370
+<h3><a class="anchor" href="#EntryGuards">What are Entry Guards?</a></h3>
1371
+
1372
+<p>
1373
+Tor (like all current practical low-latency anonymity designs) fails
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
1377
+this case, the research community knows no practical low-latency design
1378
+that can reliably stop the attacker from correlating volume and timing
1379
+information on the two sides.
1380
+</p>
1381
+
1382
+<p>
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.
1392
+</p>
1393
+
1394
+<p>
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.
1403
+</p>
1404
+
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.
1409
+</p>
1410
+
1411
+<p>
1412
+Restricting your entry nodes may also help against attackers who want
1413
+to run a few Tor nodes and easily enumerate all of the Tor user IP
1414
+addresses. (Even though they can't learn what destinations the users
1415
+are talking to, they still might be able to do bad things with just a
1416
+list of users.)
1417
+</p>
1418
+
1419
+    <hr>
1420
+
1366 1421
     <a id="EverybodyARelay"></a>
1367 1422
     <h3><a class="anchor" href="#EverybodyARelay">You should make every Tor
1368 1423
     user be a relay.</a></h3>