Based in part on our restrictive default exit policy (we re-

ject SMTP requests) and our low proﬁle, we hav e 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—we feel that we must build a

reputation for priv acy , human rights, research, and other so-

cially laudable activities.

As for performance, proﬁling shows that T or spends almost

all its CPU time in AES, which is fast. Current latency is

attributable to two f actors. First, network latency is critical:

we are intentionally bouncing traf ﬁc around the world sev eral

times. Second, our end-to-end congestion control algorithm

focuses on protecting volunteer servers from accidental DoS

rather than on optimizing performance. T o quantify these ef-

fects, we did some informal tests using a network of 4 nodes

on the same machine (a heavily loaded 1GHz Athlon). W e

downloaded a 60 megabyte ﬁle from debian.org every 30

minutes for 54 hours (108 sample points). It arriv ed in about

300 seconds on av erage, compared to 210s for a direct down-

load. W e ran a similar test on the production T or network,

fetching the front page of cnn.com (55 kilobytes): while

a direct download consistently took about 0.3s, the perfor-

mance through T or v aried. Some downloads were as fast as

0.4s, with a median at 2.8s, and 90% ﬁnishing within 5.3s. It

seems that as the network expands, the chance of b uilding a

slow circuit (one that includes a slow or heavily loaded node

or link) is increasing. On the other hand, as our users remain

satisﬁed with this increased latency , we can address our per-

formance incrementally as we proceed with de velopment.

Although T or’ s clique topology and full-visibility directo-

ries present scaling problems, we still e xpect the network to

support a few hundred nodes and maybe 10,000 users before

we’ re forced to become more distrib uted. With luck, the e x-

perience we gain running the current topology will help us

choose among alternativ es when the time comes.

9 Open Questions in Lo w-latency Anonymity

In addition to the non-goals in Section 3, many questions

must be solved before we can be conﬁdent of T or’ s security .

Many of these open issues are questions of balance. For

example, how often should users rotate to fresh circuits? Fre-

quent rotation is inefﬁcient, expensi ve, and may lead to inter-

section attacks and predecessor attacks [54], but infrequent

rotation makes the user’ s trafﬁc linkable. Besides opening

fresh circuits, clients can also exit from the middle of the cir-

cuit, or truncate and re-extend the circuit. More analysis is

needed to determine the proper tradeoff.

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. from a geometric distribution) to foil an attacker who

uses timing to learn that he is the ﬁfth hop and thus concludes

that both Alice and the responder are running ORs?

Throughout this paper, we hav e assumed that end-to-end

trafﬁc conﬁrmation will immediately and automatically de-

feat a low-latency anonymity system. Even high-latency

anonymity systems can be vulnerable to end-to-end trafﬁc

conﬁrmation, if the trafﬁc volumes are high enough, and if

users’ habits are suf ﬁciently distinct [14, 31]. Can an ything

be done to make low-latenc y systems resist these attacks as

well as high-latency systems? T or already makes some ef-

fort to conceal the starts and ends of streams by wrapping

long-range control commands in identical-looking relay cells.

Link padding could frustrate passi ve observers who count

packets; long-range padding could work against observers

who own the ﬁrst hop in a circuit. But more research remains

to ﬁnd an efﬁcient and practical approach. V olunteers pre-

fer not to run constant-bandwidth padding; but no con vinc-

ing trafﬁc shaping approach has been speciﬁed. Recent work

on long-range padding [33] sho ws 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.

A cascade topology may better defend against traf ﬁc con-

ﬁrmation by aggregating users, and making padding and mix-

ing more affordable. Does the hydra topology (many input

nodes, few output nodes) work better against some adver-

saries? Are we going to get a hydra anyway because most

nodes will be middleman nodes?

Common wisdom suggests that Alice should run her o wn

OR for best anonymity , because trafﬁc coming from her node

could plausibly have come from elsewhere. How much mix-

ing does this approach need? Is it immediately beneﬁcial

because of real-world adversaries that can’t observe Alice’ s

router , but can run routers of their own?

T o scale to many users, and to prev ent an attacker from

observing the whole network, it may be necessary to support

far more servers than T or currently anticipates. This intro-

duces sev eral issues. First, if appro val by a central set of di-

rectory servers is no longer feasible, what mechanism should

be used to prevent adversaries from signing up many collud-

ing servers? Second, if clients can no longer have a complete

picture of the network, how can they perform discovery while

prev enting attackers from manipulating or exploiting gaps in

their knowledge? Third, if there are too many servers for ev-

ery server to constantly communicate with ev ery other , which

non-clique topology should the network use? (Restricted-

route topologies promise comparable anonymity with better

scalability [13], but whate ver topology we choose, we need

some way to keep attackers from manipulating their posi-

tion within it [21].) Fourth, if no central authority is track-