Content-Type: multipart/related; start=<tor-design.mhtml>; boundary=----------v0WB7ELziomGaMwnGQQbCY
Content-Location: https://svn.torproject.org/svn/projects/design-paper/tor-design.html
Subject: =?utf-8?Q?Tor:=20The=20Second-Generation=20Onion=20Router?=
MIME-Version: 1.0

------------v0WB7ELziomGaMwnGQQbCY
Content-Disposition: inline; filename=tor-design.html
Content-Type: text/html; name=tor-design.html
Content-ID: <tor-design.mhtml>
Content-Location: https://svn.torproject.org/svn/projects/design-paper/tor-design.html
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
           "DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="GENERATOR" content="TtH 3.59" />
 <style type="text/css"> div.p { margin-top: 7pt;}</style>
 <style type="text/css"><!--
 td div.comp { margin-top: -0.6ex; margin-bottom: -1ex;}
 td div.comb { margin-top: -0.6ex; margin-bottom: -.6ex;}
 td div.hrcomp { line-height: 0.9; margin-top: -0.8ex; margin-bottom: -1ex;}
 td div.norm {line-height:normal;}
 span.roman {font-family: serif; font-style: normal; font-weight: normal;} 
 span.overacc2 {position: relative;  left: .8em; top: -1.2ex;}
 span.overacc1 {position: relative;  left: .6em; top: -1.2ex;} --></style>

         
<title> Tor: The Second-Generation Onion Router </title>
</head>
<body>
 
<h1 align="center">Tor: The Second-Generation Onion Router </h1> 
<div class="p"><!----></div>

<h3 align="center">
Roger Dingledine, The Free Haven Project, <tt>arma@freehaven.net</tt><br>
Nick Mathewson, The Free Haven Project, <tt>nickm@freehaven.net</tt><br>
Paul Syverson, Naval Research Lab, <tt>syverson@itd.nrl.navy.mil</tt> </h3>

<div class="p"><!----></div>

<div class="p"><!----></div>

<h2> Abstract</h2>
We present Tor, a circuit-based low-latency anonymous communication
service. This second-generation Onion Routing system addresses limitations
in the original design by adding perfect forward secrecy, congestion
control, directory servers, integrity checking, configurable exit policies,
and a practical design for location-hidden services via rendezvous
points. Tor works on the real-world
Internet, requires no special privileges or kernel modifications, requires
little synchronization or coordination between nodes, and provides a
reasonable tradeoff between anonymity, usability, and efficiency.
We briefly describe our experiences with an international network of
more than 30 nodes. We close with a list of open problems in anonymous communication.

<div class="p"><!----></div>

<div class="p"><!----></div>

<div class="p"><!----></div>
 <h2><a name="tth_sEc1">
<a name="sec:intro">
1</a>&nbsp;&nbsp;Overview</h2>
</a>

<div class="p"><!----></div>
Onion Routing is a distributed overlay network designed to anonymize
TCP-based applications like web browsing, secure shell,
and instant messaging. Clients choose a path through the network and
build a <em>circuit</em>, in which each node (or "onion router" or "OR")
in the path knows its predecessor and successor, but no other nodes in
the circuit.  Traffic flows down the circuit in fixed-size
<em>cells</em>, which are unwrapped by a symmetric key at each node
(like the layers of an onion) and relayed downstream. The
Onion Routing project published several design and analysis
papers [<a href="#or-ih96" name="CITEor-ih96">27</a>,<a href="#or-jsac98" name="CITEor-jsac98">41</a>,<a href="#or-discex00" name="CITEor-discex00">48</a>,<a href="#or-pet00" name="CITEor-pet00">49</a>]. While a wide area Onion
Routing network was deployed briefly, the only long-running
public implementation was a fragile
proof-of-concept that ran on a single machine. Even this simple deployment
processed connections from over sixty thousand distinct IP addresses from
all over the world at a rate of about fifty thousand per day.
But many critical design and deployment issues were never
resolved, and the design has not been updated in years. Here
we describe Tor, a protocol for asynchronous, loosely federated onion
routers that provides the following improvements over the old Onion
Routing design:

<div class="p"><!----></div>
<b>Perfect forward secrecy:</b> In the original Onion Routing design,
a single hostile node could record traffic and
later compromise successive nodes in the circuit and force them
to decrypt it. Rather than using a single multiply encrypted data
structure (an <em>onion</em>) to lay each circuit,
Tor now uses an incremental or <em>telescoping</em> path-building design,
where the initiator negotiates session keys with each successive hop in
the circuit.  Once these keys are deleted, subsequently compromised nodes
cannot decrypt old traffic.  As a side benefit, onion replay detection
is no longer necessary, and the process of building circuits is more
reliable, since the initiator knows when a hop fails and can then try
extending to a new node.

<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 &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
relies on the filtering features of privacy-enhancing
application-level proxies such as Privoxy&nbsp;[<a href="#privoxy" name="CITEprivoxy">39</a>], without trying
to duplicate those features itself.

<div class="p"><!----></div>
<b>No mixing, padding, or traffic shaping (yet):</b> Onion
Routing originally called for batching and reordering cells as they arrived,
assumed padding between ORs, and in
later designs added padding between onion proxies (users) and
ORs&nbsp;[<a href="#or-ih96" name="CITEor-ih96">27</a>,<a href="#or-jsac98" name="CITEor-jsac98">41</a>].  Tradeoffs between padding protection
and cost were discussed, and <em>traffic shaping</em> algorithms were
theorized&nbsp;[<a href="#or-pet00" name="CITEor-pet00">49</a>] to provide good security without expensive
padding, but no concrete padding scheme was suggested.
Recent research&nbsp;[<a href="#econymics" name="CITEeconymics">1</a>]
and deployment experience&nbsp;[<a href="#freedom21-security" name="CITEfreedom21-security">4</a>] suggest that this
level of resource use is not practical or economical; and even full
link padding is still vulnerable&nbsp;[<a href="#defensive-dropping" name="CITEdefensive-dropping">33</a>]. Thus,
until we have a proven and convenient design for traffic shaping or
low-latency mixing that improves anonymity against a realistic
adversary, we leave these strategies out.

<div class="p"><!----></div>
<b>Many TCP streams can share one circuit:</b> Onion Routing originally
built a separate circuit for each
application-level request, but this required
multiple public key operations for every request, and also presented
a threat to anonymity from building so many circuits; see
Section&nbsp;<a href="#sec:maintaining-anonymity">9</a>.  Tor multiplexes multiple TCP
streams along each circuit to improve efficiency and anonymity.

<div class="p"><!----></div>
<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 &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.)

<div class="p"><!----></div>
<b>Congestion control:</b> Earlier anonymity designs do not
address traffic bottlenecks. Unfortunately, typical approaches to
load balancing and flow control in overlay networks involve inter-node
control communication and global views of traffic. Tor's decentralized
congestion control uses end-to-end acks to maintain anonymity
while allowing nodes at the edges of the network to detect congestion
or flooding and send less data until the congestion subsides.

<div class="p"><!----></div>
<b>Directory servers:</b> The earlier Onion Routing design
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
routers and their current state. Users periodically download them
via HTTP.

<div class="p"><!----></div>
<b>Variable exit policies:</b> Tor provides a consistent mechanism
for each node to advertise a policy describing the hosts
and ports to which it will connect. These exit policies are critical
in a volunteer-based distributed infrastructure, because each operator
is comfortable with allowing different types of traffic to exit
from his node.

<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 &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>].
Tor hampers these attacks by verifying data integrity before it leaves
the network.

<div class="p"><!----></div>

<div class="p"><!----></div>
<b>Rendezvous points and hidden services:</b>
Tor provides an integrated mechanism for responder anonymity via
location-protected servers.  Previous Onion Routing designs included
long-lived "reply onions" that could be used to build circuits
to a hidden server, but these reply onions did not provide forward
security, and became useless if any node in the path went down
or rotated its keys.  In Tor, clients negotiate <i>rendezvous points</i>
to connect with hidden servers; reply onions are no longer required.

<div class="p"><!----></div>
Unlike Freedom&nbsp;[<a href="#freedom2-arch" name="CITEfreedom2-arch">8</a>], Tor does not require OS kernel
patches or network stack support.  This prevents us from anonymizing
non-TCP protocols, but has greatly helped our portability and
deployability.

<div class="p"><!----></div>

<div class="p"><!----></div>
We have implemented all of the above features, including rendezvous
points. Our source code is
available under a free license, and Tor
is not covered by the patent that affected distribution and use of
earlier versions of Onion Routing.
We have deployed a wide-area alpha network
to test the design, to get more experience with usability
and users, and to provide a research platform for experimentation.
As of this writing, the network stands at 32 nodes spread over two continents.

<div class="p"><!----></div>
We review previous work in Section&nbsp;<a href="#sec:related-work">2</a>, describe
our goals and assumptions in Section&nbsp;<a href="#sec:assumptions">3</a>,
and then address the above list of improvements in
Sections&nbsp;<a href="#sec:design">4</a>,&nbsp;<a href="#sec:rendezvous">5</a>, and&nbsp;<a href="#sec:other-design">6</a>.
We summarize
in Section&nbsp;<a href="#sec:attacks">7</a> how our design stands up to
known attacks, and talk about our early deployment experiences in
Section&nbsp;<a href="#sec:in-the-wild">8</a>. We conclude with a list of open problems in
Section&nbsp;<a href="#sec:maintaining-anonymity">9</a> and future work for the Onion
Routing project in Section&nbsp;<a href="#sec:conclusion">10</a>.

<div class="p"><!----></div>

<div class="p"><!----></div>
 <h2><a name="tth_sEc2">
<a name="sec:related-work">
2</a>&nbsp;&nbsp;Related work</h2>
</a>

<div class="p"><!----></div>
Modern anonymity systems date to Chaum's <b>Mix-Net</b>
design&nbsp;[<a href="#chaum-mix" name="CITEchaum-mix">10</a>]. Chaum
proposed hiding the correspondence between sender and recipient by
wrapping messages in layers of public-key cryptography, and relaying them
through a path composed of "mixes."  Each mix in turn
decrypts, delays, and re-orders messages before relaying them
onward.

<div class="p"><!----></div>
Subsequent relay-based anonymity designs have diverged in two
main directions. Systems like <b>Babel</b>&nbsp;[<a href="#babel" name="CITEbabel">28</a>],
<b>Mixmaster</b>&nbsp;[<a href="#mixmaster-spec" name="CITEmixmaster-spec">36</a>],
and <b>Mixminion</b>&nbsp;[<a href="#minion-design" name="CITEminion-design">15</a>] have tried
to maximize anonymity at the cost of introducing comparatively large and
variable latencies. Because of this decision, these <em>high-latency</em>
networks resist strong global adversaries,
but introduce too much lag for interactive tasks like web browsing,
Internet chat, or SSH connections.

<div class="p"><!----></div>
Tor belongs to the second category: <em>low-latency</em> designs that
try to anonymize interactive network traffic. These systems handle
a variety of bidirectional protocols. They also provide more convenient
mail delivery than the high-latency anonymous email
networks, because the remote mail server provides explicit and timely
delivery confirmation. But because these designs typically
involve many packets that must be delivered quickly, it is
difficult for them to prevent an attacker who can eavesdrop both ends of the
communication from correlating the timing and volume
of traffic entering the anonymity network with traffic leaving it&nbsp;[<a href="#SS03" name="CITESS03">45</a>].
These
protocols are similarly vulnerable to an active adversary who introduces
timing patterns into traffic entering the network and looks
for correlated patterns among exiting traffic.
Although some work has been done to frustrate these attacks, most designs
protect primarily against traffic analysis rather than traffic
confirmation (see Section&nbsp;<a href="#subsec:threat-model">3.1</a>).

<div class="p"><!----></div>
The simplest low-latency designs are single-hop proxies such as the
<b>Anonymizer</b>&nbsp;[<a href="#anonymizer" name="CITEanonymizer">3</a>]: a single trusted server strips the
data's origin before relaying it.  These designs are easy to
analyze, but users must trust the anonymizing proxy.
Concentrating the traffic to this single point increases the anonymity set
(the people a given user is hiding among), but it is vulnerable if the
adversary can observe all traffic entering and leaving the proxy.

<div class="p"><!----></div>
More complex are distributed-trust, circuit-based anonymizing systems.
In these designs, a user establishes one or more medium-term bidirectional
end-to-end circuits, and tunnels data in fixed-size cells.
Establishing circuits is computationally expensive and typically
requires public-key
cryptography, whereas relaying cells is comparatively inexpensive and
typically requires only symmetric encryption.
Because a circuit crosses several servers, and each server only knows
the adjacent servers in the circuit, no single server can link a
user to her communication partners.

<div class="p"><!----></div>
The <b>Java Anon Proxy</b> (also known as JAP or Web MIXes) uses fixed shared
routes known as <em>cascades</em>.  As with a single-hop proxy, this
approach aggregates users into larger anonymity sets, but again an
attacker only needs to observe both ends of the cascade to bridge all
the system's traffic.  The Java Anon Proxy's design
calls for padding between end users and the head of the
cascade&nbsp;[<a href="#web-mix" name="CITEweb-mix">7</a>]. However, it is not demonstrated whether the current
implementation's padding policy improves anonymity.

<div class="p"><!----></div>
<b>PipeNet</b>&nbsp;[<a href="#back01" name="CITEback01">5</a>,<a href="#pipenet" name="CITEpipenet">12</a>], another low-latency design proposed
around the same time as Onion Routing, gave
stronger anonymity but allowed a single user to shut
down the network by not sending. Systems like <b>ISDN
mixes</b>&nbsp;[<a href="#isdn-mixes" name="CITEisdn-mixes">38</a>] were designed for other environments with
different assumptions.

<div class="p"><!----></div>
In P2P designs like <b>Tarzan</b>&nbsp;[<a href="#tarzan:ccs02" name="CITEtarzan:ccs02">24</a>] and
<b>MorphMix</b>&nbsp;[<a href="#morphmix:fc04" name="CITEmorphmix:fc04">43</a>], all participants both generate
traffic and relay traffic for others. These systems aim to conceal
whether a given peer originated a request
or just relayed it from another peer. While Tarzan and MorphMix use
layered encryption as above, <b>Crowds</b>&nbsp;[<a href="#crowds-tissec" name="CITEcrowds-tissec">42</a>] simply assumes
an adversary who cannot observe the initiator: it uses no public-key
encryption, so any node on a circuit can read users' traffic.

<div class="p"><!----></div>
<b>Hordes</b>&nbsp;[<a href="#hordes-jcs" name="CITEhordes-jcs">34</a>] is based on Crowds but also uses multicast
responses to hide the initiator. <b>Herbivore</b>&nbsp;[<a href="#herbivore" name="CITEherbivore">25</a>] and
<b>P</b><sup><b>5</b></sup>&nbsp;[<a href="#p5" name="CITEp5">46</a>] go even further, requiring broadcast.
These systems are designed primarily for communication among peers,
although Herbivore users can make external connections by
requesting a peer to serve as a proxy.

<div class="p"><!----></div>
Systems like <b>Freedom</b> and the original Onion Routing build circuits
all at once, using a layered "onion" of public-key encrypted messages,
each layer of which provides session keys and the address of the
next server in the circuit. Tor as described herein, Tarzan, MorphMix,
<b>Cebolla</b>&nbsp;[<a href="#cebolla" name="CITEcebolla">9</a>], and Rennhard's <b>Anonymity Network</b>&nbsp;[<a href="#anonnet" name="CITEanonnet">44</a>]
build circuits
in stages, extending them one hop at a time.
Section&nbsp;<a href="#subsubsec:constructing-a-circuit">4.2</a> describes how this
approach enables perfect forward secrecy.

<div class="p"><!----></div>
Circuit-based designs must choose which protocol layer
to anonymize. They may intercept IP packets directly, and
relay them whole (stripping the source address) along the
circuit&nbsp;[<a href="#freedom2-arch" name="CITEfreedom2-arch">8</a>,<a href="#tarzan:ccs02" name="CITEtarzan:ccs02">24</a>].  Like
Tor, they may accept TCP streams and relay the data in those streams,
ignoring the breakdown of that data into TCP
segments&nbsp;[<a href="#morphmix:fc04" name="CITEmorphmix:fc04">43</a>,<a href="#anonnet" name="CITEanonnet">44</a>]. Finally, like Crowds, they may accept
application-level protocols such as HTTP and relay the application
requests themselves.
Making this protocol-layer decision requires a compromise between flexibility
and anonymity.  For example, a system that understands HTTP
can strip
identifying information from requests, can take advantage of caching
to limit the number of requests that leave the network, and can batch
or encode requests to minimize the number of connections.
On the other hand, an IP-level anonymizer can handle nearly any protocol,
even ones unforeseen by its designers (though these systems require
kernel-level modifications to some operating systems, and so are more
complex and less portable). TCP-level anonymity networks like Tor present
a middle approach: they are application neutral (so long as the
application supports, or can be tunneled across, TCP), but by treating
application connections as data streams rather than raw TCP packets,
they avoid the inefficiencies of tunneling TCP over
TCP.

<div class="p"><!----></div>
Distributed-trust anonymizing systems need to prevent attackers from
adding too many servers and thus compromising user paths.
Tor relies on a small set of well-known directory servers, run by
independent parties, to decide which nodes can
join. Tarzan and MorphMix allow unknown users to run servers, and use
a limited resource (like IP addresses) to prevent an attacker from
controlling too much of the network.  Crowds suggests requiring
written, notarized requests from potential crowd members.

<div class="p"><!----></div>
Anonymous communication is essential for censorship-resistant
systems like Eternity&nbsp;[<a href="#eternity" name="CITEeternity">2</a>], Free&nbsp;Haven&nbsp;[<a href="#freehaven-berk" name="CITEfreehaven-berk">19</a>],
Publius&nbsp;[<a href="#publius" name="CITEpublius">53</a>], and Tangler&nbsp;[<a href="#tangler" name="CITEtangler">52</a>]. Tor's rendezvous
points enable connections between mutually anonymous entities; they
are a building block for location-hidden servers, which are needed by
Eternity and Free&nbsp;Haven.

<div class="p"><!----></div>

<div class="p"><!----></div>
 <h2><a name="tth_sEc3">
<a name="sec:assumptions">
3</a>&nbsp;&nbsp;Design goals and assumptions</h2>
</a>

<div class="p"><!----></div>
<font size="+1"><b>Goals</b></font><br />
Like other low-latency anonymity designs, Tor seeks to frustrate
attackers from linking communication partners, or from linking
multiple communications to or from a single user.  Within this
main goal, however, several considerations have directed
Tor's evolution.

<div class="p"><!----></div>
<b>Deployability:</b> The design must be deployed and used in the
real world.  Thus it
must not be expensive to run (for example, by requiring more bandwidth
than volunteers are willing to provide); must not place a heavy
liability burden on operators (for example, by allowing attackers to
implicate onion routers in illegal activities); and must not be
difficult or expensive to implement (for example, by requiring kernel
patches, or separate proxies for every protocol).  We also cannot
require non-anonymous parties (such as websites)
to run our software.  (Our rendezvous point design does not meet
this goal for non-anonymous users talking to hidden servers,
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 &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
therefore not
require modifying familiar applications; should not introduce prohibitive
delays;
and should require as few configuration decisions
as possible.  Finally, Tor should be easily implementable on all common
platforms; we cannot require users to change their operating system
to be anonymous.  (Tor currently runs on Win32, Linux,
Solaris, BSD-style Unix, MacOS X, and probably others.)

<div class="p"><!----></div>
<b>Flexibility:</b> The protocol must be flexible and well-specified,
so Tor can serve as a test-bed for future research.
Many of the open problems in low-latency anonymity
networks, such as generating dummy traffic or preventing Sybil
attacks&nbsp;[<a href="#sybil" name="CITEsybil">22</a>], may be solvable independently from the issues
solved by
Tor. Hopefully future systems will not need to reinvent Tor's design.

<div class="p"><!----></div>
<b>Simple design:</b> The protocol's design and security
parameters must be well-understood. Additional features impose implementation
and complexity costs; adding unproven techniques to the design threatens
deployability, readability, and ease of security analysis. Tor aims to
deploy a simple and stable system that integrates the best accepted
approaches to protecting anonymity.<br />

<div class="p"><!----></div>
<font size="+1"><b>Non-goals</b></font><a name="subsec:non-goals">
</a><br />
In favoring simple, deployable designs, we have explicitly deferred
several possible goals, either because they are solved elsewhere, or because
they are not yet solved.

<div class="p"><!----></div>
<b>Not peer-to-peer:</b> Tarzan and MorphMix aim to scale to completely
decentralized peer-to-peer environments with thousands of short-lived
servers, many of which may be controlled by an adversary.  This approach
is appealing, but still has many open
problems&nbsp;[<a href="#tarzan:ccs02" name="CITEtarzan:ccs02">24</a>,<a href="#morphmix:fc04" name="CITEmorphmix:fc04">43</a>].

<div class="p"><!----></div>
<b>Not secure against end-to-end attacks:</b> Tor does not claim
to completely solve end-to-end timing or intersection
attacks. Some approaches, such as having users run their own onion routers,
may help;
see Section&nbsp;<a href="#sec:maintaining-anonymity">9</a> for more discussion.

<div class="p"><!----></div>
<b>No protocol normalization:</b> Tor does not provide <em>protocol
normalization</em> like Privoxy or the Anonymizer. If senders want anonymity from
responders while using complex and variable
protocols like HTTP, Tor must be layered with a filtering proxy such
as Privoxy to hide differences between clients, and expunge protocol
features that leak identity.
Note that by this separation Tor can also provide services that
are anonymous to the network yet authenticated to the responder, like
SSH. Similarly, Tor does not integrate
tunneling for non-stream-based protocols like UDP; this must be
provided by an external service if appropriate.

<div class="p"><!----></div>
<b>Not steganographic:</b> Tor does not try to conceal who is connected
to the network.

<div class="p"><!----></div>
     <h3><a name="tth_sEc3.1">
<a name="subsec:threat-model">
3.1</a>&nbsp;&nbsp;Threat Model</h3>
</a>

<div class="p"><!----></div>
A global passive adversary is the most commonly assumed threat when
analyzing theoretical anonymity designs. But like all practical
low-latency systems, Tor does not protect against such a strong
adversary. Instead, we assume an adversary who can observe some fraction
of network traffic; who can generate, modify, delete, or delay
traffic;  who can operate onion routers of his own; and who can
compromise some fraction of the onion routers.

<div class="p"><!----></div>
In low-latency anonymity systems that use layered encryption, the
adversary's typical goal is to observe both the initiator and the
responder. By observing both ends, passive attackers can confirm a
suspicion that Alice is
talking to Bob if the timing and volume patterns of the traffic on the
connection are distinct enough; active attackers can induce timing
signatures on the traffic to force distinct patterns. Rather
than focusing on these <em>traffic confirmation</em> attacks,
we aim to prevent <em>traffic
analysis</em> attacks, where the adversary uses traffic patterns to learn
which points in the network he should attack.

<div class="p"><!----></div>
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 &mdash; by
relationships in packet timing, volume, or externally visible
user-selected
options. The adversary can also mount active attacks by compromising
routers or keys; by replaying traffic; by selectively denying service
to trustworthy routers to move users to
compromised routers, or denying service to users to see if traffic
elsewhere in the
network stops; or by introducing patterns into traffic that can later be
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 &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
each of these attacks.

<div class="p"><!----></div>

<div class="p"><!----></div>
 <h2><a name="tth_sEc4">
<a name="sec:design">
4</a>&nbsp;&nbsp;The Tor Design</h2>
</a>

<div class="p"><!----></div>
The Tor network is an overlay network; each onion router (OR)
runs as a normal
user-level process without any special privileges.
Each onion router maintains a TLS&nbsp;[<a href="#TLS" name="CITETLS">17</a>]
connection to every other onion router.
Each user
runs local software called an onion proxy (OP) to fetch directories,
establish circuits across the network,
and handle connections from user applications.  These onion proxies accept
TCP streams and multiplex them across the circuits. The onion
router on the other side
of the circuit connects to the requested destinations
and relays data.

<div class="p"><!----></div>
Each onion router maintains a long-term identity key and a short-term
onion key. The identity
key is used to sign TLS certificates, to sign the OR's <em>router
descriptor</em> (a summary of its keys, address, bandwidth, exit policy,
and so on), and (by directory servers) to sign directories. The onion key is used to decrypt requests
from users to set up a circuit and negotiate ephemeral keys. 
The TLS protocol also establishes a short-term link key when communicating
between ORs. Short-term keys are rotated periodically and
independently, to limit the impact of key compromise.

<div class="p"><!----></div>
Section&nbsp;<a href="#subsec:cells">4.1</a> presents the fixed-size
<em>cells</em> that are the unit of communication in Tor. We describe
in Section&nbsp;<a href="#subsec:circuits">4.2</a> how circuits are
built, extended, truncated, and destroyed. Section&nbsp;<a href="#subsec:tcp">4.3</a>
describes how TCP streams are routed through the network.  We address
integrity checking in Section&nbsp;<a href="#subsec:integrity-checking">4.4</a>,
and resource limiting in Section&nbsp;<a href="#subsec:rate-limit">4.5</a>.
Finally,
Section&nbsp;<a href="#subsec:congestion">4.6</a> talks about congestion control and
fairness issues.

<div class="p"><!----></div>
     <h3><a name="tth_sEc4.1">
<a name="subsec:cells">
4.1</a>&nbsp;&nbsp;Cells</h3>
</a>

<div class="p"><!----></div>
Onion routers communicate with one another, and with users' OPs, via
TLS connections with ephemeral keys.  Using TLS conceals the data on
the connection with perfect forward secrecy, and prevents an attacker
from modifying data on the wire or impersonating an OR.

<div class="p"><!----></div>
Traffic passes along these connections in fixed-size cells.  Each cell
is 512 bytes, and consists of a header and a payload. The header includes a circuit
identifier (circID) that specifies which circuit the cell refers to
(many circuits can be multiplexed over the single TLS connection), and
a command to describe what to do with the cell's payload.  (Circuit
identifiers are connection-specific: each circuit has a different
circID on each OP/OR or OR/OR connection it traverses.)
Based on their command, cells are either <em>control</em> cells, which are
always interpreted by the node that receives them, or <em>relay</em> cells,
which carry end-to-end stream data.   The control cell commands are:
<em>padding</em> (currently used for keepalive, but also usable for link
padding); <em>create</em> or <em>created</em> (used to set up a new circuit);
and <em>destroy</em> (to tear down a circuit).

<div class="p"><!----></div>
Relay cells have an additional header (the relay header) at the front
of the payload, containing a streamID (stream identifier: many streams can
be multiplexed over a circuit); an end-to-end checksum for integrity
checking; the length of the relay payload; and a relay command.
The entire contents of the relay header and the relay cell payload
are encrypted or decrypted together as the relay cell moves along the
circuit, using the 128-bit AES cipher in counter mode to generate a
cipher stream.  The relay commands are: <em>relay
data</em> (for data flowing down the stream), <em>relay begin</em> (to open a
stream), <em>relay end</em> (to close a stream cleanly), <em>relay
teardown</em> (to close a broken stream), <em>relay connected</em>
(to notify the OP that a relay begin has succeeded), <em>relay
extend</em> and <em>relay extended</em> (to extend the circuit by a hop,
and to acknowledge), <em>relay truncate</em> and <em>relay truncated</em>
(to tear down only part of the circuit, and to acknowledge), <em>relay
sendme</em> (used for congestion control), and <em>relay drop</em> (used to
implement long-range dummies).
We give a visual overview of cell structure plus the details of relay
cell structure, and then describe each of these cell types and commands
in more detail below.

<div class="p"><!----></div>

<div class="p"><!----></div>

<div class="p"><!----></div>
<a name="tth_fIg1">
</a> <center><img src="cell-struct.png" alt="cell-struct.png" />
</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>

<div class="p"><!----></div>
Onion Routing originally built one circuit for each
TCP stream.  Because building a circuit can take several tenths of a
second (due to public-key cryptography and network latency),
this design imposed high costs on applications like web browsing that
open many TCP streams.

<div class="p"><!----></div>
In Tor, each circuit can be shared by many TCP streams.  To avoid
delays, users construct circuits preemptively.  To limit linkability
among their streams, users' OPs build a new circuit
periodically if the previous ones have been used,
and expire old used circuits that no longer have any open streams.
OPs consider rotating to a new circuit once a minute: thus
even heavy users spend negligible time
building circuits, but a limited number of requests can be linked
to each other through a given exit node. Also, because circuits are built
in the background, OPs can recover from failed circuit creation
without harming user experience.<br />

<div class="p"><!----></div>

<div class="p"><!----></div>
<a name="tth_fIg1">
</a> <center><img src="interaction.png" alt="interaction.png" />

<center>Figure 1: Alice builds a two-hop circuit and begins fetching a web page.</center>
<a name="fig:interaction">
</a>
</center>
<div class="p"><!----></div>
<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
<em>create</em> cell to the first node in her chosen path (call him Bob).
(She chooses a new
circID C<sub>AB</sub> not currently used on the connection from her to Bob.)
The <em>create</em> cell's
payload contains the first half of the Diffie-Hellman handshake
(g<sup>x</sup>), encrypted to the onion key of Bob. Bob
responds with a <em>created</em> cell containing g<sup>y</sup>
along with a hash of the negotiated key K=g<sup>xy</sup>.

<div class="p"><!----></div>
Once the circuit has been established, Alice and Bob can send one
another relay cells encrypted with the negotiated
key.<a href="#tthFtNtAAB" name="tthFrefAAB"><sup>1</sup></a>  More detail is given in
the next section.

<div class="p"><!----></div>
To extend the circuit further, Alice sends a <em>relay extend</em> cell
to Bob, specifying the address of the next OR (call her Carol), and
an encrypted g<sup>x<sub>2</sub></sup> for her.  Bob copies the half-handshake into a
<em>create</em> cell, and passes it to Carol to extend the circuit.
(Bob chooses a new circID C<sub>BC</sub> not currently used on the connection
between him and Carol.  Alice never needs to know this circID; only Bob
associates C<sub>AB</sub> on his connection with Alice to C<sub>BC</sub> on
his connection with Carol.)
When Carol responds with a <em>created</em> cell, Bob wraps the payload
into a <em>relay extended</em> cell and passes it back to Alice.  Now
the circuit is extended to Carol, and Alice and Carol share a common key
K<sub>2</sub> = g<sup>x<sub>2</sub> y<sub>2</sub></sup>.

<div class="p"><!----></div>
To extend the circuit to a third node or beyond, Alice
proceeds as above, always telling the last node in the circuit to
extend one hop further.

<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 &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
secrecy and key freshness. More formally, the protocol is as follows
(where E<sub>PK<sub>Bob</sub></sub>(&#183;) is encryption with Bob's public key,
H is a secure hash function, and <font face="symbol">|</font
> is concatenation):

<div class="p"><!----></div>
<a name="tth_tAb1">
</a> 
<table>
<tr><td align="right">Alice </td><td align="center">-&#62; </td><td align="center">Bob </td><td>: E<sub>PK<sub>Bob</sub></sub>(g<sup>x</sup>) </td></tr>
<tr><td align="right">Bob </td><td align="center">-&#62; </td><td align="center">Alice </td><td>: g<sup>y</sup>, H(K <font face="symbol">|</font
> "<span class="roman">handshake</span>")
</td></tr></table>


<div class="p"><!----></div>
 In the second step, Bob proves that it was he who received g<sup>x</sup>,
and who chose y. We use PK encryption in the first step
(rather than, say, using the first two steps of STS, which has a
signature in the second step) because a single cell is too small to
hold both a public key and a signature. Preliminary analysis with the
NRL protocol analyzer&nbsp;[<a href="#meadows96" name="CITEmeadows96">35</a>] shows this protocol to be
secure (including perfect forward secrecy) under the
traditional Dolev-Yao model.<br />

<div class="p"><!----></div>
<font size="+1"><b>Relay cells</b></font><br />
Once Alice has established the circuit (so she shares keys with each
OR on the circuit), she can send relay cells.
Upon receiving a relay
cell, an OR looks up the corresponding circuit, and decrypts the relay
header and payload with the session key for that circuit.
If the cell is headed away from Alice the OR then checks whether the
decrypted cell has a valid digest (as an optimization, the first
two bytes of the integrity check are zero, so in most cases we can avoid
computing the hash).
If valid, it accepts the relay cell and processes it as described
below.  Otherwise,
the OR looks up the circID and OR for the
next step in the circuit, replaces the circID as appropriate, and
sends the decrypted relay cell to the next OR.  (If the OR at the end
of the circuit receives an unrecognized relay cell, an error has
occurred, and the circuit is torn down.)

<div class="p"><!----></div>
OPs treat incoming relay cells similarly: they iteratively unwrap the
relay header and payload with the session keys shared with each
OR on the circuit, from the closest to farthest.
If at any stage the digest is valid, the cell must have
originated at the OR whose encryption has just been removed.

<div class="p"><!----></div>
To construct a relay cell addressed to a given OR, Alice assigns the
digest, and then iteratively
encrypts the cell payload (that is, the relay header and payload) with
the symmetric key of each hop up to that OR.  Because the digest is
encrypted to a different value at each step, only at the targeted OR
will it have a meaningful value.<a href="#tthFtNtAAC" name="tthFrefAAC"><sup>2</sup></a>
This <em>leaky pipe</em> circuit topology
allows Alice's streams to exit at different ORs on a single circuit.
Alice may choose different exit points because of their exit policies,
or to keep the ORs from knowing that two streams
originate from the same person.

<div class="p"><!----></div>
When an OR later replies to Alice with a relay cell, it
encrypts the cell's relay header and payload with the single key it
shares with Alice, and sends the cell back toward Alice along the
circuit.  Subsequent ORs add further layers of encryption as they
relay the cell back to Alice.

<div class="p"><!----></div>
To tear down a circuit, Alice sends a <em>destroy</em> control
cell. Each OR in the circuit receives the <em>destroy</em> cell, closes
all streams on that circuit, and passes a new <em>destroy</em> cell
forward. But just as circuits are built incrementally, they can also
be torn down incrementally: Alice can send a <em>relay
truncate</em> cell to a single OR on a circuit. That OR then sends a
<em>destroy</em> cell forward, and acknowledges with a
<em>relay truncated</em> cell. Alice can then extend the circuit to
different nodes, without signaling to the intermediate nodes (or
a limited observer) that she has changed her circuit.
Similarly, if a node on the circuit goes down, the adjacent
node can send a <em>relay truncated</em> cell back to Alice.  Thus the
"break a node and see which circuits go down"
attack&nbsp;[<a href="#freedom21-security" name="CITEfreedom21-security">4</a>] is weakened.

<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>

<div class="p"><!----></div>
When Alice's application wants a TCP connection to a given
address and port, it asks the OP (via SOCKS) to make the
connection. The OP chooses the newest open circuit (or creates one if
needed), and chooses a suitable OR on that circuit to be the
exit node (usually the last node, but maybe others due to exit policy
conflicts; see Section&nbsp;<a href="#subsec:exitpolicies">6.2</a>.) The OP then opens
the stream by sending a <em>relay begin</em> cell to the exit node,
using a new random streamID. Once the
exit node connects to the remote host, it responds
with a <em>relay connected</em> cell.  Upon receipt, the OP sends a
SOCKS reply to notify the application of its success. The OP
now accepts data from the application's TCP stream, packaging it into
<em>relay data</em> cells and sending those cells along the circuit to
the chosen OR.

<div class="p"><!----></div>
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
destination to the remote DNS server, rather than sending the hostname
through the Tor network to be resolved at the far end. Common applications
like Mozilla and SSH have this flaw.

<div class="p"><!----></div>
With Mozilla, the flaw is easy to address: the filtering HTTP
proxy called Privoxy gives a hostname to the Tor client, so Alice's
computer never does DNS resolution.
But a portable general solution, such as is needed for
SSH, is
an open problem. Modifying or replacing the local nameserver
can be invasive, brittle, and unportable. Forcing the resolver
library to prefer TCP rather than UDP is hard, and also has
portability problems. Dynamically intercepting system calls to the
resolver library seems a promising direction. We could also provide
a tool similar to <em>dig</em> to perform a private lookup through the
Tor network. Currently, we encourage the use of privacy-aware proxies
like Privoxy wherever possible.

<div class="p"><!----></div>
Closing a Tor stream is analogous to closing a TCP stream: it uses a
two-step handshake for normal operation, or a one-step handshake for
errors. If the stream closes abnormally, the adjacent node simply sends a
<em>relay teardown</em> cell. If the stream closes normally, the node sends
a <em>relay end</em> cell down the circuit, and the other side responds with
its own <em>relay end</em> cell. Because
all relay cells use layered encryption, only the destination OR knows
that a given relay cell is a request to close a stream.  This two-step
handshake allows Tor to support TCP-based applications that use half-closed
connections.

<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>

<div class="p"><!----></div>
Because the old Onion Routing design used a stream cipher without integrity
checking, traffic was
vulnerable to a malleability attack: though the attacker could not
decrypt cells, any changes to encrypted data
would create corresponding changes to the data leaving the network.
This weakness allowed an adversary who could guess the encrypted content
to change a padding cell to a destroy
cell; change the destination address in a <em>relay begin</em> cell to the
adversary's webserver; or change an FTP command from
<tt>dir</tt> to <tt>rm&nbsp;*</tt>. (Even an external
adversary could do this, because the link encryption similarly used a
stream cipher.)

<div class="p"><!----></div>
Because Tor uses TLS on its links, external adversaries cannot modify
data. Addressing the insider malleability attack, however, is
more complex.

<div class="p"><!----></div>
We could do integrity checking of the relay cells at each hop, either
by including hashes or by using an authenticating cipher mode like
EAX&nbsp;[<a href="#eax" name="CITEeax">6</a>], but there are some problems. First, these approaches
impose a message-expansion overhead at each hop, and so we would have to
either leak the path length or waste bytes by padding to a maximum
path length. Second, these solutions can only verify traffic coming
from Alice: ORs would not be able to produce suitable hashes for
the intermediate hops, since the ORs on a circuit do not know the
other ORs' session keys. Third, we have already accepted that our design
is vulnerable to end-to-end timing attacks; so tagging attacks performed
within the circuit provide no additional information to the attacker.

<div class="p"><!----></div>
Thus, we check integrity only at the edges of each stream. (Remember that
in our leaky-pipe circuit topology, a stream's edge could be any hop
in the circuit.) When Alice
negotiates a key with a new hop, they each initialize a SHA-1
digest with a derivative of that key,
thus beginning with randomness that only the two of them know.
Then they each incrementally add to the SHA-1 digest the contents of
all relay cells they create, and include with each relay cell the
first four bytes of the current digest.  Each also keeps a SHA-1
digest of data received, to verify that the received hashes are correct.

<div class="p"><!----></div>
To be sure of removing or modifying a cell, the attacker must be able
to deduce the current digest state (which depends on all
traffic between Alice and Bob, starting with their negotiated key).
Attacks on SHA-1 where the adversary can incrementally add to a hash
to produce a new valid hash don't work, because all hashes are
end-to-end encrypted across the circuit.  The computational overhead
of computing the digests is minimal compared to doing the AES
encryption performed at each hop of the circuit. We use only four
bytes per cell to minimize overhead; the chance that an adversary will
correctly guess a valid hash
is
acceptably low, given that the OP or OR tear down the circuit if they
receive a bad hash.

<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>

<div class="p"><!----></div>
Volunteers are more willing to run services that can limit
their bandwidth usage. To accommodate them, Tor servers use a
token bucket approach&nbsp;[<a href="#tannenbaum96" name="CITEtannenbaum96">50</a>] to
enforce a long-term average rate of incoming bytes, while still
permitting short-term bursts above the allowed bandwidth.

<div class="p"><!----></div>

<div class="p"><!----></div>
Because the Tor protocol outputs about the same number of bytes as it
takes in, it is sufficient in practice to limit only incoming bytes.
With TCP streams, however, the correspondence is not one-to-one:
relaying a single incoming byte can require an entire 512-byte cell.
(We can't just wait for more bytes, because the local application may
be awaiting a reply.) Therefore, we treat this case as if the entire
cell size had been read, regardless of the cell's fullness.

<div class="p"><!----></div>
Further, inspired by Rennhard et al's design in&nbsp;[<a href="#anonnet" name="CITEanonnet">44</a>], a
circuit's edges can heuristically distinguish interactive streams from bulk
streams by comparing the frequency with which they supply cells.  We can
provide good latency for interactive streams by giving them preferential
service, while still giving good overall throughput to the bulk
streams. Such preferential treatment presents a possible end-to-end
attack, but an adversary observing both
ends of the stream can already learn this information through timing
attacks.

<div class="p"><!----></div>
     <h3><a name="tth_sEc4.6">
<a name="subsec:congestion">
4.6</a>&nbsp;&nbsp;Congestion control</h3>
</a>

<div class="p"><!----></div>
Even with bandwidth rate limiting, we still need to worry about
congestion, either accidental or intentional. If enough users choose the
same OR-to-OR connection for their circuits, that connection can become
saturated. For example, an attacker could send a large file
through the Tor network to a webserver he runs, and then
refuse to read any of the bytes at the webserver end of the
circuit. Without some congestion control mechanism, these bottlenecks
can propagate back through the entire network. We don't need to
reimplement full TCP windows (with sequence numbers,
the ability to drop cells when we're full and retransmit later, and so
on),
because TCP already guarantees in-order delivery of each
cell.
We describe our response below.

<div class="p"><!----></div>
<b>Circuit-level throttling:</b>
To control a circuit's bandwidth usage, each OR keeps track of two
windows. The <em>packaging window</em> tracks how many relay data cells the OR is
allowed to package (from incoming TCP streams) for transmission back to the OP,
and the <em>delivery window</em> tracks how many relay data cells it is willing
to deliver to TCP streams outside the network. Each window is initialized
(say, to 1000 data cells). When a data cell is packaged or delivered,
the appropriate window is decremented. When an OR has received enough
data cells (currently 100), it sends a <em>relay sendme</em> cell towards the OP,
with streamID zero. When an OR receives a <em>relay sendme</em> cell with
streamID zero, it increments its packaging window. Either of these cells
increments the corresponding window by 100. If the packaging window
reaches 0, the OR stops reading from TCP connections for all streams
on the corresponding circuit, and sends no more relay data cells until
receiving a <em>relay sendme</em> cell.

<div class="p"><!----></div>
The OP behaves identically, except that it must track a packaging window
and a delivery window for every OR in the circuit. If a packaging window
reaches 0, it stops reading from streams destined for that OR.

<div class="p"><!----></div>
<b>Stream-level throttling</b>:
The stream-level congestion control mechanism is similar to the
circuit-level mechanism. ORs and OPs use <em>relay sendme</em> cells
to implement end-to-end flow control for individual streams across
circuits. Each stream begins with a packaging window (currently 500 cells),
and increments the window by a fixed value (50) upon receiving a <em>relay
sendme</em> cell. Rather than always returning a <em>relay sendme</em> cell as soon
as enough cells have arrived, the stream-level congestion control also
has to check whether data has been successfully flushed onto the TCP
stream; it sends the <em>relay sendme</em> cell only when the number of bytes pending
to be flushed is under some threshold (currently 10 cells' worth).

<div class="p"><!----></div>

<div class="p"><!----></div>
These arbitrarily chosen parameters seem to give tolerable throughput
and delay; see Section&nbsp;<a href="#sec:in-the-wild">8</a>.

<div class="p"><!----></div>
 <h2><a name="tth_sEc5">
<a name="sec:rendezvous">
5</a>&nbsp;&nbsp;Rendezvous Points and hidden services</h2>
</a>

<div class="p"><!----></div>
Rendezvous points are a building block for <em>location-hidden
services</em> (also known as <em>responder anonymity</em>) in the Tor
network.  Location-hidden services allow Bob to offer a TCP
service, such as a webserver, without revealing his IP address.
This type of anonymity protects against distributed DoS attacks:
attackers are forced to attack the onion routing network
because they do not know Bob's IP address.

<div class="p"><!----></div>
Our design for location-hidden servers has the following goals.
<b>Access-control:</b> Bob needs a way to filter incoming requests,
so an attacker cannot flood Bob simply by making many connections to him.
<b>Robustness:</b> Bob should be able to maintain a long-term pseudonymous
identity even in the presence of router failure. Bob's service must
not be tied to a single OR, and Bob must be able to migrate his service
across ORs. <b>Smear-resistance:</b>
A social attacker
should not be able to "frame" a rendezvous router by
offering an illegal or disreputable location-hidden service and
making observers believe the router created that service.
<b>Application-transparency:</b> Although we require users
to run special software to access location-hidden servers, we must not
require them to modify their applications.

<div class="p"><!----></div>
We provide location-hiding for Bob by allowing him to advertise
several onion routers (his <em>introduction points</em>) as contact
points. He may do this on any robust efficient
key-value lookup system with authenticated updates, such as a
distributed hash table (DHT) like CFS&nbsp;[<a href="#cfs:sosp01" name="CITEcfs:sosp01">11</a>].<a href="#tthFtNtAAD" name="tthFrefAAD"><sup>3</sup></a> Alice, the client, chooses an OR as her
<em>rendezvous point</em>. She connects to one of Bob's introduction
points, informs him of her rendezvous point, and then waits for him
to connect to the rendezvous point. This extra level of indirection
helps Bob's introduction points avoid problems associated with serving
unpopular files directly (for example, if Bob serves
material that the introduction point's community finds objectionable,
or if Bob's service tends to get attacked by network vandals).
The extra level of indirection also allows Bob to respond to some requests
and ignore others.

<div class="p"><!----></div>
     <h3><a name="tth_sEc5.1">
5.1</a>&nbsp;&nbsp;Rendezvous points in Tor</h3>

<div class="p"><!----></div>
The following steps are
performed on behalf of Alice and Bob by their local OPs;
application integration is described more fully below.

<div class="p"><!----></div>

<dl compact="compact">

 <dt><b></b></dt>
	<dd><li>Bob generates a long-term public key pair to identify his service.</dd>
 <dt><b></b></dt>
	<dd><li>Bob chooses some introduction points, and advertises them on
      the lookup service, signing the advertisement with his public key.  He
      can add more later.</dd>
 <dt><b></b></dt>
	<dd><li>Bob builds a circuit to each of his introduction points, and tells
      them to wait for requests.</dd>
 <dt><b></b></dt>
	<dd><li>Alice learns about Bob's service out of band (perhaps Bob told her,
      or she found it on a website).  She retrieves the details of Bob's
      service from the lookup service.  If Alice wants to access Bob's
      service anonymously, she must connect to the lookup service via Tor.</dd>
 <dt><b></b></dt>
	<dd><li>Alice chooses an OR as the rendezvous point (RP) for her connection to
      Bob's service. She builds a circuit to the RP, and gives it a
      randomly chosen "rendezvous cookie" to recognize Bob.</dd>
 <dt><b></b></dt>
	<dd><li>Alice opens an anonymous stream to one of Bob's introduction
      points, and gives it a message (encrypted with Bob's public key)
      telling it about herself,
      her RP and rendezvous cookie, and the
      start of a DH
      handshake. The introduction point sends the message to Bob.</dd>
 <dt><b></b></dt>
	<dd><li>If Bob wants to talk to Alice, he builds a circuit to Alice's
      RP and sends the rendezvous cookie, the second half of the DH
      handshake, and a hash of the session
      key they now share. By the same argument as in
      Section&nbsp;<a href="#subsubsec:constructing-a-circuit">4.2</a>, Alice knows she
      shares the key only with Bob.</dd>
 <dt><b></b></dt>
	<dd><li>The RP connects Alice's circuit to Bob's. Note that RP can't
      recognize Alice, Bob, or the data they transmit.</dd>
 <dt><b></b></dt>
	<dd><li>Alice sends a <em>relay begin</em> cell along the circuit. It
      arrives at Bob's OP, which connects to Bob's
      webserver.</dd>
 <dt><b></b></dt>
	<dd><li>An anonymous stream has been established, and Alice and Bob
      communicate as normal.
</dd>
</dl>

<div class="p"><!----></div>
When establishing an introduction point, Bob provides the onion router
with the public key identifying his service.  Bob signs his
messages, so others cannot usurp his introduction point
in the future. He uses the same public key to establish the other
introduction points for his service, and periodically refreshes his
entry in the lookup service.

<div class="p"><!----></div>
The message that Alice gives
the introduction point includes a hash of Bob's public key and an optional initial authorization token (the
introduction point can do prescreening, for example to block replays). Her
message to Bob may include an end-to-end authorization token so Bob
can choose whether to respond.
The authorization tokens can be used to provide selective access:
important users can get uninterrupted access.
During normal situations, Bob's service might simply be offered
directly from mirrors, while Bob gives out tokens to high-priority users. If
the mirrors are knocked down,
those users can switch to accessing Bob's service via
the Tor rendezvous system.

<div class="p"><!----></div>
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;
this is most practical
if there is a stable and large group of introduction points
available. Bob could also give secret public keys
for consulting the lookup service. All of these approaches
limit exposure even when
some selected users collude in the DoS.

<div class="p"><!----></div>
     <h3><a name="tth_sEc5.2">
5.2</a>&nbsp;&nbsp;Integration with user applications</h3>

<div class="p"><!----></div>
Bob configures his onion proxy to know the local IP address and port of his
service, a strategy for authorizing clients, and his public key. The onion
proxy anonymously publishes a signed statement of Bob's
public key, an expiration time, and
the current introduction points for his service onto the lookup service,
indexed
by the hash of his public key.  Bob's webserver is unmodified,
and doesn't even know that it's hidden behind the Tor network.

<div class="p"><!----></div>
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
called <tt>.onion</tt>: thus hostnames take the form <tt>x.y.onion</tt> where
<tt>x</tt> is the authorization cookie and <tt>y</tt> encodes the hash of
the public key. Alice's onion proxy
examines addresses; if they're destined for a hidden server, it decodes
the key and starts the rendezvous as described above.

<div class="p"><!----></div>
     <h3><a name="tth_sEc5.3">
5.3</a>&nbsp;&nbsp;Previous rendezvous work</h3>

<div class="p"><!----></div>
Rendezvous points in low-latency anonymity systems were first
described for use in ISDN telephony&nbsp;[<a href="#jerichow-jsac98" name="CITEjerichow-jsac98">30</a>,<a href="#isdn-mixes" name="CITEisdn-mixes">38</a>].
Later low-latency designs used rendezvous points for hiding location
of mobile phones and low-power location
trackers&nbsp;[<a href="#federrath-ih96" name="CITEfederrath-ih96">23</a>,<a href="#reed-protocols97" name="CITEreed-protocols97">40</a>].  Rendezvous for
anonymizing low-latency
Internet connections was suggested in early Onion Routing
work&nbsp;[<a href="#or-ih96" name="CITEor-ih96">27</a>], but the first published design was by Ian
Goldberg&nbsp;[<a href="#ian-thesis" name="CITEian-thesis">26</a>]. His design differs from
ours in three ways. First, Goldberg suggests that Alice should manually
hunt down a current location of the service via Gnutella; our approach
makes lookup transparent to the user, as well as faster and more robust.
Second, in Tor the client and server negotiate session keys
with Diffie-Hellman, so plaintext is not exposed even at the rendezvous
point. Third,
our design minimizes the exposure from running the
service, to encourage volunteers to offer introduction and rendezvous
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 &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>

<div class="p"><!----></div>
     <h3><a name="tth_sEc6.1">
<a name="subsec:dos">
6.1</a>&nbsp;&nbsp;Denial of service</h3>
</a>

<div class="p"><!----></div>
Providing Tor as a public service creates many opportunities for
denial-of-service attacks against the network.  While
flow control and rate limiting (discussed in
Section&nbsp;<a href="#subsec:congestion">4.6</a>) prevent users from consuming more
bandwidth than routers are willing to provide, opportunities remain for
users to
consume more network resources than their fair share, or to render the
network unusable for others.

<div class="p"><!----></div>
First of all, there are several CPU-consuming denial-of-service
attacks wherein an attacker can force an OR to perform expensive
cryptographic operations.  For example, an attacker can 
fake the start of a TLS handshake, forcing the OR to carry out its
(comparatively expensive) half of the handshake at no real computational
cost to the attacker.

<div class="p"><!----></div>
We have not yet implemented any defenses for these attacks, but several
approaches are possible. First, ORs can
require clients to solve a puzzle&nbsp;[<a href="#puzzles-tls" name="CITEpuzzles-tls">16</a>] while beginning new
TLS handshakes or accepting <em>create</em> cells.  So long as these
tokens are easy to verify and computationally expensive to produce, this
approach limits the attack multiplier.  Additionally, ORs can limit
the rate at which they accept <em>create</em> cells and TLS connections,
so that
the computational work of processing them does not drown out the
symmetric cryptography operations that keep cells
flowing.  This rate limiting could, however, allow an attacker
to slow down other users when they build new circuits.

<div class="p"><!----></div>

<div class="p"><!----></div>
Adversaries can also attack the Tor network's hosts and network
links. Disrupting a single circuit or link breaks all streams passing
along that part of the circuit. Users similarly lose service
when a router crashes or its operator restarts it. The current
Tor design treats such attacks as intermittent network failures, and
depends on users and applications to respond or recover as appropriate. A
future design could use an end-to-end TCP-like acknowledgment protocol,
so no streams are lost unless the entry or exit point is
disrupted. This solution would require more buffering at the network
edges, however, and the performance and anonymity implications from this
extra complexity still require investigation.

<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>

<div class="p"><!----></div>

<div class="p"><!----></div>
Exit abuse is a serious barrier to wide-scale Tor deployment. Anonymity
presents would-be vandals and abusers with an opportunity to hide
the origins of their activities. Attackers can harm the Tor network by
implicating exit servers for their abuse. Also, applications that commonly
use IP-based authentication (such as institutional mail or webservers)
can be fooled by the fact that anonymous connections appear to originate
at the exit OR.

<div class="p"><!----></div>
We stress that Tor does not enable any new class of abuse. Spammers
and other attackers already have access to thousands of misconfigured
systems worldwide, and the Tor network is far from the easiest way
to launch attacks.
But because the
onion routers can be mistaken for the originators of the abuse,
and the volunteers who run them may not want to deal with the hassle of
explaining anonymity networks to irate administrators, we must block or limit
abuse through the Tor network.

<div class="p"><!----></div>
To mitigate abuse issues, each onion router's <em>exit policy</em>
describes to which external addresses and ports the router will
connect. On one end of the spectrum are <em>open exit</em>
nodes that will connect anywhere. On the other end are <em>middleman</em>
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 &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
<em>restricted exits</em> that permit connections to the world at large,
but prevent access to certain abuse-prone addresses and services such
as SMTP.
The OR might also be able to authenticate clients to
prevent exit abuse without harming anonymity&nbsp;[<a href="#or-discex00" name="CITEor-discex00">48</a>].

<div class="p"><!----></div>

<div class="p"><!----></div>
Many administrators use port restrictions to support only a
limited set of services, such as HTTP, SSH, or AIM.
This is not a complete solution, of course, since abuse opportunities for these
protocols are still well known.

<div class="p"><!----></div>
We have not yet encountered any abuse in the deployed network, but if
we do we should consider using proxies to clean traffic for certain
protocols as it leaves the network.  For example, much abusive HTTP
behavior (such as exploiting buffer overflows or well-known script
vulnerabilities) can be detected in a straightforward manner.
Similarly, one could run automatic spam filtering software (such as
SpamAssassin) on email exiting the OR network.

<div class="p"><!----></div>
ORs may also rewrite exiting traffic to append
headers or other information indicating that the traffic has passed
through an anonymity service.  This approach is commonly used
by email-only anonymity systems.  ORs can also
run on servers with hostnames like <tt>anonymous</tt> to further
alert abuse targets to the nature of the anonymous traffic.

<div class="p"><!----></div>
A mixture of open and restricted exit nodes allows the most
flexibility for volunteers running servers. But while having many
middleman nodes provides a large and robust network,
having only a few exit nodes reduces the number of points
an adversary needs to monitor for traffic analysis, and places a
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 &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
adversary needs to work harder to watch all the clients; see
Section&nbsp;<a href="#sec:conclusion">10</a>.

<div class="p"><!----></div>
Finally, we note that exit abuse must not be dismissed as a peripheral
issue: when a system's public image suffers, it can reduce the number
and diversity of that system's users, and thereby reduce the anonymity
of the system itself.  Like usability, public perception is a
security parameter.  Sadly, preventing abuse of open exit nodes is an
unsolved problem, and will probably remain an arms race for the
foreseeable future.  The abuse problems faced by Princeton's CoDeeN
project&nbsp;[<a href="#darkside" name="CITEdarkside">37</a>] give us a glimpse of likely issues.

<div class="p"><!----></div>
     <h3><a name="tth_sEc6.3">
<a name="subsec:dirservers">
6.3</a>&nbsp;&nbsp;Directory Servers</h3>
</a>

<div class="p"><!----></div>
First-generation Onion Routing designs&nbsp;[<a href="#freedom2-arch" name="CITEfreedom2-arch">8</a>,<a href="#or-jsac98" name="CITEor-jsac98">41</a>] used
in-band network status updates: each router flooded a signed statement
to its neighbors, which propagated it onward. But anonymizing networks
have different security goals than typical link-state routing protocols.
For example, delays (accidental or intentional)
that can cause different parts of the network to have different views
of link-state and topology are not only inconvenient: they give
attackers an opportunity to exploit differences in client knowledge.
We also worry about attacks to deceive a
client about the router membership list, topology, or current network
state. Such <em>partitioning attacks</em> on client knowledge help an
adversary to efficiently deploy resources
against a target&nbsp;[<a href="#minion-design" name="CITEminion-design">15</a>].

<div class="p"><!----></div>
Tor uses a small group of redundant, well-known onion routers to
track changes in network topology and node state, including keys and
exit policies.  Each such <em>directory server</em> acts as an HTTP
server, so clients can fetch current network state
and router lists, and so other ORs can upload
state information.  Onion routers periodically publish signed
statements of their state to each directory server. The directory servers
combine this information with their own views of network liveness,
and generate a signed description (a <em>directory</em>) of the entire
network state. Client software is
pre-loaded with a list of the directory servers and their keys,
to bootstrap each client's view of the network.

<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 &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
server administrator before they are included. Mechanisms for automated
node approval are an area of active research, and are discussed more
in Section&nbsp;<a href="#sec:maintaining-anonymity">9</a>.

<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 &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.

<div class="p"><!----></div>
Thus these directory servers must be synchronized and redundant, so
that they can agree on a common directory.  Clients should only trust
this directory if it is signed by a threshold of the directory
servers.

<div class="p"><!----></div>
The directory servers in Tor are modeled after those in
Mixminion&nbsp;[<a href="#minion-design" name="CITEminion-design">15</a>], but our situation is easier. First,
we make the
simplifying assumption that all participants agree on the set of
directory servers. Second, while Mixminion needs to predict node
behavior, Tor only needs a threshold consensus of the current
state of the network. Third, we assume that we can fall back to the
human administrators to discover and resolve problems when a consensus
directory cannot be reached. Since there are relatively few directory
servers (currently 3, but we expect as many as 9 as the network scales),
we can afford operations like broadcast to simplify the consensus-building
protocol.

<div class="p"><!----></div>
To avoid attacks where a router connects to all the directory servers
but refuses to relay traffic from other routers, the directory servers
must also build circuits and use them to anonymously test router
reliability&nbsp;[<a href="#mix-acc" name="CITEmix-acc">18</a>]. Unfortunately, this defense is not yet
designed or
implemented.

<div class="p"><!----></div>
Using directory servers is simpler and more flexible than flooding.
Flooding is expensive, and complicates the analysis when we
start experimenting with non-clique network topologies. Signed
directories can be cached by other
onion routers,
so directory servers are not a performance
bottleneck when we have many users, and do not aid traffic analysis by
forcing clients to announce their existence to any
central point.

<div class="p"><!----></div>
 <h2><a name="tth_sEc7">
<a name="sec:attacks">
7</a>&nbsp;&nbsp;Attacks and Defenses</h2>
</a>

<div class="p"><!----></div>
Below we summarize a variety of attacks, and discuss how well our
design withstands them.<br />

<div class="p"><!----></div>
<font size="+1"><b>Passive attacks</b></font><br />
<em>Observing user traffic patterns.</em> Observing a user's connection
will not reveal her destination or data, but it will
reveal traffic patterns (both sent and received). Profiling via user
connection patterns requires further processing, because multiple
application streams may be operating simultaneously or in series over
a single circuit.

<div class="p"><!----></div>
<em>Observing user content.</em> While content at the user end is encrypted,
connections to responders may not be (indeed, the responding website
itself may be hostile). While filtering content is not a primary goal
of Onion Routing, Tor can directly use Privoxy and related
filtering services to anonymize application data streams.

<div class="p"><!----></div>
<em>Option distinguishability.</em> We allow clients to choose
configuration options. For example, clients concerned about request
linkability should rotate circuits more often than those concerned
about traceability. Allowing choice may attract users with different 
needs; but clients who are
in the minority may lose more anonymity by appearing distinct than they
gain by optimizing their behavior&nbsp;[<a href="#econymics" name="CITEeconymics">1</a>].

<div class="p"><!----></div>
<em>End-to-end timing correlation.</em>  Tor only minimally hides
such correlations. An attacker watching patterns of
traffic at the initiator and the responder will be
able to confirm the correspondence with high probability. The
greatest protection currently available against such confirmation is to hide
the connection between the onion proxy and the first Tor node,
by running the OP on the Tor node or behind a firewall. This approach
requires an observer to separate traffic originating at the onion
router from traffic passing through it: a global observer can do this,
but it might be beyond a limited observer's capabilities.

<div class="p"><!----></div>
<em>End-to-end size correlation.</em> Simple packet counting
will also be effective in confirming
endpoints of a stream. However, even without padding, we may have some
limited protection: the leaky pipe topology means different numbers
of packets may enter one end of a circuit than exit at the other.

<div class="p"><!----></div>
<em>Website fingerprinting.</em> All the effective passive
attacks above are traffic confirmation attacks,
which puts them outside our design goals. There is also
a passive traffic analysis attack that is potentially effective.
Rather than searching exit connections for timing and volume
correlations, the adversary may build up a database of
"fingerprints" containing file sizes and access patterns for
targeted websites. He can later confirm a user's connection to a given
site simply by consulting the database. This attack has
been shown to be effective against SafeWeb&nbsp;[<a href="#hintz-pet02" name="CITEhintz-pet02">29</a>].
It may be less effective against Tor, since
streams are multiplexed within the same circuit, and
fingerprinting will be limited to
the granularity of cells (currently 512 bytes). Additional
defenses could include
larger cell sizes, padding schemes to group websites
into large sets, and link
padding or long-range dummies.<a href="#tthFtNtAAE" name="tthFrefAAE"><sup>4</sup></a><br />

<div class="p"><!----></div>
<font size="+1"><b>Active attacks</b></font><br />
<em>Compromise keys.</em> An attacker who learns the TLS session key can
see control cells and encrypted relay cells on every circuit on that
connection; learning a circuit
session key lets him unwrap one layer of the encryption. An attacker
who learns an OR's TLS private key can impersonate that OR for the TLS
key's lifetime, but he must
also learn the onion key to decrypt <em>create</em> cells (and because of
perfect forward secrecy, he cannot hijack already established circuits
without also compromising their session keys). Periodic key rotation
limits the window of opportunity for these attacks. On the other hand,
an attacker who learns a node's identity key can replace that node
indefinitely by sending new forged descriptors to the directory servers.

<div class="p"><!----></div>
<em>Iterated compromise.</em> A roving adversary who can
compromise ORs (by system intrusion, legal coercion, or extralegal
coercion) could march down the circuit compromising the
nodes until he reaches the end.  Unless the adversary can complete
this attack within the lifetime of the circuit, however, the ORs
will have discarded the necessary information before the attack can
be completed.  (Thanks to the perfect forward secrecy of session
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 &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
their nodes&nbsp;[<a href="#jap-backdoor" name="CITEjap-backdoor">51</a>].

<div class="p"><!----></div>
<em>Run a recipient.</em> An adversary running a webserver
trivially learns the timing patterns of users connecting to it, and
can introduce arbitrary patterns in its responses.
End-to-end attacks become easier: if the adversary can induce
users to connect to his webserver (perhaps by advertising
content targeted to those users), he now holds one end of their
connection.  There is also a danger that application
protocols and associated programs can be induced to reveal information
about the initiator. Tor depends on Privoxy and similar protocol cleaners
to solve this latter problem.

<div class="p"><!----></div>
<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 &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.

<div class="p"><!----></div>
<em>DoS non-observed nodes.</em> An observer who can only watch some
of the Tor network can increase the value of this traffic
by attacking non-observed nodes to shut them down, reduce
their reliability, or persuade users that they are not trustworthy.
The best defense here is robustness.

<div class="p"><!----></div>
<em>Run a hostile OR.</em>  In addition to being a local observer,
an isolated hostile node can create circuits through itself, or alter
traffic patterns to affect traffic at other nodes. Nonetheless, a hostile
node must be immediately adjacent to both endpoints to compromise the
anonymity of a circuit. If an adversary can
run multiple ORs, and can persuade the directory servers
that those ORs are trustworthy and independent, then occasionally
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 &mdash; although an
adversary
could still attract a disproportionately large amount of traffic
by running an OR with a permissive exit policy, or by
degrading the reliability of other routers.

<div class="p"><!----></div>
<em>Introduce timing into messages.</em> This is simply a stronger
version of passive timing attacks already discussed earlier.

<div class="p"><!----></div>
<em>Tagging attacks.</em> A hostile node could "tag" a
cell by altering it. If the
stream were, for example, an unencrypted request to a Web site,
the garbled content coming out at the appropriate time would confirm
the association. However, integrity checks on cells prevent
this attack.

<div class="p"><!----></div>
<em>Replace contents of unauthenticated protocols.</em>  When
relaying an unauthenticated protocol like HTTP, a hostile exit node
can impersonate the target server. Clients
should prefer protocols with end-to-end authentication.

<div class="p"><!----></div>
<em>Replay attacks.</em> Some anonymity protocols are vulnerable
to replay attacks.  Tor is not; replaying one side of a handshake
will result in a different negotiated session key, and so the rest
of the recorded session can't be used.

<div class="p"><!----></div>
<em>Smear attacks.</em> An attacker could use the Tor network for
socially disapproved acts, to bring the
network into disrepute and get its operators to shut it down.
Exit policies reduce the possibilities for abuse, but
ultimately the network requires volunteers who can tolerate
some political heat.

<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 &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
that lists which versions are currently believed to be secure.  To
prevent an attacker from subverting the official release itself
(through threats, bribery, or insider attacks), we provide all
releases in source code form, encourage source audits, and
frequently warn our users never to trust any software (even from
us) that comes without source.<br />

<div class="p"><!----></div>
<font size="+1"><b>Directory attacks</b></font><br />
<em>Destroy directory servers.</em>  If a few directory
servers disappear, the others still decide on a valid
directory.  So long as any directory servers remain in operation,
they will still broadcast their views of the network and generate a
consensus directory.  (If more than half are destroyed, this
directory will not, however, have enough signatures for clients to
use it automatically; human intervention will be necessary for
clients to decide whether to trust the resulting directory.)

<div class="p"><!----></div>
<em>Subvert a directory server.</em>  By taking over a directory server,
an attacker can partially influence the final directory.  Since ORs
are included or excluded by majority vote, the corrupt directory can
at worst cast a tie-breaking vote to decide whether to include
marginal ORs.  It remains to be seen how often such marginal cases
occur in practice.

<div class="p"><!----></div>
<em>Subvert a majority of directory servers.</em> An adversary who controls
more than half the directory servers can include as many compromised
ORs in the final directory as he wishes. We must ensure that directory
server operators are independent and attack-resistant.

<div class="p"><!----></div>
<em>Encourage directory server dissent.</em>  The directory
agreement protocol assumes that directory server operators agree on
the set of directory servers.  An adversary who can persuade some
of the directory server operators to distrust one another could
split the quorum into mutually hostile camps, thus partitioning
users based on which directory they use.  Tor does not address
this attack.

<div class="p"><!----></div>
<em>Trick the directory servers into listing a hostile OR.</em>
Our threat model explicitly assumes directory server operators will
be able to filter out most hostile ORs.

<div class="p"><!----></div>
<em>Convince the directories that a malfunctioning OR is
working.</em>  In the current Tor implementation, directory servers
assume that an OR is running correctly if they can start a TLS
connection to it.  A hostile OR could easily subvert this test by
accepting TLS connections from ORs but ignoring all cells. Directory
servers must actively test ORs by building circuits and streams as
appropriate.  The tradeoffs of a similar approach are discussed
in&nbsp;[<a href="#mix-acc" name="CITEmix-acc">18</a>].<br />

<div class="p"><!----></div>
<font size="+1"><b>Attacks against rendezvous points</b></font><br />
<em>Make many introduction requests.</em>  An attacker could
try to deny Bob service by flooding his introduction points with
requests.  Because the introduction points can block requests that
lack authorization tokens, however, Bob can restrict the volume of
requests he receives, or require a certain amount of computation for
every request he receives.

<div class="p"><!----></div>
<em>Attack an introduction point.</em> An attacker could
disrupt a location-hidden service by disabling its introduction
points.  But because a service's identity is attached to its public
key, the service can simply re-advertise
itself at a different introduction point. Advertisements can also be
done secretly so that only high-priority clients know the address of
Bob's introduction points or so that different clients know of different
introduction points. This forces the attacker to disable all possible
introduction points.

<div class="p"><!----></div>
<em>Compromise an introduction point.</em> An attacker who controls
Bob's introduction point can flood Bob with
introduction requests, or prevent valid introduction requests from
reaching him. Bob can notice a flood, and close the circuit.  To notice
blocking of valid requests, however, he should periodically test the
introduction point by sending rendezvous requests and making
sure he receives them.

<div class="p"><!----></div>
<em>Compromise a rendezvous point.</em>  A rendezvous
point is no more sensitive than any other OR on
a circuit, since all data passing through the rendezvous is encrypted
with a session key shared by Alice and Bob.

<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>

<div class="p"><!----></div>
As of mid-May 2004, the Tor network consists of 32 nodes
(24 in the US, 8 in Europe), and more are joining each week as the code
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 &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
the network for web browsing, FTP, IRC, AIM, Kazaa, SSH, and
recipient-anonymous email via rendezvous points. One user has anonymously
set up a Wiki as a hidden service, where other users anonymously publish
the addresses of their hidden services.

<div class="p"><!----></div>
Each Tor node currently processes roughly 800,000 relay
cells (a bit under half a gigabyte) per week. On average, about 80%
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 &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.

<div class="p"><!----></div>
Based in part on our restrictive default exit policy (we
reject SMTP requests) and our low profile, we have had no abuse
issues since the network was deployed in October
2003. Our slow growth rate gives us time to add features,
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 &mdash; we feel that we must build a reputation for privacy, human
rights, research, and other socially laudable activities.

<div class="p"><!----></div>
As for performance, profiling shows that Tor spends almost
all its CPU time in AES, which is fast.  Current latency is attributable
to two factors. First, network latency is critical: we are
intentionally bouncing traffic around the world several times. Second,
our end-to-end congestion control algorithm focuses on protecting
volunteer servers from accidental DoS rather than on optimizing
performance. To quantify these effects, we did some informal tests using a network of 4
nodes on the same machine (a heavily loaded 1GHz Athlon). We downloaded a 60
megabyte file from <tt>debian.org</tt> every 30 minutes for 54 hours (108 sample
points). It arrived in about 300 seconds on average, compared to 210s for a
direct download. We ran a similar test on the production Tor network,
fetching the front page of <tt>cnn.com</tt> (55 kilobytes):
while a direct
download consistently took about 0.3s, the performance through Tor varied.
Some downloads were as fast as 0.4s, with a median at 2.8s, and
90% finishing within 5.3s.  It seems that as the network expands, the chance
of building a slow circuit (one that includes a slow or heavily loaded node
or link) is increasing.  On the other hand, as our users remain satisfied
with this increased latency, we can address our performance incrementally as we
proceed with development. 
<div class="p"><!----></div>

<div class="p"><!----></div>

<div class="p"><!----></div>
Although Tor's clique topology and full-visibility directories present
scaling problems, we still expect the network to support a few hundred
nodes and maybe 10,000 users before we're forced to become
more distributed. With luck, the experience we gain running the current
topology will help us choose among alternatives when the time comes.

<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>

<div class="p"><!----></div>
In addition to the non-goals in
Section&nbsp;<a href="#subsec:non-goals">3</a>, many questions must be solved
before we can be confident of Tor's security.

<div class="p"><!----></div>
Many of these open issues are questions of balance. For example,
how often should users rotate to fresh circuits? Frequent rotation
is inefficient, expensive, and may lead to intersection attacks and
predecessor attacks&nbsp;[<a href="#wright03" name="CITEwright03">54</a>], but infrequent rotation makes the
user's traffic linkable. Besides opening fresh circuits, clients can
also exit from the middle of the circuit,
or truncate and re-extend the circuit. More analysis is
needed to determine the proper tradeoff.

<div class="p"><!----></div>

<div class="p"><!----></div>
How should we choose path lengths? If Alice always uses two hops,
then both ORs can be certain that by colluding they will learn about
Alice and Bob. In our current approach, Alice always chooses at least
three nodes unrelated to herself and her destination.
Should Alice choose a random path length (e.g.&nbsp;from a geometric
distribution) to foil an attacker who
uses timing to learn that he is the fifth hop and thus concludes that
both Alice and the responder are running ORs?

<div class="p"><!----></div>
Throughout this paper, we have assumed that end-to-end traffic
confirmation will immediately and automatically defeat a low-latency
anonymity system. Even high-latency anonymity systems can be
vulnerable to end-to-end traffic confirmation, if the traffic volumes
are high enough, and if users' habits are sufficiently
distinct&nbsp;[<a href="#statistical-disclosure" name="CITEstatistical-disclosure">14</a>,<a href="#limits-open" name="CITElimits-open">31</a>]. Can anything be
done to
make low-latency systems resist these attacks as well as high-latency
systems? Tor already makes some effort to conceal the starts and ends of
streams by wrapping long-range control commands in identical-looking
relay cells. Link padding could frustrate passive observers who count
packets; long-range padding could work against observers who own the
first hop in a circuit. But more research remains to find an efficient
and practical approach. Volunteers prefer not to run constant-bandwidth
padding; but no convincing traffic shaping approach has been
specified. Recent work on long-range padding&nbsp;[<a href="#defensive-dropping" name="CITEdefensive-dropping">33</a>]
shows promise. One could also try to reduce correlation in packet timing
by batching and re-ordering packets, but it is unclear whether this could
improve anonymity without introducing so much latency as to render the
network unusable.

<div class="p"><!----></div>
A cascade topology may better defend against traffic confirmation by
aggregating users, and making padding and
mixing more affordable.  Does the hydra topology (many input nodes,
few output nodes) work better against some adversaries? Are we going
to get a hydra anyway because most nodes will be middleman nodes?

<div class="p"><!----></div>
Common wisdom suggests that Alice should run her own OR for best
anonymity, because traffic coming from her node could plausibly have
come from elsewhere. How much mixing does this approach need?  Is it
immediately beneficial because of real-world adversaries that can't
observe Alice's router, but can run routers of their own?

<div class="p"><!----></div>
To scale to many users, and to prevent an attacker from observing the
whole network, it may be necessary
to support far more servers than Tor currently anticipates.
This introduces several issues.  First, if approval by a central set
of directory servers is no longer feasible, what mechanism should be used
to prevent adversaries from signing up many colluding servers? Second,
if clients can no longer have a complete picture of the network,
how can they perform discovery while preventing attackers from
manipulating or exploiting gaps in their knowledge?  Third, if there
are too many servers for every server to constantly communicate with
every other, which non-clique topology should the network use?
(Restricted-route topologies promise comparable anonymity with better
scalability&nbsp;[<a href="#danezis-pets03" name="CITEdanezis-pets03">13</a>], but whatever topology we choose, we
need some way to keep attackers from manipulating their position within
it&nbsp;[<a href="#casc-rep" name="CITEcasc-rep">21</a>].) Fourth, if no central authority is tracking
server reliability, how do we stop unreliable servers from making
the network unusable?  Fifth, do clients receive so much anonymity
from running their own ORs that we should expect them all to do
so&nbsp;[<a href="#econymics" name="CITEeconymics">1</a>], or do we need another incentive structure to
motivate them?  Tarzan and MorphMix present possible solutions.

<div class="p"><!----></div>

<div class="p"><!----></div>
When a Tor node goes down, all its circuits (and thus streams) must break.
Will users abandon the system because of this brittleness? How well
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 &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.

<div class="p"><!----></div>

<div class="p"><!----></div>
 <h2><a name="tth_sEc10">
<a name="sec:conclusion">
10</a>&nbsp;&nbsp;Future Directions</h2>
</a>

<div class="p"><!----></div>
Tor brings together many innovations into a unified deployable system. The
next immediate steps include:

<div class="p"><!----></div>
<em>Scalability:</em> Tor's emphasis on deployability and design simplicity
has led us to adopt a clique topology, semi-centralized
directories, and a full-network-visibility model for client
knowledge. These properties will not scale past a few hundred servers.
Section&nbsp;<a href="#sec:maintaining-anonymity">9</a> describes some promising
approaches, but more deployment experience will be helpful in learning
the relative importance of these bottlenecks.

<div class="p"><!----></div>
<em>Bandwidth classes:</em> This paper assumes that all ORs have
good bandwidth and latency. We should instead adopt the MorphMix model,
where nodes advertise their bandwidth level (DSL, T1, T3), and
Alice avoids bottlenecks by choosing nodes that match or
exceed her bandwidth. In this way DSL users can usefully join the Tor
network.

<div class="p"><!----></div>
<em>Incentives:</em> Volunteers who run nodes are rewarded with publicity
and possibly better anonymity&nbsp;[<a href="#econymics" name="CITEeconymics">1</a>]. More nodes means increased
scalability, and more users can mean more anonymity. We need to continue
examining the incentive structures for participating in Tor. Further,
we need to explore more approaches to limiting abuse, and understand
why most people don't bother using privacy systems.

<div class="p"><!----></div>
<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
method offers provable protection against our chosen adversary.

<div class="p"><!----></div>

<div class="p"><!----></div>
<em>Caching at exit nodes:</em> Perhaps each exit node should run a
caching web proxy&nbsp;[<a href="#shsm03" name="CITEshsm03">47</a>], to improve anonymity for cached pages
(Alice's request never
leaves the Tor network), to improve speed, and to reduce bandwidth cost.
On the other hand, forward security is weakened because caches
constitute a record of retrieved files.  We must find the right
balance between usability and security.

<div class="p"><!----></div>
<em>Better directory distribution:</em>
Clients currently download a description of
the entire network every 15 minutes. As the state grows larger
and clients more numerous, we may need a solution in which
clients receive incremental updates to directory state.
More generally, we must find more
scalable yet practical ways to distribute up-to-date snapshots of
network status without introducing new attacks.

<div class="p"><!----></div>
<em>Further specification review:</em> Our public
byte-level specification&nbsp;[<a href="#tor-spec" name="CITEtor-spec">20</a>] needs
external review.  We hope that as Tor
is deployed, more people will examine its
specification.

<div class="p"><!----></div>
<em>Multisystem interoperability:</em> We are currently working with the
designer of MorphMix to unify the specification and implementation of
the common elements of our two systems. So far, this seems
to be relatively straightforward.  Interoperability will allow testing
and direct comparison of the two designs for trust and scalability.

<div class="p"><!----></div>
<em>Wider-scale deployment:</em> The original goal of Tor was to
gain experience in deploying an anonymizing overlay network, and
learn from having actual users.  We are now at a point in design
and development where we can start deploying a wider network.  Once
we have many actual users, we will doubtlessly be better
able to evaluate some of our design decisions, including our
robustness/latency tradeoffs, our performance tradeoffs (including
cell size), our abuse-prevention mechanisms, and
our overall usability.

<div class="p"><!----></div>

<div class="p"><!----></div>

<h2>Acknowledgments</h2>
 We thank Peter Palfrader, Geoff Goodell, Adam Shostack, Joseph Sokol-Margolis,
   John Bashinski, and Zack Brown
   for editing and comments;
 Matej Pfajfar, Andrei Serjantov, Marc Rennhard for design discussions;
 Bram Cohen for congestion control discussions;
 Adam Back for suggesting telescoping circuits; and
 Cathy Meadows for formal analysis of the <em>extend</em> protocol.
 This work has been supported by ONR and DARPA.

<div class="p"><!----></div>

<div class="p"><!----></div>

<div class="p"><!----></div>
<h2>References</h2>

<dl compact="compact">
<font size="-1"></font> <dt><a href="#CITEeconymics" name="econymics">[1]</a></dt><dd>
A.&nbsp;Acquisti, R.&nbsp;Dingledine, and P.&nbsp;Syverson.
 On the economics of anonymity.
 In R.&nbsp;N. Wright, editor, <em>Financial Cryptography</em>.
  Springer-Verlag, LNCS 2742, 2003.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEeternity" name="eternity">[2]</a></dt><dd>
R.&nbsp;Anderson.
 The eternity service.
 In <em>Pragocrypt '96</em>, 1996.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEanonymizer" name="anonymizer">[3]</a></dt><dd>
The Anonymizer.
 <tt>&lt;http://anonymizer.com/&#62;.

<div class="p"><!----></div>
</tt></dd>
 <dt><a href="#CITEfreedom21-security" name="freedom21-security">[4]</a></dt><dd>
A.&nbsp;Back, I.&nbsp;Goldberg, and A.&nbsp;Shostack.
 Freedom systems 2.1 security issues and analysis.
 White paper, Zero Knowledge Systems, Inc., May 2001.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEback01" name="back01">[5]</a></dt><dd>
A.&nbsp;Back, U.&nbsp;M&#246;ller, and A.&nbsp;Stiglic.
 Traffic analysis attacks and trade-offs in anonymity providing
  systems.
 In I.&nbsp;S. Moskowitz, editor, <em>Information Hiding (IH 2001)</em>, pages
  245-257. Springer-Verlag, LNCS 2137, 2001.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEeax" name="eax">[6]</a></dt><dd>
M.&nbsp;Bellare, P.&nbsp;Rogaway, and D.&nbsp;Wagner.
 The EAX mode of operation: A two-pass authenticated-encryption
  scheme optimized for simplicity and efficiency.
 In <em>Fast Software Encryption 2004</em>, February 2004.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEweb-mix" name="web-mix">[7]</a></dt><dd>
O.&nbsp;Berthold, H.&nbsp;Federrath, and S.&nbsp;K&#246;psell.
 Web MIXes: A system for anonymous and unobservable Internet
  access.
 In H.&nbsp;Federrath, editor, <em>Designing Privacy Enhancing
  Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>.
  Springer-Verlag, LNCS 2009, 2000.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEfreedom2-arch" name="freedom2-arch">[8]</a></dt><dd>
P.&nbsp;Boucher, A.&nbsp;Shostack, and I.&nbsp;Goldberg.
 Freedom systems 2.0 architecture.
 White paper, Zero Knowledge Systems, Inc., December 2000.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEcebolla" name="cebolla">[9]</a></dt><dd>
Z.&nbsp;Brown.
 Cebolla: Pragmatic IP Anonymity.
 In <em>Ottawa Linux Symposium</em>, June 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEchaum-mix" name="chaum-mix">[10]</a></dt><dd>
D.&nbsp;Chaum.
 Untraceable electronic mail, return addresses, and digital
  pseudo-nyms.
 <em>Communications of the ACM</em>, 4(2), February 1981.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEcfs:sosp01" name="cfs:sosp01">[11]</a></dt><dd>
F.&nbsp;Dabek, M.&nbsp;F. Kaashoek, D.&nbsp;Karger, R.&nbsp;Morris, and I.&nbsp;Stoica.
 Wide-area cooperative storage with CFS.
 In <em>18th ACM Symposium on Operating Systems Principles
  (SOSP '01)</em>, Chateau Lake Louise, Banff, Canada, October 2001.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEpipenet" name="pipenet">[12]</a></dt><dd>
W.&nbsp;Dai.
 Pipenet 1.1.
 Usenet post, August 1996.
 <tt>&lt;http://www.eskimo.com/&nbsp;weidai/pipenet.txt&#62; First mentioned in a
  post to the cypherpunks list, Feb.&nbsp;1995.

<div class="p"><!----></div>
</tt></dd>
 <dt><a href="#CITEdanezis-pets03" name="danezis-pets03">[13]</a></dt><dd>
G.&nbsp;Danezis.
 Mix-networks with restricted routes.
 In R.&nbsp;Dingledine, editor, <em>Privacy Enhancing Technologies (PET
  2003)</em>. Springer-Verlag LNCS 2760, 2003.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEstatistical-disclosure" name="statistical-disclosure">[14]</a></dt><dd>
G.&nbsp;Danezis.
 Statistical disclosure attacks.
 In <em>Security and Privacy in the Age of Uncertainty (SEC2003)</em>,
  pages 421-426, Athens, May 2003. IFIP TC11, Kluwer.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEminion-design" name="minion-design">[15]</a></dt><dd>
G.&nbsp;Danezis, R.&nbsp;Dingledine, and N.&nbsp;Mathewson.
 Mixminion: Design of a type III anonymous remailer protocol.
 In <em>2003 IEEE Symposium on Security and Privacy</em>, pages 2-15.
  IEEE CS, May 2003.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEpuzzles-tls" name="puzzles-tls">[16]</a></dt><dd>
D.&nbsp;Dean and A.&nbsp;Stubblefield.
 Using Client Puzzles to Protect TLS.
 In <em>Proceedings of the 10th USENIX Security Symposium</em>. USENIX,
  Aug. 2001.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITETLS" name="TLS">[17]</a></dt><dd>
T.&nbsp;Dierks and C.&nbsp;Allen.
 The TLS Protocol - Version 1.0.
 IETF RFC 2246, January 1999.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEmix-acc" name="mix-acc">[18]</a></dt><dd>
R.&nbsp;Dingledine, M.&nbsp;J. Freedman, D.&nbsp;Hopwood, and D.&nbsp;Molnar.
 A Reputation System to Increase MIX-net Reliability.
 In I.&nbsp;S. Moskowitz, editor, <em>Information Hiding (IH 2001)</em>, pages
  126-141. Springer-Verlag, LNCS 2137, 2001.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEfreehaven-berk" name="freehaven-berk">[19]</a></dt><dd>
R.&nbsp;Dingledine, M.&nbsp;J. Freedman, and D.&nbsp;Molnar.
 The free haven project: Distributed anonymous storage service.
 In H.&nbsp;Federrath, editor, <em>Designing Privacy Enhancing
  Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>.
  Springer-Verlag, LNCS 2009, July 2000.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEtor-spec" name="tor-spec">[20]</a></dt><dd>
R.&nbsp;Dingledine and N.&nbsp;Mathewson.
 Tor protocol specifications.
 <tt>&lt;http://freehaven.net/tor/tor-spec.txt&#62;.

<div class="p"><!----></div>
</tt></dd>
 <dt><a href="#CITEcasc-rep" name="casc-rep">[21]</a></dt><dd>
R.&nbsp;Dingledine and P.&nbsp;Syverson.
 Reliable MIX Cascade Networks through Reputation.
 In M.&nbsp;Blaze, editor, <em>Financial Cryptography</em>. Springer-Verlag,
  LNCS 2357, 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEsybil" name="sybil">[22]</a></dt><dd>
J.&nbsp;Douceur.
 The Sybil Attack.
 In <em>Proceedings of the 1st International Peer To Peer Systems
  Workshop (IPTPS)</em>, Mar. 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEfederrath-ih96" name="federrath-ih96">[23]</a></dt><dd>
H.&nbsp;Federrath, A.&nbsp;Jerichow, and A.&nbsp;Pfitzmann.
 MIXes in mobile communication systems: Location management with
  privacy.
 In R.&nbsp;Anderson, editor, <em>Information Hiding, First International
  Workshop</em>, pages 121-135. Springer-Verlag, LNCS 1174, May 1996.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEtarzan:ccs02" name="tarzan:ccs02">[24]</a></dt><dd>
M.&nbsp;J. Freedman and R.&nbsp;Morris.
 Tarzan: A peer-to-peer anonymizing network layer.
 In <em>9th ACM Conference on Computer and Communications
  Security (CCS 2002)</em>, Washington, DC, November 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEherbivore" name="herbivore">[25]</a></dt><dd>
S.&nbsp;Goel, M.&nbsp;Robson, M.&nbsp;Polte, and E.&nbsp;G. Sirer.
 Herbivore: A scalable and efficient protocol for anonymous
  communication.
 Technical Report TR2003-1890, Cornell University Computing and
  Information Science, February 2003.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEian-thesis" name="ian-thesis">[26]</a></dt><dd>
I.&nbsp;Goldberg.
 <em>A Pseudonymous Communications Infrastructure for the Internet</em>.
 PhD thesis, UC Berkeley, Dec 2000.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEor-ih96" name="or-ih96">[27]</a></dt><dd>
D.&nbsp;M. Goldschlag, M.&nbsp;G. Reed, and P.&nbsp;F. Syverson.
 Hiding routing information.
 In R.&nbsp;Anderson, editor, <em>Information Hiding, First International
  Workshop</em>, pages 137-150. Springer-Verlag, LNCS 1174, May 1996.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEbabel" name="babel">[28]</a></dt><dd>
C.&nbsp;G&#252;lc&#252; and G.&nbsp;Tsudik.
 Mixing E-mail with Babel.
 In <em>Network and Distributed Security Symposium (NDSS 96)</em>,
  pages 2-16. IEEE, February 1996.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEhintz-pet02" name="hintz-pet02">[29]</a></dt><dd>
A.&nbsp;Hintz.
 Fingerprinting websites using traffic analysis.
 In R.&nbsp;Dingledine and P.&nbsp;Syverson, editors, <em>Privacy Enhancing
  Technologies (PET 2002)</em>, pages 171-178. Springer-Verlag, LNCS 2482, 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEjerichow-jsac98" name="jerichow-jsac98">[30]</a></dt><dd>
A.&nbsp;Jerichow, J.&nbsp;M&#252;ller, A.&nbsp;Pfitzmann, B.&nbsp;Pfitzmann, and M.&nbsp;Waidner.
 Real-time mixes: A bandwidth-efficient anonymity protocol.
 <em>IEEE Journal on Selected Areas in Communications</em>,
  16(4):495-509, May 1998.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITElimits-open" name="limits-open">[31]</a></dt><dd>
D.&nbsp;Kesdogan, D.&nbsp;Agrawal, and S.&nbsp;Penz.
 Limits of anonymity in open environments.
 In F.&nbsp;Petitcolas, editor, <em>Information Hiding Workshop (IH
  2002)</em>. Springer-Verlag, LNCS 2578, October 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEsocks4" name="socks4">[32]</a></dt><dd>
D.&nbsp;Koblas and M.&nbsp;R. Koblas.
 SOCKS.
 In <em>UNIX Security III Symposium (1992 USENIX Security
  Symposium)</em>, pages 77-83. USENIX, 1992.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEdefensive-dropping" name="defensive-dropping">[33]</a></dt><dd>
B.&nbsp;N. Levine, M.&nbsp;K. Reiter, C.&nbsp;Wang, and M.&nbsp;Wright.
 Timing analysis in low-latency mix-based systems.
 In A.&nbsp;Juels, editor, <em>Financial Cryptography</em>. Springer-Verlag,
  LNCS (forthcoming), 2004.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEhordes-jcs" name="hordes-jcs">[34]</a></dt><dd>
B.&nbsp;N. Levine and C.&nbsp;Shields.
 Hordes: A multicast-based protocol for anonymity.
 <em>Journal of Computer Security</em>, 10(3):213-240, 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEmeadows96" name="meadows96">[35]</a></dt><dd>
C.&nbsp;Meadows.
 The NRL protocol analyzer: An overview.
 <em>Journal of Logic Programming</em>, 26(2):113-131, 1996.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEmixmaster-spec" name="mixmaster-spec">[36]</a></dt><dd>
U.&nbsp;M&#246;ller, L.&nbsp;Cottrell, P.&nbsp;Palfrader, and L.&nbsp;Sassaman.
 Mixmaster Protocol - Version 2.
 Draft, July 2003.
 <tt>&lt;http://www.abditum.com/mixmaster-spec.txt&#62;.

<div class="p"><!----></div>
</tt></dd>
 <dt><a href="#CITEdarkside" name="darkside">[37]</a></dt><dd>
V.&nbsp;S. Pai, L.&nbsp;Wang, K.&nbsp;Park, R.&nbsp;Pang, and L.&nbsp;Peterson.
 The Dark Side of the Web: An Open Proxy's View.
 <tt>&lt;http://codeen.cs.princeton.edu/&#62;.

<div class="p"><!----></div>
</tt></dd>
 <dt><a href="#CITEisdn-mixes" name="isdn-mixes">[38]</a></dt><dd>
A.&nbsp;Pfitzmann, B.&nbsp;Pfitzmann, and M.&nbsp;Waidner.
 ISDN-mixes: Untraceable communication with very small bandwidth
  overhead.
 In <em>GI/ITG Conference on Communication in Distributed Systems</em>,
  pages 451-463, February 1991.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEprivoxy" name="privoxy">[39]</a></dt><dd>
Privoxy.
 <tt>&lt;http://www.privoxy.org/&#62;.

<div class="p"><!----></div>
</tt></dd>
 <dt><a href="#CITEreed-protocols97" name="reed-protocols97">[40]</a></dt><dd>
M.&nbsp;G. Reed, P.&nbsp;F. Syverson, and D.&nbsp;M. Goldschlag.
 Protocols using anonymous connections: Mobile applications.
 In B.&nbsp;Christianson, B.&nbsp;Crispo, M.&nbsp;Lomas, and M.&nbsp;Roe, editors, <em>
  Security Protocols: 5th International Workshop</em>, pages 13-23.
  Springer-Verlag, LNCS 1361, April 1997.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEor-jsac98" name="or-jsac98">[41]</a></dt><dd>
M.&nbsp;G. Reed, P.&nbsp;F. Syverson, and D.&nbsp;M. Goldschlag.
 Anonymous connections and onion routing.
 <em>IEEE Journal on Selected Areas in Communications</em>,
  16(4):482-494, May 1998.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEcrowds-tissec" name="crowds-tissec">[42]</a></dt><dd>
M.&nbsp;K. Reiter and A.&nbsp;D. Rubin.
 Crowds: Anonymity for web transactions.
 <em>ACM TISSEC</em>, 1(1):66-92, June 1998.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEmorphmix:fc04" name="morphmix:fc04">[43]</a></dt><dd>
M.&nbsp;Rennhard and B.&nbsp;Plattner.
 Practical anonymity for the masses with morphmix.
 In A.&nbsp;Juels, editor, <em>Financial Cryptography</em>. Springer-Verlag,
  LNCS (forthcoming), 2004.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEanonnet" name="anonnet">[44]</a></dt><dd>
M.&nbsp;Rennhard, S.&nbsp;Rafaeli, L.&nbsp;Mathy, B.&nbsp;Plattner, and D.&nbsp;Hutchison.
 Analysis of an Anonymity Network for Web Browsing.
 In <em>IEEE 7th Intl. Workshop on Enterprise Security (WET ICE
  2002)</em>, Pittsburgh, USA, June 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITESS03" name="SS03">[45]</a></dt><dd>
A.&nbsp;Serjantov and P.&nbsp;Sewell.
 Passive attack analysis for connection-based anonymity systems.
 In <em>Computer Security - ESORICS 2003</em>. Springer-Verlag, LNCS
  2808, October 2003.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEp5" name="p5">[46]</a></dt><dd>
R.&nbsp;Sherwood, B.&nbsp;Bhattacharjee, and A.&nbsp;Srinivasan.
 p<sup>5</sup>: A protocol for scalable anonymous communication.
 In <em>IEEE Symposium on Security and Privacy</em>, pages 58-70. IEEE
  CS, 2002.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEshsm03" name="shsm03">[47]</a></dt><dd>
A.&nbsp;Shubina and S.&nbsp;Smith.
 Using caching for browsing anonymity.
 <em>ACM SIGEcom Exchanges</em>, 4(2), Sept 2003.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEor-discex00" name="or-discex00">[48]</a></dt><dd>
P.&nbsp;Syverson, M.&nbsp;Reed, and D.&nbsp;Goldschlag.
 Onion Routing access configurations.
 In <em>DARPA Information Survivability Conference and Exposition
  (DISCEX 2000)</em>, volume&nbsp;1, pages 34-40. IEEE CS Press, 2000.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEor-pet00" name="or-pet00">[49]</a></dt><dd>
P.&nbsp;Syverson, G.&nbsp;Tsudik, M.&nbsp;Reed, and C.&nbsp;Landwehr.
 Towards an Analysis of Onion Routing Security.
 In H.&nbsp;Federrath, editor, <em>Designing Privacy Enhancing
  Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>,
  pages 96-114. Springer-Verlag, LNCS 2009, July 2000.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEtannenbaum96" name="tannenbaum96">[50]</a></dt><dd>
A.&nbsp;Tannenbaum.
 Computer networks, 1996.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEjap-backdoor" name="jap-backdoor">[51]</a></dt><dd>
The AN.ON Project.
 German police proceeds against anonymity service.
 Press release, September 2003.

  <tt>&lt;http://www.datenschutzzentrum.de/material/themen/presse/anon-bka_e.htm&#62;.

<div class="p"><!----></div>
</tt></dd>
 <dt><a href="#CITEtangler" name="tangler">[52]</a></dt><dd>
M.&nbsp;Waldman and D.&nbsp;Mazi&#232;res.
 Tangler: A censorship-resistant publishing system based on document
  entanglements.
 In <em>8<sup>th</sup> ACM Conference on Computer and Communications
  Security (CCS-8)</em>, pages 86-135. ACM Press, 2001.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEpublius" name="publius">[53]</a></dt><dd>
M.&nbsp;Waldman, A.&nbsp;Rubin, and L.&nbsp;Cranor.
 Publius: A robust, tamper-evident, censorship-resistant and
  source-anonymous web publishing system.
 In <em>Proc. 9th USENIX Security Symposium</em>, pages 59-72, August
  2000.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEwright03" name="wright03">[54]</a></dt><dd>
M.&nbsp;Wright, M.&nbsp;Adler, B.&nbsp;N. Levine, and C.&nbsp;Shields.
 Defending anonymous communication against passive logging attacks.
 In <em>IEEE Symposium on Security and Privacy</em>, pages 28-41. IEEE
  CS, May 2003.</dd>
</dl>


<div class="p"><!----></div>
<hr /><h3>Footnotes:</h3>

<div class="p"><!----></div>
<a name="tthFtNtAAB"></a><a href="#tthFrefAAB"><sup>1</sup></a>Actually, the negotiated key is used to derive two
  symmetric keys: one for each direction.
<div class="p"><!----></div>
<a name="tthFtNtAAC"></a><a href="#tthFrefAAC"><sup>2</sup></a>
        With 48 bits of digest per cell, the probability of an accidental
collision is far lower than the chance of hardware failure.
<div class="p"><!----></div>
<a name="tthFtNtAAD"></a><a href="#tthFrefAAD"><sup>3</sup></a>
Rather than rely on an external infrastructure, the Onion Routing network
can run the lookup service itself.  Our current implementation provides a
simple lookup system on the
directory servers.
<div class="p"><!----></div>
<a name="tthFtNtAAE"></a><a href="#tthFrefAAE"><sup>4</sup></a>Note that this fingerprinting
attack should not be confused with the much more complicated latency
attacks of&nbsp;[<a href="#back01" name="CITEback01">5</a>], which require a fingerprint of the latencies
of all circuits through the network, combined with those from the
network edges to the target user and the responder website.
<br /><br /><hr /><small>File translated from
T<sub><font size="-1">E</font></sub>X
by <a href="http://hutchinson.belmont.ma.us/tth/">
T<sub><font size="-1">T</font></sub>H</a>,
version 3.59.<br />On 18 May 2004, 10:45.</small>
</body></html>


------------v0WB7ELziomGaMwnGQQbCY
Content-Disposition: inline; filename=cell-struct.png
Content-Type: image/png; name=cell-struct.png
Content-Location: https://svn.torproject.org/svn/projects/design-paper/cell-struct.png
Content-Transfer-Encoding: Base64

iVBORw0KGgoAAAANSUhEUgAAAaYAAAB5CAIAAAD9DBIaAAAACXBIWXMAAAxNAAAM
TQHSzq1OAAAAHXRFWHRTb2Z0d2FyZQBHTlUgR2hvc3RzY3JpcHQgNy4wN6zhIvkA
ABU2SURBVHic7Z0/srPG0oeHr97chRIHzkbeASe/Ccpd5ULeAVoCWgJaAuzAsARY
Ascu5xZlBw4ceKiyA9sRN/h9p++8wx8BEhIS/URHHNTTdA/NdM+Iseq6FgzDMOvg
/x6tAMMwzP3gkPc/3t/fH60C83xUVXVbgdwPZ2X2kFdV1eFw2Gw2lmVtt9vj8Th3
ixPI83y32729vT1aEeYJKMvS0jidTvSv4/G43W6bXR13wdvbm2VZu92uK6jFcbzd
brkfzks9M57nZVlW13VRFI7jCCGCIJi70VEkSRKG4X2swbwAQRAopegj/R0EgW3b
6O1RFAkhfN/HCVJKdHullOd5tm2fz+dW4ZP7IdplLjLvTV4URRRF9DHLMiGEbduz
NjoNDnnMEJRSCGQG5/PZeJz7vi+EyLIMf1CMK4qComGTaf1QKbXM22qBzB7yzPY4
5DHPDBIC13XDMNRHakEQIMDRETzgEe+MriWEkFK2yp/QD5VSyJ9GfWu13NVMSqme
59tj4ZDHDCGKItd1bdvGw5uSmGbQQW+XUqJr6blwT2fDv6Iowhcdx0mSpK7rLMvQ
KEVV27allOfz2fM8qlNhmFkUBR2UUuIrGJ9CCJRfZy5815s8iiLbtnXfLwcOecwo
qP6LkNTaf3DQdV1EMeN4q1gKebUW5tAEBpI0tEyShPJoQ6DjODgNA0DkVYihOAGS
wzC8gSGejbve5FLKZqq7EDjkMWNB1EOK2hPyqISNUVWWZVLKgYktpkFwMgp2lCT5
vk/hT/9WkiSiARoVQniehzFHURRdUyivzf1u8iAI9Afd0uCQx4wFqSu6TWs1DZlp
XddZluEE27aDIHAcZ+D0hd5E/flAz/O81m8FQeC6blMyLZlY7fgO3GkpchzHUkoq
5TLMC4Csk4puQog8z+m/WHyHrNZ1XeQ3SinXdd/f3/UC3MAmxMdkSBzHcRxDciut
6/4cx8EKCikl1g+maTr0Ul+JO4TVKIqMZ9oC09u7WYN5GfSFKVh6oi9SQdrbTB4d
x9EHaAZGP2xd+2LbtiFB/xZyYX1qQimVJInrunQQo8Vlrp2Ym9lv8izLDPdEUbTA
IgKHPOYiRVEEQUC9Fykq/Vdfp4L5AWPVPeZMHcfpmcFDP8QJ5/PZ931juIAgaByk
b53PZ5T8qHQIIc3FEuIj6V4bs6/Lo0lxorXQ8EAQlO857GWeFMwMIJYBI3jhBxhC
CPq5BVBKYXXLxZ8eIYyiKzqO01r+pjRZ/5bQFs0URYG0F9MdUFJ8ZN/G8bVh1fzy
KIYZTFVVepFuIGmaSikp4lzJbrfDLDAzAQ55DPNMxHFcVRWGdcwEPj1aAYZhLpOm
6eFwcBynqioe4l0DhzyGeQKwTqUsyyRJmvVxZjic2DIMsyL4rcgMw6wIDnkMw6yI
T3meHw4H+kXLU/DXX3/9+eefX3311aMVaefnn3/++uuvH60FwzCfUVWV67qfhBCe
59GbcJ6CPM/zPF+szrxsimEWCOIGJ7YMw6wIDnkMw6wIDnkMw6wIDnkMw6wIDnkM
w6wIDnkMw6wIDnkMw6wIDnkMw6wIDnkMw6yIQSEvz/P9fr/ZbCzLsixrs9kcj8e3
tzf893Q6WZbVuqlSD7vdzvpgv99j06b9fm9pbDab3W53Op2qqhp7YT06U9ObzaZV
cp7npFie57dVjHkKpjm9qiq6L3SOx6PVzfF4HCiHuQFZlvW/jx/7yDmOQ9sjFUWB
zSLwES/wmvAefWxcIj7fbkI/cj6foyjCduvYsB1crzP2oxKf7x1F0FYYYxUDS9vc
g5nMcKeD5u5iwPM86mm6TKUU9tAYKIe5BsSNCyGPNktvRrSu7dZH0R9ZgFIKbz2g
naVuojPOae5rhx2hpikGOOS9DMOdDlzXtW272QGMrcUMmc09HrvkMNeAuHEhscXm
vrRvk04QBJTMGkP9siz7xY4CG0oJIU6n05DzB+qMj1VVxXGsnxPH8fBtlUcpxrwA
PU7P89xxHN/38zw3boH+rSqMF2T0yGFuQP+ICef0bDubJImeMGLkL4QoioLGUNi+
s3WzO8hvtmi0ghSYxmhX6kynYcdPfeinlMIjd5pigB/OL8Nwp9d1jW0SW/eZvShz
ghxmLINGeaDnbXqe5+V5Th8dx8EwKo7jMAyllFVV7XY7ikGe551Op7HPLnrx/9iv
9IPdPMuyxMAQao/arG+CYsyz0+r0siyxYbaU0vd97EM2Qfit5DCdDBkx9cdO4xzj
I4b0VFZTSulF2ab8rhb149frjNPqjyc2jcvoj2mKGUKYZ2e404MgoMQCk2NdXbS/
fw6Xw4xl0Cjv+r2UUCkjOSjKjhWCB91AZUbpjGcp3h2YpunYzZVHKca8Bk2noyK8
3W6x6ATrS4wa8UDJN5HD9HAh5CEEjF1zp4P+cWXqh8RzYKwcqzNqkWmaxnE8dkfk
UYoxr0HT6WmahmGoDyhaZ8aGSL6JHKaHCyEPfqVSl05VVUOqDAhAer2vLEv94xDg
clo70s9YnV3XdRwnjmPMt8ynGPMaNJ1+Op2MWX78d+xU/q3kMD1cCHm+7yMc6HMO
VVVh7/SeL1JkwbjpeDwizJVl2Zwi6BkDlmW53+/LsoyiaOBgaojOUI9GguhYo4Z4
ExRjnp1Wp8dxjPXJ+plSStd1e57uzePT5DCjufhLBqVUGIb6Xe15XhRFVBHEQZRd
9RVGJDZJEoz1MEOKqYwsy/TnpOu6WZY1F8S5rqsXdPUy5GSdaWGNriQtBy2KghTz
fb8oiuGKAZ6+eAEGOh0/PRLaDBgdx8SulFL/qYbxWKWpvLFymAkgblhZli15t7BW
eIczhmHGwjucMQyzOjjkMQyzIjjkMQyzIjjkMQyzIjjkMQyzIjjkMQyzIqyiKJrv
oV44f//9999//73ZbB6tSDu//fbbV1999WgtGIYx8TzPqj9e7cAwDPPycGLLMMyK
4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK
4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK4JDHMMyK4JD3P97f3x+tAjOU
sizzPH+0FnPBXXE+Zg95VVUdDofNZmNZ1na7XeYbmPM83+12b29vj1ZkOk9h55sQ
x/Fut8vz3HGcWRt6iElfoCsO4Xg8WpZFH2Hqt7c3y7J2u50R8Y/H43a7tSxrs9kc
Doeqqq5qu54Zz/OyLKvruigK9NEgCOZudBRJkoRheB9rzMfy7Xw9SinHcTzPU0rd
obn7m/Q1uuJFiqKwbZuuUSklpYRtlVKe59m2fT6f8d8gCIQQRVHUdZ0kiRDCdd1r
Wp/XskVRRFFEH7MsE0LYtj1ro9N46n72RHaeDOKd4zj3ae6BJn3qrngRpVQQBK7r
0jX6vi+EoBhXFIUQwvd9fDSscb1xZg95ZntLvRWfup89kZ0ng3EWhl134IEmfequ
eBHf95VSeshrXq8QQkqJv6WU5HdEwyvH2vPW8oxqC5Jwz/NmbXSFvLyd4zh+f3+X
UuZ5juLafr+ftcb/8iZ9CHEcu66LrNbAqNCVZYk/kOnD3cfjMQgCyv0nck28HEsU
RbZt36cQM5b7W2M+lmznaSAAOY6DwVeWZbhtmmOxmbinSV+pK+qcz2dKV/VRHv7W
ywiGBZIkgbtvUku9q2WllHfro2N5pX62ZDtPA97RIw4e9Z7n3UeBe5r0lbqijj7v
pIc8qpMie82yTEpJiW1d10mSuK6Lxx4Fzcncz7JBEOiBfGm8TD9buJ2n0fTO+Xy+
m8vubNKX6Yo6QRDodVg95NV1nWUZIppt20EQOI5DoS2KIiFEkiRKKUx0XDnWu5Nl
oyha+H34Gv1s+XaeBu4QmtQD93HZ/U36Gl3RAB5s0oxfGPRRfDSWs4irJ5HuYdko
iozh6ALTrhfoZ09h52ngUa/fHuj9cye2DzHpC3TFi/RcI5Zedp15vXFmt2yWZUa/
jKLIeFwvgWfvZ89i58kgqQnDEB+DINAXrM7Bo0z67F1xCK3XiNTVcRy9aItZcvjd
WLI3selrvnwRWmatc+Xi6ZuDnk3qPVqdKTyFna8HYQ6pje/7s0afh5j0BbriQIwL
VEpFUeS6bjPPRRwkvwdBcOW8uUXNMwzDPIQ0TaWUc/9oGnDIYxhmRfDLoxiGWREc
8hiGWREc8hiGWREc8hiGWREc8hiGWRGfyrKM4/jRaozj33///eeff7744otHK9LO
77///uWXXz5ai3uzcKe0Mp/OC7HGQtRYDq7rfirLsqqq53oR2I8//vjDDz98++23
j1aknSAITqfTo7W4Nwt3Sivz6bwQayxEjYXw/v6e5/knIYRt210/+l0sf/zxx2J1
3mw2i9VtVpbslC7m03kh1liIGgshz3Ou5TEMsyI45DEMsyI45DEMsyI45DEMsyI4
5DEMsyI45DEMsyI45DEMsyI45JlUVZXn+aO1YBhmFgaFvDzP9/s9dom3LGuz2RyP
x7e3N/z3dDpZljV26/jdbmd9sN/v4ziO43i/31sam81mt9udTidjJ/Me4jjWJUPI
4XAYEsXoMne73ahrGcXxeNxut9DtcDjs9/vhVzcTM/mCGC5tWl+6hp9++okuf7/f
l2V58yZ6bh9qerPZtBo2z3PSLc/z2/rlSqYpU1UVhQ6d4/FodXM8HgfKuUyWZf37
QmKbFcdxaJu1oijwAzV8xF7iE15I37oVqX7kfD5HUeQ4jm3bSZLQOf06Y+8rXT28
YHrI1nzGd6fRs0NCEARCCFwL3vdPOxYD/e97MtkXxMWONETa5L50kVbDQuebOL1V
cj3g9sEWNqJje1b6Jah+cLhfLjrlekZ1kvpjs7qmOzzPI1V1mUqpIAiaV9ElpwdY
40LIg1wpZbMX6tuJT6bfnUApJaUU2jamo+6u+uN+HqjwrCFP35QT6FsaK6Wu3KPz
Gqb5ghjrlH5pt6XLsKTzTCFv4O2Dc5oans9nRMzJfrlzyOtXBriui1+4Gsf1fcua
Mpu7d3bJ6QHWuJDYpmmK509zt6cgCCgBMcaxt80OsK2REGLyb/XhgDlylmnoF+L7
PsxYVdVut7u5JZfmi4vSbp6gtRr2VvTn4ANvH3ysqsp4p1EcxwPf93Fbv1xJjzJ5
njuO4/t+nudGz8RXugjDcKCcy/Q/B3BOz0M4SRJ9lI5hrRCiKAp6cOnbskkp9eYg
v9mi0YoxTBs7oIC99McIJRcQqw+P9e/iNNIc2zZnWYYj+obqUkqy0sXEFg42nvx6
58YAoWnJLrVb9SyKAr8np60CkW5Qpk9ndll+iC+ICaM8Q5rRl+qPpMaIF2il1RR6
T8P1GtskGhoOHOW1tpVlGR6lWZaRPckj/59DXbp9yDIYh+pWVUphaHONXx4yyutS
pq5r3/eVUvhvz3a0/e4YLsdgUGJ7se3682SNChO+7+PWUkohHuMORz+gTjDQncbx
gXdXlmVZliE1MEKM4zjQAerpOYXeEI2cUe4hFxpXkSSJrk//YJvuBCmlUV7Um25a
skftLj3JDrVWpsRHyIfYZutdR3qOTwt5dcPg+jnwHRyHJJGaaDUFYhDpY9s2tnzu
anpgyOsyO76FohXsaTyVh9w+kFN/Xuet6zoMQ3SPa/zyqJDXevx8PpMyumeHyxwr
x+BmIc84x/gIR5JOSqmuIVV/ixNCHppulsOTJBENSCu9oTAMjXhBV4Hdo/HR2Eb6
Yn1Br9H0lDCMjz1qd+nZL7D/Y+uRnuM3CXk9KumX1mUKhDzP8+Dxoijgl66mh4S8
HrP3aDsh5GHMQp2H/rjGL4sKeUEQ0G2CJ0SXbv12Gy7HYFAtr1mDGAvKE3quMeHt
XSjEjFUmDEOUSIwZ7vf392ZUatUqCAIpZRzHKMoQiHdxHKOOUFUVbraBYHyH2ck4
jpsT8K30qN2l5xxM88U0abAqal44B3GkyxQYDqdput1uT6eT4zij/NLK8N7SZJSV
pJQoTuV5nqbp2H2sb+uXK2kqg0olLc/C+pIJ72O/Xs6FkAe7X7NOChd/ZREdd/KE
WBmGoeu6WGimHx94RafTKY5j3/dpUEbgCCQPVKwsS71dz/MwghjusC61e/S8OZN9
MUFakiQI5UKI0+nk+z6VsVtN4ThOURRRFEkpsf7xymcA+u3k/j/29kHFME3TOI77
y/lNbuuXK2kqk6Ypigz6YK05YzNE8rVy+oe+6GGtJyilkD5ADh03PjbXxJ3P59Ys
susICTFqw106142EiMrMONJc0aOUohoKfRfho0cxVMpbp89btUIlyMiyhRBGbair
xS61e/TsF9j/sfVI3fAFMS2xNaQ1z8FQHZOAdLDLFK7r0kEqa3Q1XV9KbDF50tNb
egwIyUNun/ojsdUN0r9iY7hfHpXYNpVprtTpWTrW5a+xcgwG1fKoXhuGIeXPcDlV
TFodT2phIEMLbvXSI52sF8IMaefzGXORetAce3ch4bdtm4rQtm3rKtHsiv5dDMvR
bpZlxnXVH7ZuThj1r8vTV6UatwQ1oVeg9DJoq9o9eva7pvW/Y31BTFgs2ZRmnINx
a5ZlxqRnlymawQLzM4Zhmzo37zHMdydJ0tNbLoa8IbcP1Kapc0TYHi8MtKRxgfMx
RJkoipojg/qjPtB8fEJm8/hYOQaDQl5d10oppIfiA8/z6HroHkNNUV8+Q2JpVQRK
YPA0zaUCPJ+bq5Bc19WrlbrqXVdFQvRZWigmpaT5NVyRrhLCMb5L+RF9C/8y2nVd
V1/nQQe7jOm6LpZQNq1UawOTKIpaLdmqdpee5Br0Br0Mn2UZyU+S5BpfjHVKjzSj
L9Xa7PZAU4iPXNI4rhvWUOybb77pWftG0yDNtkjbMAxxj5BtdWv03z60Lke/NLqr
i6LQp7mKohjrl1lD3kBlULMW2swMHdf7LR03nE6BbKycVoWDILCyLMvz3Fjpt3BQ
4l2CzrvdTo8sPQcN8JtfDAHmUu6+zOGU0+mEcTEtJM7zHI+Nm8ifryMtpIsuRI2F
AGt8erQaT8zwiYsmCykzL5nD4RDHcf2R5gDHcZbzKxrmGeGXR40mTVO8MQKTpI9W
52XBrN/xeMQQr6qqNE3xS6NHq8Y8MRzyRkO/2MV7UB6tzsuCSlYcx5vNBm8Aw/z4
o/VinhtObEeDhSaP1uL1wYJtzGAyzK3gUR7DMCuCQx7DMCvCyrIMv0Z8tCYj+PXX
X3/55Zf//Oc/j1akne+///677757tBb3ZuFOaWU+nRdijYWosRCqqrJt21JK3XOr
AYZhmEchpfwvRo30MWPMZdwAAAAASUVORK5CYIKJUE5HDQoaCgAAAA1JSERSAAAB
pgAAAHkIAgAAAP0MEhoAAAAJcEhZcwAADE0AAAxNAdLOrU4AAAAddEVYdFNvZnR3
YXJlAEdOVSBHaG9zdHNjcmlwdCA3LjA3rOEi+QAAAaZJREFUeJzt1DEBACAMwDDA
v+fhAo4mCnp1z8wCaDi/AwDesTwgxPKAEMsDQiwPCLE8IMTygBDLA0IsDwixPCDE
8oAQywNCLA8IsTwgxPKAEMsDQiwPCLE8IMTygBDLA0IsDwixPCDE8oAQywNCLA8I
sTwgxPKAEMsDQiwPCLE8IMTygBDLA0IsDwixPCDE8oAQywNCLA8IsTwgxPKAEMsD
QiwPCLE8IMTygBDLA0IsDwixPCDE8oAQywNCLA8IsTwgxPKAEMsDQiwPCLE8IMTy
gBDLA0IsDwixPCDE8oAQywNCLA8IsTwgxPKAEMsDQiwPCLE8IMTygBDLA0IsDwix
PCDE8oAQywNCLA8IsTwgxPKAEMsDQiwPCLE8IMTygBDLA0IsDwixPCDE8oAQywNC
LA8IsTwgxPKAEMsDQiwPCLE8IMTygBDLA0IsDwixPCDE8oAQywNCLA8IsTwgxPKA
EMsDQiwPCLE8IMTygBDLA0IsDwixPCDE8oAQywNCLA8IsTwgxPKAEMsDQiwPCLE8
IMTygBDLA0IsDwixPCDE8oAQywNCLmRoA+80gcaPAAAAAElFTkSuQmCC

------------v0WB7ELziomGaMwnGQQbCY
Content-Disposition: inline; filename=interaction.png
Content-Type: image/png; name=interaction.png
Content-Location: https://svn.torproject.org/svn/projects/design-paper/interaction.png
Content-Transfer-Encoding: Base64

iVBORw0KGgoAAAANSUhEUgAAAuwAAAGHCAIAAABkmZCvAAAACXBIWXMAAAxNAAAM
TQHSzq1OAAAAHXRFWHRTb2Z0d2FyZQBHTlUgR2hvc3RzY3JpcHQgNy4wN6zhIvkA
ACAASURBVHic7J1PrOxGlf/Lv/CSMImYuCOxeqCHWyMNCxZ5boGyIhq5BxHNLN0b
FClIkVuRWGPvkqU9K8QG7BEKmZEGjXsxCyQUYS/yRiJ6C1uzhAW2kgwLWDwbwkD4
J/xbHG5RqbLd7m53t7vv97O48q0uVx2Xy67jqnNOaU3TMAAAAACAS+P/nVsAAAAA
AIB9aFFiNpvNer1W09M01W6glNVqpWlaa2YATkld157nLRYL6p/z+dzzvLIseYay
LD3P4x14Pp/TwXK5jKJop7ryPPc8bzabjX0RAPyFk/Xn9Xo9m800TZvNZp7n1XV9
hKsB14yqGAyhVXnI83wfCRoF27YZY0VRqD9JZ5mmyRizLEvNeV6yLDu3COCvVFV1
1PKzLNN1nTHm+z6l+L7PGNN1XeoJUgd2XZf+dV13SEVxHPNTWp+do4JefXaO3ZOJ
k/VnsTMTjuOMey2gi9P0pdOwxytRVR6SJNnvpSqfUxRFz2MgyRrHMWMsDMM9Kh4d
3/ezLIvjmJQwSrRt27bt/rN0Xe8veWshhGVZrWqiZVnUUNSq6lCUZRk/13Gc63iP
iA2bZRl/HY9OVVX0xpfazXEceu+L6rj6sNG/W/uAyCmVGPTqs3OynkycrD8XReE4
Dg2lNH6crFdvhbr9uaU4Crw7naAvnYw9Oo+kPHDFfZ/apf9d1zUMgx4DVVXcKmtV
VWEYuq7b+l47HlJ1TPg02fpRsrXhhhTSNI1t2/z9wluJ3hRiioppmlz4JElM09xa
17moqmr4B4R4vVmWDfw63BX+NZkkiZguDrGiSK0v/Z0enpO97tGrJ8JpejJxsv5c
FIX4LA/Xfo7NiceOUdjvxXjsvnQyhvS6qqq6bivXYEZQYqqqchyHpi5Z2xSLKGuW
ZZLocRyTKFwgukNUrJQ4IkmSSF8tu45JY4khlsmLpfSeOyS9sKbcrYd8u3Ok63Uc
p3WN8kBI51bbtqoqSjcMQxRJzMznHcU8WzmNEoNePR1O05OJ0/dnsaizT5ip3f4i
2PvFeNS+NJCiKGh0Nk2zKAquUvB/DcOgZ7lrKOf9kCaM6dw4jvkptHhkmqZhGKSk
il1Xmu7dVW34yKMShmEcx61PiySr+i8Xi0QXf6ILoFtF4o5722zblr5a2M33ouu6
9AlIz0aSJCSAOI/HL8eyLF3XXdcVxRMLoSailulfRFNfQz2ve6p3p6lFPldvWVZV
VT1XVxQFJRqGQTeX+pDrulQpFUKXTP2MyqcC+colnUhXwRcyJTGapqmqilJo9luU
mQxKhl/jQKQ+2f8TT0mSJI5jujpxsuHAGkcEvXp4r26aZkjHbu3VrVU35+jJxOn7
c3Pz9m6dfT8xYren9qdj8cK7OoZ6E7tyjtt/pBejKkbT3Z2O2peGQ5fA5+FISFIA
SJmg9K6hnPdDmpGibIwx3if5HIzjOHS9UmdW+/ZwteEjjwp/qXF9im7wX3N3V8xP
oZ/o3iRJQu9H8ZUqvY8OxzAM6dmj6ug9KEobhiFNaomzpjyz9KInpEIGLmfu9Lrn
d33rKMLz815l2zY9Oa1XRznpoujhJA01SRI+/2lZFi+NtNjm5rOPCiyKwjRNvnzQ
LwZfpFCttKicrVe3K/u99Dl7iNRT44igV3ddndqrm5se29+xu3r1RHoycfr+3Nw0
4xQWccRuT/dLPW7aOkbrTezJOWL/aYQXY5cYXd3pqH1pOHwOjx5VPh1YFEUYhqRW
9gzlUs/kMxqGYfDFGXoRUdOpp0j/7qQ2/LU1xXk8vv4qeR71VNz17KkG8GzsFSW1
Uqm79yQ2N/PeotbcUwX/uOz/ZFGborVxRMIwpPvdL0lz46og0nV13HCvEZYkJTHo
XvNPCrWQpmmSJKFHXUxsFUN8B/Xfl7HgWr/6E6WL7wguqjifuWtv7Orq44Je3XV1
rb26GdaxW3v1RHoycfr+TOsFU9BgGqVhe7q3dNx6E1tzjt5/xPQuMXq607HfJAPh
s0dJkpD1MWPM932+UtYzlEsXK6ZwdYTgja/eJvHfndSGjyzOqacxYSKov2J+LH32
cWmON1GpdgLW1t1bE+mYpr57HmOen17KotFiV361p6pySvCPV8uyWu8ildBqkrn1
kltzErROSUsMXdn4XeYpw8XoSTmcLkNI7nDRZQgpvm6kc/uRnoIjgV495JK7MhNq
x27t1RPpycSJ+zPdHXHG/bzepq03aMhxl6G6mnP0/iMeDBejp96zwLUN27ZpPokx
Zpomn//oGcrVVyL9S0pekiR8oYbdzIxIp0j/7qQ2/OUcWiMUf+CliCZLPRVzKaVb
yCd1xOdkXIVGtajf+u6TjulJNk2zSzAxf1EUtm33m85Jd7Q1pWma5Aax8NacIq7r
SjeLzlKl1XVdfCXRTKlaOI1h0rqDmI3aR0rsEkN0ZpEqOsbj2uWSyld5VRcMLgbv
tOraTQ/qE3sM0Kt36tVNW+9SO3Zrr55IT+ZSnbI/m6bJG5OGLsmE4MRI3b6ne0vH
rTexNefo/UdM7xGjqzsd+00yHFpFoo7H5/Z4R+oZyqV+yJ93x3Fo9a25ecPwbNIp
0r87qQ1/bXpJAa9uzHuZ4KbUUzE3adZ1nd5fNCvV3EyQGobBlyF3+vDdim3bagwo
9bj/GaAe2WVkzvNzyft73pDXPZmJUbuJ7vLso4qjCn2T8fl/3/fVBWM6oBVfKpzM
I5qb4U0q0zAMdemQ7he92qgQJszMtYph2za3M5AqInu3nuvam72Dg1VVxVd/B/pE
iM/FUWfg0at36tXNsI7d2qun05N5+afpz62z7+d1lpG6PbuZVaIuJKZLx603sTXn
6P2nEV6MXWJ0dadj96WdIEWZdwDDMKRe1DWU885D18VjGlHzkpdTc3Pt/TMx1Gg9
dan8dR5SVMmTJJEmfl3XFacrpX95PxM/BfgTyOemqJZxNZimacIwFA3USbAkSfhx
lmW8bxVFwY+rqiKNj2Ir0aKgZNsvFtLcfOtIurwIzT3SxfLeKa0LcqgQcjwT23br
VxQ9h1zarqsTc5JRApdEnXiTrojysBubLEqk+8h7tiRGc7O+TlfBhBVQaoTj2eHz
p4V3P6kZ1SlN8eVIbPWTDMNQLER8CEcHvXp4rxaF6e/Yrb1arbo5X08mTtCfW5f2
9vDNHhex2zfC/BNNilAH6OoY6k3cmnOs/iO+GFUxmu7udIK+NBxpQUbVG7qGcmoN
qUNy5YN3Y97gqvLArXBE98CBasNUJrIOZCc3/WlCj9nxLIf6Ed/RBDt4eJYK3Gra
CSTQqw9H6tj79Wr05FPS1e3P0uaj9B8JscAr60v0vHe5Qx5p6vpKlJirCX14Fmi1
Ukoc5XHluBcYhfPsoFcfiNqxD+/V6MnHZjrd/hj9RwR9aRSuRIlpbnTAc0txYdC0
Hg/IyKluoiaMUkuWZdf0tXFK0Kv3o7VjH96r0ZNPw9m7/ZH6jwj60lhojWBTA24b
ZVkuFgtxrwmCb6pOa+3nEA2A/Wnt2OjVYCDoPxcElBgAAAAAXCT/79wCAAAAAADs
A5QYAAAAAFwkuykxURQtl8sjiQLAiUF/BtcE+jOYDsvlMoqiE1S0mxJTlmWapkcS
BYATg/4Mrgn0ZzAd0jQty/IEFWE5CQAAAAAXCZQYAAAAAFwkUGImRF3X5xYBAAAA
uBhGVmLyPF+v17PZTNM0TdOWy+VqtTrvMm2apkOM3TabjdaGKHwQBHme95dTlqV0
1nDByrIMgmDriQAAAABg4yoxURQtFgtxv3jXdbeO+v3UdX3I/ERd17quD1Ep+A6c
YjxjcaNXz/MsyxI35GwlCALLsrbqIq2CmaZpWZbneVulBQAAAMBoSgzNwVCcZtpz
nDFmWRbfTXs/1us17dC9H7qub1U7euDbiKdpWtf11qLIOyBJkq1uAl2CmaZZ1/Vp
jLoBAACAi2Y0JYbmHlSVxbIsxlhd157n5Xnued5sNmOM5Xm+XC5pyYnmWqIoms/n
YornebTKQ8su6ikSZVlShvl8vtlsDryisizzPCcVKooiPlUjSrJYLBaLBd9TIwgC
mrxxXZdc5CnbbDZL03S9Xs/n863TQpZlnca9HgAAALhsdtoukkbo1p/6S+P7f1Y3
OI5DP9m2bVlW0zS6rvOcfHtPXmbrKVIVjuMURUFyUmlSIf1ILSNuYWoYhrjjqGVZ
VJHv+7yioigMw+B5DMOgPHEcM8aKonAcR9q2tFWwoihM0xwiMDiQnv4MwMWB/gym
A2PMdd1TVLRT7r2VmOajA7a0ZzL9FIZh0zRFUYg5+XHrKSKiilBVFbfLaXZUYvi/
YRhyJUYqgatZpHJRYpIk4i7t4r+u6xqGEcdxT5sMSQfjgpc+uCbQn8F0OJkSM9py
Ell4DDTjretaujzGGNm0dpmDtJ4iEkURt5450BSGcByHG/dIkKhkvMIrsiyL1s7U
fx3HKcsSli4AAADAiIymxNBHwHBjDkndKctysVg4jiPqAVtPEf/VdV2s/UC3JsIw
DDJhkYyL4zjO83w2m63X6zAMt5YTRZHrukEQQI8BAAAAxmI0Jca2bcdxoigKgoBr
D3Vdi7FVeLplWWmaki0w5dF1XdQ5xGM6vfUUUQDHcTzPIz2mNYPIkIgvjLE0TclA
2LIsMX8QBLQ2lGXZ1imfzWZjGIbv+6ZprtfrrZXmed6jyQEAAADgL+y0+LR1zTWO
Yz4A67ruOA7ZpvDpCm6QS7a3jDHbtskAlk50XZdcnHzfb5qGjsmkVz1FFY8yWJbF
bVbIrla8WDK7EY1wRQmlJSQSIwxDOiCkZSPV2IWTJImu67QQxqsgA2dVMC7JaZYS
AWwIwDWB/gymA7s4w96LY9f2tW2bDqqqCsOwqioy3Y3jWPSEOhyugYFjc039GQD0
ZzAdTqbE3NK9kzabjRj3ZQiu61Is3eVyyed7LMvSdX3E1R/P88hte6wCAQAAgGvl
Y+cW4DzsqsEwxkzTpI0CRC8q2ihgiG3vEPI85ytiAAAAAOjnliox+2EYhmEYlmWp
QWtG4XC3cAAAAOD2ACUGXCGvvvrqvXv3hmzYCQAA4HKBEgOukLfeeuvdd9999tln
f/Ob33zhC1/48pe/DIUGAACuDygx4Gp59OgRY+zBgwcPHjyAQgMAANfHPkoMOekA
MFnUYM2iQnPnzp2mae7evXvv3r0zCAcAAGAk9lFiEE8WTJw333zzV7/6lZr++OOP
P/bYY0899dT9+/dfeeWVd9555+233z61cAAAAEYCSgy4Qp588kl+/MQTT9y5c+eZ
Z56xLOvFF1+k0D7008D9SgEAAEwT2MSAK+TOnTtPP/10q+ICAADgaoASA66Q733v
e4ZhQHEBAIDrBkoMuELgfAQAALeBW7p3EgAAAAAuHSgxAAAAALhIoMQAAAAA4CKB
EgMAAACAiwRKDAAAAAAuEigxAAAAALhIoMSAq0XdQQkAAMA1ASVmZ/I8X6/Xs9lM
0zRN05bL5Wq1StP0NLUHQTCbzYbnT9N0uVweUmNZlpqmDbzAgdVtNhtqPc/zKPa/
msIYC4Igz3NqcPo1CAKqZT6fz+dzz/O4pqJWXZYl5QcAAHCdNLvguu6up1wZYRgy
xlzXLYqCUpIkMQwjSZJDiq2qqqqqgZmH34KqqrIsO/CWOY5jWZZlWeNWp3Y/KcV1
3SzLWn/NssyyLLHFuqrOssx13S4Z0J/BNYH+DKYDDZQnqAgzMTtAUwKO4/i+bxgG
JVqW5TjOgSWv1+tjxMjXdf3A2LVlWaZpmiQJHRy7Ok6apnVdt5aW57nneXEciy3W
VbVpmnVdl2U5ilQAAAAmBZSYHaC1CVVloW2967qmpRDP82jFJ8/z5XJJS0581SOK
ovl8LiZ6nkeLKbQa0npWXdeUuF6vW2Ury5IyzOfzzWazx9XxeheLxWKx0DSNLpk+
71zXjaKIUkg20gwo/x7V9RNFkW3banpd11EUSRpMP5ZlkeQAAACujZ3mbW75dGV/
i1VVxRhLkqS6wXEc+sm2bb4co+s6z8wXRHixXWe5rktTc0mSqDLQWbTC5bouVSGK
PeTqLMuiEnzfpxKKojAMg2cwDIMy0OQTJYZhGMfxHtX1d0jDMKT1NfrVsqyelbvW
qouiME2zNf8t78/gykB/BtOBnWo5CUrMDmxV+8Rffd9vHZ7DMGyapigKMTM/7jpL
HNRVGRzH4b+SdUiXVP3CUyGkYDVNkySJqDHwf+M45pnVbrqTEtOVohbCbtaMdF2X
LnBr1V3pt7w/gysD/RlMh5MpMVhO2gGyuuC+M/3UdS3dQkq3LMvzvC4rja6zyrLs
WUCJooj/urdhCglGFiRUAtnzihnoX9u2DcMIguDEtiZ1XZMZtbjQBgAA4NYCJWYH
6ENnuIGFpO7QkL9YLMjfZ6ezxAMVXddFqeq63mOMj+M4z/PZbLZer8kJqwcykYmi
6HCj5la6NDZd15Mk0XUdegwAAAAoMTtg27bjOFEUBUEgmtxSOBP+Lx1YlpWmKdkC
Ux4amMWhVzymErrOsm2bJzIljJvjOJ7nkR4jntWKKK2UTtYtWZZtnctxHEfX9TzP
uZfWrtX1Y1lW11m6rpO+tVgshiiUeZ73qIwAAAAumJ0Wn7Dm2jRNHMd8UNR13XEc
MtHgsxeiNS5XQXhcGTrXdV2aw/B9v2kaOiZr2dazsiwjdYFugWgEI9UlBlCpqors
V/i9Jlsc0VyXI60cSea6Kq7rkn0PZ3h1ZJ7MhIg7UkoYhtQyVAhdNWOMjHJ4a/DW
VqvmhGHYtTSL/gyuCfRnMB0YDHtBF8PD4nWh9q2qqsIwrKqKrHfJh7m/EFWRGl7d
EGzb3uMsFSksngj6M7gm0J/BdDiZEoPlpMvjwLB4m81GDcGyXC75RI5lWbqu9y/B
lGVZ1/UQSVqrG4Lrup7n7XGiiOd55DF+YDkAAAAmyMfOLQA4Na0qhegzZZqmZVld
tr1BEHieZxjGVuPfnuqGQN7UaZrubdGS5zlfZQMAAHB9QIkBjDHm+74aoqYVMjGm
QHzHlsowjK2Gwz2MtQcCAACAaTK+ElPXdZqmP/jBD772ta9hFLk+KOzeuaUAAAAA
RlJiuOKSpukvf/nLP/7xj7///e+/8pWvjFI4AAAAAIDK/kpMq+IyomQAAAAAAD3s
o8R8/vOf/8lPfvLb3/5W07Q//elPXdm+853vpGl6gGwAHJcHDx6cWwQALoCyLLEV
/K1C2nNmyuyjxHzrW9/65je/mWXZ+++/r2nar3/969Zs9+/ff+655w4TD4Aj8t57
7z18+PDcUgAwdSikwt6ehuCyyPP8ELfQE7OPEmOa5ptvvknHeZ5///vf/+EPf/jj
H/9Y0zQxHP5zzz13Ka0AbieYKQRgIFtjR4Fr4oLejYca9pqmaZrm66+/zj6q0Pzh
D38YQToAAAAAgA7GdLGWFJpDInwAAAAAAPRzrGB3iBADAAAAgKOCvZMAAABcFZvN
RtM0TdM8z8vz/MS1B0Ewm81OXOmtBUoMAACAq4I7Uvm+f/plAdd1RR8XcFSgxAAA
AADgIoESAwAA4BaR5/lyudQ0bblc8ikTnrhYLBaLhaZprTnTNF2v12maUnoQBLzY
uq4pcb1e80TP81ar1Wmv73YBJQYAAMBtoa7rKIqSJGmaRtd1rmF4nheGYdM0tm2X
Zdk0TWtOy7KiKCrLMo7jLMtEJSYIAtM0qYTzXNut5FjeSQAAAMDUiG6Q0tM01XWd
MeY4jud5PTkpD2PMNE3R9mWz2WRZxhgTowL6vn+EiwB/5cwzMae3G6dKYXU1EVpv
xAUFiwQAXBZ1Xbuu2whQumVZnufVdV2WJdkCd+XsoixLUoPAKRlNieEubcRsNluv
12VZ9uRfrVaLxWIsAURowbL1p8Vikec5dTVJZs5RB9GB3ndpmq5Wq9lspjbm1qbe
bDa0pjufz/vVxCEtEARBfyFlWQ5sNFWwsizF+VhC1/X5fL61NAAA2Al6TUkvNHp5
xnGc5zm9TsMwpJ9ac/awNQMYn2YXXNftOUUskObQaIGwh10FGEJVVTSnN6RGtRFc
16VF0K7Cq6o6UMKtVx2Goa7rWZbxFN/3dV0vioKX0NXURVG4rktyOo4z5Bb0tIDr
uqIYrTiOQ1ue9mfrEizLMulzpzlOx1Dp788AXBbH689JkqgP6cRR32xZljmOkyQJ
Y8z3/aZpqqryfZ9e6a7r8hcs0ZVTLFY8tm3bcRzKzBjjxV5c041yuxljp7nwYykx
6r9dp+wkwHD2VmL61RTbto8nG0FPjnT76amgJ6TpbeowDLn8dNZWYbpaIEkSXmMX
RVEYhtE0jWEYPcpfv2CO40ivDygxAOwKlBgOn0qRINNd13VpMt62bf7mEQ1ZLMuK
47g1J9dsiqLgx/Rmy7KMNtuhG+E4TlVVtm1v/cCbGlBi/vqvruv83yzLqJdYlsUH
MzF/GIbUAygDTTBYlkVdp3VepygKKtMwDOpzYu1dQvbITP2yuenQuq7TQE4jNF0+
SdV6UZQ5SRJKJBWeqKqKEskirKsNmxvLdnX+gy6zVWypqUW60re2AEki6iX8YmmT
LDrLcRx6L4RhSBpea9P1CxbHsbr23C/2KECJAdcElJi9qaqKvrKSJEmSJI7jrW/O
rQWOJdvpue1KDHUCx3F0XafhrWkaWkGgY1EzFUujTiNOxFmWxc8Kw1BSU6hMUnFI
X5aE6RJSlZkjjrhxHDPGiqIghVo9vfWiSNmnJS1RJD6pSMp7Vxs2bVMjanpPU4vE
cbx1KqWnBQzDEB9FrlDS2lYjTMPw/JShtel6BCuKQtJQocQAsCtQYvbGNM04jvnL
KkmSUSbdL5TbrsSQPiGNSaqbGT+F56FhuCgKnkhjIV9ZlKoTB0hSGiRhVAlpLkGV
WZRBnDZwXVea4xEzt16UNEHCj0WFYCwlprWpRcTJ0oHViS2gKnx0CXwxiLQonkH8
V226fsGkuizLalXLxgVKDLgmoMTsDb2v6GVomiZZ751bqLNxWUrM+C7Wvu+TmTe5
2hNDfNXIw0207rZt2zCMIAhaTb6jKOL+bDSW9wtW17XnebSa0wUtf4j/lmXZZXC+
kwPecO87Wk5qdQgSZWMdTc2Jokh8MgcitYCI6oJI9rxiBv5vT9MNEcz3/Z6WBwCA
ESEbF3qNZ1lGk83nFgoM4ihxYizL8n0/CAIxTNBWX7XFYkF+LmKi67oUbkhVPnRd
F8uv67o/+ouu63EciwGhWzEMg3sL03DbpUWxHR3wBg7JdKWbzUb9SQ0E2drU7EbD
22/nM94C0mPc6oLYRVfTDRRsuVzuoYGBSYFoTACAY3OsYHeu69q2zbdBtywrTVOK
CFLXdRAEqp4rvvL4MRl85HmujmcUV5EG764yJXRd3/piTdOUFIjNZmMYBm2CKqo+
XHEZclEc27Z5Tv63NQQLraREUST+tNlsaJJTLVlqasYYtQnXeKjereFe1BawLEs8
JQgCWh7KsqxfC+lqulbBGGN5nkvKa13XU/gSyvN8vV5TtB7aP2W1Wp0xFt+JIwCx
wUGAWgVrDQIEAABjstPiU8+aK9mvMMa4t31VVYZhcJtTyVeNpuwYY9yKgoYx13Vp
KoK79riu22UewcsUPZ6qquLCqNKyj9p/UB51mSZJEl3XabWIZyMrWia4OksXtZP3
3f/8z/8wweFIgizLqF7LssQ12v6mpnpFKFtrXT0tQL+KDlatLoitkrc2XatgXIwJ
eieR8GL0iCRJtnqS93NInKHTRwBqhgUB6hGsNQgQOBKwiQGjcFk2MWMa9h6JLg+X
/Ti9/Cri5Zzy1bBHXdxEf3QXRBFRByXOrsRQvETVt4sU3L1rPMTl4cQRgJrBQYD6
BVODAIEjASUGjMJlKTFT38W6LMtxVxaGrCgdG345m83mZPud7leX67pkNbxcLvmk
l2VZuq5LC0B743meZEZ39hvEbpa6VEssumoyEieTatpEIs/z5XJJS04kfxRF8/lc
TPE8j1Z5aE8M9RSJsiwpw3w+32w2tLRKP+m6vutDUZYl33AjiiKxM3BJFosFrQrx
RqBxkUzTGGOUbTabpWm6Xq/n83mapv2C0a6/O4kKAABD2UnlOeVMDC02HTh7r0Jx
1W6z+9yu0NLYkVwQsyxTy3FdV1zGOh49/bn/6aD5hiRJqhvUiEFq3KNGmGHqipwk
VtETBunYEYCafYMAqYKpQYDAkcBMDBiFy5qJma4SUxQFN60A4BjsrcQ0AyIGqXGP
xLO6Iidx+sMgHTsCULNvEKBWwU720rjlQIkBo3BZSsx0l5PoY1F91wOwlVdffXW4
N1Yr5H41sITWiEFq3KOtp4j0hEE6QQQgtlcQoP0EA4AzhaVkcFlMV4kBYG/eeust
z/O+9KUvffzjH3/hhRf2UGjoo3a4MYcaMag17lH/KeK/XWGQzh4BiHUEATpEMHAd
DHHsZ72+/Ye75UsyUK8WOyq3ANM0bb1eq5HD6rperVaHyHAyVqvVpYh6PKDEgKvl
0aNHv/vd7x48eLCHQmPbtuM4URQFQcC/DikaED+dp7dGDGqNe8RudJetQYZawyB1
BdoZeFGHRwBiHUGAugRjbUGAwLXCO4A4xShFt/I8z7Ksrm5mmibNC44lA9mkiyP9
er3mJne2basPThRFm81msuHCxbCuhmFg4vNje5xzSA8D4ASok9KPHj1ijD148ODB
gwd37txpmubu3bv37t3rKSQMQ/KsoQ6v6zppNqZp0pg9m80sy6JNy2lmwvM827bJ
PNayrPl8TnGPZrOZ7/t0TDM0FBpHOkWsnRZSPc9br9cUlYccghhjXHWg4aEsS8/z
yPCWn85ncebzufg65pvDp2nKB5I8z+fzOR3TrqtdjmwkAzlt2ba9Xq81TfuXf/mX
r3/966pgvHBMz9xmxM6Qpmld1/39gZ6vsixHGZ7Jv1LUVPI8Fz8/VA2bqg6CYMis
5OlZr9c8VBjMLRhjmroY34PneUEQqFHLAJgUL7300s9//nM1/fHH/ftgQAAAIABJ
REFUH3/ssceeeuqp+/fvv/LKK++88843vvGNnR6ByUKe6sPzr1YrehXWdU3u9/Si
r+t6vV6The8oLJdLiio0VoGgC3o/H6M/p2mapumQDkb++VwGsp3iisJqteJrrMvl
Mk1T2g1ms9mkaUqfDYyxzWaT5/neI7Qkg6Zpuq7zLr1cLvM8d123NQD6ZrMhFYee
gq5+S+EV0jSlDwxd12makyKzU1vxb4z1ep2mKc1f2rZNE6u2bW82G1qZpdmpMAwN
w9A0zTRNCtrOQ7HzWugWMyGwe5qmFNSKVsGoSR3Hodbrkqqf4be7B03TyM/0kEIG
sZMZMHb9BReBOMXyxBNPPP3003fv3n355ZfjOJYiDV5Hf47jeEj4XREeS9c0TbFZ
KFT0WIINjAsMRmEK3knS+CLFyJB8+7vc9Q90y6eqyZ+OghiJMd+rqqKpIMMw1Fjw
PEBAj29sV3wExhgFfsyyjEdYUAMlSAEamqah6U8qJAxDeh55adQaPAMTwjTQhAKX
nJbJKGY6XzJTpdrKZXknQYkBV8jf/d3fdSkuIre8Px81AlDTEQQIHI/pKDH8X9Gx
v2lztu9y1z/kQkgGUhq6lKEwDNUta4qiELe76Rryu+IjMCWYQlegBOnqSJmjnLyd
xTykl7Sey/8VpaVJnS6ptgIlBoAzM3D4RH8GF8HAfRsmqMQ0HxVeFY8MudTglpSz
a+2j/yd+QBMVPRMqNCXDp1LUCN2t2/bRUlTrtUvHXbdDTTcMg7Zpa1VixH8PSb9K
JQbeSeAKMU0TRhjgavinf/qnvYMFnB3u2M8U337W4a7P6Yrc3f8Tx7Is3/eDIOB2
7mTtwYWhKRBKIa8fsSgy7229qP74CJyuQAkq5EUVRZGqSNGJW63jJY/I2+O1BCUG
AAAmzYcffrh3sICzwx37meLb3+quz0Z1y3ddl5vHMsZ0XV+tVlyxoFGffPHI2FY6
tyxLKcgNGxAfgdMaKEGsWsyp63qe56LyQboR7dQmKjet991xHN7OUv7rBkoMAABc
DIdEPzo2omM/Dze3XC75wEzDPx2Tuz6N07Ztp2nKw+Id4pYvDuRUOJm/LJfLKIpM
06T5FZJtsVi4rhuGYZqmFE6Gi0cBrMVyODykAoXLs22bvJMYYzSlxI8pqoLneZqm
rVYrMYTmbDajjWA5tm1LWhSFMJjP5+RwRIkUpmG9Xud5TooU3XrXdfM8p/h+7Maz
vVWqKwuLvI+L9U6nADBZqD8jFBuYOD/60Y8+/PDDrl81TWua5qmnnvrc5z738OHD
Y7yfR/G5Jbhvfw8ncMsn3+9JrTtTFD4uD93Ws0hyWS7W+wS7A+CaQNwjMHE+85nP
vPvuu2LKE088cefOnWeeecayrBdffNGyLAoi8vDhwzPJOBQKi9IzttGvx9Ytphbr
tizLuq6no1FdEFBiAADgAmhVXM4t1M7Q5AeFiVN/pTB0l3hde0NhuyloDU+kFZ+u
VgIiUGIAAGDSvPDCC4yxy1VcJHpmQW7hDhUUTpeC5vFEsmtZLpe0scn5pLsAoMQA
AMCkeeONN84tAjgWFMVYSoTh6XDgnQQAAACAiwRKDAAAAAAuEigxAAAAALhIoMQA
AAAA4CKBEgMAAACAiwRKDAAAAAAuEigxAAAAALhIoMQAAMAFcIn79uV5vpPY6pbR
APQDJQaAW02e5+v1ejab8T2Hxb18j00QBBScdAibzWaxWNC+vntv2lyWJd8teazq
NpsNtZ7neZRTTWGM0V7T1OD0K+1CnKbpfD6fz+ee59GQ31p1WZaU/1JYLBZ5nlOI
4eVySZc8n89pG2fatlpqIl3X5/P5WALUdb1araREfmsk+AbaXNT1er1er8cSZnRW
q5V6dbeRZhdod++dTgFgsqA/03YtrusWRUEpSZIYhpEkySHFVlVVVdXAzANvQVEU
rutSyY7jmKa5n2yO41iWZVnWuNWpr1MpxXXdLMtaf82yzLIs3mI9VWdZ5rpulwzH
689JkvTU24UkDG1Mres6v1Lf98Mw7D/rEGibSd63xSqkWlzXpT5vmia/TUmS7N3N
joT4ZLmuu8dNGcJ+t1uCXiyjyLOlop1y46UProlb3p+zLGOMOY4jpfu+f6ASY9v2
8MwDb0EYhvz1TWHa9xCsKArDMJqm2aqo7VpdvxKTJInUzvxXSYPZWrXjOOqoTExc
iWmaJssyXdepqCzL1L7XetbeOI5jGIZai3qzuHLAGBM7xmmG4eHs9GTtzWUpMVhO
AuCWQmsTjuNI6bQRXV3XNM/veR6t+PCZ9uVyyQ0doiiaz+dioud5NGO/XC67zqrr
mhK7puvLsqQM8/l8s9mQnHzvQ/qg7786Xu9isaClGbpkGuld16VFjSAISLayLBlj
lH+P6vqJosi2bTW9rusoimiKgif2V21ZFkl+iZim6bpuEARRFHmeJ+7bPDqbzYaq
i6Ko3y6nLEu+7GVZ1mq14st2NJcjIXXpNE3X63WappQoLvmp3Vh6rFq7Hy04pmlK
/bb1ySrL0vM86qtMeKBms5nneYyxHqmujZ1Unlv+5QqujFven/vfADQHkCRJdQP/
oqUdd+lY13Wemc8f8GK7zuIz4bRDr1o1n29wXZeqEInjuPUjXsSyLCrB930qgU/D
EIZhUAbLsnhpYRjGcbxHdf0vWNrkT81PexT3FKtWXRRF1xrH9GdiCNKSu+aTxroE
3m587kesQkSclquqinbSNgxDXepqOro0Y4zmz2iqScwpdWPpsWrauh/loQLpdvMM
4pMlPjuO4/i+3zRNkiS6rtNxq1RDuKyZGCgx4PZyy/vz1s8Y8Vf1k5TS6UVfFIWY
mR93nSUO6qoMjuOI6ymiKQlh23bXECjKQIXwFZkkSUSNgf8bxzHP3PraHVgd615O
Uq+RMabrummauq6rF9hfddddm5QSQ8tkrT/RVFPXr5ZltWoPO1EUBQ3kTZseLN2s
MAwlVTIMQz4xI2mfrV26tfN3dWPpHrV2PzEP6SWt5/J/xQsMw5CU9VaphgAl5uj0
PPPHq3G4oSI4Pa13Z6thx0T687mgL86ep0lsnC4rQrJClSZU+HHXWf2v1/6bEobh
kDcAfeDS4LHVPNMwDLJuVqUdWN0eSgwNXaTHtHbgrqqnr8RUVWVZljqn1dwY89JC
EtczRMh4mU9gsDa60nkh6iKpqBipN0vVFPmUjKRstXbp1v7cdS/UdLX7dSkrO6Xf
EiXmnDYxkqvbbDZbr9e0NNhzymq14guBI0Jrh60/iY6C/e55R2K4G+pODqsqA71P
R3c9ZcfxPh3XXfP6oJFguIGFdK/pUV0sFuTvs9NZ4oGKruuiVHVdiyY4NIGxVdo4
jvM8p7fKVtsLspyIokga/IZX10+XSY2u6/SdLRoMjVv1WdB1PY5j1eApTdOyLB3H
cRzHtm166qU8y+XSdV3DMFiHltM0TVc6lUAdRkw3DKPfKMQwjPQG8RJYW+iari6t
NkJXN5bo6n78xK3dQNd1sXBqvdvCTirP6Jq+KANN0w1xaRtXhuZmrq+rWNb9gUVw
97ye8g+cyBl+yYc0zhDv09FdT5tjep/2t8Ytn4lpbj5Yfd8X571936fbwQQzF5pr
ocGD8nBvDvqKZR+1iaESus6ybZuW+SVjGoLm/+nTuaoqflvpC55no2K5tBKi3/gQ
DMOQev5O1fX3c9u2pbOkTs4+aoTRWjXP3PWETmcmhpCEkSSvqoq0tP6z9sB1XWkS
iLRY/pZWbxa5j5HtCG95ui+SQ1Brl2Ztcx5d3Vjt8I3S/fhjRS86LhL76NSpWBfP
47out4lRcw7hsmZiJqTEqP/2nDWiDFuL3ToGb9VRDveLO4ESM9D7dFzX0+bI3qdQ
YrYSxzGfR9F1nV7lzc17nwnT6fRSptc6b2c613Vdrg81N7oR3dbWs7Iso49FugWi
9YBUF+8ANHiIkJpCw796XeLkUNfShlSjqDfsVB3PzDUnKSUMQ66IkCJOv9KDxluD
3Zj6qlXzusIw7BobpqzE0ISTZVliFBa6asnu58BLoIqYoLKQAsEYM02T7gW1qjRd
QTfINE0xnT6ZpCqkLs3VGvGY27hI3Vh9rHiZ0oIXdWDJKpk/WVmW0Wc/tSfpOmL+
HqmGtCGUmMHVM8Y+qsSIBko0hjHFuoqfQhZMYga6r9wxgbVN7RRFQcUahiG+2rou
jfWOwdRFmpuXJs0PU3wCSucvLOq16kVR/iRJKJ2/7Ghdmd04wfY0S1fOVvjppmnS
LCWlc30/DEPSuoY05lajd6m51BTbtiWdiTLQY9n/1Em1x3GsuiH0nA4lZgocbm2m
viurqiJ9l6x3yYe5v5Ctna2nuiGMFeFDNTXlTFmJOfZZ40Jv9VPaQUrd77yNACVm
l+pvPkdoIBen8rqcMxvFJFuake53mOzx3txJieGI8xa0hloURVeP7Loo1uYL1+qG
2lpCv8OqhOp62uzrfXq462lzZO9TKDFXTxzH6vqOaZrkqkr/JknSr0MURTFQyWit
bgj9wXYHIi28qr9OSonpMljuYe8whheN2v2gxOxQ0U65j6TEkDIhDT9dzpnNR2di
GsW9s99hssd7s/XS1BVoSRjJPY9M0qTBnufvuqjWq2t1Q20tod9hVYIprqfNvt6n
h7uetgrMxvM+7XfXhBJzrXDLUHYTYK1rNKUH6vCdFobAZ233Y6uP5NSUGJoZ3UmP
4fYct4TW7sdjyZxLKigxu1R/M57RFIJ4zV3OmY0wULW6dza9DpM98qs/tToKqqOy
OJSSRiU9hzz/Th6nrYnDHfy62Mn1tOluzFFcT1sFpgyjeJ+K7poqw/vz4abZYJoU
RaEGQ7tQpqbEgK20dj/+gbp1h68jcVlKzMfYNLAsy/d9z/NoqwtKVD3ZJFOsxWIh
2sRxXNel0Muqxxq5vfF0ckvrcYCM43g+n7eGDOeQex4ZmkRR5LpuEAS2bbf6uW29
qK2/tjr49ZcjEsfxcrmczWamaQ4J+93amCP6f/Z7ny4Wi+VyyY31dq19uVzSa2IP
wSig+A9+8IM0TX/2s59xoyVwTdAs5rmlALeU1u7XdK/CA5UJ7Z3kuq5t2zx8iGVZ
aZqSc39d10EQqEOR6BkvHpN5TZ7n6rjuOI7neeS+31WsiOR/30qaprQvxmazMQzD
933TNKUYCcMvikNxFPil0d/WElpzspvgK1KxQRDQ3BLNxPRfGmtrTGo9rtjxAAyt
1W3Fsqyus0iJzPN8sVjwiAtdtTPG8jyX9Iy6rnfSYOq63mw2X/3qVz/1qU99+tOf
fumll7773e/+7Gc/2+mKAAAAnIid5m3Gna4kewsm+CVWVWUYBjfvVZ0zuV+Z6BAk
uXdyUbuMIVS3t6qquDDqBYopPe55NFtAE2g8G8nZ73Ha5QvX5Yba2ixqzi530F1d
T6XG7PL/bK1uq+sptdXxvE/7uyvVRXf/5Zdfvnv37tNPP/3EE0+0PilnXKIGYAhY
TgKjcFnLSVqzy8yV53lBEOx0yrlYr9fkfXN4UZq2Wysdg+EzClJOz/NEW2CaabBt
myY/6rper9dbp9OHN6ZU3UBWq5WoRO7NcrmUNgTuv3fUnz/5yU8+evToz3/+c/9d
vn///iHRkAE4Nj/96U/ffffdY7ysKJTtHo82uERGud2appGZ9lhSdTEVm5hxKcty
13WEHmhFaazS9pZhj5ykr4i/UkhvdhNJiZvy9DC8MdXqBkJmNwd2dypBlHPrOiDx
i1/8gjGW5/n3v//9H/7whz/+8Y81TVPPDYIANjFgypBSfm4pADgpE7KJGYUgCDRN
Wy6XrZtQ7EcYhkEQDBwRJ4Vt25LVi2VZnufNZjNN0xaLRZqmPba9uzamWt1AaK/5
Q/afyvPcdV2p9iAIhitGpmm+/vrr77zzTl3XSZK89tprzz///DPPPHNe5RUAAEAP
1zYTQyauFAVuxDL3m2CYIL7vDx/Xj9GYXRiGccimZa3K095TOxTL+PXXX2c3MzRv
v/02tBkAAJga4ysx3DH1a1/72um3YIXD5IigMZmwOQMAAICpMc5yUqtj6iWuvwAA
AJg+y+VS07TZbEaBsoggCGaz2Wq1OmRteldWq9VqtRqSk2TWNM3zPArMoQmQ5DyW
BBjI/jMxYiiwX/7yl3/84x9///vfjygZAAAA0Eocx7PZrK7r1WqVZRklUqDRMAxP
ufg7fB08SRJN05iy0k0OZTSkBkEQRZEU3hP0sI8S8/nPf/4nP/nJb3/7W03T/vSn
P3Vl+853vnNKdRiAXXnw4MG5RQAA7AON8aS1iL6Np/ckHcuLmMKWMsZWq9VOTgm3
nH2UmG9961vf/OY3syx7//33NU379a9/3Zrt/v37zz333GHiAXBE3nvvvYcPH55b
CgDAFsqyXK/XaZpSSHTuaeH7PgUutyxrFP+DKIqCICjLkgKBSvqQKkZZllEUpWma
ZRlJYtv2ZrOJoqiqqi6xe6A8+P7fgZ1C46kRIbMs63JGRYRTMHGwizW4Jq41Ym9V
VY7jUIBvildO6fxixZ1iD2wBKpwcGqQ9X1vFqKqK70DMd5+ublDzS8Nu6yi8x9A8
LpcVsfdQw96u6Bp/8zd/c2DJAAAAAK0W8Z1V1L1HkiQxDEParm4/aBGndWPgVjF0
XeczQHw3G13XdV3fKjYYhTGD3YkKzX//93/DMRUAAMCB0K71dNy6fT1tt8d3xiU8
z9Pa6EqnsygcqOjxNFyMA/MTpD8dEjTrtnGsiL00v3ekwgEAANwSdF0XHY/rulbj
d5immSSJqMSI+wGLdKXTWYvFwnGcVvOaIWIckp/YbDbsxjIGDOHath0AAABwTTiO
43keKQRkPMu/kEUDWNM0D/foEfUMSefoEaO1hJ78rTM9PJtpmmTeBIZwbdsOAAAA
uCZINfE8b71ek9MQY4yUg+VyaVkWNzdxHKdLPxiIZVnz+dx1XcdxZrOZ7/tcn2gV
I89zUqTyPM/znDE2m81IJDU/V7nm87llWbxkcTHLcRxoMDuhNbvs2067pO50CgCT
Bf0ZXBPH689pmqZpisglt4RRbremaa7rnqDPYDkJAAAAABcJlBgAAAAAXCRQYgAA
AABwkUCJAQAAAMBFAiUGAAAAABcJlBgAAAAAXCSIEwMAAGALeZ57nnduKcApqOv6
ggLuQ4kBAADQB2LI3jYuaPMmKDEAAAD6EPdqBmBSwCYGAAAAABcJlBgAAAAAXCRQ
YgAAAABwkUCJAQAAAMBFAiUGAAAAABfJX5SYPM+Xy2We5/yH1pT//M//FE8eeBZS
kDLNFPRnpFxTCvozUi405RC0pmmG5/Y8LwiCnU4BYLKgP4NrAv0ZTAdN01zX9X3/
2BVhOQkAAAAAFwmUGAAAAABcJFBiAAAAAHCRQIkBAAAAwEUCJQYAAAAAFwmUGAAA
AABcJFBiAAAAAHCRQIkBAAAAwEUCJQYAAAAAFwmUGAAAAABcJGdWYsbaPWHXSuu6
HpIITkOapgMTAQAAAM5oSsxms9EEZrPZer0uy7In/2q1WiwWYwkgkqbpcrls/Wmx
WOR5rut6V+JyudQ+ymKx8DxvDxVntVqtVqv9LuFAgiDQNG1IzmMISft7UTeIokhK
nM/nPJHQdX0+n0uFtCYCAAAAnNGUGNu26aBpmqZpXNeNoqhndLRtO47jsWoXqeta
1/Wu7/g8zx3H6UlMkoQO6EKKojBNMwiCPUZ6wzAMw9j1rFFwXXdgTlHIuq5HmY5a
rVZxHDdNkySJ53lU8mq10nW9qirHcdbrtTgJZ5qmqu+2JgIAAACcYy0n0SB6ltUi
XddN0xyrNMMwwjBke61u+L5/yB6edV2TBnBURCHX67U0RyWy2WwGNkJZlqR/GIZB
WlEURWVZOo6j6zrpi9JkDAAAALArx7WJEUdEvpqwXC5bP/ejKJrP5zwDLYgsl0sa
DmlZRzqlLEu+QrHZbI50FTTc8rmN1gvhiYvFYrFYaJpWlqXneSRzmqbr9ZoWuTRN
C4Kgv8ayLNfr9WKxID1G0zSaB1qtVpqmkWaTpulsNqOr7mrbzWZDTbper7kyIS7o
iEJ6nkdrgrQSp5ap6zpJpeofnueJM1Wu69JcSxRF1G4kp2VZ7KZXwOQFAADAoTS7
QANS169UYJIkSZLQN3cYhvQTLSLQsW3blmXxU/jpuq5TTsZYVVVN01iWxc8Kw5BW
KDhUZlEUJBidLgrTJeTWRKmJdF3nVXddiGVZJInv+/xCaGWKlxmGYVVVWZZJoook
SWLbtq7rrutSIzRNYxiG7/u8cbIso3TXdXtEohqbpsmyzDAMykxVZ1nGC5SE7L9M
ktCyLBKJS+i6rm3bPE9VVZZl0ZSY2KRSC/fcgp7EEenvzwBcFujPYDowxmjQOXpF
O+UeosSQPsFHL0JdVeGn8Dw04hZFwRPJaIZGSrU5HMfhgygpB5IwqoRZlonjcVei
KGEcx6ZpmqZJ5fdcCAlDeoYqRmuiCFcOuObH8X2ft6dpmqReJElCqtWQto3jmNQX
Xde5+tIjZFeZYqORntraTauqcl2XeotlWdQm/UqMZVnqhbcmjghe+uCaQH8G0+Fk
Ssz4y0m+78dxnOe5aM9R17V0PeqJlmV5nifactq2bRhGEAStBp5RFPHlqiF2MLQ0
I1n1tiaKkAFynue0XNJ1ISR8XddlWe5nkZPneZqmjuNwE2mO4zh5nlMG0zRpaSZN
U8o5pG1t26YlId/3gyBYLBb9NrNbyzRNk+5Oq2nLarWyLMv3/SRJqOnUNpGMb3zf
55Y0/YlTZjohA8AJwJIoAOdnJ5VnyEwMHdOnPP+Mdl1Xmu2gxRexNF3X1cQwDOlz
n34SEZermqapqqp1dkGkqip1KUdNVFuGp3RdSFVVNE7zORtJDLZtJqb56PSGdL3O
Dc3N6hJXMoa0bdM0fC6nKArSP3qE7CqTCMOwa9JIvcAsy9iNRVGSJM3NZJu4/NQ0
DTkuSeW0Jo5IT3+WXOfIHlnthGJ+0ilHF5LmAhljhmFI041N05imye8CmRyJmKYp
rksOx7Zt6QadBnpvDMw8upA0KUu3W+zbPF3q87RQO6IAB4KZGDAd2OUuJ/F/ybaD
XrtkeMEXMrg5hTS089FXfO0ahqGuATU3djD0TqH1C0mYLiG3JkoXQsJT+V0X0qpm
NTsqMURRFHRp4qhJ60F0sWR2w38a0rau63Kf5x552I3BTWuZVVWFYUi3Q7JPosUj
/i834qHLoRUlXddt26Y7JSq4PW1y7Dfyrkq5tEjaesqY8t10Bmp8x3FUAXq6blEU
NMXY+vj0I93QUzK8DUUhpW+Y/TAMgwoRDdeqqjIMg7oudYPWr5QpACUGTIfLU2L4
lysfzunh50MvDcz0CV4UBdmW8q/z5uY70nVdevPyUdB13a4vfl4mDZOUWFWV+Bkt
X/C2wZLHiSEojIp4M6QLEYUnaIznF5hlGdcJiqLgx/3vXHpjit95pmnSKTSV0toO
okg0qUOXwHUOmi3gN0UUkk5hjNF8j1om3Rp+v0Qk498sy2jygFQxPjDwRLVzT1yJ
Uf/tOmU04ZqmaRoyBqdjydyqtUZVyCFij4v6RbET+0nbPyUTx3Frv1WrpgdBbGrx
NUXp3OZ9b2mPBJQYMB0uT4k5HqIB7+EcY7CkKQry9CF72x7/o0NqaT2+Di5CiRFv
K19iEBVoMT/NWvEMNBZyL7bWeR2atZL0ThG1X/WrLBTiiL9KVJl5Clmv07k0/UPi
kachWZ2Lnxat0NyPYRhcD2Y364akPfPpTO7xp4rEGIvjmJpOfPbpWviCjigkD39A
mrRaZpIkhmGIS28c0bGOCiTNnjcabxbewq1LsVMASgyYDlBi/oI663Agx7C9ME0z
jmNeArlJ7y/i7aN1jqE1cVwuKGRA0zRxHItzAGqNXGbO1ugAamiAZq/oAK2hAZq9
ogOwttAAzUmiA6ihAZo2XVb6t7VBzgKUGDAdoMT8ZRbXMIwh88DDieNYNXVsTRyO
67o8cv/eppS3Gdd11U/81sTR692qxEwkZEDTNOJaIXF4dADWERpAvJb+MbsnNECz
V3QAsQpxUvME0QHU0ADNNiXm2FEAdgJKDJgOUGKaoii6wpAA0E+PG5HIwOUk0bKb
n9jaM8XSaL1DnC1omoamFuinnnNVwjCU1BqaNpCmc6QhllQoWv5olZkmh0hnkhS1
gUoMKQ1dNl58AobPZjWCAtcqUpcuRY6KW73/hpgkJ0limqY6q2RZFn0y0YIXKYjq
cpK0qthl1H96oMSA6QAlBoD9+exnP/vkk09+8Ytf9H1fndLgXErIAHXtiec5MDpA
V2iAZrAS0/SGBmh2jw4gVSGqVseODiBWTaEBmptO0hUd4NhRAHYC72cwHaDEALA/
9+7d46sJzz77bJdCcxEhA8IwFEdcaYmtS2UhtkYH6JlFGK7EEK2hAZrdowOIVfDQ
AM1JogOooQGaG02xKzrApN6HeD+D6QAlBoD9EZUYEUmhmX7IAMnhX30vqCoLZ0h0
ADU0QPNRx/tdowOooQGaHaMDtIYGaE4SHaA1NEDTGx1gUu9DvJ/BdDiZEqM1ikdD
D57nBUGgBgYFYFL86Ec/+vDDD7t+1TStaZqnnnrqc5/73MOHD3d6BA5nvV7ThMQo
pdG17HduXdebzca2bdotoa7r9XrNN7oakbqu+fWKx1fAIe0/OvR+no484DajaRo5
Zxy7oo/tcY76dQjApPjMZz7z7rvviilPPPHEnTt3nnnmGcuyXnzxRfKk9Tzv4cOH
pxSsLMtxR3Fd1/cucLlcck8cxliapkf6PhHFuyYNBltWAXB29lFiALgIWhWXcwkT
BIHneWRSOmKxYRgGQcAXUHZC3HLVNE3yFh5RtqsnCIITfGgCAHqAEgOukBdeeIEx
dnbFRcS27SAIyAJj3GLVbc8H4vs+xuBDQOsBcHagxIAr5I033ji3CDK0ueC5pQAX
yauvvnrv3j3Lssi+GADAgRIDAACT5q233nr33XefffbZ3/xqbGAhAAAgAElEQVTm
N1/4whe+/OUvQ6EBgIASAwAAF8CjR48YYw8ePHjw4AEUGgAIKDHgtuN53rlFAKAP
1Q1KVGju3LnTNM3du3e7wiMBcMVAiQG3HcQ9AhPnzTff/NWvfqWmP/7444899thT
Tz11//79V1555Z133nn77bdPLRwAZwVKDLjtQIkBE+fJJ5/kxz2BAyhoIQC3Cigx
AAAwae7cufP0009PJOIRAJMCSgwAAEya733ve7Rv17kFAWBy/L9zCwAAAKAP0zSh
wQCGnS7agBIDAADg/ARBkOf5crnU2lgulzxnnufr9Xo2m/GfVqtVmqabzUY8ZT6f
e54nDfxRFM1ms7EE7ilqeEX95YiUZRkEwVD5bgdQYgAAAJwZz/Mo4I2u60VRNE3D
t+NumqYoCsMw6N8oihaLha7rWZZRNtd1yaiZb8HRNE1VVbTXx3q9FityHGes+QzX
dXuKGl5RfzkitMcZokKIQIkBAABwTtI0reuaQvY5jsP1FY5hGKSg0ByM4zi+7/Ns
lmU5jiOdous6bW612WyOfgEnxDTNuq5p31bAoMQAAAA4L1EU8UmUrpAHlE6LKarK
0noWTW+0mhPleb5YLDRN46szURTN53NanKIT0zRdr9dpmtIKF89Z1zWlSHM8URTR
GlYURTtVJLJcLmezGW0vzxfXpJyWZYlV3HaaXXBdd9dTAJgs6M/gmrjc/kzbo6rp
6iC1ddjiGaqqIl0nDEM1j+/7VVVlWabrOiXSAe3SyoWh06Wcruu6rts0TZIkojCU
Icsy3/f3qIgSXdel1TSSn361bduyLF5RURSmafY0whRgjFErHb2inXJf7kMCgAr6
M7gmLrc/d4m9txJDK02macZx3F8dPyZdpyiK1l/FY1HlkpQYUl9af91aUZIklmXx
c2ktrGvGYfo3+mRKDJaTAAAAXAZkN7M1NjFNZmRZxleptkIGs0NsTcqybF2i8n0/
CILFYtFfSFdF5JzF0+u6lpSAgRdy24ASAwAA4JwMj4JDs03HsAhZLBaO4wzchKRV
TXEcJ8sywzBWq9UeFcVxbBjGer3m5i+SrgZj3lagxAAAADgnlmUN3PjJtm3HcaIo
CoKAD/Z1XdM0Bs+2hxO1eEr/6eS5zbPxzGmaGoYRx3G/ttFVka7rZGRD9sKWZaVp
yisKgkDcJAs7vnGgxAAAADgnNGCLKWVZ8mgoYpg7xlgYhnEcp2lKwe7Il4dizHBv
akpsrYsqoiB4lJ+OLcui4HiO48xmsyAIKGcQBGVZ8mNa5UnTlDsc8Xh65J00m83C
MNypIvqVKtJ1fbPZrFYrwzBc1w2CgNygbNsWlRhaVgOMMW2nlTbP84IgwOIcuA7Q
n8E1cdH9ebVaxXF8bil2pq7r0+8IsVwu4zie+E4Umqa5rquaJ48OZmIAAACcGdd1
LzEQ7ek1Cc/zfN+fuAZzSrCLNQAAgDNDGw6kaQprjx7yPHddFxqMCJQYAAC4XfSE
sj0jhmGoGw4AkbObwkyw52A5CQBwdAb6noxb41j7/E0EyfR1V8i89Ktf/eqnPvWp
2Wx2+jsCroA8z2ez2b1791599dXNZjOFRwxKDABgKJvNRhOYzWbr9brfoZRcLRaL
xTGEoV1p5vO5NCQvFos8z8XvRdo4kPxZaDOa1Wp1oFpwVIIgmM1mYoqu6/P5fKdC
RMXl05/+9EsvvfTd7373Zz/72aiSglvHe++99+1vf/uVV165d+/e2RUaKDEAgKHw
+KcUQtR13SiK+kN72bZ9DK8T2h4vSZKqqizLkrbiy/Nc3CMwiqLFYqHrepZlXPKz
TEXUdT3wXe+6rpTTNM0h4c66FJf/+7//+/3vf7+n3AAofPDBBx988MHZFRrYxAAA
9oQ8Ss6iDaRpyi0cfd+XJi1EaA7GcRzR29OyLHUn5BOwXq+P7Uj893//948ePfrz
n//c72vtui5vNN/3JWML9bYiD/L08MEHH9Dfb3/72//2b/929+7draeMxk47LV3u
BmMAqKA/74H03mCM8e15m6bJsoy8S8St7JqP7n5Hxps8A+kWlmXRfjeMMXWH3qIo
qFiKiKpKJcrQfHR7PJo94nMwoqhJkjRNQ3M5dCF8t5okSRzHoT35GGO0sV9rYs+F
S2JTf6M8XadwYUjHUhtfvXaO2J+zLHvttdeef/75Z555ptUMk64dgJ2gmMISn/jE
J5588snnn3/+tdde4w8awy7WABwb9Oc94EMgjei6rtOuvE3TVFXlOA4d27ZNQzU/
iw5I26iqijHGR26aF6Fjiscq1kjFkopDsy+SSHEc89Ol6poB+x7TJE3TNEmS8I2I
6cQwDKuqyrKMV9qa2HrhrWJzSbraynVdevXTaCGJOlyJEWlVaKDEgD3gSkyr4iIC
JQaAo4P+vAf0CqNRWZoyUaNzimfRAWk8RVGIv9IKC+k06ovPcRxxokJ9Y9q2TboC
QTMcksA9VyRqRTRRJMksHrcmtl54q9j9pzRNYxgGP0sV27IsrjKqDOnPpNB88Ytf
bB14AOgny7IexUXkZEoMDHtPykQcTa/M+7TLx2TKvieXju/7cRzneS5GWaVtZaQX
mYRlWZ7nSQaqtm0bhkF7x6inRFHE5w9Ic5J+dV2Xxxep65p2peEZKH/Poyc+C47j
7LFXcOuF94vd1Va0e05XRb7vl2V5yG7Gpmm+/vrrb7/99tkjjoBLxDTNd9555/XX
X59O/4ESsw+TcjRN01TaII2jOpq2Jl6692mX6+keLqlgOJZl+b4fBEEURTxR0hXU
h2KxWDiOo0ZlJUenKIpUe1td18UqRAcfUhTE96mu63Eci85KND8hlqCWL+ox+8Vb
Uy+8R+yuU6QDleVyKWpsAAAsJ+2J2Ho0M6xaI7aeNa4YNE3dVWxrupRIG666rssn
5JMkMQzj9EvmVVWJpqD9SFexUwtw0J/3QHpv0Oa6NLdM6+VkU1JVle/76soIY4wb
8Eq32zAMcRmIQ0tXtIxSVRWfwAjDUFxbEc1spdtKipEoD4lHYruuy8uhLevUQljv
clLrhbeKzW5MjLvayrZtspWRzIZar0ttKPRnMBEYbGImjvQqH6gRHqn19lZiSAGS
jCKbpvF9//RKjG3bwzNDiTkL3D2Ya71VVRmGwUdr7vbM7VSyLCMtn3oUzcG4rssV
C164qExI8GK5I4/qJSG+MdXbGscxn/7Rdd1xHL6oTza2TPFOIvGKouDH//Vf/6Um
clMe6cJbxaaK6IlrPSXLMppooc4pGta0XpfUSujPYCJAiZk6qhJziKPpEC/TptvR
dG8l5lzep+qFHOh9CiXmCpAG7EO4jtuqtgb6M7gUoMRMHRpxR3Q07fcybXodTfdW
YrZOIB3D+7TrQrgke3ifQom5dIqi2Gkqrh9d18fSh6YDvS56MqA/g+kAJWbq8Bns
sRxN+71Mm15H09abIjmatiZuVWKO4X3adSE9p1B6j/dpl+vp4S6p4NjQ7R7XDIsi
y12ZHiPa63RlQH8GE+FkSgy8kw5iREfTfi9Tts1jU0J1NG1NPIv36dYL2cP7tMv1
9HCXVC7SNTmlTwoyDaYptxHL9H2/x1f5EvF9n6+6AgAIKDGHMqKjaY+XKet1NG3N
LDmatiaexfv0b//2b7deyK7ep12up4e4pIob6c1ms7PsEHQboAk2dfoNAAC2AiVm
BFzXtW2bb51lWVaapkEQMMbqug6CQP0iFIdtfky2NXmetw66juN4nkfDf1exIpL+
0ZpI/pxRFAVBwNOpcLoWx3E2mw2lq1M7Q1Bb46tf/WrXhfQ3oG3bPJEpbdjaGl3p
XXTtALzrVQMAADgFOy0+Yc2VOJ6jaY+XadPmsVlVlbgprpS/9Wapiaf3PlUvpDnM
+7SrW/Z3VyqH2vDll1++e/fu008//cQTT7Q+KdhrBkwcvJ/BdGCnsonRmt7t2iU8
zwuCYKdTwE6s1+sR1/I1reX+tiZeHNIUS9dF9V8s9edPfvKTjx49+vOf/9zfLPfv
3xfDBAMwNX7605++++67V/B0gytA0zQyRT92RR87dgVgOGVZ7rr80Q8tHkkFtiZe
HKL8XbZBA01xf/GLXzDG8jz//ve//8Mf/vDHP/6xpmnquUEQjGh5CsDokFJ+bikA
OCmwiZkEQRDQpkV7GJ30EIahaOzSk3jRBEHQqu93pbdCG+O98847dV0nSfLaa689
//zzzzzzzKVrewAAcMVgJmYSkMnquF6mVCzF5N2aeNF0aSp7z2Sapkk6DbuZoXn7
7behzQAAwNQYX4mp6zpN0x/84Adf+9rXprNb98QhL9NzSwFaIIXm3FIAAABoYRwl
hisuaZr+8pe//OMf//j73//+K1/5yiiFAwAAAACo7K/EtCouI0oGAAAAANDDPkrM
5z//+Z/85Ce//e1vNU3705/+1JXtO9/5TpqmB8gGwHF58ODBuUUAAACwP/soMd/6
1re++c1vZln2/vvva5r261//ujXb/fv3n3vuucPEA+CIvPfeew8fPjy3FAAAAPZk
HyXGNM0333yTjnuiazz33HOIqwGmDGYKAQDgojnUsFd1RiWF5g9/+MMI0gEAAAAA
dDCmi7Wk0Oy3dTAAAAAAwBCOFewOoTUAAAAAcFSw7QAAAAAALhIoMQAAAAC4SKDE
AAAAAOAigRIDAAAAgIsESgwAAAAALhIoMQAAAAC4SKDEAAAAAOAigRIDAAAAgIsE
SgwAAAAALhIoMQAAAAC4SKDEAAAAAOAigRIDAAAAgIsESgwAAAAALhIoMQAAAAC4
SM6sxOR5fpZK67oeknhKzlv7dBDbIU1TNUNrIgAAgFvIaErMZrPRBGaz2Xq9Lsuy
J/9qtVosFmMJIJKm6XK5bP1psVjkea7releieiGr1SqKomPIyRibzWbiAa/d8zzS
8KSU5XKptbFcLnt+ki5qPp97nteqNpVluV6v5/O5mJMaUyqEQ63dVfV+7UDouj6f
z6WcrYkAAABuI80uuK7bc4pYoO/7jDHTNPsL3FWAIVRVlWVZV8mt6VKieCFVVcVx
bJqmaZpVVfXX25+hFdM0i6JomsYwDLV2NcW2bcovphdF4ThOz09iSlVVdB9t25aE
CcOQMeb7Pk8pisKyLMuyumRzXTdJkv6q92sHXpqaeaxu09+fAbgs0J/BdGCMua57
iop2yj1ciVH/7TplJwGGM5YSQ8RxvPWWqDrBEBzHocGbj/f9SkySJF3pPT+pxaq1
JEnCGFPVDtJjus4i1a2/6iGo7cBLUzNDiQFABf0ZTIeTKTHHtYkRV234UshyuWxd
yIiiiFYxKEMQBHRMa1KapqlrT2VZUpnz+Xyz2RzvQmzbZoI1hiQqY8zzPFptoQUU
NUNPyYZhMMboBbQVy7K60nt+klJIJGlNjZbM6EpFDMMg/UalLEtahhtedRe7tgMA
AAAw/kwMTQk4jqPrehiG9FNVVfwL27Zt8cuen67rOuVkjNG6jGVZ/KwwDOM4Fquj
Munz3XVdOl0UpkvIrYmtLSMmqqJuvZbhDL9TPXdQ/YmnULsxxvjd6TpF1F3olkki
kX4zXKo9GHK/9gZfruCaQH8G04Fd7kxMmqar1SrPcz5YMsaiKIqiiIw9N5tNq4MJ
mdGIkwSO40RRRCllWUqTBJ7n+b7PP9+7ZgtE8jxX5wZaE/tRRd01w1ak3jAW8/l8
NpvleR7HMb87XViWRXoYY4wW1CTZTjBrYlmWalXdmggAAOC2Mb4S4/t+HMd5nnue
xxPrupaUMvVEy7I8zxMdmmiJIQiCVi+nKIq4fqDrumma/YLVde15njRytya2nssY
I4WpVdSt1zIRaOIqyzJ12YgaUHJ6F1tYLc1xHN4mR8L3/bIspZZsTZwC0wkZcEoQ
HYApjYBAAACciJ3mbXb1TuILFq7r8iUkgkZT9tElGDUxDENd113X5c4vYn5xQURy
DmqVs6oqadWpNVFtGXLb4XpYq6hbr2Ugau1dd6rnDg4vhENzLdJtkk5sLURaUdqj
X/Wg67q6HteauAc9/VmceWKM6brO1y678pNeeLhUasmkXxqGkWWZ9KtpmvwpUGW2
bVtaNBwR/tTQVfPaXdclOaWU/cy5pIsyDMN13da7T95wXKumnNSfpUI4SZL0VL1H
I3CyLJP87E4AlpPAdGBX4J1k27au6/Q6o7Ue8t2tqsr3fXoNsY8qAXzgF19ShmG0
vlDIDobe0eQ2LAnTJeTWROlCqqoyDEN0sW4VlTHGxxg1g+/76gjUJWG/PFvTewrp
H/tJV6ORo7UotViyf+qvOo5jfu1dx10MuV97M/2QAUVR0JhNi7OqAD1dZWB0gP1C
AzSIDtDRCOK1DylhRKDEgOlweUqM+NVFTzWN/VzPIJ2DXkBFUWRZRgMD/46nTyLX
dWlxh7+PXNft+prkZZL1BiXSu5t/UckXvG1QVG1rLMsSX45dotIxvfukDF//+tcZ
Y0O+zHjtvBnVlOZmbOPiiSW0/iQ2SH/Hotc6XzwyDIN/zdM4wYRlNYI3TpdUNCXQ
f9zF1vt1CNMPGRCGodixt/ZnVcit0QH2Cw3QIDpA0zTdoQEaKDHgdrN1rBmtop1y
n+UhcRxnlLUD4qiDYj+nuaMTRLx9XcddTEqJEZcd+fqIqECL+cMwJG2PMpDKblkW
n6JTp1Vo0CU1UfLFI9TF0K1KjFSXJJWkdEq/drUMwYd5dSajX56e9K2FkCYntQMt
5PWrHVKxRVGM4linNoJY2k5FHQ6UGDAdoMT8haIo9v5SbOWoNhY9DFk6ARKtcw+t
iftxQSEDmqYhhzJVSFXm1gvpkqpf5p1gHXTl7CmkNeUKogMcFSgxYDpAifmLFULr
u+YQ4jhWDQNbE8HZcV1XWsjrSty7/K1KDOkT0qwJdU51nGYfnYlpmqYoCp5IKzvU
zdTHW5xxpK0zpAyi9QZBs0GqzK0X0iVVv8w70aN/bM25tRCaIjJNU52jai2NRwfg
upp0pcdWYizLOp5VdStQYsB0gBLTFEVBfkmnqQ5cEz1uRCIDl5Pos17siq7rtvZM
sTSyEKJzeSK5zNBPPeeqhGEoqTVVVUkm2E3bMExjObfHUqXaKvNwjqrE9NRL3luq
2ifpl1IhrQtAI77fsixrdas8HlBiwHSAEgPA/nz2s5998sknv/jFL/Y7hV1KyAB1
7YnnOTw6wFaZh3MuJeaCogMclYHvZ0w5E2iHowIlBoD9uXfvHrvh2Wef7VJoLiJk
QBiGonIjLaX1j/dDogOw3tAADaIDjBod4Kj092fE9WltB3AkGJQYAPZGVGJEJIVm
+iEDVIf/nnhI+0UH6AkN4Ps+2ccgOkDPcRenf1X2v58R16erHcAx2PrAjoXWdPsU
qHieFwTBrjsNAXBifvSjH3344Yddv2qa1jTNU0899bnPfe7hw4c7PQKHs16vfd/f
b0ctFbqWUYrqgfYpO3YtE6Sua36nuo67OM2tEaH3c1el6/XadV3DMNbrNekQmqYx
xsT8YkqapvxVL6UzYYN69RSpWLWWNE2Xy6XjOFy5JMqyXK/XpPuqZ9HGDuJWd13S
9qO2AzgGmqaRE8axK/rYHucM2WoRgDPymc985t133xVTnnjiiTt37jzzzDOWZb34
4ouWZem67nnew4cPTylYWZZDxr/h6Lo+boEqm81G3WnrliA2bNdxKxPcT4q2omOM
Ddy3tWfhZvgprZvg0u6taqciX9TWkmmvtP6VrC6pJHZtBzBxxt8AEoCJ8MQTTzz9
9NN37959+eWX//3f//3999//3//93zfeeENcdDgZQRBomkYfoCMWG4ZhEARHHTJt
2966uyqQCIJganNXfJiX1tQ0gXFrpO11GWNSU2w2G/ZRtSNNUy7DcrlUZRMTD6Sr
HcCFss9MDAAT54UXXmCM8RmXc4vDGGO2bQdBQJHxxi321k6TTJmpaTA9qMtJozCf
z8uypLg+W7soGYHNZjPGmLRpDB3Q5A0AKlBiwBXyxhtvnFsEGcMwePg1AHbi1Vdf
vXfvnmVZFzQlRibhrZimmed5nufi5fCPjdavDsdxyrIcXUhwBWA5CQAAJs1bb73l
ed6XvvSlj3/84y+88EIQBHmen1uo/SFjFFppGo5hGGRTDIAIlBgAALgAHj169Lvf
/e7BgwcXodD02GmR6zv5KJF9zBDSNN2aebPZ8NboOgZXBpaTwG1n1y9CAE6MqhA8
evSIMfbgwYMHDx7cuXOnaZq7d+92hUdqhc9qeJ5HQefUFMZYWZbcHmW5XIreQ60/
cT1jNpv1eNhS+VEUrdfr1WrFbuL6kMUYL5YMa/hZvLQuqdbrNQ+413UMrox94sSc
OPgBAEeC+jNCBoCJ89JLL/385z9X0x9//PHHHnvsqaeeun///iuvvPLOO+984xvf
uM3v50Pi+oBxmXScGACuCQRvBBPnySef5MetEY/oJ6yY7B3XB1wuUGIAAGDS3Llz
5+mnn25VXAC45UCJAQCASfO9732P9u06tyDgttMagvm8wDsJAAAmjWmakxo2wK0l
z/PZbHbv3r1XX311s9lMYXsNzMQAAAAAYCjvvffet7/97f/4j/9gjOm6/uUvf/kf
/uEfzrXKCSUGAAAAALvxwQcf0N9WheZkYkCJAQCA62HEvRIBkOjaO0VUaP71X//1
2WefPZlIUGIAAOB6QNwjcDwozrKU+IlPfOIPf/jDc88994//+I///M//TFtijb4p
ehdQYgAAAACwA62Ky1mAEgMAAACA7ei6/vzzz59dcRGBEgMAAACA7Zim+c4775xb
io+AODEAAAAAuEigxAAAAADgIoESAwAAAICLBEoMAAAAAC4SKDEAAAAAuEigxAAA
AADgIoESAwAAAICLBEoMAAAAAIZS1/W5RfgrUGIAAACAqRAEQZ7n55aij7IsgyA4
txR/AUoMAAAAMAk8z7MsayIR/bswTdOyLM/zzi0IY1BiAAAAgCmQpmld1xPXYAjT
NOu6Lsvy3IJAiQEAAAAmQBRFtm3TcV3Xnuflee553mw2Y4zleb5cLjVNWy6XZJUS
RZGmafP5PIoiyrBer9M0XSwWYjYqjc6dzWY0g5KmKWWmdHF5SCq2tWrGmGVZPMMZ
gRIDAAAAnJ88z8VpmCAI6rp2XbcoirquoyhKkqRpGl3XV6sVY8zzvKZp4jgmxcIw
jCiKyrJMkoRO4Ss+tEpFmaMoCoKAVJCyLOM4zrJMVGKkYlurZoyZppmm6ckap5Nm
F1zX3fUUACYL+jO4JtCfLx3p9on/+r6vjt26rvu+3zRNVVXqKUmS6LpOx/ygaZow
DA3DkDKLx1KxrVW3CiwJ77ruDhe/L5iJAeBWc3o/iDzPJ+WiOUFa22cSX73gTNCU
jKQl+L4fBMFisWi1TbEsS1xO4umO4/TbskjFtlY9HaDEAPD/2ztjF7mNt4+PXn4Q
CCmiLVzFIdGlCFx1p8WQKgS0f4K2MYG4kZrU0Xa5ctW6MRIY4nZVhqTwqrhrwhXa
2i6sJevOhaWAwRDHeN/i4YaxZqTd1Wl3tdrvp9LNjUaPRs9qHs08zzNdIIoiTaDX
67muW/2qiqJoOBz2+/1tCEOr8icnJwUjqd/vz2YzXdeVMg+Hw22vsrc/fpWVhLDq
un5ycrIXecBuoN9FGQW9nc/njuMkSWIYBl/iERF9hHVdF+0YwzAqLiQ3K1+68j52
y0bzNpiuBF2iY/os/qJpBtg0zXXOalaMNE09z8uyLMsyx3EKMjBpwpyXZFk2mUxM
0zRNk0+PK6HGa8jmeV6SJDVO3D1Jksiz8dUPq2P6fITYti3qJ2OM6/l0OmWM8VWe
8XicZRn5qSwFxWCMpWlKdRzHCYKAyj3PE4+pHVayMFRoVnnp5XKZJAn52ShhWE4C
ANSGxrO9TDnEcex5nq7rtLK+vgy6rtu27XnebDarTqXlum71N2uZYIcSv8raFMIK
doZlWXzRkKYke73eYDCgf3me5/u+pmmu69q2res6hRH1er0gCHgjruvSJKiu647j
UCH9rKgy/UkX8n1/Pp/zYzHoiTervDST3JD3xkYmDyx90CU6ps+FXzRjTPTmo88m
xphlWeI0Bj+F3P3ECjSdY1kWfdsx1dROmqbUrGEYk8lElkqUYVk5EyMW8gvJUtFT
oxJlhTJs2+afmFmW0awM2Vtl/UMvccMw6Cs2SRLHcabTKb27ec0sy+hcXdf51+d0
OqXK9C/6kJXbLLv0crmcTCayL0LFDXZMn48T27Zvc/ouFaD6F8d2NRMDIwYcLx3T
Zxrap9MpDZ+6rvNhkuaW6di2bXESmPcAjeVZljFhEtuyLH5iEAQFM4WaJROHWwMi
k8mEn164nCiz8kYqpGIfR1LIFZQYhsErUP3pdJrdoOwfbt/wuXTGWBAEWZalaWqa
Jp3lOA5VoHgQbq/wykmSFOJExDbLHg1doqL3CnRMn48T5TLi+uxMAVauzMKIAWDr
dEyfaewnY6Iw+K0TJEkWT5qm4n8nkwk3DuRXkuM4olkgv9Rs2yYTh5AX0VcaMUqp
xGNlBSWy/cSPy/pnzRBWZfxqoXJZmxWPRpbZsixumMp0TJ+PljRN+ZThRnDTvHGR
CiRJstIpbWdGDHxiAOgU4/F4MplQok9euE6QJG2GUnDCsG3bMAxaOJdPCcOQ+6aQ
5VT4r+d5PA6CUm/xRfoyeNquCqlWir0pZf2zZgjrzuJXx+PxfD6/vaNMnueIcm8t
hmHQ8uKmkL/LYDAgN5rtYZpmDae0LQEjBoCuYVkWjZRiuPLKIMl+v+84jvz29Dwv
DMMwDGX7g1wL+Z/i0Ej2jWjW6Lo+mUxc160WPooixhhPvl4m1UqxZTaNX2WqWFMR
7ia8s/jVwWAg2oUbked5FEUPHjy4e/dur9drf5w52BRuB1M80bGw0bwNpitBl+iY
Phd+0RREQEs8ZUGSS1VwJpOcS+jTUL4iLV3RAge5ylJ5EATiqgf3EVmu8onJssww
DDHEWikVY4wvXSkrjMdj5drWRvGrSynWVLycGMKqjAlzQLgAAArTSURBVF9dliwn
rRm/uixZfVuWI+szRa3/9NNPX3zxxWefffbJJ5/wN/8OFh3AMcPgEwPAtumSPpPz
Cr04+ChrGAY3MsjgYIxxPxXyLeXjGU1meJ5HMy6i5SEO0gV4szxUQf4KFN9lrPJ7
keaQxPaVUtEx+cPKFcg/hjumcIIgKIQIsZsQJ2X/LJdLmhASXaTpFPZxIBIZNEyK
TuLy8OMsy+Q2lZcmIWtEJ1UYLiIwYsBW2ZkRoy03SSE8Go1839/oFABaC/R5TVzX
HY/HjayCa9pm75zajEYj2Wd2OBxya68eO5OfMTYYDCaTidjt1Vcnfb5z587r168/
fPhQLef5+Tm5UACwDShflPwbbJz/bfsCAICDZj6f53nelB8fuY9s2yswiiLuVSPi
eZ7SuGkhJKfYUWu64r569YoxNpvNfv/996dPnz579kzTNPlc2se4QYEBENE0bTcX
gmMvAEAN5egcDAYrQ4rWJwgCnhh0e9i2rcwlSpldau+kSGLvYCPG2WzmeV7hFnzf
X9/8Mk3z4uLir7/+yvN8Op3++uuv33333eeff96eoBIAGgEzMQAANbZt+75PGdga
bFM5R7IzDMOoF93DhBBWy7K2GgCitMBqTyDRdlQXFxfsZobm8vIS1gzoBpiJYWxP
W8zMZjP5e1RZCDjKzin7Mm7ki5kHph5hSCqluD2IxZfdwH0JDzeE1TCM09PTr7/+
et+CANAMXTNioijSBHq9nuu6FXkXoigaDof9fn8bwsRxXJZ0qN/vz2azwseQWCjf
yHA4FHNybAPf91s+VM/nc3lrQF3XT05O5Mpl5SsRM2p8+eWXP/7442+//QbjEhwo
0GfQZTaKZTqIkFTxvugjUt61Tj6lcTEoC3tZy8pyVp5Cg8ImaVq4Ot8zbQRTQ+CV
e2G0BOXeIhv1M0fU55WBqQhJBS0H+gzaA9tViHXHfWIoGGEvswtyFvZbtkaeBMPh
sNq/z3XdGkGkcRzz9KMtxzTNMAzn83ltz4YC9+7de/78+du3bzVNe//+fVm1x48f
78CjE4DaXF1dMegzODI6bsQQ4qoN7SkTx7FlWYUcDEQYhrRTDFUIw3A0GtG+a4Zh
aJpmmiZNsXDm87nrunEcG4YxHo+357dILfNXT0FUXddHoxGtQ5HjoVyhrGUxqXye
5+TOGUVRGIZZlsmdFoah67qGYVCSsdlsFoahbdtkMoqXy/N8OBzGcazrOm32G8cx
RcD6vh/H8Xg8pi9IEkNslpU8L8uywjBsylfj0aNHDx8+TJLk5cuXmqa9efNGWe38
/Pzs7KyRKwKwDRaLxfX1NfQZtAF53X9bbDRvc0DLSdPpdDqdOo4jZsYs2/VevCna
kJa2A6V1Gcuy+FlBEEwmE/Fy1Cbl2aTMmwVhyoRcWah8QGKhLOrKeymDXDj5HVEH
ZjfInUYtU8pXfkoQBFmWpWlKgax0Chkuy5stf+mYV06SROwxuVnl86JLrOzPinJC
1uckScqCUTH9DloO9Bm0B4ZtB2pDP1GyJwpDXdmu9+JNkcVDmcuphFZnaIyXn4rj
OOLwX3ArUXaXvCWKsnClESOLuvJeypDtJ36s7DRujiiNJ7JX6Fi0UWg2q1C5YHWJ
zZY9L1lgmiqT76usnKjWZ3EA+PTTT/HSBy0H+gzaw86MmK5FJ3HG4/FkMqHFCF64
zq73lmWNRiMxoMm2bcMwaF1Grk+79dLxOn4weZ6PRqNC9jBlofJcJuyRK4u68l5q
oOw02iS53+8rG7csi8c+iEEQjuNUC1Nodp3nxU+cz+dy42Xl6yCmC/vjjz+++eab
Go0A0BKgz6CbbGTyHNBMDB3Tp7y40VphtoPvf8tLdF2XC4MgoK3dxO3ZeH3xW78Q
HKTsrizLCqtOykL5AdGudXxcV4q68l6UVKyClXVamqZk3smnZFnG58B0XRc7pHom
ptBs2aXlswpXWVnOb62iZ8T4Dobpd9B6oM+gPTAsJ9WmMPbbtq3rOq3ylO16XxhT
+cBfGH3lNaDljR8M2TFZlq2566yynElrOgXLwDAMMcRaKSpjjC9pyRXG47Eyjtq2
bbFcbFDZafwNyCXk1yJHFtFwFI+5T4zyrgvNlj0v5dKbfFMV5VyeQoWKwFS89EHL
gT6D9gAjpiY8upjPmtDYz+2Mwq735EMq/qQpwzqPjqERdPnxYFyAt2lZlugfI4Y6
F05ZacTIKUEty+LCVIhKx+QPW6jwyy+/MMb43IlIEAS8cZrvoSsWbpA6bblcUpyU
OAtF9alQ1F2yacRybpqkacqPqd/kZuVLk4S3MRY5pM8rM2rgpQ8OAugzaA87M2I2
21aetnrf6JTO4LpuYVPZ26Bpip5XFjZO2S6+w+GwRoIZzm6EJwaDQSFivOzq1VKR
Pt+5c+f169cfPnyolv/8/Jy2zgGgnbx48eLvv/+GPoM2EMcxTb1v+0JHkSfm9szn
8zzPG9wyTdd1uUFlYbNQghblvygxYPs3yiEhxV4qS6C+ZmL1V69esZuN8Z4+ffrs
2TNN0+Rzfd9vcB9EABqHjHLoM2gDmqbt5kKdjU5qCt/3NU0bDAYrQ4c2IggC3/cL
bxZlYbPYtl0WP0XJXeol8SSZd5AAdDabeZ5XuIWyFMbVqY0LiLEb0+m0LLsGAAcB
9BkcCxstPrXfJ6Zx0jQtOHkAGa5OSt/n1rKOPlN2je+///4gNpYCxwz0GbQHdrh7
J+V5Hsfxn3/++fPPPx/EXjzVUCrbfUvRdpbddZMyDOP09HSxWOxbEAAagDaR3bcU
ADRGM0YMN1ziOP7nn3/++++/f//99/79+400DsCOgT4DAMBBUN+IUb7oG5QMgF0C
fQYAgIOjjhGDrd5BN7i6umLQZ9AVSJ8BOCrqGDHY6h10g8VicX19DX0G3YD0ed9S
ALBT6hgxpmk+efKEjiuyEZydnSEPAWgzNLMCfQbdADOF4Ai5rWMv+bpfXFywjweA
d+/eNSAdALsF+gwAAAdEkyHW4gBweXn51VdfNdg4ADumYNAYhrFviQAAAHxEkxl7
8zyPoujBgwd379794YcfXrx40WDjAOwR0zSR6hQAANrGbWdiEJgKAAAAgL1Qx4iB
4QIAAACAvVPHiPn222/X2erd8zxs9Q7aDFY8AQDgoKljxGCrd9ANRqOR7/v7lgIA
AEBN6vvElAWjKg0aAAAAAIBmaSbEWjZoLi8vEc0BAAAAgO3RZJ4YwjCM09PTxWLR
eMsAAAAAAJxmjBhlvNL9+/cbaRwAAAAAQKa+EYNAawAAAADskTpGzL17954/f/72
7VtN096/f19W7fHjx9iQDLSZq6urfYsAAACgPnWMmEePHj18+DBJkpcvX2qa9ubN
G2W18/Pzs7Oz24kHwBZZLBbX19f7lgIAAEBN6hgxpmk+efKEjiuCq8/OzpAnBrQZ
zBQCAMBBc1vH3rJsMe/evWtAOgAAAACAEpoMsS4YNIZhNNg4AAAAAIBI83liCNM0
t9QyAAAAAABj7P/2LQAAAAAAQB1gxAAAAADgIIERAwAAAICDBEYMAAAAAA4SGDEA
AAAAOEhgxAAAAADgIIERAwAAAICDBEYMAAAAAA4SGDF7Joqi2Wy2TmFFOQAtAfoM
DpGNVBR62ypgxOwZ13V931+nsKIcgJYAfQaHyEYqCr1tFdpyudy3DEdNnue6rq9T
WFEOQEuAPoNDZCMVhd62ChgxAAAAADhI/h9vOfLl8lisZAAAAABJRU5ErkJggolQ
TkcNChoKAAAADUlIRFIAAALsAAABhwgCAAAAZJmQrwAAAAlwSFlzAAAMTQAADE0B
0s6tTgAAAB10RVh0U29mdHdhcmUAR05VIEdob3N0c2NyaXB0IDcuMDes4SL5AAAG
zUlEQVR4nO3WQQ0AIBDAMMC/58MDH7KkVbDn9swsAICa8zsAAOCFiQEAkkwMAJBk
YgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJ
xAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECS
iQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAk
EwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJ
JgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCS
TAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAk
mRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBI
MjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQ
ZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAg
ycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBA
kokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCA
JBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAA
SSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEA
kkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMA
JJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYA
SDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwA
kGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgA
IMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEA
QJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIA
gCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQA
AEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokB
AJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMD
ACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYG
AEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwM
AJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkY
ACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIx
AECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRi
AIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnE
AABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkmBgBIMjEAQJKJ
AQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJMDACQZGIAgCQT
AwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZGAAgycQAAEkm
BgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgyMQBAkokBAJJM
DACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBkYgCAJBMDACSZ
GAAgycQAAEkmBgBIMjEAQJKJAQCSTAwAkGRiAIAkEwMAJJkYACDJxAAASSYGAEgy
MQBAkokBAJJMDACQZGIAgCQTAwAkmRgAIMnEAABJJgYASDIxAECSiQEAkkwMAJBk
YgCAJBMDACSZGAAg6QJ8KQYLdPVlHAAAAABJRU5ErkJggg==

------------v0WB7ELziomGaMwnGQQbCY--
