Onions in the Crosshairs - arXivOnions in the Crosshairs When The Man really is out to get you Aaron D. Jaggard U.S. Naval Research Laboratory [email protected] Paul Syverson

Onions in the CrosshairsWhen The Man really is out to get you

Aaron D. JaggardU.S. Naval Research Laboratory

[email protected]

Paul SyversonU.S. Naval Research Laboratory

[email protected]

ABSTRACTWe introduce and investigate targeting adversaries who selectivelya�ack users of Tor or other secure-communication networks. Weargue that a�acks by such adversaries are more realistic and moresigni�cant threats to those most relying on Tor’s protection thanare a�acks in prior analyses of Tor security. Previous research andTor design decisions have focused on protecting against adversarieswho are equally interested in any user of the network. Our adver-saries selectively target users—e.g., those who visit a particularwebsite or chat on a particular private channel—and essentiallydisregard Tor users other than these. We present a model of suchadversaries and investigate three example cases where particularusers might be targeted: a cabal conducting meetings using MTor, apublished Tor multicast protocol; a cabal meeting on a private IRCchannel; and users visiting a particular .onion website. In generalfor our adversaries, compromise is much faster and provides morefeedback and possibilities for adaptation than do a�acks examinedin prior work. We also discuss selection of websites for targetingof their users based on the distribution across users of site activity.We describe adversaries both a�empting to learn the size of a cabalmeeting online or of a set of su�ciently active visitors to a targetedsite and a�empting to identify guards of each targeted user. Wecompare the threat of targeting adversaries versus previously con-sidered adversaries, and we brie�y sketch possible countermeasuresfor resisting targeting adversaries.

KEYWORDSadversary models, Tor, targeted a�acks

1 INTRODUCTIONTor is a network for tra�c security of Internet communications [7]with millions of users [31]. Most Tor users are unlikely to be ofspeci�c interest to an adversary; they are primarily protected byTor against opportunistic local eavesdroppers and local censorsor against hostile destinations. Deanonymizing adversaries aregenerally modeled as a�empting to a�ack as many users as possiblerather than targeting particular users or groups.

For many Tor users this is perhaps appropriate, but Tor is explic-itly intended to protect human rights workers, law enforcement,military, journalists, and others [30] who may face large, well-�nanced, and determined adversaries. More to the point, some ofthese adversaries adversaries will hoover up whatever they can, butthey may also be more interested in speci�c individuals or groupsof Tor users, possibly based on o�ine or out-of-band reasons. An

,. .DOI:

adversary whose interest is directed primarily or more ferventlyat particular users may employ di�erent strategies. And if Tor’sdesign decisions are motivated by analyses of what hoovering ad-versaries can do, those most in need of Tor’s protections may bethe least well served.

We regard the adversaries in this paper as the next step in anongoing evolution of most appropriate and important onion routingadversaries, away from abstracting reality till it matches modelsand towards be�er matching models to reality. Our focus in thiswork is on targeting adversaries. �ese need not di�er at all frompreviously studied adversaries in terms of their capabilities or re-source endowment, though they might. �ey di�er primarily intheir goals and strategies. We will set out various types of targetingadversaries presently; however, we mention an example here togive the basic idea. A targeting (or “selective”) adversary, Sam, whohas compromised a particular user of interest, Alice, and observedher connecting to Bob, an interesting and unusual .onion website(essentially websites reachable only over Tor) may wish to targetother users of that site. Sam might be particularly interested tolearn which are the most active site users or how popular the siteis in general.Background: We sketch here a basic background on Tor to providecontext for this work. For further descriptions, see the Tor designpaper [7], or related documentation at the Tor website [33]. Torclients randomly select sequences of three out of roughly 10,000relays [32] forming the current Tor network, and create a crypto-graphic circuit through these to connect to Internet services. Sinceonly the �rst relay in the circuit sees the IP address of the client andonly the last (exit) relay sees the IP address of the destination, thistechnique separates identi�cation from routing. In response to avulnerability analysis [25], Tor began having clients each choose asmall set of entry guards from which to persistently choose the �rstrelay in any circuit. �e appropriate size and rotation criteria for theset of guards is the focus of ongoing work, including that presentedbelow. Tor currently has roughly two million users connectingin this way [31]. For simplicity of this �rst analysis of targetingadversaries, we ignore the 150,000 users currently connecting toTor via bridges, a mechanism to access Tor in environments thatcensor users connecting to the Tor network at all. Nonetheless,much of our analysis will apply there as well.

Tor also facilitates onion services, which are services at Inter-net sites on the .onion top-level domain that is reserved by IETFstandard [2]. Onionsites create circuits into the Tor network toIntroduction Points at which they are then reachable. �us, thoughnot part of the Tor network itself, onionsites are only reachable viaTor. Connections to them, including for address lookup, do not exitthe Tor network described above.

arX

iv:1

706.

1029

2v1

[cs

.CR

] 3

0 Ju

n 20

17

, , Aaron D. Jaggard and Paul Syverson

Result Highlights: MTor is a published protocol for multicastover Tor [20]. Its security goals are to “prevent an adversary from(1) discerning the sender of the message and (2) enumerating groupmembers.” We show in Sec. 3 that a targeting adversary with capabil-ities within those assumed by MTor’s authors can enumerate groupmembers and can identify the guard relay of a message sender.

In Sec. 4, we describe how a targeting adversary will, within a fewweeks of a�ack initiation, have a high probability of locating theleader of a cabal that meets several times per day on a private IRCchannel. In contrast, to achieve the same expectation of cabal-leaderlocation by an adversary with roughly the same resources usingprevious strategies would require several months [18]. We alsoshow that targeting adversaries receive feedback on intermediategoals such as cabal size and activity, allowing them to decide, adapt,or refocus subsequent a�acks at a similarly faster rate than previousadversaries. �ose results are discussed in Sec. 6, where we will alsobrie�y describe possible counters to the kinds of targeted a�ackswe introduce in this paper.

Tor has recently taken steps to make it di�cult for adversariesto predict the onionsites for which relays they own would functionas directory [9] or recognize which onionsite is being requestedwhen receiving a directory request [21]. �is was in part to counterpublished a�acks allowing an adversary to monitor interest inonionsites by monitoring the rate of directory requests [3]. Usinga�acks similar to those that we describe against MTor and IRCcabals, we show in Sec. 5 that a moderately resourced adversarycan assess not just the level of site activity but the distribution ofclient interaction with a targeted onionsite and will identify theguards of more active clients, potentially for additional targeteda�acks.

A�er noting some relevant prior work next, we present in Sec. 2a brief description of the targeting adversaries used in the workedexamples just mentioned, along with the general strategy they allfollow. A more general and abstract description of various types oftargeting adversaries, their goals, and their properties is reservedfor Apps. A and B.Related Work: We will primarily discuss related work at pointsin the text where that work is relevant. We here brie�y mentiona few highlights of prior general work on Tor (or more generally,onion routing) adversary models and security analysis.

Analysis of onion routing security has generally focused on end-to-end correlation. To be practical, onion routing networks aregenerally low-latency. �us, an adversary able to observe bothends of a connection can correlate pa�erns of communication andcorrelate connection source and destination with li�le error re-gardless of what happens between the ends. Given the fractionf of Tor relays that are compromised or observed, this providesroughly f 2 probability of any one onion-routing circuit being com-promised [29]. Various end-to-end correlating adversaries and thismetric of security against them are the basis for the bulk of Torsecurity research and design. Hintz, however, was the �rst to ob-serve that if an adversary can recognize a destination from theusual pa�ern of tra�c that results from connecting to it, then it issu�cient to observe the client end to recognize its destination in a�ngerprinting a�ack [11]. Such recognition is a central feature ofa�acks for all three of our examples.

Feamster and Dingledine were the �rst to examine an adversaryoccupying the network links between relays rather than at therelays themselves [8]. Vulnerability to link adversaries is signi�cantenough that any useful Tor security design must take them intoaccount. Nonetheless, we will show that a targeting relay adversaryis su�cient to carry out e�ective a�acks.

Prior to the last half decade, research has primarily looked atthe risk of correlation at a network snapshot. Johnson et al. consid-ered security of using the Tor network over time, examining suchquestions as the time until a user with a given type of behavior islikely to experience its �rst correlated connection, and given suchbehavior, the fraction of connections that will be so compromisedover a period of use [18]. Since they consider IRC use as one oftheir classes of behavior, we will compare the a�acks we devise onan IRC cabal to those they examined.

Not all work prior to Johnson et al. ignored observation overtime. Predecessor and intersection a�acks examine repeated con-nections or message transmissions to see who is the only one orthe most common one who could have been sending when a givendestination is receiving. Crowds was a published system designfor anonymous web browsing that was created with these a�acksin mind [28]. Wright et al. analyzed these a�acks for many tra�csecurity systems including pre-Tor onion routing [36]. Most inter-section a�acks and analyses looked for any association of a senderand receiver. As such they were not targeted. However, the �rstsuch a�acks conducted on a deployed, publicly-used system wereused to show that an adversary could repeatedly connect to andthereby �nd the IP address of a speci�c hidden onion service. �esewere a basis for introducing guard relays to Tor [25]. Nonetheless,end-to-end correlation still remains the primary concern of mostTor analyses and defenses.

2 TARGETING ADVERSARIESWe expect selective targeting Tor adversary description and analysisto be amenable to rigorous formal reasoning. We also anticipatefuture analyses of other targeting adversaries than in our examples,e.g., an adversary that a�empts for a given targeted user to build apro�le of that user’s selected destinations and activity at them overa given period. To this end, we set out in Apps. A and B an abstractmodel of both system elements and actions, as well as di�erentcategories of targeting adversaries and their goals. Here we simplysketch the basic adversary properties and strategy that should applyto all of our worked examples. In the �rst two of these examples, theadversary is interested in a cabal of users communicating throughTor with either a multicast system or IRC; in our third main example,he is interested not in a cabal per se, but in the set of users whofrequently visit a targeted onionsite.

�e general approach that all of our examples follow is to havean adversary that initially deploys all of its relay capacity at middlerelays in the network. We assume that communication within atargeted cabal or with a targeted onionsite is recognizable by itstra�c pa�erns at middle relays. �e basis of that assumption varieswith example and is stated in each section. �e initial strategy of theadversary is then to a�empt to �nd a guard for each of the targetedclients by observing which guards transmit or receive recognizabletarget tra�c. �is may be a �nal strategy if the adversary’s only

Onions in the Crosshairs , ,

goal is to learn the size of a cabal and/or monitor the distribution ofits activity. But, it may be just a stepping stone, e.g., to inform thedecision whether to a�empt to “bridge” guards—i.e., to transitionbeyond knowing that a guard is being used by one or more clientsof interest to identifying client IP addresses. �e adversary maybe selective in this decision as well; rather than targeting all cabalmembers it might, e.g., a�empt to bridge only for those that sendthe most or prompt the most responses when they send. Notethat “bridging” typically implies ge�ing across a network obstacle,rather than compromising it directly [4]. In our se�ing this couldbe done via the guard ISP, compromised ASes between a guard andclient, etc. For convenience, we will subsume under “bridging” bothbridging in that sense and compromise of a guard by physical accessto its hardware, threatening its operator, exploiting con�gurationerrors, using zero-day exploits on its so�ware, etc.

Another adversary goal is to assign con�dence to its assessmentof cabal size. �is can involve evaluation of con�dence in thecorrectness of the fraction of cabal users who have had a guardidenti�ed. �e adversary will also need to evaluate the expecteddegree of guard collision amongst cabal members.

3 EXAMPLE: MULTICAST CABALSMTor is a design for multicast group communication over Torrecently introduced by Lin et al. [20].

3.1 MTor overviewEach client that joins a given MTor multicast group creates a circuitto a Tor relay that serves as the group’s current multicast root(MR). We do not describe MTor’s selection or rotation of MR andskip many other details as well. Communication for the grouptravels up this circuit and then propagates down from any nodewith untraversed subtrees to the group members at the leaves.�is creates the overhead savings in Tor circuit construction of atree (at largest a star topology) versus pairwise connections to allgroup members. As we will see, for moderately sized cabals on thecurrent Tor network, a star topology or a tree that is almost a staris reasonable to expect.

Since the MR is a Tor relay, MTor’s design also incurs the per-formance and overhead advantages of not having tra�c exit thenetwork. Limited network exit capacity is o�en a dominating factorfor Tor performance and is one of the motivations for Facebook’s of-fering an onionsite rather than merely encouraging connections totheir registered domain via Tor [23]. And, MTor circuits are client–guard–middle–MR vs. client–guard–middle–exit-server for unicast,thus saving one hop of path overhead for each group member.

MTor also modi�es normal Tor behavior for the potential perfor-mance gain from message deduplication that is typical of multicast.Tor normally creates cryptographic circuits by tunneling a Di�e-Hellman protocol to establish a session key known only to the clientand to the next onion router in the circuit being built. MTor usesgroup keys so that if a client a�empts to build a circuit througha relay that is already part of the same multicast tree, the relaywill recognize the session group identi�er (GID) sent by the clientand join the new circuit to the existing group circuit rather thancontinue building as per the client request. To further manage treesize and improve the advantages of multicast, MTor also allows the

restriction of middle relay selection for MTor communication toa designated subset of relays and/or to relays having a minimumbandwidth.

3.2 MTor adversaryA targeted and compromised Alice belonging to a cabal that meetsonly via MTor reveals to the adversary all cabal communications,as well as long-term group keys and identi�ers. A targeted butuncompromised Alice with a compromised guard connecting to anMTor cabal could make the cabal a target by association. (Whenthe targeted group is open, the adversary can join it too.)

3.2.1 Adversary goals. Lin et al. consider adversary goals oflooking at all pairs of users and trying to link each pair as partof a multicast group (by their guards seeing the same GID) andof identifying a user as participating in a multicast group (by aguard seeing the GID—experiments consider only a single multicastgroup) [20]. While these may be useful for some purposes, ourtargeting adversary has goals of identifying all members of a mul-ticast group of interest, estimating the cabal’s size, or identifyingMTor groups to which a targeted user might belong. Indeed, atargeted user communicating over MTor is a natural subject of allthe adversary goals identi�ed in App. B.3.

3.2.2 Adversary endowment and capabilities. For simplicity, andlike Lin et al., we will consider only a relay adversary. On theother hand, it will be useful for our adversary to compromise relaysother than guards. An adversary that owns middle relays can bothestimate the cabal size and identify guards to target for compromiseor bridging so as to identify the clients behind them. Even the MRcan estimate cabal size.

�e guard of an MTor group member can see all session GIDsfor the group, and may then wish to identify, e.g., others in thatgroup. We will assume, however, that tra�c pa�erns for any cabalmember in a multicast session will be adequately linkable so thatthe GID will not be needed for this adversary to associate otherclients with the cabal. (�is assumption is also made by MTor’sauthors.) In general, we consider an adversary capable of activea�acks, including disrupting group communications or generatingits own group tra�c if a member. For simplicity, however, ourinitial analysis assumes a passive adversary. Since MTor sessionsare always identi�able by a participating adversary relay and ouranalysis will parametrize over the number of sessions, this is notas signi�cant a limitation on the adversary as is usually the casefor Tor communications.

3.3 MTor cabal analysisNote that while the GID is not that signi�cant to a targeting adver-sary who can observe tra�c pa�erns, the multicast tree structureis. To illustrate with an unrealistic example, if the middle-relay setwere restricted to a singleton, then in sessions where the adversaryhas compromised this relay he has thereby identi�ed all the guardsused by any cabal members in that session. Lin et al. do not givecriteria for middle-relay-set restriction. If gameable an adversarymight be able to improve its expected inclusion in this set dispro-portionate to its actual relay and bandwidth resources. On the other


hand, a restriction of middle-relay-set size can obscure cabal sizeestimates by a an adversarial MR.

3.3.1 Learning a guard of every cabal member. For our initialanalysis, we consider an adversary who controls a fraction B of themiddle-relay bandwidth and seeks to identify at least one guard ofeach member of a cabal. (�is might be used to adaptively targetguards for future a�ack or as part of an estimation of cabal size.If the adversary has a joined or compromised cabal member, hecan associate a guard with every cabal member who ever sends.) We also consider the e�ects of the number c of cabal membersand the number m of cabal multicast sessions observed. If theinstance of MTor restricts the set of usable middle relays to obtainthe associated deduplication bene�t, we take B to be the fraction ofMTor-available middle-relay bandwidth that is controlled by theadversary. Here, we also consider a probability T that an adversarymight allow for his failure.

We assume for simplicity a static network that does not changefor the period of our analysis. In each multicast session, a newrandom MR is chosen and the circuits constituting the multicasttree are also reformed. We also assume that all members of thecabal participate in all multicast sessions (meetings) and that cabalcomposition does not change.

If a cabal member constructs a circuit that uses a middle relaycontrolled by the adversary, then the adversary learns the client’sguard for that circuit. We take this as the only way that the adver-sary learns guards.

�e probability that a given cabal member never uses a com-promised middle relay in any of m sessions is (1 − B)m . Given thesimplifying assumption that such compromise is independent forall clients, the probability that a guard of every one of the c cabalmembers is identi�ed at least once over the course ofm meetingsis thus (1 − (1 − B)m )c . We can then gauge adversary success bybounding the probability that the adversary fails to carry out thiscompromise, giving us

1 −(1 − (1 − B)m

)c< T . (1)

We now explore the parts of the (c,m,B,T ) space that satisfy thisinequality. If the number of meetings

m > log1−B[1 − (1 −T )1/c

], (2)

where B ∈ (0, 1), then, with probability at least 1−T , the adversarylearns at least one guard of each of the c cabal members. �e le�column of Fig. 1 plots the right-hand side of (2) as a function of B forc = 5, 20, and 50 (top to bo�om subplots) andT = 0.1, 0.5, and 0.9 asindicated on the curves within each subplot. �us, for cabal sizes upto 50 an adversary holding 10% of middle-relay bandwidth has a 90%chance of having identi�ed a guard for each cabal member a�er nomore than 60 meetings. On the other hand, a�er 10 meetings, evenfor c = 5 the adversary must hold a more ambitious middle-relaybandwidth of nearly 40%. Note that the more relays the adversaryintroduces the more gradually he must introduce them and themore the relays should be in multiple locations if he is to avoidsuspicion.

Again using (1), if the number of cabal members

c < log1−(1−B)m [1 −T ] , (3)

0.0 0.2 0.4 0.6 0.8 1.0Fraction of bandwidth with c = 5

0

20

40

60

80

100

Min

. m

eeti

ngs

T = 0.1

T = 0.5

T = 0.9

0.0 0.2 0.4 0.6 0.8 1.0Failure probability with B = 0.05

0

1

2

3

4

5

Max. ca

bal si

ze

m = 1

m = 4

m = 8


0

20

40

60

80

100

Min

. m

eeti

ngs


0

1

2

3

4

5

Max. ca

bal si

ze


0

20

40

60

80

100

Min

. m

eeti

ngs


0

1

2

3

4

5

Max. ca

bal si

ze

Figure 1: Le� column: �eminimumnumber ofmeetingsm,as a function of middle-relay bandwidth B controlled by theadversary, required for the adversary to learn at least oneguard of each cabal member for cabal sizes c = 5, 20, and50 (top to bottom). Di�erent curves in each subplot corre-spond to di�erent failure probabilities for the adversary asindicated. Right column: �e maximum cabal size c, as afunction of the adversary’s failure thresholdT , required forthe adversary to learn at least one guard of each cabal mem-ber when the adversary controls B = 0.05, 0.1, and 0.2 of themiddle-relay bandwidth (top to bottom). Di�erent curves ineach subplot correspond to di�erent numbers of cabal meet-ings as indicated.

where B ∈ (0, 1) andm is a positive integer, then the adversary willlearn at least one guard of each of the c cabal members. �e rightcolumn of Fig. 1 plots the right-hand-side of (3) as a function of Tfor B = 0.05, 0.1, and 0.2 (top to bo�om subplots) andm = 1, 4, and8 as indicated on the curves within each subplot.

From the cabal’s perspective, it should keep its set of membersminimal with respect to the qualities needed to accomplish its goals.However, the cabal might reasonably ask how many meetings itshould hold and what the e�ects of additional meetings are on itssecurity. For a given cabal size c and a subset of i cabal members,the probability that a guard of exactly those i members is exposeda�erm meetings is (1 − (1 − B)m )i (1 − B)m(c−i). Considering thedi�erent ways to choose the subset of cabal members, the expectednumber of cabal members with an identi�ed guard a�erm meetingsis

∑ci=0 i

(ci)(1 − (1 − B)m )i (1 − B)m(c−i). Applying known results

about the mean of the binomial distribution, the expected numberof cabal members with no guard identi�ed is c(1−B)m . �e fractionof the cabal that has identi�ed guards is thus independent of c andequal to 1 − (1 − B)m . Figure 2 shows the expected fraction ofcabal members with identi�ed guards a�erm meetings for di�erentfractions B of middle-relay bandwidth controlled by the adversary.Perhaps unsurprisingly, failure probability appears to be highly


5 10 15 20 25Number of meetings m

0.0

0.2

0.4

0.6

0.8

1.0

Expect

ed f

ract

ion o

f ca

bal co

mpro

mis

ed

B = 0.2B = 0.15B = 0.1B = 0.05

Figure 2: �e expected fraction of the cabal members forwhich the adversary identi�es at least one guard as a func-tion of the number of meetings m. Di�erent curves showdi�erent fractions B of middle-relay bandwidth controlledby the adversary.

responsive to either the number of meetings observed or the fractiondoing the observing.

3.3.2 Estimating cabal size as multicast root. An adversary whocontrols the MR can estimate cabal size from the number of distinctGID circuits connecting to the MR. �e MR is selected uniformly atrandom from all relays that have the fast and stable �ags and meetthe minimum bandwidth parameter of the multicast group. Weassume that all adversary relays meet these requirements. Given a�xed fraction of middle-relay adversary bandwidth, the adversarymaximizes his chances of being selected for MR if he distributes thatbandwidth across as many relays as possible, subject to inclusionrequirements. He can accomplish this with a uniform distributionamongst this maximal set of relays, which will also simplify anycombination of calculations based on adversary’s fraction of relayswith those based on adversary’s fraction of bandwidth.

As we have noted, increased deduplication decreases the infor-mation an MR gets about cabal size from the number of observedcircuits. Collisions can occur in either the selection of guard or ofmiddle relay; as there are far fewer guards than middles in the cur-rent Tor network, guard selection is by far the dominating sourceof collision. For the following calculations we assume that guardbandwidth is also uniformly distributed.

With д guards in the network, for a cabal of size c , the expectednumber of guards selected is д(1 − (1 − 1/д)c ). As of this writing,the Tor network has about 2500 guards, and Tor selects middles fromabout 5000 relays. If we assume that the expected number of guardsare selected, and middles are selected uniformly, then the expectednumber of middles is given by the the same formula as above wherec is replaced by h, the expected number of guards selected, andguards are replaced by middles, viz: m(1 − (1 − 1/m)h ). �us theexpected number of middles selected, hence observed by the MR,is the same as cabal size for cabals up to c = 41, o� by less thanone for cabals up to c = 58 and within �ve percent for cabals up toc = 182.

A signi�cantly skewed guard distribution would impact the like-lihood of collisions, again diminishing information about cabal sizeavailable to the MR, but it may also help the adversary in narrowing

the set of most useful guards to target for bridging. Even for a selec-tion among 800 guards and 2000 relays, the above calculation givesan expected number of middles the same as cabal size up to c = 24and within �ve percent up to c = 60. Whether the distributionis skewed or not, an adversary owning a cabal member and theMR can recognize all colliding circuits for cabal members who eversend during a meeting, which can be used to improve the cabal sizeestimate.

If all relays selectable as middles by Tor meet the group criteriafor serving as MR, then the probability of an adversary being in aposition to make the above observation is governed by the fractionof middle relays he owns. �us, a B = 0.2 adversary will be morelikely than not to have been chosen as MR a�er only four multicastsessions and will have a nearly 90% chance of being chosen a�er10 sessions.

3.3.3 Estimating cabal size from middle relays. Estimates basedon relays serving as middles (second hops) in MTor sessions arealso possible. Compared to results from compromising a multicastroot, these will be much less likely to have information about thecircuits of all cabal members but much more likely to provide someinformation about cabal size every session. In addition, middlerelays will identify guards of cabal members with every observedcabal connection.Setting and assumptions: Here, we look at some very basic nu-merical simulations of the information learned by the adversaryfrom middle relays in the MTor usage scenario. �ese make as-sumptions that parallel those made in our analysis above, but theyallow us to study the e�ects of MTor deduplication more easily.In particular, we assume a static network and that cabal memberschoose guards and middle relays uniformly at random from sets of2500 and 5000 such nodes, respectively.Approach: In each of 10,000 trials, we identify some middle relaysas compromised; each is compromised independently with proba-bility B, and the compromise status remains unchanged throughoutm cabal meetings. We then choose a set of guards (the size of whichdepends on the simulation) for each cabal member; these sets areunchanged throughout them meetings.

For each meeting, each guard selects a client from its set. For eachguard selected, we then select a middle relay to use to connect to theMR. (�is simulates the choice of a middle relay made by the �rstclient using that guard in that meeting. Any other clients who usethat guard for that meeting will use the same middle relay.) If thatmiddle relay is compromised and the adversary has not a�emptedto bridge the guard before (i.e., that guard has not been used inconjunction with a compromised middle relay in this trial), thenwe bridge the guard with probability pb . Across all meetings in thetrial, we keep lists of the guards that have been bridged and that theadversary has tried but failed to bridge. A�er determining whichguards are newly compromised in each meeting, we determine theclients that have been identi�ed; this set is the union of the clientsthat were compromised before the current meeting and all of thosethat, in the current meeting, used a guard that has been successfullybridged during any meeting up to this point (including the currentmeeting).


0 10 20 30 40 50Number of meetings

0

5

10

15

20

25

Mean n

um

ber

of

identi

fied c

abal m

em

bers B = 0.5

B = 0.2B = 0.15B = 0.1B = 0.05


0

5

10

15

20

25

Mean n

um

ber

of

identi

fied c

abal m

em

bers

Figure 3: Mean (over 10,000 trials) number of cabal mem-bers (out of 25) identi�ed as a function of the number of ca-bal meetings for the one (le�) and three (right) guards perclient when the adversary controls B = 0.05, 0.1, 0.15, 0.2, and0.5 of the middle-relay bandwidth (di�erent curves) and theprobability of bridging a guard is pb = 0.5.

As noted in Sec. 2, a guard might be bridged in many ways,and we expect an adversary to try them in parallel and/or succes-sively. He will likely start with the least costly, least likely to raisesuspicion, and most likely to succeed, perhaps with varied empha-sis depending on se�ing. We use pb to capture the cumulativeprobability of success of these di�erent approaches.Results: Figure 3 shows the mean number of identi�ed cabal mem-bers, out of 25 and averaged over 10,000 random trials, for di�erentvalues of B as a function of the number of meetings when eachclient has one (le�) and three (right) guards. �is assumes a bridg-ing probability pb = 0.5. Figure 4 is similar and shows the e�ectsof the value of the bridging probability on these computations inthe three-guard-per-client case. �e di�erent curves in this plotcorrespond to di�erent values of pb ; this assumes B = 0.2.

Both B and pb can have a signi�cant impact on the adversary’ssuccess. Figure 3 illustrates the bene�t to the adversary of havingadditional guards that he may a�empt to bridge (for a �xed pb ).As we also discuss below, the adversary might be able to increasepb against long-lived guards by continuing to devote resources tobridging them if initial a�empts fail. Figure 4 highlights the bene�tsof increasing pb by this or other means.

4 EXAMPLE: TARGETING IRC CABALSWe now consider the following scenario: A cabal of interest to theadversary communicates via a private IRC channel. All of the cabalmembers access the IRC server via Tor, and each creates a newTor circuit for each cabal meeting. In doing so, we assume a clientchooses a guard uniformly at random from her set of guards andthen chooses a middle relay uniformly at random from all middlerelays. �e adversary compromises the middle relays independentlywith probability B, corresponding to the fraction of middle-relaybandwidth that he controls. We assume that the network is static.

4.1 Identifying guards and cabal membersWith respect to learning guards of cabal members, the analysis ofSec. 3.3.1 applies in this se�ing as well. �e assumption made therethat probabilities for clients never using a compromised middlerelay are independent is even more realistic here.


0

5

10

15

20

25

Mean n

um

. id

enti

fied c

abal m

em

bers pb = 0.95

pb = 0.9pb = 0.75pb = 0.5pb = 0.25pb = 0.1pb = 0.05

Figure 4: Mean (over 10,000 trials) number of cabalmembers(out of 25) identi�ed as a function of the number of cabalmeetings in the three-guard case when the adversary con-trols B = 0.2 of the middle-relay bandwidth and the proba-bility of bridging a guard is pb = 0.05, 0.1, 0.25, 0.5, 0.75, 0.9,and 0.95.

We also consider the adversary’s success in identifying and lo-cating particular cabal members. If the adversary already has acabal membership, by the properties of IRC he has a list of channelpseudonyms for all cabal members, even those a�ending meetingssilently, and has a complete pseudonmymous record of all com-munications. We again assume the adversary owns some fractionB of the middle-relay bandwidth. If the cabal leader Alice usesa middle relay controlled by the adversary Sam, he observes thetra�c pa�ern through that relay and the matching messages thatappears in the channel and thus learns the guard used by Alice forthat circuit. Once the adversary knows this guard, he is able tobridge the guard and identify Alice’s IP address with probabilitypb . Other than through this combination of events, we assume theadversary is not able to identify Alice’s IP address. Even if Samonly owns the ISP of some targeted, uncompromised cabal member,he still passively observes everything there, including the tra�cpa�ern for a cabal’s IRC channel; as noted above, we assume thatthis or other information allows the adversary to identify cabaltra�c at middle relays.

We make the simplifying assumption that bridging is actuallywith respect to client–guard pairs rather than individual guards.�us, if clients c1 and c2 use the same guard д for circuits that gothrough compromised middle nodes (which may or may not be thesame for the two clients), then the adversary bridges д and learnsc1 with probability pb and, independently, bridges д and learns c2with probability pb . Bridging that arises from compromising theguard itself would not be independent for these two clients, whilebridging that arises from compromising client ISPs or some part ofthe network between the clients and д might be. We thus think thisassumption is reasonable, although others could be made as well.

Figure 5 plots the probabilities, for various cases, that the ad-versary is able to identify the cabal leader. �e computations arediscussed in App. C. �e top row assumes one guard per client; thebo�om row assumes three guards per client. �e le� column (pairof subplots) shows plots this probability as a function of B for mmeetings (di�erent curves form = 1, 5, 10, and 20). �e right col-umn (pair of subplots) shows this as a function ofm with di�erent


curves for B = 0.05, 0.1, 0.15, and 0.2. Each pair of subplots showsbridging probability pb of 0.5 (le�) and 0.95 (right).

0.0 0.2 0.4 0.6 0.8 1.0Middle-relay BW B

0.0

0.2

0.4

0.6

0.8

1.0

Pro

babili

ty o

f lo

cati

ng c

lient

m = 20m = 10m = 5m = 1

0.0 0.2 0.4 0.6 0.8 1.0Middle-relay BW B

0.0

0.2

0.4

0.6

0.8

1.0

10 20 30 40 50Num. meetings m

0.0

0.2

0.4

0.6

0.8

1.0

B = 0.2B = 0.15B = 0.1B = 0.05


0.0

0.2

0.4

0.6

0.8

1.0

0.0 0.2 0.4 0.6 0.8 1.0Middle-relay BW B

0.0

0.2

0.4

0.6

0.8

1.0

Pro

babili

ty o

f lo

cati

ng c

lient

0.0 0.2 0.4 0.6 0.8 1.0Middle-relay BW B

0.0

0.2

0.4

0.6

0.8

1.0


0.0

0.2

0.4

0.6

0.8

1.0


0.0

0.2

0.4

0.6

0.8

1.0

Figure 5: Probability that the attacker is able to identify thecabal leader for one (top row) and three (bottom row) guardsper cleint when the attacker controls a fraction B of themiddle-relay capacity over the course of m meetings. �isis shown as a function of B in the le� column (with di�er-ent curves for di�erent values ofm) and as a functionm inthe right column (with di�erent curves for di�erent valuesof B). �e bridging probability pb is, in each quadrant, 0.5(le� subplot) and 0.95 (right subplot).

Considering Fig. 5, the a�acker is likely to be able to identify thecabal leader if he makes a substantial but not unrealistic investmentin middle-relay bandwidth (B = 0.2), even if the cabal has a modestnumber of meetings (10 or more). �e le� subplot in the top-le�pair shows the adversary’s chances bounded by pb = 0.5 becausethere is only one guard to bridge. However, we expect that, if thereis a single long-lived guard, the adversary’s chance of bridging theguard would go up over time, and the success probabilities wouldbecome closer to those shown in the right subplot in this pair.

Separately, we note that (ignoring the fact that the a�ackercannot expect to kill every circuit) killing one circuit per clientper meeting would compress them axis in Fig. 2 (which, as noted,applies to the IRC case as well) by a factor of 2. If the a�acker werewilling and able to kill k total circuits per client, it could shi� thesecurves to the le� by k . Considering Fig. 2, we see that the greatestbene�t to the a�acker comes in the �rst circuit that he kills.

4.2 Estimating cabal sizeWe turn now to estimating the total size of the cabal (when theadversary does not already own a member). In particular, if an IRCcabal of size c hasm meetings, what estimate of c will be made byan adversary who controls a fraction B of middle-relay bandwidth?

How is this estimate likely to be distributed, and how much of anerror is he likely to make?

To answer these questions, we numerically compute the maximum-likelihood estimator (MLE) of the cabal size based on an m-tuple®x ∈ {0, 1, . . . , c}m of observations that the adversary might makeof the number of cabal members using compromised middle relaysduring each ofm meetings. We then compute the distribution onpossible observations to determine, for each estimated value, theprobability that the adversary will make observations that give riseto that estimate.

In doing this, we assume that the adversary considers only thenumber of circuits that he sees during each meeting window andnot the guards used for these circuits. In the case that each clientuses only one guard, if the adversary sees one circuit in each of threemeetings and these circuits all use di�erent guards, then he knowsthat he has observed three di�erent clients and not just one clientmultiple times. As a result, he should probably increase his estimateof the cabal size compared to his estimate when simply using acount of the circuits he observes. �e approach we take alreadyrequires signi�cant computational resources, and accounting forguard identities makes it even more complex to the point that weexpect it would be infeasible (while also not adding signi�cantly tothe adversary’s accuracy). We do note that this issue may have ane�ect. (We compute the probabilities of guard collisions and showthese in Tab. 1 in App. C.2.)

Figure 6 shows the error in the expected value of the MLE—i.e.,the expected MLE minus the actual cabal size c—as a function of cfor di�erent values of B (di�erent subplots) andm (di�erent curves).

5 10 15 20Actual cabal size with B = 0.05

2.0

1.5

1.0

0.5

0.0

MLE

Err

or

m = 1

m = 2

m = 5


2.0

1.5

1.0

0.5

0.0M

LE E

rror


2.0

1.5

1.0

0.5

0.0

MLE

Err

or


2.0

1.5

1.0

0.5

0.0

MLE

Err

or


2.0

1.5

1.0

0.5

0.0

MLE

Err

or


2.0

1.5

1.0

0.5

0.0

MLE

Err

or

Figure 6: Expected value of the MLE for the number c ofcabal members minus c as a function of c for number ofmeetingsm = 1, 2, and 5 (di�erent curves). �e le� columnhas the adversary-controlled fraction of middle-relay band-width B = 0.05, 0.1, and 0.15 (top to bottom); the right columnhas B = 0.2, 0.5, and 0.9 (top to bottom).


1 5 10 15 20Actual cabal size

50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e


50

40

30

20

10

0

MLE

Valu

e

Figure 7: �e e�ect of increasing the number of meetingsmand changing the adversary-controlled middle-relay band-width B. From top to bottom, m = 1, 2, and 5. From le� toright, B = 0.05, 0.1, 0.2, and 0.5. Within each subplot, the ac-tual cabal size c increases from 1 to 20 along the horizontalaxis, and possible MLE values increase from 0 to 50 up thevertical axis. For each c and MLE value, the plot indicatesthe probability (darker values are larger) of the adversaryobserving a tuple for which it would compute the indicatedvalue as its MLE for c.

Figure 7 presents a matrix of plots of distributions of the MLEvalue. Each subplot shows, for each value c on the horizontal axis,the distribution of MLE values, with larger probabilities correspond-ing to darker shading. In the matrix of plots, B increases from le�to right (0.05, 0.1, 0.15, 0.2, 0.5, 0.75, and 0.9), andm increases fromtop to bo�om (1, 2, and 5).

From these distributions we may compute, for each parametervector, the probability that the adversary will compute an MLE ofcabal size that has error at least a certain size. Figure 8 presents a

matrix of subplots that show these probabilities. In each subplotwe show, as a function of the true cabal size c , the probability thatthe adversary’s MLE computation di�ers from c by at least 1, 5, and10 (di�erent curves within the subplot). �is is repeated across thematrix for di�erent values ofm (1, 2, and 5, le� to right) and B (0.05,0.1, 0.15, 0.2, 0.5, 0.75, and 0.9, top to bo�om).

From Figs. 6–8, we see that MLE is not an unbiased estimator ofcabal size but that, in expectation, it gives a fairly close estimate.While the distributions may be spread out and discontinuous, bythe time the cabal hasm = 5 meetings and the adversary controlsB = 0.2 of the middle-relay bandwidth, the MLE distribution isstarting to converge and the probability of a substantial error isfairly small.

5 EXAMPLE: PICKING RIPE ONIONS�e set of users of a particular site may be similar to a cabal com-municating via multicast or IRC. While they may not be holdingsimultaneous meetings or even see themselves as a group, an ad-versary may target them because they are users of that site. Asite may be interesting for exogenous reasons, e.g., because of apublic mention of it or its presence in the browser bookmarks of apreviously compromised target. �e adversary may want to countthe users visiting a site that he has targeted, but site popularitymay also be a criterion for targeting a site. For example, he mighttarget onionsites that show a sudden spike in popularity.

Our analysis here essentially applies to Tor users visiting manyordinary Internet sites, but we focus on onionsites, particularlyhidden web services. �ese were designed to hide many featurestypically visible for ordinary websites. �ey have also had recentdesign changes speci�cally intended to make it harder for an adver-sary to discover a site’s .onion address, popularity [21] or networklocation [19].

Beyond this inherent interest, such sites are plausible candi-dates for targeting of their users. Onionsites o�er protections fortheir users that are not yet common on the Internet, much likeHTTPS-protected websites when those were relatively rare. LikeHTTPS-protected sites of that era, there has been a prominent per-ception that most current (thus still early-adoption) onionsites areintentionally set up to thwart targeted a�ack. Even if that percep-tion of onionspace is initially inaccurate, the perception can itselfdrive a�ention of a�ackers, thus becoming somewhat self-ful�lling.

As noted, learning about site popularity may be an adversarygoal for a targeted site or may be a criterion for deciding to targeta site. Previous work [3, 26] has measured popularity of onionsitesby requests to the onion address directory. Besides the directorysystem design changes that make this approach much less feasible,it can also be a misleading and inaccurate measure of onionsitepopularity in several ways [22]. We can, however, use variants ofthe techniques described in previous sections to measure onionsitepopularity (as well as the popularity of other Tor-accessed Internetsites).

Directory requests and even site connections can be unreliableindicators of human interest in onionsites because of crawlers andautomation such as link prefetching. �us, just knowing the numberof connections or distinct clients connecting to a site is not veryuseful to a targeting adversary. Information about the distribution


5 10 15 20Actual cabal size with B = 0.05 and m = 1

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or

error >= 1error >= 2error >= 5error >= 10


0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or



0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Pro

babili

ty o

f sp

eci

fied a

bso

lute

err

or


Figure 8: Probability MLE error is at least a speci�ed value (1, 2, 5, and 10; di�erent curves in each subplot) as a function oftrue cabal size c. Number of meetingsm is 1, 2, or 5 (top to bottom); the fraction B of middle-relay bandwidth controlled by theadversary is 0.05, 0.1, 0.2, and 0.5 (le� to right).

of connections among users would be much more useful both forunderstanding a site’s popularity and for selecting its users fortargeting.

Unlike the cabal-meeting case, because visits are not synchro-nized the targeting-adversary technique of starting with middlerelays might seem problematic for individuating onionsite visitors.But, as with our analyses above, distinct guards are a fairly accurateindicator of distinct clients up to a moderate-size set of clients, allthe more when each client uses a single guard per destination (oroverall).

Even if site users do share guards, as long as guard overlap isinfrequent enough, this will still give a targeting adversary a muchbe�er idea about interest in the site than could be obtained viapreviously published techniques. “Infrequent enough” implies thatthe rough picture of popularity painted by targeted-site connectionsper guard per unit time presents a ballpark estimate of site-useractivity distribution.

To use our middle-relay techniques, we must assume that desti-nations of potential interest can be recognized by an adversary inthe middle of circuits. We do so based on tra�c pa�erns plus possi-bly other factors like latency, which has been known since at least2007 [12] to leak some identifying information for Tor communica-tion. Destination �ngerprinting of route-protected communicationspredates Tor [11]. How e�ective it is has been the subject of muchresearch [34].

�ough the level of success for �ngerprinting Tor destinations ingeneral may remain uncertain, onionsites constitute a much smallerset. And current onionsite protocols are su�ciently di�erent from

applications connected over vanilla Tor circuit protocols that sepa-rating these is currently very easy and reliable for relays carryingtheir streams. �ere are about 60,000 unique onion addresses in thedirectory system, but of these typically only a few thousand at anytime are reachable and return a connection to a web server. If thesenumbers are roughly representative (even if we add in onionsitesnot listed in the directory system and those that can only be reachedif proper authentication is shown to the Introduction Point), then�ngerprintability of all persistent onionsites becomes a reasonableassumption. Note that our techniques are not a�ected by whetheror not a website is listed in the onionsite directory system or re-quires authentication to be reachable. �e most direct techniquefor a middle relay targeting adversary is then to simply count thenumber of connections going to a particular onionsite from eachguard. �is will already give a rough picture of the distribution ofclient activity as well as which guards are most worth targeting forfurther adversary interest.

5.1 Recounting Onions From Our PastGiven our assumptions about numbers and �ngerprintability of.onion websites, and rough numbers and distribution of their usersand implications for individuating clients by guards, there are addi-tional estimation techniques at our disposal.

We can estimate the number of clients visiting a site n or moretimes using capture-recapture techniques. �ese were originallyused for species population estimates in biology where it wouldbe impossible to observe the entire population, e.g., estimating the


number of �sh in a given lake. �ey are now used in many se�ings,including computer networks [1].

�e Lincoln–Petersen (LP) estimate is the simplest and quickestfor our adversary to perform, provided we add a few assumptionsto those made above. To calculate the number of clients making nor more connections to a target site per unit time, we must assume(1) that all clients (targeted or otherwise) visit a target site withthe same frequency during di�erent sampling intervals of the samelength, and (2) that connections (visits) and observation intervalsare such that no connection is counted in more than one interval.To avoid problems with division by 0, we use the Chapman versionof the LP estimator, given by N = (c1+1)(c2+1)

m2+1 − 1, where c1 is thenumber of guards in interval t1 to be ‘captured’ and ‘marked’ ascarrying circuits for n or more visits in that interval, c2 is the totalnumber of guards observed to ‘visit the target’ n or more times int2, and m2 is the number of guards ‘marked’ in t1 and observedvisiting the target at least n times in t2.

Note that, if multiple clients used the same guard simultaneouslyto connect to an onionsite through one or more compromised mid-dles, the adversary might reasonably conclude that the guard is infact serving multiple visitors to the onionsite. �is does not followwith certainty, and we do not model such reasoning here.

In Fig. 9 we show the results of numerical experiments withthe Chapman estimator. In these experiments, we assume 2,500guards and 5,000 middle relays; each of the la�er is compromisedwith probability B. We run each experiment 10,000 times. Foreach client, we pick a guard set. We assume there are two types ofclients: “regular” clients who visit the targeted site twice duringeach examination window and “interesting” clients who visit thetargeted site 10 times during each examination window. Eachexperimental run speci�es the number of each type of client; foreach client, we have it repeatedly pick (twice or 10 times, dependingon its type) a guard from its guard set and a middle relay. We trackthe number of times that each guard is used with any compromisedrelay; this could be multiple compromised relays, and the sameguard could be used by multiple clients. We specify a thresholdvalue; guards that are seen by compromised middle relays at leastthis many times are considered marked and are remembered bythe adversary. �is process is repeated again to model the secondexamination window.

�e subplots of Fig. 9 show violin plots that focus on varyingdi�erent parameters; except for the parameter being varied in aparticular subplot, these use B = 0.25, a threshold of 3, a client mixof 25 targeted clients (who each visit the destination 10 times perperiod) and 225 “regular” clients (who each visit the destination 2times per period), and 1 guard per client. �e subplots examine thee�ects of varying B (top le�; results for B = 0.05, 0.1, 0.15, 0.2, 0.25,0.3, 0.35, 0.4, 0.45, 0.5, and 0.55), the threshold (top right; resultsfor thresholds of 1, 2, 3, 5, 7, and 10), the client mix (bo�om le�;results for regular/targeted clients combinations of 25/25, 225/25,475/25, 2475/25, and 50/50), and the number of guards per client(bo�om right; results for 1, 2, 3, 5, and 10 guards per client).

Considering Fig. 9, we see that the adversary’s estimate increasesin accuracy with B, as expected, but much of the gain comes inensuring that the adversary controls one ��h to one third of themiddle-relay bandwidth. We also see that the best threshold seems

0 1 2 3 4 5 610*B

0

20

40

60

80

100

120

0 2 4 6 8 10 12Threshold

0

50

100

150

200

250

300

25/2

5

225/

25

475/

25

2475

/25

50/5

0

Mix of regular/targeted clients

0

100

200

300

400

500

600

700

0 2 4 6 8 10 12Guards per client

0

20

40

60

80

100

120

140

160

Figure 9: Violin plots showing Chapman estimates for10,000 trials each of: di�erent values of B (top le�), di�erentthreshold values (top right), di�erent combinations of regu-lar/targeted client types (bottom le�), and di�erent numbersof guards per client (bottom right). When not being explic-itly varied as noted, the parameters are: B = 0.25, thresholdof 3, 25 targeted clients who visit 10 times per period, 225regular clients who visit 2 times per period, and 1 guard perclient.

to be 3 for this combination of parameters; this also appears to bethe case for other parameter combinations that we explored (withthe regular clients visiting the destination twice and the targetedclients visiting 10 times). As might be expected, increasing thenumber of guards generally decreases the adversary’s accuracy.Finally, the adversary’s estimate is reasonable for small enoughnumbers of targeted users; however, when these users are just 1%of the total user population, the estimate is o� by a large amount.

More sophisticated and accurate estimators exist. For example,the Schnabel estimator generalizes Lincoln–Petersen to incorpo-rate repeated samplings with marking of not-previously-markedmembers of the population. Other estimators may allow relaxationof assumptions such as constant ratios from one sample to the next.And, unlike most applications, the set of unmarked guards has astructure that can inform our estimates. For example, given a guardobserved to have carried circuits connecting to a targeted site 9times in a day, we can use the expectation that the associated clientactually visited 10 or more times that day to adjust our estimates,and similarly for smaller numbers of target visits per guard perday.

6 DISCUSSIONIn this paper, we have considered adversaries with di�erent goalsand strategies, but o�en with the same endowment and capabilitiesas adversaries in previous work. Another important di�erence onlytouched on above is how long an adversary may have (or be willing


to use) some of his resources. �is can a�ect both a�ack successand decisions about which a�acks to a�empt.

We now brie�y describe some of the temporally dependent fea-tures of an adversary’s endowment and strategy, although we leavedetailed analysis of this for future work. We then describe possiblecountermeasures to a targeting adversary, particularly one withtemporal limitations on his endowment.

6.1 Time Is on My SideTemporal aspects of adversary endowment have been considered fora long time [24], and have also been applied to onion routing beforeTor [29]. And we have noted that intersection a�acks are inherentlyacross time. Nonetheless, these adversaries have a uniform boundon resources; what varies is either the distribution of these [24] or ofnetwork resources and status [18]. And generally, these adversarieswill still be equally happy to a�ack any user, or possibly any userwith the same behavior on the network.

In this section we discuss a Tor adversary that has, or is willingto deploy, di�erent amounts and types of resources at di�erenttimes, typically based on some particular target. Limitations onendowment could derive from funding or statutory start date orexpiration. (We assume that the adversary has enough understand-ing of his funding status to plan.) More generally, given a levelof required resources, approving or commi�ing to any course ofaction is typically easier if the anticipated duration of needed re-sources is relatively clear, whether for oneself or when authorizingothers, and whether psychologically or in policy-based decisions;the shorter that duration is, typically the greater the willingnessto commit resources. Similarly, the presence of intermediate goals,which if achieved would themselves be of interest or would helpdetermine whether and how to commit to further action, can makecommitment to an action more acceptable hence more likely.

Johnson et al. [18] set out as a behavioral user class an IRC user,who 27 times a day creates the same single IRC sessions to the sameserver. We now compare their analysis of IRC users’ security againstan end-to-end correlating relay adversary to the adversary in Sec. 4targeting a cabal that meets on a private IRC channel. For this usertype, they considered variously endowed adversaries and looked indetail at a relay adversary allocated 100 MiB/s, approximately 4%of the total network bandwidth at the time of their analysis, and onthe order of the largest identi�ed families of relays under a singleoperator or organization. �e time until an IRC user experiencedthe �rst end-to-end correlation failure (both guard and exit of acircuit compromised) was analyzed under an optimal distributionof adversary bandwidth to guards and exits (roughly four to one).In our scenario, a relay is assumed to be able to always identify acabal connection passing through it. So we should assume that theJohnson et al. adversary is able to devote all relays to the guardposition. We thus very roughly estimate a 20% reduction in mediantime to compromise compared to what Johnson et al. reported.

For a cabal size of 10 or 20, and a roughly comparable fraction ofbandwdith allocated to middle relays, our targeting adversary willhave a good idea of cabal size and will identify the guards of nearlyall cabal members in under 4 days (100 meetings). According tothe analysis by Johnson et al., the just-described contributed-guardadversary will require about 10 times as long to get a much rougher

idea of cabal size, having identi�ed guards for roughly half thecabal. To get approximately the same likelihood as the targetingadversary of having identi�ed guards for almost all of the cabalwill take 40-50 times as long (under a week vs. 150-200 days). �isis not just about size: in about a week of IRC usage the targetingadversary will have a good sense of cabal size, cabal guards, andclient send-receive activity per cabal guard (which may indicatecabal leaders and will indicate which members send the most).

�e contributed-guard adversary is also no more likely at anytime to identify a cabal leader than any other member. �is alsoholds for the targeting adversary with respect to identifying aleader’s guard. But it will still typically take less than a week atthe stated rate of meetings. For a leader recognized by messagepa�erns, a determined targeting adversary can bring all resourcesand a�acks to bear to signi�cantly increase his chance of bridginga leader’s guard. Some a�acks may take weeks to know if theyhave succeeded, but others will take only hours or even minutes.A leader’s guard might be resistant to all a�empts at compromiseor bypass. But such relays can then be subject to persistent DoS orother resource depletion a�acks [14], giving the adversary anotherchance with a new leader guard.

One guard vs. three or more guards in general involves manytrade-o�s, some of which we have identi�ed. Our analysis of leaderidenti�cation in Sec. 4 clearly favors using single guards to thwartour targeting a�acker. But vs. the contributed-guard adversary(which was a primary basis for Tor’s decision to move to singleguards [6]), this is much more signi�cant in terms of speed of a�ackand adversary feedback in process—despite a correlating adversaryautomatically identifying any client for which he owns the guard.�ough the correlating adversary remains important and shouldnot simply be abandoned, this again shows that even when theyagree about what is more secure, the targeting adversary is o�enthe dominant basis for the assessment.

Johnson et al. also assume a network at steady state, a�er ad-versary relays have obtained the guard �ag. Middle relays can seesome usage in less than a day a�er announcing themselves andreach steady state in about a week. Relays generally take over aweek to obtain the guard �ag and about ten weeks to reach steadystate for guard usage [5]. For an adversary mounting an a�ack fromscratch, the above time comparison thus overstates signi�cantly infavor of the contributed-guard adversary.

6.2 Possible countermeasures�e primary purpose of this paper is to describe a class of adver-sary that has been overlooked but we believe is as pertinent ormore pertinent for Tor than the one generally receiving the mosta�ention. Before concluding, however, we wanted to at least sketchsome possible ways to improve resilience against such selectiveadversaries on the Tor network. In the interest of space (and time)we have limited the scope of our analysis to adversaries at Tor re-lays, only minimally considering an adversary on the network linksbetween them and/or between clients or destinations and the Tornetwork. Any countermeasure we describe here will likely need tobe signi�cantly redesigned to be e�ective once those resources areadded to the adversary arsenal. So there is li�le point to providingmore than a sketch here.


Layered Guards: �e same paper that introduced Tor guards alsointroduced the idea of layered guards [25]. �e notion of layeredguards has been revisited periodically, most recently in a Tor Pro-posal on slowing guard discovery for onion services [19]. Usingonly one or a small set of relays for each client-guard’s middlecould make it hard to identify guards just as guards make it hard toidentify clients. But, if single persistent middles are chosen, thenrandomly selected exits could possibly enumerate and monitor thebehavior of associated users for many destinations and, worse, willalways know for which destination without �ngerprinting. In thecase of �ngerprinted onion services, cabal/user enumeration willbe possible using (easily spun up) middles chosen as rendezvouspoints. In general, the number and rotation of guards and theirsecond-layer guards can complicate determination of cabal size aswell as guard discovery.Randomized selection of guard set size and duration: As ouranalysis shows, single, persistent guards generally provide muchmore enumeration information about size of a cabal or set of targeted-site users and more information about targeted-site user behaviorthan does a set of guards with more overlap between clients’ sets.And long persistence means that bridging an identifed guard is notneeded for monitoring a portion of targeted client’s behavior, andthat, if a bridging is a�empted, it will pay o� for a long period ofmonitoring targeted-client behavior and IP address(es). And thatbridging need not be quickly successful to be useful. In additionto enlarging and randomizing size of a client’s guard set, selectingguards for less persistent or predictable periods would also countertargeting a�acks, pseudonymous pro�ling, and con�dence in theexpected value of bridging a guard. Other related strategies may beworth investigating, such as a client limiting and controlling theuse of the same guard for visits to the same sensitive site. Obviouslythere is a tension between the increased risk of correlation a�ackfrom using more guards for shorter periods and targeted a�ackson cabals or clients of targeted sites.Trust: One way to simultaneously reduce vulnerability from bothtargeted middle-relay a�acks and untargeted correlation a�acks isto incorporate trust into route selection. �e paper that introducedguards for Tor observed that guards could be “chosen at randomor chosen based on trust” [25]. Subsequent work noted that trustcould be based on many of the criteria just mentioned as useful fordetermining which bridging strategies might be e�ective againstwhich guards and introduced a mathematical characterization oftrust as the complement to the probability of compromise [16]. �edownhill algorithm [17] explored combining layered guards withtrust: A the �rst relay in a circuit is chosen from a small set ofthose most highly trusted. Later relays in a circuit are selectedfrom ever larger sets that include relays further “down the hill” ofassigned trust. �is would add delay to enumeration a�acks aswell as reducing their e�ectiveness. It could also be combined withvarying periods of guard rotation in various ways. An unpublishedversion of the downhill algorithm had a slowly rotating �rst-hoprelay set and ever faster rotating relay sets for each subsequenthop [27]. For trust-based protections to be e�ective in practice,trust of all elements in the network path (ASes, IXPs, submarinecables, etc.) must be considered [13].Standardized onion service tra�c templates: Our targetinga�acks on onion services are dependent on the e�ectiveness of

�ngerprint-based individuation of them. Making tra�c �nger-prints of many onion services similar to each other could reducethe e�ectivness of those a�acks. Providing simple bundles or tem-plates for users wanting to set up onionsites would be useful formany reasons, incorporating data management and communicationprotocols to create default standardized tra�c �ngerprints amongthem. To reduce the likelihood that a single draconian standardwill discourage site operators from using these defaults, a smallnumber of templates might be available depending on basic sitecon�guration choices. Sites using standardized templates can alsocommunicate this to clients either in their directory informationor upon �rst contact. Tra�c �ngerpint normalization can thenbe enhanced by cooperation between clients and sites. To furtherfacilitate adaptation to individual sites, onion protocols could usecomponentized chunks of �ngerprint-normalized communication,possibly split over multiple circuits. Again the trade-o�s againstcorrelation vulnerability would need to be considered, but we hopewe have shown that �ngerprinting by interior elements of the net-work is as realistic or more realistic and serious a threat to Tor’smost sensitive users.

7 CONCLUSIONS AND FUTUREWORKWe have introduced targeting adversaries, who focus on particularsystem users or groups of users, and shown that the di�erencein goals and strategy of these overlooked adversaries can lead toa�acks on Tor users at least as devastating and relevant as any Tora�acks set out in previous research. While we have shown thecapabilities of a targeting adversary in realistic scenarios involv-ing a published multicast system, IRC, and onionsites, we cannothope to quantify in this introductory treatment the possible e�ectsfor all Tor users, for all possible client locations and network des-tinations. We anticipate extensive future research into targetingadversaries, including: abstract characterization and formal treat-ment of targeting adversaries, expansion of contexts in appliedtargeting adversary models (such as network link adversaries), andanalysis of security against combinations of targeted and hoover-ing adversaries, particularly when large and well-resourced. Andwe expect all of this to have an impact on future guard and pathselection algorithms.

Onion services are also an active area of discussion and redevel-opment [21, 35]. We expect that an interesting and useful directionfor future research will be the analysis of the e�ects of di�erent re-design proposals on security in the context of targeting adversaries.�is will require a substantial extension to TorPS [15], which doesnot currently support modeling of onion services.

ACKNOWLEDGMENTSWe thank Giulia Fanti, Nick Hopper, Rob Jansen, George Kadianakis,Ma� Traudt, and Ryan Wails for their comments on earlier dra�sof this paper.

REFERENCES[1] Nicola Acce�ura, Giovanni Neglia, and Luigi Alfredo Grieco. �e capture-

recapture approach for population estimation in computer networks. ComputerNetworks, 89:107 – 122, 2015.

[2] J. Appelbaum and A. Mu�e�. �e “.onion” special-use domain name. h�ps://tools.ietf.org/html/rfc7686, 2015.

https://tools.ietf.org/html/rfc7686

https://tools.ietf.org/html/rfc7686


[3] Alex Biryukov, Ivan Pustogarov, and Ralf-Philipp Weinmann. Trawling for Torhidden services: Detection, measurement, deanonymization. In Proceedings ofthe 2013 IEEE Symposium on Security and Privacy, SP ’13, 2013.

[4] George Danezis and Paul Syverson. Bridging and �ngerprinting: Epistemica�acks on route selection. In Proceedings of the 8th International Symposium onPrivacy Enhancing Technologies, PETS ’08, pages 151–166, 2008.

[5] Roger Dingledine. �e lifecycle of a new relay. h�ps://blog.torproject.org/blog/lifecycle-of-a-new-relay, September 2013.

[6] Roger Dingledine, Nicholas Hopper, George Kadianakis, and Nick Mathewson.One fast guard for life (or 9 months). 7th Workshop on Hot Topics in PrivacyEnhancing Technologies (HotPETs 2014), July 2014.

[7] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor: �e Second-Generation Onion Router. In Proceedings of the 13th USENIX Security Symposium,August 2004.

[8] Nick Feamster and Roger Dingledine. Location diversity in anonymity networks.In Sabrina De Capitani di Vimercati and Paul Syverson, editors, WPES’04: Pro-ceedings of the 2004 ACM Workshop on Privacy in the Electronic Society, pages66–76, Washington, DC, USA, October 2004. ACM Press.

[9] David Goulet and George Kadianakis. Random number generation during Tor vot-ing (Tor proposal #250). h�ps://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt, August 2015.

[10] Jamie Hayes and George Danezis. Guard sets for onion routing. Proceedings onPrivacy Enhancing Technologies, 2015(2):65–80, June 2015.

[11] Andrew Hintz. Fingerprinting websites using tra�c analysis. In Roger Dingledineand Paul Syverson, editors, Privacy Enhancing Technologies: Second InternationalWorkshop, PET 2002, pages 171–178, San Francisco, CA, USA, April 2002. Springer-Verlag, LNCS 2482.

[12] Nicholas Hopper, Eugene Y. Vasserman, and Eric Chan-Tin. How muchanonymity does network latency leak? In Sabrina De Capitani di Vimercati,Paul Syverson, and David Evans, editors, CCS’07: Proceedings of the 14th ACMConference on Computer and Communications Security, pages 82–91. ACM Press,2007.

[13] Aaron D. Jaggard, Aaron Johnson, Sarah Cortes, Paul Syverson, and Joan Feigen-baum. 20,000 in league under the sea: Anonymous communication, trust, MLATs,and undersea cables. Proceedings on Privacy Enhancing Technologies, 2015(1):4–24,April 2015.

[14] Rob Jansen, Florian Tschorsch, Aaron Johnson, and Bjorn Scheuermann. �esniper a�ack: Anonymously deanonymizing and disabling the Tor network. InProceedings of the Network and Distributed Security Symposium - NDSS ’14. IEEE,February 2014.

[15] Aaron Johnson. Tor Path Simulator code. h�ps://github.com/torps/torps.[16] Aaron Johnson and Paul Syverson. More anonymous onion routing through

trust. In 22nd IEEE Computer Security Foundations Symposium, CSF 2009, pages3–12, Port Je�erson, New York, July 2009. IEEE Computer Society.

[17] Aaron Johnson, Paul Syverson, Roger Dingledine, and Nick Mathewson. Trust-based anonymous communication: Adversary models and routing algorithms.In Proceedings of the 18th ACM Conference on Computer and CommunicationsSecurity, CCS ’11, pages 175–186, New York, NY, USA, 2011. ACM.

[18] Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul Syverson. Usersget routed: Tra�c correlation on Tor by realistic adversaries. In Proceedings ofthe 2013 ACM SIGSAC Conference on Computer & Communications Security, CCS’13, pages 337–348, New York, NY, USA, 2013. ACM.

[19] George Kadianakis and Mike Perry. Defending against guard discovery a�acksusing vanguards (Tor proposal #247). h�ps://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-discovery.txt, July 2015.

[20] Dong Lin, Micah Sherr, and Boon �au Loo. Scalable and anonymous groupcommunication with MTor. Proceedings on Privacy Enhancing Technologies,2016(2):22–39, June 2016.

[21] Nick Mathewson. Next-generation hidden services in Tor, (Tor proposal#224). h�ps://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt, November 2013.

[22] Nick Mathewson. Some thoughts on hidden services. h�ps://blog.torproject.org/blog/some-thoughts-hidden-services, December 2014.

[23] Alec Mu�e�. RFC 7686 and all that . . . . h�ps://www.facebook.com/notes/alec-mu�e�/rfc-7686-and-all-that/10153809113970962, 2015.

[24] Rafail Ostrovsky and Moti Yung. How to withstand mobile virus a�acks. InProceedings of the Tenth ACM Symposium on Principles of Distributed Computing(PODC ’91), pages 51–59. ACM Press, 1991.

[25] Lasse Øverlier and Paul Syverson. Locating hidden servers. In 2006 IEEE Sympo-sium on Security and Privacy (S& P 2006), Proceedings, pages 100–114. IEEE CS,May 2006.

[26] Gareth Owen and Nick Savage. �e Tor dark net. Paper Series: No. 20 20, GlobalCommission on Internet Governance, September 2015.

[27] Personal communication.[28] Michael Reiter and Aviel Rubin. Crowds: Anonymity for web transactions. ACM

Transactions on Information and System Security (TISSEC), 1(1):66–92, 1998.[29] Paul Syverson, Gene Tsudik, Michael Reed, and Carl Landwehr. Towards an

analysis of onion routing security. In InternationalWorkshop on Designing Privacy

Enhancing Technologies: Design Issues in Anonymity and Unobservability, pages96–114, New York, NY, USA, 2001. Springer-Verlag New York, Inc.

[30] Who uses Tor. h�ps://www.torproject.org/about/torusers.html. Accessed Febru-ary 2017.

[31] Tor metrics portal. h�ps://metrics.torproject.org/.[32] Tor network size. h�ps://metrics.torproject.org/networksize.html.[33] �e Tor Project. h�ps://www.torproject.org/.[34] Tao Wang and Ian Goldberg. On realistically a�acking Tor with website �nger-

printing. Proceedings on Privacy Enhancing Technologies, 2016(4):21–36, October2016.

[35] Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadi-anakis, Paul Syverson, and Roger Dingledine. Rendezvous single onion ser-vices, (Tor proposal 260. h�ps://gitweb.torproject.org/torspec.git/tree/proposals/260-rend-single-onion.txt, 2015.

[36] Ma�hew Wright, Micah Adler, Brian Neil Levine, and Clay Shields. Defendinganonymous communication against passive logging a�acks. In Proceedings, 2003IEEE Symposium on Security and Privacy, pages 28–43. IEEE Computer Society,May 2003.

A MODEL�e model we present is meant to �t within general models ofnetwork actors. Jaggard et al. [13] describe a more general modeland associated formal language. We focus here in se�ing out amodel speci�c to Tor and that is suitable for describing targetingadversaries. Adversaries are modeled in App. B.

A.1 EntitiesPrincipals P is the set of all principals. We think of these as

the individual humans using the system.• �ese may be mobile or using multiple Tor client in-

stances– For now, we assume that a change in location

by a principal implies a change in the clientinstance being used.

• �e principals are the ultimate targets of a�acks. Anatural simplifying step is to focus on a�acking Torclients instead of the principals using the clients. Do-ing so omits the consideration of a�acking a principalwho uses Tor in multiple locations because, in ourcurrent model, each location would have a di�erentclient.

• Principals might use multiple identities, e.g., via theNew Identity bu�on in the Tor Browser

Identities I is the set of all identities. An identity is any col-lection of actions or properties that might be tied togetherunder a pseudonym from some perspective. But unlike theusual usage of ‘pseudonym’, we consider the possibilitythat a single identity might include the behavior of multipleprincipals. In practice, we generally make the simplifyingassumption that relevant perspectives assign one princi-pal per identity. Clicking the New Identity bu�on in TorBrowser results in a new identity from the perspective ofa destination seeing prior and posterior connections fromthat client.

Clients CL is the set of Tor clients.• To simplify things, we assume that each client is used

by a single principal. As noted in the discussion ofprincipals, a single principal may use multiple Torclients.

Relays R denotes the set of all Tor relays.

https://blog.torproject.org/blog/lifecycle-of-a-new-relay

https://blog.torproject.org/blog/lifecycle-of-a-new-relay

https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt

https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt

https://github.com/torps/torps

https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-discovery.txt

https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-discovery.txt

https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt

https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt

https://blog.torproject.org/blog/some-thoughts-hidden-services

https://blog.torproject.org/blog/some-thoughts-hidden-services

https://www.facebook.com/notes/alec-muffett/rfc-7686-and-all-that/10153809113970962

https://www.facebook.com/notes/alec-muffett/rfc-7686-and-all-that/10153809113970962

https://www.torproject.org/about/torusers.html

https://metrics.torproject.org/

https://metrics.torproject.org/networksize.html

https://www.torproject.org/

https://gitweb.torproject.org/torspec.git/tree/proposals/260-rend-single-onion.txt

https://gitweb.torproject.org/torspec.git/tree/proposals/260-rend-single-onion.txt


Guards G denotes the set of all Tor guards. G ⊆ R. We useG for a set of guards used by an entity. We will assumethat each client chooses a single set G of guards from Gaccording to a distributionγ , which may be time dependent.More complex guard selection strategies are also possible.[10]

Middles M denotes the set of all Tor middle relays.M ⊆ RExits E is the set of Tor exit nodes. E ⊆ R.Circuits CIR is the set of Tor circuits.Destinations D is the set of destinations.Links L is the set of network links between relays, bridges,

clients, and destinations. We will consider only links be-tween clients and the Tor network or destinations and theTor network in this paper, and only abstractly. In practiceit can be further decomposed into ASes, ISPs, submarinecables, etc. [13]

Bridges We will not analyze the use of Tor bridges in thispaper, and include this entry only for readers who may bewondering about the omission.

Remark A.1 (Conventions). We typically use lowercase, italicizedle�ers for atomic individuals (e.g., a guard д), uppercase, italicizedle�ers for distinguished sets of atomic individuals (e.g., a principal’sguard set G), and uppercase, caligraphic le�ers for the set of allsuch possibilities (e.g., the set G of all guards).

A.2 Dynamics, history, and activityRoughly, we expect a principal to choose a client cl (possibly mul-tiple clients over time). Each client will have a distribution δ ondestinations (this may be inherited from the underlying principal).Given δ , the client will choose a distribution γ on 2G ; this may betime dependent. (We expect that γ will capture the various guard-selection procedures of interest. Its support may thus be limited toall sets of size k , etc..) �e guard set may change over time; indeed,the e�ect of temporal change is a question upon which this workwill shed light).

Once the client has chosen her guard set, she selects/receivesdestinations one at a time. We assume that the destination d isdrawn from D according to a distribution δ that depends on eitherthe principal or the client, depending on which type is the ultimatetarget of a�ack.1 For each destination, we assume that the clientselects an existing circuit or builds a new one; we assume thatthe circuit-selection and -construction decisions are made in anonline way, before the next destination is selected/received. Oncethe circuit (which we denote ci) is chosen/constructed, the clientand the destination exchange tra�c over the circuit. �is tra�cmay depend on the circuit and destination d , and we assume it istimestamped. As needed, we denote this tra�c by tr(cl, ci,d, t).

We capture this �ow as shown in Fig. 10, with right arrows denot-ing the sequence of events and le� arrows indicating randomizedchoices.

1δ could be enriched to model the fact that destinations might not be chosen indepen-dently of each other. One destination may induce tra�c to/from another destinationautomatically, or the tra�c may prompt the user to explore other destinations on herown, e.g., going to the Wikipedia page for a person mentioned in a news article thatshe reads. δ might then produce a set of destinations, each of which is fed into therest of the process modeled here.

We think of the history and current activity of the principal/clientas the primary things that an adversary might use in an a�ack. Asan initial step, we take the history and current activity to compriseinstances of:

• Circuit construction, including timestamps (and perhapssome portion of the circuit)

• Tor tra�c, including some projection of the information intr(cl, ci,d, t) (the projection may be di�erent for di�erentinstances of tra�c)

B ADVERSARIES AND THEIR GOALSB.1 AdversariesAdversaries will vary in the type of resources they control or ob-serve. �ey may observe or operate Tor relays, or they may observeall tra�c at an ISP or AS. �ey may observe all tra�c arriving ata speci�c destination. In addition they may have di�erent endow-ments of each type of resource, and they may vary in their goals.We will leave goals until a�er se�ing out the targets to which theymay direct those goals.

An adversary will be de�ned as a tuple of resources of the typesde�ned in the model, where each entry will re�ect the endowment,either as an absolute number or as a fraction. Elements in thetuple are not automatically independent or disjoint. For example,one element may re�ect the number of compromised guards andanother the number of compromised middles. How to handle suchwill depend on the needs of the analysis being done.

B.2 Targets and the pro�les they generateFor convenience, we let T be the set of possible adversary targets.2As we consider possible a�acks on targets, we will think of theadversary as having “pro�les” of his targets. We leave the formalde�nition of these to speci�c scenarios; broadly, we think of apro�le as comprising some combination of history and auxiliaryinformation such as identity, a�nity, etc..3 We consider I ⊂ T .�is is a proper subset because adversaries may be targeting acollection of identities and may be speci�cally targeting a collectionof principals, e.g., all the people who visit a particular website on agiven day or receive email from a particular identity.

We might consider pro�les generated by targets, e.g., P = P(T ).While again deferring formal de�nitions, this intuitively means thatall of the history in P was generated by T , and all of the auxiliaryinformation in P is about T . Of course, for a collection T ′ oftargets, we can generalize this to saying that a pro�le P concernsthis collection, wri�en P = P(T ′), if

P ⊆⋃T ∈T′

P(T ). (5)

Similarly, we will write A for ongoing network activity that theadversary might observe. Connecting this to speci�c targets raisesthe same issues raised by pro�les, so we will write A = A(T ) toindicate that activity is generated by a particular target T .

2It is natural to let this be the set of all principals or the set of all clients, but we donot want to restate this inclusiveness at every instance of discussing targets, nor dowe wish to rule out other collections of targets.3While we defer the formal de�nition of a pro�le, we note that it must admit a notionof containment so that we can meaningfully write P ⊆ P′.


p −→ cl −→ δ −→ γ −→ (Gγ←− 2G) −→ (d δ←− D) −→ ci −→ tr(cl, ci,d, t)

(4)

Figure 10: Activity �ow in our model.

B.3 Adversary goalsWe now set out some of the abstract goals a targeting adversarymay have.

Pro�le matching �e adversary has a pseudonymous pro-�le and is presented with new network activity; is thisactivity part of the pro�le (or how likely is it to be so)? I.e.,given P(T ) and A(T ′), does T = T ′?

Pro�le extension �e adversary has a user pro�le (not nec-essarily pseudonymous); can the adversary extend this toinclude additional information (perhaps of a speci�ed type).I.e., given P(T ), construct P ′(T ) ⊇ P(T ).

Knowledge gathering A client is identi�ed as being of in-terest; what else can the adversary learn about the client?I.e., given T , construct P(T ) (maybe also with some auxil-iary information Aux(T ) related to the target).

Group identi�cation Which people (or pseudonymous pro-�les) are behaving similarly, e.g., using the same services?(If “behaving similarly” is de�ned by some predicate, how isthe ease of answering this question related to the speci�cityof the predicate?) As one example, given a target T and apredicate P (maybe satis�ed by T ), describe {T ′ |P(T ′)} (ora nontrivial subset of this set).

Group enumeration Whether or not the individual targetsare known, it may be of interest to determine the exactor approximate size of a group target, |{T ′ |P(T ′)}|. �is isone of the goals considered in the body of this paper.

An example of a group target is a cabal with some properties incommon, e.g., meet together on Tuesdays at noon, all were on thesame high school sports team, etc.

As in earlier research, a primary goal is to associate source anddestination of communication. On the other hand, for a targetingadversary if the source or destination here is a target, other sources(respectively destinations) may be ignored as uninteresting. Othergoals also become salient for a targeting adversary. For example,group enumeration may be useful in itself as a measure of a grouptarget’s signi�cance. Other goals of interest may be similarly aboutnumbers rather than about source and destination correlation perse: the fraction of a source target’s connections devoted to di�erentcategories of activity, website downloads vs. cha�ing or bandwidthto route-unprotected sites vs. onionsites, etc.

C COMPUTATIONSC.1 Identifying an IRC cabal member

C.1.1 One-guard case. If the cabal leader is using one guard,then with probability B the leader will choose a compromised mid-dle relay during the �rst meeting, allowing the a�acker to learnthe leader’s guard. With probability pb , the a�acker will learn

the leader’s address. Alternatively, the leader does not use a com-promised middle relay for the �rst meeting (which happens withprobability 1−B, or with probability (1−B)i for the �rst i meetings)but then uses a compromised middle relay (with probability B) forthe second (or (i + 1)st) meeting. Once the compromised middlerelay is used, then the a�acker learns the leader’s address withprobability pb . We note that it only ma�ers when the leader �rstuses a compromised middle relay—the a�acker only has one chanceto “bridge” the leader’s guard; if she fails the �rst time, then weassume that she is not able to successfully bridge that guard ona later occasion that the leader uses a compromised middle relay.�us, we have that the probability of the adversary successfullybridging the cabal leader’s single guard is

Bpb + (1 − B)Bpb + · · · + (1 − B)m−1Bpb

=[1 − (1 − B)m

]pb . (6)

C.1.2 Three-guard case. We turn now to the case where eachclient uses three guards. Our approach parallels the one-guardcase, but the computations becomes more complex. We describe ageneral approach that works for any number of guards. �e sepa-rates out the adversary’s successful identi�cation of the client intodi�erent cases, depending on how many guards the adversary un-successfully bridges before successfully bridging one of the client’sguards. Together, the probability of success in these cases (up tothe total number of guards used by the client) gives the adversary’stotal probability of success.

In particular, we let Fnj (i), with i > 0, be the probability that theadversary makes her jth observation of a previously unseen guard imeetings a�er previously observing a new guard, that the leader isusing n guards total (and choosing from these uniformly at randomfor each meeting), and that the adversary fails to bridge this guard.�is involves the leader doing something other than both choosinga fresh guard (i.e., one the adversary has not previously a�emptedto bridge) and a compromised middle relay for i j −1 meetings (eachtime with probability 1 − n−j+1

n B), then choosing a fresh relay anda compromised middle guard (with probability n−j+1

n B), and thenthe adversary failing to bridge that guard (with probability 1 − pb ).�is gives

Fnj (i) =(1 − n − j + 1

nB

)i−1 n − j + 1n

B(1 − pb ). (7)

We also let Snj (m) denote the probability that the adversary suc-cessfully bridges the jth guard she observes and that she has mmeetings in which to do so (a�er trying and failing to bridge the(j − 1)st guard. �is involves the leader doing something other thanboth choosing a fresh guard and a compromised middle relay for kmeetings (each time with probability 1 − n−j+1

n B), 0 ≤ k ≤ m − 1,and then choosing a fresh guard and a compromised middle relay


(with probability n−j+1n B) and having the adversary bridge that

guard (with probability pb ). �is gives

Snj (m) =[1 −

(1 − n − j + 1

nB

)m ]pb . (8)

With this notation, we can concisely capture the probability ofsuccess for any number of guards д as

д∑k=1

∑0=i0<i1< · · ·<ik−1<m

Sдk (m − ik−1)

k−1∏j=1

Fдj (i j − i j−1). (9)

Here, k represents the guard that is successfully bridged, and i1,. . . , ik−1 are the meeting numbers at which the previous guards areidenti�ed but unsuccessfully bridged.

In the three-guard case, we obtain the following probability ofsuccess for identifying the leader of the cabal:

S31(m) +

∑1≤i1<m

F 31 (i1)S

32(m − i1)+∑

1≤i1<i2<mF 3

1 (i1)F32 (i2 − i1)S

33(m − i2). (10)

C.2 Guard collisionsWe show in Tab. 1 the probabilities of multiple clients sharing aguard for one and three guards per client and various cabal sizes.�is assumes 2,500 guards.

# Clients→ 3 5 10 20 251 guard/client 0.1% 0.4% 1.8% 7.3% 11.3%3 guards/client 1.1% 3.5% 15.0% 49.8% 66.4%

Table 1: Guard-collision probabilities for 2,500 guards, oneor three distinct guards per client, and various numbers ofclients.

D MLE COMPUTATIONSHere, we present more detail about the process of computing theMLE of cabal size.

First, we construct the function L(®x |θ ) capturing the likelihoodthat the adversary will make a sequence of observations ®x if theactual size of the cabal is θ . �is is 0 if any of the observationsis greater than θ . Otherwise, it is a ma�er of choosing, in the ithmeeting, xi cabal members to observe, observing each of them withprobability B, and not observing each of the θ − xi cabal memberswith probability 1−B. �is is done independently for each meeting,giving us

L(®x |θ ) =∏i

(θ

xi

)Bxi (1 − B)θ−xi , xi ≤ θ . (11)

We consider actual cabal sizes c ranging from 1 to 20. For eachc and each possible observation vector ®x that could be observedfor that cabal size (i.e., iterating over {0, . . . , c}m ), we computethe value θ (®x) that maximizes the likelihood function for ®x bynumerically testing values of θ up to 100. (If multiple values of θmaximize L(θ | ®x), we choose the smallest as θ (®x).) We also computethe probability, given the actual cabal size c , that ®x is observed bythe adversary.

Documents

Onions in the Crosshairs - arXivOnions in the Crosshairs When The Man really is out to get you Aaron D. Jaggard U.S. Naval Research Laboratory [email protected] Paul Syverson