[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[or-cvs] r10169: a bit of that manual hacking for tor-design.html too (tor/trunk/doc/design-paper)



Author: arma
Date: 2007-05-11 22:29:10 -0400 (Fri, 11 May 2007)
New Revision: 10169

Modified:
   tor/trunk/doc/design-paper/tor-design.html
Log:
a bit of that manual hacking for tor-design.html too


Modified: tor/trunk/doc/design-paper/tor-design.html
===================================================================
--- tor/trunk/doc/design-paper/tor-design.html	2007-05-12 02:26:46 UTC (rev 10168)
+++ tor/trunk/doc/design-paper/tor-design.html	2007-05-12 02:29:10 UTC (rev 10169)
@@ -49,8 +49,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc1">
+<a name="sec:intro">
 1</a>&nbsp;&nbsp;Overview</h2>
-<a name="sec:intro">
 </a>
 
 <div class="p"><!----></div>
@@ -92,7 +92,7 @@
 <div class="p"><!----></div>
 <b>Separation of "protocol cleaning" from anonymity:</b>
 Onion Routing originally required a separate "application
-proxy" for each supported application protocol-most of which were
+proxy" for each supported application protocol &mdash; most of which were
 never written, so many applications were never supported.  Tor uses the
 standard and near-ubiquitous SOCKS&nbsp;[<a href="#socks4" name="CITEsocks4">32</a>] proxy interface, allowing
 us to support most TCP-based programs without modification.  Tor now
@@ -130,7 +130,7 @@
 <b>Leaky-pipe circuit topology:</b> Through in-band signaling
 within the circuit, Tor initiators can direct traffic to nodes partway
 down the circuit. This novel approach
-allows traffic to exit the circuit from the middle-possibly
+allows traffic to exit the circuit from the middle &mdash; possibly
 frustrating traffic shape and volume attacks based on observing the end
 of the circuit. (It also allows for long-range padding if
 future research shows this to be worthwhile.)
@@ -146,7 +146,7 @@
 
 <div class="p"><!----></div>
 <b>Directory servers:</b> The earlier Onion Routing design
-planned to flood state information through the network-an approach
+planned to flood state information through the network &mdash; an approach
 that can be unreliable and complex. Tor takes a simplified view toward distributing this
 information. Certain more trusted nodes act as <em>directory
 servers</em>: they provide signed directories describing known
@@ -164,7 +164,7 @@
 <div class="p"><!----></div>
 <b>End-to-end integrity checking:</b> The original Onion Routing
 design did no integrity checking on data. Any node on the
-circuit could change the contents of data cells as they passed by-for
+circuit could change the contents of data cells as they passed by &mdash; for
 example, to alter a connection request so it would connect
 to a different webserver, or to `tag' encrypted traffic and look for
 corresponding corrupted traffic at the network edges&nbsp;[<a href="#minion-design" name="CITEminion-design">15</a>].
@@ -218,8 +218,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc2">
+<a name="sec:related-work">
 2</a>&nbsp;&nbsp;Related work</h2>
-<a name="sec:related-work">
 </a>
 
 <div class="p"><!----></div>
@@ -377,8 +377,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc3">
+<a name="sec:assumptions">
 3</a>&nbsp;&nbsp;Design goals and assumptions</h2>
-<a name="sec:assumptions">
 </a>
 
 <div class="p"><!----></div>
@@ -404,7 +404,7 @@
 however; see Section&nbsp;<a href="#sec:rendezvous">5</a>.)
 
 <div class="p"><!----></div>
-<b>Usability:</b> A hard-to-use system has fewer users-and because
+<b>Usability:</b> A hard-to-use system has fewer users &mdash; and because
 anonymity systems hide users among users, a system with fewer users
 provides less anonymity.  Usability is thus not only a convenience:
 it is a security requirement&nbsp;[<a href="#econymics" name="CITEeconymics">1</a>,<a href="#back01" name="CITEback01">5</a>]. Tor should
@@ -474,8 +474,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc3.1">
+<a name="subsec:threat-model">
 3.1</a>&nbsp;&nbsp;Threat Model</h3>
-<a name="subsec:threat-model">
 </a>
 
 <div class="p"><!----></div>
@@ -504,7 +504,7 @@
 Our adversary might try to link an initiator Alice with her
 communication partners, or try to build a profile of Alice's
 behavior. He might mount passive attacks by observing the network edges
-and correlating traffic entering and leaving the network-by
+and correlating traffic entering and leaving the network &mdash; by
 relationships in packet timing, volume, or externally visible
 user-selected
 options. The adversary can also mount active attacks by compromising
@@ -516,7 +516,7 @@
 detected. The adversary might subvert the directory servers to give users
 differing views of network state. Additionally, he can try to decrease
 the network's reliability by attacking nodes or by performing antisocial
-activities from reliable nodes and trying to get them taken down-making
+activities from reliable nodes and trying to get them taken down &mdash; making
 the network unreliable flushes users to other less anonymous
 systems, where they may be easier to attack. We summarize
 in Section&nbsp;<a href="#sec:attacks">7</a> how well the Tor design defends against
@@ -526,8 +526,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc4">
+<a name="sec:design">
 4</a>&nbsp;&nbsp;The Tor Design</h2>
-<a name="sec:design">
 </a>
 
 <div class="p"><!----></div>
@@ -570,8 +570,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc4.1">
+<a name="subsec:cells">
 4.1</a>&nbsp;&nbsp;Cells</h3>
-<a name="subsec:cells">
 </a>
 
 <div class="p"><!----></div>
@@ -627,8 +627,8 @@
 </center>
 <div class="p"><!----></div>
      <h3><a name="tth_sEc4.2">
+<a name="subsec:circuits">
 4.2</a>&nbsp;&nbsp;Circuits and streams</h3>
-<a name="subsec:circuits">
 </a>
 
 <div class="p"><!----></div>
@@ -662,8 +662,9 @@
 </a>
 </center>
 <div class="p"><!----></div>
-<font size="+1"><b>Constructing a circuit</b></font><a name="subsubsec:constructing-a-circuit">
-</a><br />
+<a name="subsubsec:constructing-a-circuit"></a>
+<font size="+1"><b>Constructing a circuit</b></font>
+<br />
 A user's OP constructs circuits incrementally, negotiating a
 symmetric key with each OR on the circuit, one hop at a time. To begin
 creating a new circuit, the OP (call her Alice) sends a
@@ -704,7 +705,7 @@
 <div class="p"><!----></div>
 This circuit-level handshake protocol achieves unilateral entity
 authentication (Alice knows she's handshaking with the OR, but
-the OR doesn't care who is opening the circuit-Alice uses no public key
+the OR doesn't care who is opening the circuit &mdash; Alice uses no public key
 and remains anonymous) and unilateral key authentication
 (Alice and the OR agree on a key, and Alice knows only the OR learns
 it). It also achieves forward
@@ -797,8 +798,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc4.3">
+<a name="subsec:tcp">
 4.3</a>&nbsp;&nbsp;Opening and closing streams</h3>
-<a name="subsec:tcp">
 </a>
 
 <div class="p"><!----></div>
@@ -818,7 +819,7 @@
 the chosen OR.
 
 <div class="p"><!----></div>
-There's a catch to using SOCKS, however-some applications pass the
+There's a catch to using SOCKS, however &mdash; some applications pass the
 alphanumeric hostname to the Tor client, while others resolve it into
 an IP address first and then pass the IP address to the Tor client. If
 the application does DNS resolution first, Alice thereby reveals her
@@ -855,8 +856,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc4.4">
+<a name="subsec:integrity-checking">
 4.4</a>&nbsp;&nbsp;Integrity checking on streams</h3>
-<a name="subsec:integrity-checking">
 </a>
 
 <div class="p"><!----></div>
@@ -920,8 +921,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc4.5">
+<a name="subsec:rate-limit">
 4.5</a>&nbsp;&nbsp;Rate limiting and fairness</h3>
-<a name="subsec:rate-limit">
 </a>
 
 <div class="p"><!----></div>
@@ -955,8 +956,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc4.6">
+<a name="subsec:congestion">
 4.6</a>&nbsp;&nbsp;Congestion control</h3>
-<a name="subsec:congestion">
 </a>
 
 <div class="p"><!----></div>
@@ -1018,8 +1019,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc5">
+<a name="sec:rendezvous">
 5</a>&nbsp;&nbsp;Rendezvous Points and hidden services</h2>
-<a name="sec:rendezvous">
 </a>
 
 <div class="p"><!----></div>
@@ -1144,7 +1145,7 @@
 the Tor rendezvous system.
 
 <div class="p"><!----></div>
-Bob's introduction points are themselves subject to DoS-he must
+Bob's introduction points are themselves subject to DoS &mdash; he must
 open many introduction points or risk such an attack.
 He can provide selected users with a current list or future schedule of
 unadvertised introduction points;
@@ -1170,7 +1171,7 @@
 and doesn't even know that it's hidden behind the Tor network.
 
 <div class="p"><!----></div>
-Alice's applications also work unchanged-her client interface
+Alice's applications also work unchanged &mdash; her client interface
 remains a SOCKS proxy.  We encode all of the necessary information
 into the fully qualified domain name (FQDN) Alice uses when establishing her
 connection. Location-hidden services use a virtual top level domain
@@ -1205,20 +1206,20 @@
 services. Tor's introduction points do not output any bytes to the
 clients; the rendezvous points don't know the client or the server,
 and can't read the data being transmitted. The indirection scheme is
-also designed to include authentication/authorization-if Alice doesn't
+also designed to include authentication/authorization &mdash; if Alice doesn't
 include the right cookie with her request for service, Bob need not even
 acknowledge his existence.
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc6">
+<a name="sec:other-design">
 6</a>&nbsp;&nbsp;Other design decisions</h2>
-<a name="sec:other-design">
 </a>
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc6.1">
+<a name="subsec:dos">
 6.1</a>&nbsp;&nbsp;Denial of service</h3>
-<a name="subsec:dos">
 </a>
 
 <div class="p"><!----></div>
@@ -1270,8 +1271,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc6.2">
+<a name="subsec:exitpolicies">
 6.2</a>&nbsp;&nbsp;Exit policies and abuse</h3>
-<a name="subsec:exitpolicies">
 </a>
 
 <div class="p"><!----></div>
@@ -1304,7 +1305,7 @@
 nodes that only relay traffic to other Tor nodes, and <em>private exit</em>
 nodes that only connect to a local host or network.  A private
 exit can allow a client to connect to a given host or
-network more securely-an external adversary cannot eavesdrop traffic
+network more securely &mdash; an external adversary cannot eavesdrop traffic
 between the private exit and the final destination, and so is less sure of
 Alice's destination and activities. Most onion routers in the current
 network function as
@@ -1348,7 +1349,7 @@
 greater burden on the exit nodes.  This tension can be seen in the
 Java Anon Proxy
 cascade model, wherein only one node in each cascade needs to handle
-abuse complaints-but an adversary only needs to observe the entry
+abuse complaints &mdash; but an adversary only needs to observe the entry
 and exit of a cascade to perform traffic analysis on all that
 cascade's users. The hydra model (many entries, few exits) presents a
 different compromise: only a few exit nodes are needed, but an
@@ -1367,8 +1368,8 @@
 
 <div class="p"><!----></div>
      <h3><a name="tth_sEc6.3">
+<a name="subsec:dirservers">
 6.3</a>&nbsp;&nbsp;Directory Servers</h3>
-<a name="subsec:dirservers">
 </a>
 
 <div class="p"><!----></div>
@@ -1403,7 +1404,7 @@
 <div class="p"><!----></div>
 When a directory server receives a signed statement for an OR, it
 checks whether the OR's identity key is recognized. Directory
-servers do not advertise unrecognized ORs-if they did,
+servers do not advertise unrecognized ORs &mdash; if they did,
 an adversary could take over the network by creating many
 servers&nbsp;[<a href="#sybil" name="CITEsybil">22</a>]. Instead, new nodes must be approved by the
 directory
@@ -1414,7 +1415,7 @@
 <div class="p"><!----></div>
 Of course, a variety of attacks remain. An adversary who controls
 a directory server can track clients by providing them different
-information-perhaps by listing only nodes under its control, or by
+information &mdash; perhaps by listing only nodes under its control, or by
 informing only certain clients about a given node. Even an external
 adversary can exploit differences in client knowledge: clients who use
 a node listed on one directory server but not the others are vulnerable.
@@ -1460,8 +1461,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc7">
+<a name="sec:attacks">
 7</a>&nbsp;&nbsp;Attacks and Defenses</h2>
-<a name="sec:attacks">
 </a>
 
 <div class="p"><!----></div>
@@ -1558,7 +1559,7 @@
 keys, the attacker cannot force nodes to decrypt recorded
 traffic once the circuits have been closed.)  Additionally, building
 circuits that cross jurisdictions can make legal coercion
-harder-this phenomenon is commonly called "jurisdictional
+harder &mdash; this phenomenon is commonly called "jurisdictional
 arbitrage." The Java Anon Proxy project recently experienced the
 need for this approach, when
 a German court forced them to add a backdoor to
@@ -1580,7 +1581,7 @@
 <em>Run an onion proxy.</em> It is expected that end users will
 nearly always run their own local onion proxy. However, in some
 settings, it may be necessary for the proxy to run
-remotely-typically, in institutions that want
+remotely &mdash; typically, in institutions that want
 to monitor the activity of those connecting to the proxy.
 Compromising an onion proxy compromises all future connections
 through it.
@@ -1603,7 +1604,7 @@
 some user will choose one of those ORs for the start and another
 as the end of a circuit. If an adversary
 controls m &gt; 1 of N nodes, he can correlate at most
-([m/N])<sup>2</sup> of the traffic-although an
+([m/N])<sup>2</sup> of the traffic &mdash; although an
 adversary
 could still attract a disproportionately large amount of traffic
 by running an OR with a permissive exit policy, or by
@@ -1644,7 +1645,7 @@
 <div class="p"><!----></div>
 <em>Distribute hostile code.</em> An attacker could trick users
 into running subverted Tor software that did not, in fact, anonymize
-their connections-or worse, could trick ORs into running weakened
+their connections &mdash; or worse, could trick ORs into running weakened
 software that provided users with less anonymity.  We address this
 problem (but do not solve it completely) by signing all Tor releases
 with an official public key, and including an entry in the directory
@@ -1741,8 +1742,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc8">
+<a name="sec:in-the-wild">
 8</a>&nbsp;&nbsp;Early experiences: Tor in the Wild</h2>
-<a name="sec:in-the-wild">
 </a>
 
 <div class="p"><!----></div>
@@ -1751,7 +1752,7 @@
 matures. (For comparison, the current remailer network
 has about 40 nodes.) Each node has at least a 768Kb/768Kb connection, and
 many have 10Mb. The number of users varies (and of course, it's hard to
-tell for sure), but we sometimes have several hundred users-administrators at
+tell for sure), but we sometimes have several hundred users &mdash; administrators at
 several companies have begun sending their entire departments' web
 traffic through Tor, to block other divisions of
 their company from reading their traffic. Tor users have reported using
@@ -1766,7 +1767,7 @@
 of each 498-byte payload is full for cells going back to the client,
 whereas about 40% is full for cells coming from the client. (The difference
 arises because most of the network's traffic is web browsing.) Interactive
-traffic like SSH brings down the average a lot-once we have more
+traffic like SSH brings down the average a lot &mdash; once we have more
 experience, and assuming we can resolve the anonymity issues, we may
 partition traffic into two relay cell sizes: one to handle
 bulk traffic and one for interactive traffic.
@@ -1779,7 +1780,7 @@
 resolve bugs, and get a feel for what users actually want from an
 anonymity system.  Even though having more users would bolster our
 anonymity sets, we are not eager to attract the Kazaa or warez
-communities-we feel that we must build a reputation for privacy, human
+communities &mdash; we feel that we must build a reputation for privacy, human
 rights, research, and other socially laudable activities.
 
 <div class="p"><!----></div>
@@ -1816,8 +1817,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc9">
+<a name="sec:maintaining-anonymity">
 9</a>&nbsp;&nbsp;Open Questions in Low-latency Anonymity</h2>
-<a name="sec:maintaining-anonymity">
 </a>
 
 <div class="p"><!----></div>
@@ -1913,7 +1914,7 @@
 does the method in Section&nbsp;<a href="#subsec:dos">6.1</a> allow streams to survive
 node failure? If affected users rebuild circuits immediately, how much
 anonymity is lost? It seems the problem is even worse in a peer-to-peer
-environment-such systems don't yet provide an incentive for peers to
+environment &mdash; such systems don't yet provide an incentive for peers to
 stay connected when they're done retrieving content, so we would expect
 a higher churn rate.
 
@@ -1921,8 +1922,8 @@
 
 <div class="p"><!----></div>
  <h2><a name="tth_sEc10">
+<a name="sec:conclusion">
 10</a>&nbsp;&nbsp;Future Directions</h2>
-<a name="sec:conclusion">
 </a>
 
 <div class="p"><!----></div>
@@ -1955,7 +1956,7 @@
 why most people don't bother using privacy systems.
 
 <div class="p"><!----></div>
-<em>Cover traffic:</em> Currently Tor omits cover traffic-its costs
+<em>Cover traffic:</em> Currently Tor omits cover traffic &mdash; its costs
 in performance and bandwidth are clear but its security benefits are
 not well understood. We must pursue more research on link-level cover
 traffic and long-range cover traffic to determine whether some simple padding
@@ -2484,3 +2485,4 @@
 T<sub><font size="-1">T</font></sub>H</a>,
 version 3.59.<br />On 18 May 2004, 10:45.</small>
 </body></html>
+