<?xml-model href='http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng' schematypens='http://relaxng.org/ns/structure/1.0'?><TEI xmlns="http://www.tei-c.org/ns/1.0">
	<teiHeader>
		<fileDesc>
			<titleStmt><title level='a'>On the Complexity of Anonymous Communication Through Public Networks</title></titleStmt>
			<publicationStmt>
				<publisher></publisher>
				<date>07/25/2021</date>
			</publicationStmt>
			<sourceDesc>
				<bibl> 
					<idno type="par_id">10276676</idno>
					<idno type="doi"></idno>
					<title level='j'>2nd Conference on Information-Theoretic Cryptography (ITC 2021).</title>
<idno></idno>
<biblScope unit="volume">9</biblScope>
<biblScope unit="issue"></biblScope>					

					<author>Megumi Ando</author><author>Anna: Upfal Lysynskaya</author><author>Stefano Tessaro</author>
				</bibl>
			</sourceDesc>
		</fileDesc>
		<profileDesc>
			<abstract><ab><![CDATA[Onion routing is the most widely used approach to anonymous communication online. The idea is that Alice wraps her message to Bob in layers of encryption to form an “onion” and routes it through a series of intermediaries. Each intermediary’s job is to decrypt (“peel”) the onion it receives to obtain instructions for where to send it next. The intuition is that, by the time it gets to Bob, the onion will have mixed with so many other onions that its origin will be hard to trace even for an adversary that observes the entire network and controls a fraction of the participants, possibly including Bob. Despite its widespread use in practice, until now no onion routing protocol was known that simultaneously achieved, in the presence of an active adversary that observes all network traffic and controls a constant fraction of the participants, (a) anonymity; (b) fault-tolerance, where even if a few of the onions are dropped, the protocol still delivers the rest; and (c) reasonable communication and computational complexity as a function of the security parameter and the number of participants.In this paper, we give the first onion routing protocol that meets these goals: our protocol (a) achieves anonymity; (b) tolerates a polylogarithmic (in the security parameter) number of dropped onions and still delivers the rest; and (c) requires a polylogarithmic number of rounds and a polylogarithmic number of onions sent per participant per round. We also show that to achieve anonymity in a fault-tolerant fashion via onion routing, this number of onions and rounds is necessary. Of independent interest, our analysis introduces two new security properties of onionrouting – mixing and equalizing – and we show that together they imply anonymity.]]></ab></abstract>
		</profileDesc>
	</teiHeader>
	<text><body xmlns="http://www.tei-c.org/ns/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>Suppose that Alice wishes to send a message anonymously to Bob. Informally, by anonymously, we mean that no one (not even Bob) can distinguish the scenario in which Alice sends a message to Bob from an alternative scenario in which it is Allison who sends a message to Bob. To begin with, Alice can encrypt the message and send the encrypted message to Bob so that only Bob can read the message. However, an eavesdropper observing the sequence of bits coming out of Alice's computer and the sequence of bits going into Bob's computer can still determine that Alice and Bob are communicating with each other if the sequences of bits match. Thus, encryption is not enough.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.1">Problem setting</head><p>Before describing our results in detail, let us first define our problem setting. Let P def = {P 1 , P 2 , . . . , P N } denote the set of N parties, participating in an onion routing protocol. We assume that the protocol progresses in global rounds and that an onion sent at round r arrives at its destination prior to round r + 1. Moreover, the adversary is modelled with rushing, i.e., the adversary receives onions sent in round r instantaneously in round r. <ref type="foot">1</ref> We assume that the number N of participants and every other quantity in the protocol is polynomially bounded in the security parameter &#955;.</p><p>We define an onion routing protocol to be a protocol in which the honest parties form and process only message packets that are cryptographic onions. To do this, the honest parties use a secure onion encryption scheme which is a triple of algorithms: (Gen, FormOnion, ProcOnion).</p><p>See Section 2.1 for more details. During setup of an onion routing protocol, each honest party P generates a public-key pair (pk(P ), sk(P )) &#8592; Gen(1 &#955; ) using the onion encryption scheme's key generation algorithm Gen. Each party P publishes his/her public key pk(P ) to a public directory so that everyone knows everyone else's public keys.</p><p>Let M be the space of fixed-length messages. An input &#963; = (&#963; 1 , . . . , &#963; N ) to the protocol is a vector of inputs, where &#963; i is a set of message-recipient pairs for party P i . For m &#8712; M and P j &#8712; P, the inclusion of a message-recipient pair (m, P j ) in input &#963; i means that party P i is instructed to send message m to recipient P j . In this paper, we consider the following "benchmark" input space, dubbed the simple input/output setting (I/O). An input &#963; = (&#963; 1 , . . . , &#963; N ) is in the simple I/O setting if there exists a permutation function &#960; : P &#8594; P such that each party P &#8712; P is instructed to send a message to party &#960;(P ) and no other message, i.e., &#8704;P &#8712; P, &#8707;m P &#8712; M such that &#963; P = {(m P , &#960;(P ))}. The simple I/O setting is a superset of the spaces considered in prior works <ref type="bibr">[3,</ref><ref type="bibr">25,</ref><ref type="bibr">30,</ref><ref type="bibr">31]</ref>.</p><p>Unless stated otherwise, the adversary is active and can observe the traffic on all communication channels and, additionally, can non-adaptively corrupt and control a constant fraction of the parties. By non-adaptively, we mean that the corruptions are made independently of any protocol run.<ref type="foot">foot_1</ref> Without loss of generality, this type of corruption is captured by allowing the adversary to select the set Bad of corrupted parties prior to the beginning of the protocol run. Once the adversary corrupts a party, the adversary can observe the internal state and computations of the corrupted party and arbitrarily alter the behavior of the party. By V &#928;,A (1 &#955; , &#963;), we denote the view of the adversary A when it interacts with protocol &#928; on input: the security parameter 1 &#955; and the instructions &#963;. The view consists of all the observations that A makes during the run: the values and positions of every onion at every round, the states and computations of every corrupted party between every pair of consecutive rounds, the randomness used by A, and the numbers of messages received by the honest parties. The view does not include the honest parties' randomness. V &#928;,A,Bad (1 &#955; , &#963;) denotes A's view given its choice Bad for the corrupted parties. At the end of the protocol run, each honest party P i outputs the set O &#928;,A i (1 &#955; , &#963;) of (non-empty) messages from the message space M that P i receives from interacting with adversary A in a run of protocol &#928; on input &#963;. We define the output O &#928;,A (1 &#955; , &#963;) of protocol &#928; in an interaction with adversary A on input &#963; as the N parties' outputs: <ref type="foot">3</ref> </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.2">Our results</head><p>We now describe our results. Our construction pertains to the problem setting described in Section 1.1. Our lower bound applies more generally to any arbitrary input set (not necessarily constrained to the simple I/O setting). Following prior work <ref type="bibr">[3,</ref><ref type="bibr">25,</ref><ref type="bibr">30,</ref><ref type="bibr">31]</ref>, we use a natural game-based definition of anonymity: a protocol is anonymous if the adversary cannot distinguish the scenario in which Alice sends a message to Bob while Carol sends one to David, from one in which Alice's message goes to David while Carol's goes to Bob; (see <ref type="bibr">Definition 4)</ref>. More precisely, for any pair of inputs (&#963; 0 , &#963; 1 ) that agree on the inputs and outputs for the adversarial participants, O &#928;,A (1 &#955; , &#963; 0 ) &#8776; O &#928;,A (1 &#955; , &#963; 1 ), where "&#8776;" denotes indistinguishability.</p><p>We relate anonymity of an onion routing protocol to two new concepts: An onion routing protocol mixes if it sufficiently shuffles the honest users' onions making it infeasible for the adversary to trace a received message back to its sender. A protocol equalizes if the adversary cannot determine the input from the numbers of messages received by the parties; in other words, the number of messages output by each participant -or the fact that a participant did not receive an output at all -are random variables that are computationally unrelated to the input vector &#963;. (See Definitions 5 and 7.)</p><p>We show that in many cases, mixing and equalizing implies anonymity, i.e., an onion routing protocol that mixes and equalizes is anonymous. (See Theorem 3 for the formal theorem statement.) We use this to prove that our protocol is anonymous. Anonymity also implies equalizing; this observation is useful for proving a lower bound that (almost) matches our protocol.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.2.1">Anonymous, "robust," and efficient onion routing</head><p>As we just explained, our strategy is to construct a protocol that mixes and equalizes.</p><p>Intuitively, mixing is the easier one to achieve: the onions need to sufficiently shuffle with other onions traveling over the network to ensure that each of them is hard to trace. This intuition is essentially correct with the caveat that an active adversary can strategically interfere with this process by dropping onions. To ensure that each onion shuffles with a sufficiently large number of onions (formed by an honest party) a sufficiently large number of times, our protocol uses checkpoint onions <ref type="bibr">[3]</ref> that each intermediary expects to receive, and if a constant fraction (e.g., one-third) of them don't arrive because the adversary dropped them, the protocol aborts.</p><p>An active adversary who controls a fraction of the participants can try to "isolate" an honest party Alice from the rest of the network by dropping all of the messages/onions received directly from Alice. In a fault-tolerant network protocol, the remaining participants may still be able to get their messages through to their destinations. In this case, based on who received an output, an adversary can infer who Alice's intended recipient was. This attack explains why equalizing is difficult to achieve.</p><p>To overcome this attack, we introduce a new type of onions, called merging onions. When two merging onions belonging to the same pair arrive at some intermediary I, I recognizes that they are from the same pair (although, other than their next layer and destination, I does not learn anything else about them). The protocol directs I to discard one of them (denoted, pp) and the parties' states (denoted, states). Thus, we could be more precise by denoting the view and the output as V &#928;,A (1 &#955; , pp, state, &#963;) and O &#928;,A (1 &#955; , pp, states, &#963;), but we will use the simpler notation for better readability.</p><p>(chosen at random) while sending its mate along. If only one onion of the pair arrived at I while its mate is missing (i.e. the adversary dropped it some time earlier in the protocol run), then I simply sends along the mate that survived, and there is nothing to discard.</p><p>Why does this help? Suppose that both Alice and Allison created 2 h merging onions; at rounds r 1 , r 2 , . . ., r h each of these onions (if it hasn't been deleted yet) will meet a mate. Say, exactly one of Alice's onions is dropped by the adversary at some point prior to round r 1 , so its mate (the onion it was supposed to pair with at round r 1 ) was not dropped. Also, suppose that none of Allison's onions were dropped. Then at round r 1 all but one of Alice's remaining merging onions will meet a mate, and half of them will be dropped, so exactly 2 h-1 of Alice's onions will remain in the system -which is exactly how many of Allison's onions remain. Additional h -1 opportunities to merge account for the possibility that the adversary has dropped a larger number of Alice's onions. Merging onions ensure that the number of Alice's onions that remain in the system at the end of the protocol is the same as the number of Allison's onions, i.e., that the protocol equalizes. The fact that Alice was targeted and many of her onions had been dropped upfront doesn't matter because the protocol discards all but one of them anyway! (See Section 4 for a more in-depth description of merging onions and how to construct them.)</p><p>Positive result. We construct an onion routing protocol &#928; &#9655;&#9665; , pronounced "Pi-butterfly," because it uses a butterfly network. &#928; &#9655;&#9665; takes advantage of the merging onions technique described above. It is (a) anonymous from the active adversary who can corrupt up to a constant fraction &#954; &lt; 1 2 of the parties and (b) robust, i.e. whenever the adversary drops at most logarithmic (in the security parameter) number of message packets (i.e. onions), &#928; &#9655;&#9665; delivers the messages from honest senders with overwhelming probability. Moreover, (c) during the execution of the protocol, every honest party transmits up to a polylog (in the security parameter) number of onions: specifically &#947; 1 log N log 3+&#947;2 &#955; onions, where N is the number of participants, and &#955; is the security parameter. &#947; 1 and &#947; 2 are parameters that can be set as desired: increasing them increases the rate at which the maximum distance in the adversarial views for any two inputs shrinks. (See Theorem 12 for the precise relationship.)</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.2.2">Matching negative result</head><p>Our protocol is essentially optimal as far as both the round complexity and the number of onions each participant sends out are concerned. In Section 7, we explain why a protocol that is anonymous and robust in the presence of an active adversary that corrupts a constant fraction of participants requires a polylogarithmic number of onions sent out per participant.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.3">Related work</head><p>Our work is inspired by the fact that Tor <ref type="bibr">[18]</ref>, the most widely adopted anonymous communication system, is also known to have numerous security flaws <ref type="bibr">[23,</ref><ref type="bibr">27,</ref><ref type="bibr">29,</ref><ref type="bibr">32]</ref>: Tor is based on a highly efficient design that favors practicality over security and is not secure even from the passive adversary <ref type="bibr">[17]</ref>. Moreover, it has been shown to be vulnerable to network traffic correlation attacks <ref type="bibr">[23,</ref><ref type="bibr">27,</ref><ref type="bibr">29,</ref><ref type="bibr">32]</ref>. Thus, our goal was to design a protocol that was as close to Tor's efficiency and fault tolerance as possible, while also being provably anonymous. We consider a very specific and narrow problem in the much larger field of anonymous messaging systems. Although our definition of anonymity and adversary models are standard in cryptography, other definitions have been considered <ref type="bibr">[1,</ref><ref type="bibr">5,</ref><ref type="bibr">6,</ref><ref type="bibr">10,</ref><ref type="bibr">19]</ref> and positive results for alternative models are known <ref type="bibr">[4]</ref><ref type="bibr">[5]</ref><ref type="bibr">[6]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I T C 2 0 2 1</head><p>Other provably anonymous systems exist <ref type="bibr">[12,</ref><ref type="bibr">14,</ref><ref type="bibr">15,</ref><ref type="bibr">28]</ref>, but they are not nearly as efficient. Achieving anonymous channels using heavier cryptographic machinery has been considered also. One of the earliest examples is Chaum's dining cryptographer's protocol <ref type="bibr">[12]</ref>. Rackoff and Simon <ref type="bibr">[28]</ref> use secure multiparty computation for providing security from active adversaries. Other cryptographic tools used in constructing anonymity protocols include oblivious RAM (ORAM) and private information retrieval (PIR) <ref type="bibr">[14,</ref><ref type="bibr">15]</ref>. Corrigan-Gibbs et al.'s Riposte solution makes use of a global bulletin board with a latency of days <ref type="bibr">[15]</ref>.</p><p>We are not the first to look into lower bounds on the complexity of anonymous messaging protocols (e.g., <ref type="bibr">[13,</ref><ref type="bibr">17]</ref>). However, all other lower bounds are for the setting where every participant is guaranteed to receive an output, and don't apply to protocols that allow aborts or that allow some participants to receive an output while others' output doesn't make it through.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Preliminaries</head><p>For a set S, we denote the cardinality of S by |S|, and s &#8592;$ S denotes that s is chosen from S uniformly at random. For an algorithm A(x), y &#8592; A(x) is the (possibly probabilistic) output y from running A on the input x. In this paper, log(x) is the logarithm of x base 2. We say that a function f : N &#8594; R is negligible in the parameter &#955;, written f (&#955;) = negl(&#955;), if for a sufficiently large &#955;, f (&#955;) decays faster than any inverse polynomial in &#955;. When &#955; is the security parameter, an event E &#955; is said to occur with (non-)negligible probability if the probability of E &#955; can(not) be bounded above by a function negligible in &#955;. An event occurs with overwhelming probability (abbreviated, w.o.p.) if its complement occurs with negligible probability. We use the standard notion of a pseudorandom function <ref type="bibr">[20,</ref><ref type="bibr">Chapter 3.6</ref>].</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">Onion encryption schemes</head><p>Our work on onion routing builds upon a secure onion encryption scheme [2, <ref type="bibr">7,</ref><ref type="bibr">24]</ref>. Recall that an onion encryption scheme is a triple: (Gen, FormOnion, ProcOnion). The algorithm Gen generates a participant key pair, i.e., a public key and a secret key. The algorithm FormOnion forms onions, and the algorithm ProcOnion processes onions.</p><p>Let P be a set of participants, and let Bad &#8838; P be the set of corrupt parties. For every honest P &#8712; P \ Bad, let (pk(P ), sk(P )) &#8592; Gen(1 &#955; , pp, P ) be the key pair generated for party P , where &#955; is the security parameter, and pp, the public parameters. For every corrupt party P &#8712; Bad, let pk(P ) denote P 's public key. Let M be the message space consisting of messages of the same fixed length, and let the nonce space S consist of nonces of the same fixed length. These lengths may be a function of the security parameter &#955;. Here, a nonce is really any metadata associated with an onion layer.</p><p>FormOnion takes as input a message m &#8712; M, an ordered list (Q 1 , . . . , Q d-1 , R) of parties from P, the public keys (pk(Q 1 ), . . . , pk(Q d-1 ), pk(R)) associated with these parties, and a list (s 1 , . . . , s d-1 ) of (possibly empty) nonces from S associated with the layers of the onion. <ref type="foot">4</ref>The party R is interpreted as the recipient of the message, and the list</p><p>is the routing path. The output of FormOnion is a sequence (O 1 , . . . , O d ) of onions. Such a sequence is referred to as an evolution, but every O i in the sequence is an onion. Because it is convenient to think of an onion as a layered encryption object where processing an onion O i produces the next onion O i+1 , we sometimes refer to the process of revealing the next onion as "decrypting the onion" or "peeling the onion."</p><p>For every i &#8712; [d -1], only intermediary party In our constructions, a sender of a message m to a recipient R "forms an onion" by generating nonces and running the FormOnion algorithm on the message m, a routing path (Q 1 , . . . , Q d-1 , R), the keys (pk(Q 1 ), . . . , pk(Q d-1 ), pk(R)) associated with the parties on the routing path, and the generated nonces; the formed onion is the first onion O 1 from the list of outputted onions.</p><p>Secure onion encryption. Suppose that (honest) Alice generates an onion carrying a message m for Bob. That is, she generates a string of nonces and runs the algorithm FormOnion on the inputs: the message m, the routing path (Q 1 , . . . , Q i-1 , I, Q i+1 , . . . , Q d-1 , Bob), the public keys associated with the routing path, and the nonces. Let O denote the onion for intermediary party I, i.e., O is the i th onion in the outputted evolution. Suppose that (honest) Carol runs the algorithm FormOnion on the inputs: the message m &#8242; , the routing path</p><p>, David), the public keys associated with the routing path, and some nonces. Let O &#8242; denote the onion for intermediary party I. Provided that the onion encryption scheme is secure, if party I receives onions O and O &#8242; in the same round and consequently processes the two onions in the same batch, then the adversary cannot tell which processed onion resulted from processing O and which resulted from processing O &#8242; . In other words, onions formed by honest parties "mix" at honest parties. For a precise, cryptographic definition of secure onion encryption, see the recent paper by Ando and Lysyanskaya [2].</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.2">Onion routing protocols</head><p>In an onion routing protocol, all the packets sent between protocol participants are treated as onions; i.e., upon receipt, they are fed to ProcOnion. Moreover, internally, there are type checks that ensure that these onions are processed properly. There are two cases for processing an honestly formed onion properly: the case where peeling the onion reveals its next layer and destination and the case where it reveals a message for the processing party.</p><p>If Q i runs ProcOnion and outputs the next layer of the onion O i+1 (together with its destination Q i+i and nonce s i+1 ), then the only two options for what an onion routing protocol permits</p><p>Which of these actions are taken depends on the specifics of the algorithm and also on the values (Q i+1 , s i+1 ). In other words, an onion routing protocol cannot have an onion sent to incorrect destinations or fed as input to another algorithm.</p><p>Further, if Q i runs ProcOnion and outputs a message m &#824; = &#8869;, then this message becomes (ultimately, at the end of the protocol) part of Q i 's output, i.e., it will be on the list of messages that have been sent to Q i . In other words, m cannot be internal to the protocol; it must be a message that someone sent to Q i via the protocol. Conversely, the only way that a message m can be on the list of messages received by Q i is if Q i obtained it by peeling one of the onions it received.</p><p>These restrictions on protocol design are natural. Indeed, any implementation of onion routing would ensure that it is adhered to by using type checking of the objects created, sent, and processed by the algorithm. Without such a restriction, any protocol can be thought of I T C 2 0 2 1 9:8</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>On the Complexity of Anonymous Communication Through Public Networks</head><p>as an instance of onion routing protocol, so limiting our attention in this way is meaningful. Note that this places restrictions just on the protocol that the honest parties are executing; the adversary is still free to do anything he wishes: to mismatch types, to route onions incorrectly, to try to rewrap onions, to form and process onions adversarially, etc.</p><p>Onion routing serves a purpose: to route messages from senders to recipients. Therefore, it needs to satisfy correctness:</p><p>&#9654; Definition 1 (Correctness). A messaging protocol &#928; is correct if in an interaction with a passive adversary, it delivers all the messages with overwhelming probability.</p><p>In this paper, we will consider only correct onion routing protocols, but we will analyze their interactions with active adversaries.</p><p>Further, the protocols we design in this paper have an additional attractive property of being indifferent:</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>&#9654; Definition 2 (Indifference). An onion routing protocol &#928; is indifferent if two properties hold: (i) The routing path corresponding to each honestly formed onion is of a fixed length. (ii) The sequence of intermediaries, including the recipients of dummy onions, and the sequence of nonces corresponding to each honestly formed onion do not depend on the input.</head><p>The intuition behind this notion is that the contents of the messages sent and received between parties have no bearing on how the messages are routed and transmitted. For protocol design, indifference is an attractive property that allows components of an onion to be in place (and possibly the bulk of the cryptographic computation finished) before the message contents even becomes known. Another attractive feature of indifferent protocols is that their security properties are easier to analyze, as we will explore in the next section. Our negative results apply to all onion routing schemes, indifferent or not.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>3</head><p>Security definitions: anonymity, equalizing, and mixing A motivating example. Consider Ando, Lysyanskaya, and Upfal's very simple protocol &#928; p (p, for passive) in the passive adversary setting <ref type="bibr">[3]</ref>. Recall that corrupted parties also follow the protocol in this setting. Let Servers &#8838; P be the set of servers which is a subset of P. During the onion-forming phase, every party P generates an onion from the messagerecipient pair (m, R) in P 's input by first choosing d -1 servers (S 1 , . . . , S d-1 ), each chosen independently and uniformly at random from Servers. Next, P forms an onion O by running FormOnion on the message m, the routing path P &#8594; = (S 1 , . . . , S d-1 , R), the public keys associated with P &#8594; , and the sequence of empty nonces. At the first round of the execution phase, each party P sends its formed onion O to the first server S 1 on the routing path. For every round r &#8712; [d], each server S does the following: Between the r th and (r + 1) st rounds, S processes all the onions it received at the r th round. At the (r + 1) st round, S sends the processed onions to their respective next destinations. At the d th round, each party receives an onion that, once processed, reveals a message m for the party. &#928; p is anonymous if the protocol sufficiently shuffles the onions during the execution phase. In prior work <ref type="bibr">[3]</ref>, Ando, Lysyanskaya, and Upfal showed that sufficient shuffling occurs when the server load (i.e., the average number of onions received by a server at a round: N |Servers| ) and the number of rounds (i.e., d) are both superlogarithmic in the security parameter. However, there is no parameter setting for which &#928; p can be anonymous from the active adversary. If &#954;N out of N participants are corrupted, then with probability &#954;, the adversary can determine the recipient of any honest party, say Alice: Suppose that during 9:9 the onion-forming phase, Alice picks a routing path that begins with an adversarial party S 1 . During the execution phase, the adversary can direct S 1 to drop Alice's onion before the second round. In this case, the adversary can figure out who Alice's recipient is (say, it's Bob) by observing who does not receive an onion at the end of the protocol run.</p><p>The motivating example illustrates that while mixing (i.e. sufficiently shuffling onions) is helpful for achieving anonymity, it is not enough. To be anonymous, the protocol must also guarantee that the numbers of messages received by the parties don't reveal the input. We call this property, equalizing.</p><p>Here, we provide formal game-based definitions of anonymity (Section 3.1), equalizing (Section 3.2), and mixing (Section 3.3). Given these definitions, it can be shown that for indifferent onion routing protocols, equalizing and mixing imply anonymity:</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>&#9654; Theorem 3. For any adversary class A, an indifferent (Definition 2) onion routing protocol that mixes and equalizes for A in the simple I/O setting is anonymous for A in the simple I/O setting, provided that the underlying onion encryption is secure (i.e., UC-realizes the ideal functionality for onion encryption [2]).</head><p>We omit the proof for brevity. We will use Theorem 3 to prove our upper bound in Section 6.3.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Anonymity</head><p>Anonymity is a property of a messaging protocol &#928; (i.e., &#928; doesn't have to be an onion routing protocol).</p><p>In the anonymity game (for defining anonymity), the adversary necessarily learns the corrupt parties' inputs and received messages. For example, let N = 4, and let P 3 be a corrupt party. Suppose that the adversary chooses as inputs &#963; 0 = (&#963; 0 1 , &#963; 0 2 , &#963; 0 3 , &#963; 0 4 ) and</p><p>Then, the adversary can determine the input from P 3 's input. Suppose that the adversary chooses as inputs &#963; 0 and &#963; 1 such that &#963; 0 contains an instruction to send message m 0 to P 3 , whereas &#963; 1 contains an instruction to send message m 1 &#824; = m 0 to P 3 . Then, the adversary can determine the input from P 3 's received message. Thus, the adversary's choice for (&#963; 0 , &#963; 1 ) is constrained to pairs of inputs that differ only in the honest parties' inputs and "outputs."</p><p>We define this formally by first defining equivalence classes for inputs as follows. Let &#931; be a set of input vectors. Let A be the adversary, and let Bad be the set of parties controlled by A. Fixing Bad imposes an equivalence class on &#931;. Each equivalence class is defined by a vector (e 1 , e 2 , . . . , e N ). For each corrupted party P i &#8712; Bad, e i = (&#963; i , M i ) "fixes" the input &#963; i for P i and also, the set M i of messages instructed to be sent from honest parties to P i . For each honest party P i &#8712; P \ Bad, e i = V i "fixes" the number V i of messages instructed to be sent from honest parties to P i . An input vector belongs to the equivalence class (e 1 , e 2 , . . . , e N ) if for every P i &#8712; Bad, the input for P i is &#963; i , the set of messages from honest parties to P i is M i , and e i = (&#963; i , M i ); and if for every P i &#8712; P \ Bad, the number of messages from honest parties to P i is V i , and e i = V i . Two input vectors &#963; 0 and &#963; 1 are equivalent w.r.t. the adversary's choice Bad for the corrupted parties, denoted &#963; 0 &#8801; Bad &#963; 1 , if they belong to the same equivalence class imposed by Bad.</p><p>We now describe the anonymity game (below); the protocol &#928; is anonymous if this induces indistinguishable adversarial views.</p><p>The anonymity game. AnonymityGame(1 &#955; , &#928;, A, &#931;) is parametrized by the security parameter 1 &#955; , a protocol &#928;, an adversary A, and a set &#931; of input vectors.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I T C 2 0 2 1 9:10</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>On the Complexity of Anonymous Communication Through Public Networks</head><p>First, the adversary A and the challenger C set up the parties' keys: A chooses a subset Bad &#8838; P of the parties to corrupt and sends Bad to the challenger C. For each honest party in P \ Bad, C generates a key pair for the party; the public keys pk(P \ Bad) of the honest parties are sent to A. A picks the keys for the corrupted parties and sends the corrupted parties' public keys pk(Bad)) to C.</p><p>Next, the input is selected: A picks two input vectors &#963; 0 , &#963; 1 &#8712; &#931; such that &#963; 0 &#8801; Bad &#963; 1 and sends them to C. C chooses a random bit b &#8592;$ {0, 1} and interacts with A in an execution of protocol &#928; on input &#963; b with C acting as the honest parties adhering to the protocol and A controlling the corrupted parties.</p><p>At the end of the execution, A computes a guess b &#8242; for b from its view V &#928;,A,Bad (1 &#955; , &#963; b ) and wins the anonymity game if b &#8242; = b.</p><p>The standard notion of anonymity is defined as follows: </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Equalizing</head><p>Here, we introduce a new concept called equalizing, which is closely related to anonymity. Like anonymity, equalizing is a property of a messaging protocol &#928;.</p><p>Informally, &#928; equalizes if observing how many messages each party received during the protocol run does not reveal whether the protocol ran on &#963; 0 or &#963; 1 . In &#928; p (in our motivating example), whether Bob receives a message or not exposes who was sending Bob the message: Alice or another party, Allison; so &#928; p does not equalize. Instead, in an equalizing protocol, the probability that Bob receives a message doesn't depend on the sender's identity. Put another way, Bob is expected to receive the same number of messages in the scenario where Alice is the sender as the one where it is Allison. Formally, equalizing is defined with respect to the equalizing game (below).</p><p>The equalizing game. EqualizingGame(1 &#955; , &#928;, A, D, &#931;) is parametrized by the security parameter 1 &#955; , a protocol &#928;, an adversary A, a distinguisher D, and a set &#931; of input vectors.</p><p>The challenger for the equalizing game first interacts with the adversary exactly the same way as the challenger for the anonymity game. (See the previous section, Section 3.1, for the description of the anonymity game.) Recall that at the end of the anonymity game, each honest party P r outputs the set O &#928;,A r (1 &#955; , &#963; b ) of (non-empty) messages from the message space M that it obtained during the execution from processing onions. Let v r be the number of messages that P r received during the run, i.e., v</p><p>(These statistics are part of the adversary's view in the anonymity game.)</p><p>We define the statistics for the corrupt parties differently since C does not get to observe how many messages the corrupt parties output; indeed it is not even clear what it means for a corrupt party to produce an output. For each recipient P r &#8712; Bad, let v r correspond to the number of onions that C has routed to an adversarial participant P &#8242; such that (1) they had been formed by an honest participant with P r as the recipient; and (2) all the participants after P &#8242; on the remainder of this onion's route are controlled by the adversary. In other words, v r is the number of onions from honest participants that P r would receive if, internal to the adversary, all the onions are processed and delivered to their next destinations. We define this formally below.</p><p>Let msPairs(P r ) denote the set of message-sender pairs for P r . That is, for every (m, P s ) &#8712; msPairs(P r ), the input &#963; s for P s includes the message-recipient pair (m, P r ), i.e., (m, P r ) &#8712; &#963; s . Let receivableOnions(P r ) be the following set of onions: An onion O is in receivableOnions(P r ) if there exists a message-sender pair (m, P s ) &#8712; msPairs(P r ) such that i. O was formed by C (on behalf of P s ) by running FormOnion on input the message m, a routing path For each adversarial recipient P r &#8712; Bad, we define the statistic v r to be the number of onions in receivableOnions(P r ) that the challenger sent out during the execution.</p><p>Let v = (v 1 , v 2 , . . . , v N ). C provides these statistics v alone (and not the rest of the view) to the distinguisher D, who outputs a guess b &#8242; for the challenge bit and wins the game if b &#8242; = b, i.e. if it correctly determines whether the challenger ran the protocol on input &#963; 0 or &#963; 1 . The definition for equalizing is as follows:</p><p>&#9654; Definition 5 (Equalizing). A messaging protocol &#928;(1 &#955; , pp, states, $, &#963;) equalizes for the adversary class A w.r.t. the input set &#931; if for every adversary A &#8712; A and distinguisher D, D wins EqualizingGame(1 &#955; , &#928;, A, D, &#931;) with negligible advantage, i.e., Pr D wins EqualizingGame(1 &#955; , &#928;, A, D, &#931;) -1 2 = negl(&#955;).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>The protocol computationally (resp. statistically) equalizes if the adversaries and the distinguishers are computationally bounded (resp. unbounded).</head><p>Clearly, a protocol that satisfies anonymity must equalize: &#9654; Theorem 6. For any adversary class A, a protocol that is anonymous for A w.r.t. the input set &#931; equalizes for A w.r.t. &#931;.</p><p>Proof. If D can guess b based on the statistics v alone, then the adversary A who has access to the entire view of its interaction with C can guess b also. (It is also easy to see that a protocol need not satisfy anonymity in order to satisfy equalizing. Thus, equalizing is necessary but not sufficient to achieve anonymity.) &#9664;</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">Mixing in the simple I/O setting</head><p>Mixing is a property of onion routing protocols. Informally, an onion routing protocol mixes if the protocol sufficiently shuffles the honest parties' "message-bearing" onions. That is, once an honestly generated onion has traveled far enough, getting peeled at every intermediary, the adversary cannot trace it to the original sender. If the adversary is the recipient of the message contained in the onion, it should not be able to trace it to the sender provided the message itself does not reveal the sender. Formally, mixing is defined with respect to the mixing game. To keep things simple, we present the definition in the simple I/O setting, but this can be extended to any arbitrary input set.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I T C 2 0 2 1 9:12</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>On the Complexity of Anonymous Communication Through Public Networks</head><p>The mixing game. Let OE = (Gen, FormOnion, ProcOnion) be a secure onion encryption scheme. MixingGame(1 &#955; , &#928;, A) is parametrized by the security parameter 1 &#955; , an onion routing protocol &#928;, and an adversary A.</p><p>First, the adversary A and the challenger C set up the parties' keys (exactly as we described above for the anonymity game): A chooses a subset Bad &#8838; P of the parties to corrupt and sends Bad to C. For each honest party in P \ Bad, C generates a key pair for the party by running the onion encryption scheme's key generation algorithm Gen and sends the public keys pk(P \ Bad) of the honest parties to the adversary A. A picks the keys for the corrupted parties and sends the public-key portions pk(Bad) to C.</p><p>Next, the input is selected: A identifies a set S &#8838; P \ Bad of honest target senders and a set R &#8838; P, |R| = |S| of target receivers. In addition to S and R, A also decides part of the input; for every non-target sender P s &#8712; P \ S, A chooses a message m and a unique non-target recipient P r &#8712; P \ R such that P s 's input becomes &#963; s = {(m, P r )}; and for every target recipient P r &#8712; R, A chooses a message m r to be sent to P r . We call the portion of the input that A decides "the partial input vector," and denote it &#963;. A sends (S, R, &#963;) to the challenger C. C supplies the rest of the input vector &#963; = (&#963; 1 , . . . , &#963; N ) by choosing a random bijection g from S to R; each P s &#8712; S is instructed to send the message m g(Ps) to g(P s ) &#8712; R, i.e., &#963; s = {(m g(Ps) , g(P s )} where the message m g(Ps) was supplied by A as part of the partial input vector.</p><p>Next, C interacts with A in an execution of protocol &#928; on input &#963; with C acting as the honest parties adhering to the protocol and A controlling the corrupted parties. Whenever the protocol &#928; specifies for an onion to be formed or processed, C runs the onion encryption scheme's onion-forming algorithm FormOnion or onion-processing algorithm ProcOnion.</p><p>Let O R be the set of onions received by the parties in R.</p><p>At the end of the execution, A chooses two onions O s , O s &#8712; O R and a target sender P s &#8712; S and outputs (O s , O s, P s ).</p><p>Let an onion O be a "valid challenge onion" if (i) there exists a message m r &#8712; M and a target recipient P r &#8712; R such that m r is A's choice for the message to be sent to P r , and (ii) O is the last onion to be received by the recipient over the network in the onion evolution generated by C on behalf of one of the target senders running FormOnion on the message m r and a routing path ending in P r .</p><p>Let sender(O s ) be the sender of O s , and let sender(O s) be the sender of O s. To maximize his chances of winning the game, the adversary wants both O s and O s to be valid challenge onions such that O s was sent by P s , while O s was not. Formally, if A chose two valid challenge onions, and {P s } &#8834; {sender(O s ), sender(O s)} &#8838; S, then A wins iff P s = sender(O s ). Otherwise, if A did not choose two valid challenge onions, or if {P s } &#824; &#8834; {sender(O s ), sender(O s)} or {sender(O s ), sender(O s)} &#824; &#8838; S, then A wins with probability one-half. See Figure <ref type="figure">1</ref> for a quick reference to the mixing game.</p><p>We now define mixing as follows.</p><p>&#9654; Definition 7 (Mixing). An onion routing protocol &#928;(1 &#955; , pp, states, $, &#963;) mixes conditioned on the event E for the adversary class A if given E, every adversary A &#8712; A wins MixingGame(1 &#955; , &#928;, A) with negligible advantage, i.e.,</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>The protocol computationally (resp. statistically) mixes if the adversaries in A are computationally bounded (resp. unbounded).</head><p>Now that we have defined mixing formally, let us walk the reader through our definitional choices. The starting intuition is that this definition needs to capture that it should be hard for the adversary to pinpoint the origin of an onion received by one of the target recipients. This goal comes with a caveat that of course an adversary can determine the sender of an onion that one of the target senders has just created, or, more generally, that hasn't traveled very far and hasn't had a chance to mix with any onions from other target senders. Hence, we need to restrict the set of onions on which the adversary can win to a set of onions that have traveled far and have already had a chance to mix with other onions. This is why we have the requirement that the onion be a valid challenge onion. Intuitively, a valid challenge onion is one that was formed by a target sender and has already arrived at its destination, a target recipient, and now the adversary's job is to figure out where it came from.</p><p>Next, let us explain why, to win the game, the adversary must produce two valid challenge onions, and correctly attribute one of them to a sender P s , while the other must have originated with another target sender. What does it mean that the adversary cannot trace an onion? One intuitive approach would be to say: the adversary's chances of winning the game where he picks just one onion and guesses its origin are close to a simulator's chances of winning a game where he just guesses a sender, and the challenger picks the onion uniformly at random and independently of the simulator's guess. The problem with this approach is that we don't know the best strategy for such a simulator and with what probability it would succeed. So our approach is to have the adversary pick a sender and two onions. "Mixing" means that, if it so happens that exactly one of them comes from P s and the other comes from another target sender, then try as he may, the adversary cannot tell which is which any better than by guessing randomly; and if it doesn't happen that way, then the adversary wins with probability one-half.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Main tools: checkpoint onions and merging onions</head><p>We describe the main ingredients for our constructions: checkpoint onions (a tool that was introduced in prior work <ref type="bibr">[3]</ref>) and a new tool: merging onions. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.1">Checkpoint onions</head><p>Our goal is to achieve anonymity by ensuring that our protocol mixes and equalizes in the presence of an active adversary that drops onions. The challenge is: if the adversary drops too many onions, then the remaining ones don't have enough onions to mix with, and so the resulting protocol will not mix. Checkpoint onions give the honest participants a way of checking that there are still enough onions in the system for mixing to be possible.</p><p>A checkpoint onion O is a dummy onion (containing the empty message &#8869;) formed by a party P that travels through the network until, at a pre-determined checkpoint round r, it arrives at the intermediary I, who is expecting it. If it fails to arrive, then I is alerted to the activity of an active adversary. More precisely, let F &#8226; (&#8226;, &#8226;) be a pseudo-random function over two inputs, keyed by sk(P, I) which is a secret key shared between P and I. Let b be a binary predicate. Let D be the diagnostic rounds; the honest parties test whether enough onions remain in the system after these rounds. For each intermediary I and each round r &#8712; D, P determines whether or not to create a checkpoint onion that will arrive at I at round r by computing f = F (sk(P, I), (r, 0)) and then checking if b(f ) = 1; if so, P creates this checkpoint onion. Similarly, the intermediary I will know to expect a checkpoint onion from P at round r by computing f = F (sk(P, I), (r, 0)) and then checking if b(f ) = 1.</p><p>P forms O by running FormOnion on input the empty message &#8869;, a randomly chosen routing path P &#8594; = (I 1 , . . . , I d ), the public keys associated with parties on P &#8594; , and a sequence (s 1 , . . . , s d-1 ) of nonces. The nonce s r which will be received by I, is the value that I will know to expect: s r = F (sk(P, I), (r, 1)); the rest are random nonces. The reason that I will know to expect s r is that I can compute it too, since sk(P, I) is shared between P and I. Of course, the shared key sk(P, I) need not be set up in advance: it can be generated from an existing PKI, e.g., using Diffie-Hellman.</p><p>If the adversary drops an onion belonging to the same evolution as O before it reaches I, I will detect it: it will detect that no onion with nonce s r was received in round r. (Since F is pseudorandom, it is highly unlikely that another onion peels to the same nonce value.)</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.2">Merging onions</head><p>Checkpoint onions help with mixing, but not with equalizing. If our routing protocol just has every sender form one "message-bearing" onion to its recipient and send it along in addition to a set of checkpoint onions (as in the protocol &#928; a of Ando, Lysyanskaya, and Upfal <ref type="bibr">[3]</ref>), then an adversary who targets the sender Alice can cause Alice's recipient Bob to receive the message with a smaller probability than her alternative recipient, Bill; so this protocol will not equalize and, from Theorem 6, has no hope of achieving anonymity.</p><p>So how can we design a protocol that equalizes? One approach is to detect when the adversary drops any onions at all (e.g., using verifiable shuffling) <ref type="bibr">[25,</ref><ref type="bibr">30]</ref> and abort when that happens. While this approach equalizes, it is not at all fault-tolerant. To achieve fault tolerance and equalizing, the protocol must be able to react to the adversary dropping onions in a way that is less dramatic than total abort. This can be accomplished by using a new tool: merging onions. The idea here is that a sender P can create two onions, O 1 and O 2 that bear the same message to the same recipient R. Further, they will be routed through the same intermediary I, arriving at I at the same round r. Let O &#8242; 1 (resp. O &#8242; 2 ) denote the r th layer of O 1 (resp. O 2 ) that arrives at I at round r. When I peels both O &#8242; 1 and O &#8242; 2 , I discovers that they are (essentially) the same onion, and only forwards one of them to the next destination. If I receives just one of them (because the other one had been dropped by the adversary), then it forwards it to the next destination too.</p><p>The onion-forming phase. During the onion-forming phase, each honest party P creates two types of onions: merging onions and checkpoint onions.</p><p>On input {(m, R)}, P forms a set of x merging onions using the number y of rounds in an epoch, the message m, and the recipient R.</p><p>In addition to merging onions, P generates (on average) x checkpoint onions using the set D = {y, 2y, . . . , (log x + 1)y} as the diagnostic rounds. (Appropriate functions are chosen for F &#8226; (&#8226;, &#8226;) and b(&#8226;) such that P generates x checkpoint onions in expectation. See Checkpoint onions in Section 4 to recall how these functions are used for generating checkpoint onions.) For both merging onions and checkpoint onions, the length of the routing path is fixed; it is (log x + 1)y + 1.</p><p>The execution phase. All onions are created during the onion-forming phase and released simultaneously in the first round of the execution phase.</p><p>After each round r of the execution phase, P peels all onions it received at the r th round and merges mergeable onions (i.e., if two onions peel to the same nonce value, drop one of them at random).</p><p>If r is a diagnostic round (i.e., r &#8712; D), P runs the following diagnostic test: Let Ckpts(P, r) denote the set of checkpoints that P expects to see from peeling the onions between rounds r and r + 1. P counts how many checkpoints from Ckpts(P, r) are missing. If the number exceeds a fixed threshold value t, then P aborts. Otherwise, P continues for another round by sending the processed onions to their respective next destinations in random order. At the end of the execution phase, P peels the onions it received at the last round and outputs the set of (non-empty) messages it received.</p><p>&#9654; Remark 8. &#928; x,y,t &#9651; is anonymous from the adversary who corrupts up to &#954; fraction of the parties when (i) the onion encryption scheme is secure, (ii) the number x of onions formed by each (honest) party is &#8486; 2 &#8968;log(&#967;(log &#967;+1))&#8969; where &#967; = max( N log 2+&#1013; &#955;, log 2(1+&#1013;) &#955;), (iii) the number y of rounds per epoch is &#8486; log 1+&#1013; &#955; , and (iv) the threshold t is 2(1 -&#948;)(1&#954;) 3 &#954; log 1+&#1013; &#955;. (See the full version of the paper for the proof.) The reason that &#928; x,y,t &#9651; needs so many onions is that the adversary can target Alice and drop a lot of her onions before the honest participants realize (via checkpoint onions) the presence of an attack and abort. The protocol &#928; &#9655;&#9665; presented in the next section improves on this by giving the routing paths enough structure that missing onions can be detected sooner.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>6</head><p>Our main construction, &#928; &#9655;&#9665;</p><p>In this section, we present our main construction &#928; &#9655;&#9665; (pronounced "Pi-butterfly"). &#928; &#9655;&#9665; uses a variant of a butterfly graph described below.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6.1">The butterfly network and variants</head><p>Recall <ref type="bibr">[26,</ref><ref type="bibr">Chapter 4.5</ref>.2] that the butterfly network B = (V (B), E(B)) is a directed graph on (n + 1)2 n vertices. The vertices are organized into N = 2 n rows and n + 1 columns, so each vertex has an address (r, c) where 1 &#8804; r &#8804; N and 0 &#8804; c &#8804; n. Vertices in column i represent potential locations of a data packet (here, an onion) at epoch i;</p><p>each participant P has a dedicated row. An edge from (P, i) to (Q, i + 1) means that an onion can travel from participant P to participant Q in epoch i. The edges of the specific butterfly network that will be useful for us are E(B) = {((P, i), (Q, i + 1)) | P = Q or binary representations of P and Q differ in position i + 1 only}.</p><p>Let J and J &#8242; be two participants whose binary representation differs in bit i + 1 only. In &#928; &#9655;&#9665; , epoch i is dedicated to having an onion bounce y times between J and J &#8242; . This way, by the end of the epoch, the onions that J and J &#8242; held at the beginning of the epoch will be mixed together if one of them is honest. More formally, the onions travel along the edges of a stretched butterfly network, defined as follows: its N (ny + 1) vertices are organized into N rows and ny + 1 columns; and its edges are: E(&#946;) = {((P, j), (Q, j + 1)) | for i = &#8970;j/y&#8971;, ((P, i),</p><p>However, what if both J and J &#8242; are adversarial? Then sending the onions through the stretched butterfly network just once will result in the adversary knowing the i th bit of an onion's destination! So to prevent this, we will send the onions through the iterated stretched butterfly network. For an integer z, let &#946; z denote the stretched butterfly network iterated z times. More precisely, &#946; z is a directed graph in which the vertices are organized into N rows and nyz + 1 columns, i.e., a vertex has an address (r, c) where 1 &#8804; r &#8804; N and 0 &#8804; c &#8804; nyz. The edges are as follows:</p><p>To summarize, we begin with a butterfly network B, then we stretch it by y to get &#946;, then we iterate it z times to get &#946; z ; see Figure <ref type="figure">2</ref>. By a "walk through &#946; z " we mean a sequence (J 0 , . . . J nyz ) such that, for each i &lt; nyz, ((J i , i), (J i+1 , i + 1)) &#8712; E(&#946; z ). A random walk from a node J 0 is a sequence that begins with J 0 such that for i &gt; 0, each J i is a walk selected uniformly at random conditioned on the first i elements being (J 0 , . . . , J i-1 ). A random walk starting at any address can be sampled efficiently.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>B &#946; &#946; z</head><p>Figure <ref type="figure">2</ref> Diagrams of the butterfly network B, the stretched butterfly network &#946;, and the iterated stretched butterfly network &#946; z for n = log(8) = 3, and y = z = 2.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6.2">Description of the construction</head><p>&#928; x,y,z,t &#9655;&#9665; consists of setup, the onion-forming phase, and the execution phase. It is parameterized by the number x of merging onions per sender, the number y of rounds per epoch, the number z of iterations of a variant of a butterfly graph, and the threshold t for missing checkpoint nonces. The execution phase is further divided into the mixing sub-phase and the equalizing sub-phase. The iterated stretched butterfly graph determines routing options for the mixing sub-phase.</p><p>Let OE = (Gen, FormOnion, ProcOnion) be a secure onion encryption scheme. During setup, each honest participant P generates its public key pair (pk(P ), sk(P )) using Gen. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6.2.1">The onion-forming phase</head><p>On input {(m, R)}, each honest party P generates exactly x merging onions and (on average) x checkpoint onions. To form an onion, P first needs to pick a path for it. Each onion will (potentially) travel to d def = (nyz + 1) + y log x + 1 parties to reach its destination: the first nyz + 1 steps involve a random walk through the iterated stretched butterfly network (the mixing sub-phase), and the next y log x + 1 steps will take the onion through the equalizing sub-phase and to the recipient.</p><p>To begin with, P generates the x merging onions as follows: Let T be the binary tree of height log x. Let k be an address of a node in T (i.e., k is a binary string of length at most log x); let v k denote this node. I.e., V (T ) = {v k | k is a binary string, |k| &#8804; log x}. To each non-leaf vertex v k in T , P assigns a sequence of y random parties and y random nonces; let</p><p>) denote the sequence of vertices and</p><p>) denote the sequence of nonces corresponding to vertex v k . (Up until this step, this is exactly how merging onions are formed in &#928; &#9651; .) For each leaf vertex v &#8467; , P picks a random walk through the iterated stretched butterfly &#946; z and nyz + 1 random nonces; let J &#8594; v &#8467; = (J v &#8467; ,0 , . . . , J v &#8467; ,nyz ), denote the random walk, and let t &#8594; v &#8467; = (t v &#8467; ,0 , . . . , t v &#8467; ,nyz ) be the sequence of nonces. Let v &#8467; be a leaf of T . Let v &#8467;,i = v ki where k i is the i-bit prefix of &#8467;. I.e. v &#8467;,&#8467; = v &#8467; and v &#8467;,0 = v &#949; , and (v &#8467;,h , v &#8467;,h-1 , . . . , v &#8467;,0 ) is the path from v &#8467; to the root of the tree, where h = log x. P will create an onion O &#8467; for each leaf v &#8467; . Its routing path is</p><p>where k i is the i-bit prefix of &#8467;, and R is the recipient, and such that</p><p>) denote the sequence of nonces corresponding to this path. To form the onion O &#8467; corresponding to v &#8467; , P runs the algorithm FormOnion on the message m, the routing path I &#8594; &#8467; , the public keys associated with the routing path, and the nonce sequence s &#8594; &#8467; . After forming the merging onions, P generates the checkpoint onions. Just as in &#928; &#9651; , the execution phase consists of epochs, and the last round of every epoch is a diagnostic round. Here, each epoch lasts y rounds, thus round r &gt; 0 is a diagnostic round if r is a multiple of y. For each diagnostic round r and for each intermediary I, P uses the pseudorandom function F sk(P,I) (r, 0) to determine whether to form a checkpoint onion to send to I at round r, and if so, calculates the nonce s = F sk(P,I) (r, 1).</p><p>When F sk(P,I) (r, 0) = 1, P generates a checkpoint onion to be verified by party I in round r. Recall that d def = (nyz + 1) + y log x + 1; so round d is the last round of the execution phase. Since the checkpoint onion should not be distinguishable from a merging one during the mixing sub-phase, it needs to travel over the edges of the iterated stretched butterfly network for the first nyz + 1 rounds, and follow a random path through the network during the equalizing sub-phase, all the way until the last round d.</p><p>As a result, for r &#8805; nyz + 1, P generates the routing path by first picking a random walk J 0&#8594;nyz = (J 0 , . . . , J nyz ) through the iterated stretched butterfly network starting at a random node J 0 , and then choosing each participant on the next part of the path J nyz+1&#8594;r-1 = (J nyz+1 , . . . , J r-1 ) uniformly at random from P. Next, J r = I, and each router on the remaining stretch of the path J r+1&#8594;d is, again, chosen uniformly at random from P. So the resulting routing path is J &#8594; I,r = (J 0&#8594;nyz , J nyz+1&#8594;r-1 , J r , J r+1&#8594;d ). P chooses the corresponding nonces {s I,r,j } j&#8712;{0,...,d-1}\{r} uniformly at random, sets s I,r,r = s, and gives the resulting routing path, sequence (s I,r,0 , . . . , s I,r,d-1 ) of nonces and the empty message to FormOnion to obtain checkpoint onion O I,r .</p><p>If r &#8804; nyz, then round r occurs during the mixing sub-phase, as the onion is making its way through the butterfly network. So its path has to be formed in such a way that it arrives at I at round r; but it needs to be a randomly chosen path conditioned on this event (so that a checkpoint onion's path is distributed the same way as one of a merging onion). Let J 0&#8594;nyz be a random walk through &#946; z that is at address I at round r. Let each intermediary in the sequence J nyz+1&#8594;d be chosen uniformly at random from P. Again, for j &#824; = r, 0 &#8804; j &#8804; d -1, the nonce s I,r,j is chosen at random, while s I,r,r = s. Let J &#8594; I,r = (J 0&#8594;nyz , J nyz+1&#8594;d ). Run FormOnion on input the routing path J &#8594; I,r , sequence of nonces s &#8594; I,r and the empty message to obtain checkpoint onion O I,r . &#9654; Remark 9. In both &#928; &#9651; and &#928; &#9655;&#9665; , the onion layers are tagged with their respective round number to prevent replay attacks. If by peeling an onion received at round r, an honest relaying party observes a round number r &#8242; &#824; = r, the party drops the onion. (We can, therefore, assume that replay attacks do not happen. We can safely do so since the security of the onion encryption scheme prevents the adversary from modifying the onions formed by honest participants in any meaningful way. See, for example Ando and Lysyanskaya's work on onion encryption [2], for a sufficiently strong construction.)</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6.2.2">The execution phase</head><p>At the beginning of the execution phase, each party P is live. P 's status will change from live to aborted if it ever receives a special abort message from another party. An aborted party sends the special abort message to a random sample of x parties. (A slight technicality is that, since all messages must be onions, the abort message is a specially formed onion.)</p><p>For each r &#8712; {0, . . . , d -1}, each live honest party P first peels all the onions it received at the r th round. It merges onions that are mergeable: if it received two onions that have the same nonce, then it drops one of them, selected at random, and sends the other one to its next destination.</p><p>If r is a diagnostic round (i.e., a multiple of y), then P runs the diagnostic test: P compares the number of checkpoint onions it expects to receive with the number it received. For every participant Q &#8712; P, if F sk(Q,P ) (r, 0) = 1, then P expects to receive a checkpoint onion with nonce s = F sk(Q,P ) (r, 1) in this round. In the mixing sub-phase, if fewer than t checkpoint onions are missing so far in the protocol run (not just in this round, but cumulatively), then P continues the run by processing all the other onions.</p><p>Otherwise, P 's status changes: it is no longer live but becomes an aborted party. In the equalizing sub-phase, change status to aborted if there are t or more missing checkpoint onions in this round, else continue. At the last round (round d) of the execution phase, P peels the onions it received and outputs the set of (non-empty) messages it received.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6.3">Proof that &#928; &#9655;&#9665; is anonymous, robust, and efficient</head><p>In this section, we will prove that there exists a parameter setting (for x, y, z, and t) such that &#928; &#9655;&#9665; is simultaneously anonymous, fault-tolerant, and efficient. Our measure of efficiency is onion cost per user, which measures how many onions are transmitted by each user in the protocol. This is an appropriate measure when the parties pass primarily onions to each other. It is also an attractive measure of complexity because it is algorithm-independent: If we measured complexity in bits, it would change depending on which underlying encryption scheme was used. Since an onion contains as many layers as there are intermediaries, its bit complexity scales linearly with the number of intermediaries. (We assume that every message m can be contained in a single onion.) To translate our lower bound from onion complexity to bits, we will consider onions to be at least as long (in bits) as the message m being transmitted and the routing information. More formally, (1 &#955; , &#963;) denote the number of onions formed by an honest party that party P i transmits directly to another party in a protocol run of &#928; with adversary A, security parameter &#955; and &#963;. The onion cost of &#928; is OC</p><p>The expectation is taken over the input &#963; &#8592;$ &#931;, the party P i &#8592;$ P, and the randomness $ of the protocol.</p><p>For an adversary class A, the onion cost of &#928; interacting with A w.r.t. &#931; is the maximum onion cost over the adversaries in A, i.e., OC &#928;,A (1 &#955; , &#931;) def = max A&#8712;A OC &#928;,A (1 &#955; , &#931;).</p><p>Our formal notion of fault tolerance is robustness, defined below: &#9654; Definition 11 (Robustness). A messaging protocol &#928; is robust if in every interaction in which the adversary drops at most a logarithmic (in the security parameter) number of message packets, &#928; delivers all messages sent out by honest participants w.o.p.</p><p>Let A &#954; denote the class of active adversaries who can corrupt up to a constant &#954; fraction of the participants. In this section, we will prove the following upper bound on onion cost: &#9654; Theorem 12. For any constants &#954; &lt; 1 2 and &#947; 1 , &#947; 2 &gt; 0, there is a setting of x, y, z, and t such that &#928; x,y,z,t &#9655;&#9665; is robust and anonymous from the adversary class A &#954; with onion cost at most &#947; 1 log N log 3+&#947;2 &#955; (in the presence of A &#954; ), where &#955; is the security parameter and N = &#969;(log &#955;) is the number of participants.</p><p>Proof. Recall that the number of corruptions is &#954; &lt; 1 2 . Set &#1013; 1 such that &#947; 1 = 6&#1013; 3 1 and &#1013; 2 such that &#947; 2 = 3&#1013; 2 . Let x = y = z = &#1013; 1 log 1+&#1013;2 &#955;. Let an onion (layer) be commutable if (i) an honest party formed it, and (ii) it is not a checkpoint onion for verification by an adversarial party (more precisely, it does not belong to the same evolution as a checkpoint onion for verification by an adversarial party); and let t = W 3 , where W = (1-&#954;)x z log N +log x is the expected number of commutable checkpoint nonces at a party at a diagnostic round.</p><p>Having set the parameters, we wish to show that the protocol &#928; x,y,z,t &#9655;&#9665; (a) is robust; (b) has onion cost OC &#8804; &#947; 1 log N log 3+&#947;2 &#955;; and (c) is anonymous, provided that the underlying onion encryption scheme is secure.</p><p>Part (a) is true by inspection.</p><p>To see why (b) follows, recall that each participant forms x merging onions and, on average, x checkpoint onions; let X be the maximum number of onions formed by an honest party. Each of these onions will need to be processed in each round, so OC &#8804; Xd, where d is the number of rounds. Using Chernoff bounds, X &lt; 3x with overwhelming probability. The number of rounds is d = (nyz + 1) + y log x + 1; for our setting of parameters, therefore, OC &#8804; 6&#1013; 3  1 log N log 3(1+&#1013;2) &#955;. We show part (c) via a series of lemmas that follow. First, we invoke the UC composition theorem of Canetti <ref type="bibr">[8]</ref> in order to replace cryptographic algorithms for onion encryption with ideal encryption; this allows our further analysis to assume that onions reveal nothing to an intermediary I other than the information that is intended for I (Lemma 13). Let &#928; ideal &#9655;&#9665; be the resulting protocol. Next, we argue that &#928; ideal &#9655;&#9665; is an indifferent onion routing protocol (Lemma 15). This is helpful because then we will be able to invoke Theorem 3. Third, we discard, for the purposes of analysis, all the checkpoint onions that are checked by the adversary; we show that if a protocol mixes (resp. equalizes) in this setting, then it mixes (resp. equalizes). Finally, we show that in this setting, &#928; &#9655;&#9665; mixes (Lemma 16) and equalizes (Lemma 17). Then, putting it all together, we get our desired result. &#9664; &#9654; Lemma 13. Let &#928; be onion routing protocol that makes use of an onion encryption scheme that is UC-secure <ref type="bibr">[8]</ref> under a computational assumption A. Let &#928; ideal be the same protocol, but the onion encryption scheme is replaced by the ideal onion encryption functionality of Camenisch and Lysyanskaya <ref type="bibr">[7]</ref>. If &#928; ideal is anonymous, then &#928; is anonymous under assumption A.</p><p>Proof. The Lemma follows by the UC composition theorem of Canetti <ref type="bibr">[8]</ref>. &#9664; &#9654; Remark 14. Since CCA2-secure public-key encryption UC-realizes the ideal public-key encryption functionality of Canetti, and in &#928; &#9655;&#9665; , the adversary already knows how many layers of a given onion have already been peeled, forming onions by using CCA2-secure encryption to encrypt each layer will also result in an anonymous &#928; &#9655;&#9665; .</p><p>&#9654; Lemma 15. &#928; ideal &#9655;&#9665; is indifferent.</p><p>Proof. In &#928; ideal &#9655;&#9665; , the length of each routing path is fixed, and the intermediaries and nonces of honestly formed onion layers do not depend on the input &#963; to the protocol. The procedure for generating intermediaries and nonces takes as input only the values x, y, and z. Thus, by definition, &#928; ideal &#9655;&#9665; is indifferent. &#9664;</p><p>For the subsequent lemmas (Lemmas 16-18), we analyze only commutable onions.</p><p>&#9654; Lemma 16. With parameters x, y, z, and t defined as above, &#928; ideal &#9655;&#9665; mixes for the adversary who corrupts up to half of the parties.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Proof sketch. If &#928; ideal</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>&#9655;&#9665;</head><p>delivers messages in the final round d, then w.o.p., the adversary dropped (at most) a constant fraction of the commutable checkpoint onions before the last epoch: The adversary cannot drop more than a constant fraction of all commutable onions without also dropping a proportional number of checkpoint onions. This is because if the adversary were to drop more than a constant fraction of all commutable onions, then, from known probability concentration bounds <ref type="bibr">[22]</ref>, w.o.p., the adversary would drop close to a proportional number of checkpoint onions, which, in turn, would cause all honest parties to abort the run. Combining this with Chernoff bounds we get: during each round of the penultimate epoch e, each honest party processed a polylogarithmic (in the security parameter) number of commutable onions. From Chernoff bounds, we also get: during epoch e, each commutable onion went to an honest party a polylogarithmic number of times. Thus, either the &#928; ideal &#9655;&#9665; aborts, or it sufficiently shuffles the commutable onions during the penultimate epoch since shuffling for a polylogarithmic number of rounds with a polylogarithmic number of other onions is sufficient for mixing. Either way, &#928; ideal &#9655;&#9665; mixes. &#9664; &#9654; Lemma 17. With parameters x, y, z, and t defined as above, &#928; ideal &#9655;&#9665; equalizes for the adversary who corrupts up to half of the parties, who also receives everything about noncommutable onions as an auxiliary input.</p><p>Before proving Lemma 17, let us prove the following: &#9654; Lemma 18. Let &#928; ideal &#9655;&#9665; run with parameters x, y, z, and t are as defined above on input &#963;, with A corrupting up to half of the participants, and receiving an auxiliary input about non-commutable onions as an auxiliary input. If there is an unaborted honest party at the beginning of the equalizing phase, then with overwhelming probability for each honest party P , at least 1-&#954; 9 of P 's merging onions remained undropped by the adversary at the end of the mixing phase. (Recall that &#954; is the corruption rate.) I T C 2 0 2 1</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>9:22</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>On the Complexity of Anonymous Communication Through Public Networks</head><p>Proof sketch. In the first round, the adversary A knows the sender of each commutable onion. As the protocol progresses, A loses track of this information. Thus, A's optimal tactic is to target Alice upfront by dropping every onion that might have come from Alice that is routed to an adversarial party during the first three rounds of the first epoch (as well as the last round of the epoch).</p><p>In the first round, some of Alice's onions route to a corrupt party; A drops all of these. However, from Chernoff bounds, w.o.p., at least a constant fraction of Alice's onion go to an honest party first. Let O be such an onion, and let P be the honest party that receives O in the first round. Recall that during each epoch of the mixing phase, P shuffles onions back and forth with another party P &#8242; . A can attempt to drop O if P &#8242; is corrupt. However, even if P &#8242; is corrupt, A cannot drop O if it arrives at P first and remains at P during rounds 2 and 3 (and return to P at round y) -so, using probability concentration bounds, 1-&#954; 9 of the time. Thus, even if A employs the optimal tactic for dropping Alice's onions, (at least) 1-&#954; 9 of Alice's onions will make it to the equalizing phase. Since A cannot do better than this, this proves Lemma 18.</p><p>&#9664; Proof sketch of Lemma 17. From Lemma 18, if &#928; ideal &#9655;&#9665; continues into the equalizing phase, then a constant fraction of each honest party's merging onions are still in play at the start of the equalizing phase. However, Lemma 18 does not guarantee that there will be an epoch i &gt; nyz such that the number of Alice's merging onions at epoch i, numMO Alice,i , will be close to that of Allison's, numMO Allison,i . To prove that &#928; ideal &#9655;&#9665; equalizes, we need to show that there exists an epoch i &#8804; d such that (for any two parties Alice and Allison), numMO Alice,i &#8776; numMO Allison,i . If A doesn't drop any commutable onions during the equalizing phase, then this condition is satisfied by the merging of onions.</p><p>So what can A do? The only information that A has for guessing where any commutable onion came from is which onions are part of a mergeable pair and which are not; this is because the onions are shuffled during the mixing phase and each epoch of the equalizing phase. Let a singleton be a commutable onion that is not part of a mergeable pair; note that it can be either a checkpoint onion or a merging onion. W.l.o.g., suppose that A dropped more of Alice's onions upfront (during the mixing phase) than Allison's. Then, at the start of the equalizing phase, it is likely that more singletons are Alice's merging onions than Allison's merging onions. So, A can attempt to prevent the numbers of merging onions from evening out by dropping singletons. We can show that the best that A can do is to drop as many singletons as possible (without causing the protocol to be aborted) at the beginning of the equalizing phase. (Of course, A could also drop onions that belong in a mergeable pair, but this would only help to even out the numbers of merging pairs.) Even if A does this, there exists an epoch i &#8804; d such that numMO Alice,i &#8776; numMO Allison,i .</p><p>Armed with Lemma 18 and the above analysis, we can prove that &#928; ideal &#9655;&#9665; equalizes. If the adversary drops too many onions during the mixing phase, then &#928; ideal &#9655;&#9665; equalizes since every honest party stops participating (Lemma 18), and so no one receives their message. Otherwise, &#928; ideal &#9655;&#9665; equalizes since enough of each sender's merging onions make it to the equalizing phase (Lemma 18), and the numbers of merging onions are eventually evened out by the merging of onions (above). &#9664;</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="7">Our lower bound: polylog onion cost is required</head><p>In this section, we present our lower bound: an onion routing protocol can be anonymous from the active adversary only if the onion cost is superlogarithmic in the security parameter. Our lower bound holds for protocols that are minimally functional for the active adversary.</p><p>We call this notion weakly robustness, defined below. The reason this definition is weaker than robustness (Definition 11) is that here we only insist that the protocol guarantee delivery for senders whose onions are never dropped.</p><p>&#9654; Definition 19 (Weakly robust). Let &#928;(1 &#955; , pp, states, $, &#963;) be an onion routing protocol and let A be an adversary attacking &#928; that drops at most O(log(&#955;)) onions. &#928; is weakly robust if whenever A doesn't drop any onions sent by honest party P , P 's message will be delivered to its recipient with overehlming probability.</p><p>&#9654; Theorem 20. If the onion routing protocol &#928;(1 &#955; , pp, states, $, &#963;) is weakly robust and (computationally) anonymous from the adversary A who corrupts up to a constant fraction of the parties and drops at most f (&#955;) = O(log(&#955;)) onions, then the onion cost of &#928; interacting with A is &#969;(f (&#955;)).</p><p>Proof sketch. Let us give the intuition for the proof of this theorem. If an honest P i sends out only O(log(&#955;)) onions, then an adversary that chooses which participants to corrupt uniformly at random has a 1/&#955; O(1) chance of controlling each and every participant that ever receives an onion directly from P i . (This is because O(log(&#955;)) = O(log(N )), since &#955; and N are polynomially related.) Thus with non-negligible probability it can cut off P i entirely by dropping all of the onions it sends out, guaranteeing that the intended recipient of P i 's message never receives the message; yet, by weak robustness (Definition 19), we can show that there will be some recipient whose probability of receiving his message is high. Therefore, &#928; will not equalize (Definition 5): based on who failed to receive the message, it is possible to determine whether P i 's intended recipient was Bob or Bill. Since it does not equalize, by Theorem 6, it is not anonymous. See the full version of this paper for the proof. &#9664;</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="8">Conclusion and future work</head><p>Here, we mention a few extensions of our results: We proved that the required onion cost for an onion routing protocol to provide robustness and (computational) anonymity from the active adversary is polylogarithmic in the security parameter. Our proof for the lower bound can be used to prove the stronger result that polylogarithmic onion cost is required even when (i) the adversary observes the traffic on only &#920;(1) fraction of the links and or when (ii) the security definition is weakened to (computational) differential privacy. (iii) Also, while we explicitly showed this to be the case for the simple I/O setting, the result holds more generally whenever any party can send a message to any other party. We also proved the existence of a robust and anonymous onion routing protocol with polylogarithmic (in the security parameter) onion cost. (iv) This result also extends beyond the simple I/O setting; our onion routing protocol is anonymous w.r.t. any input set where the size of each party's input is fixed.</p><p>There is a small gap between our lower and upper bounds. A natural direction for future work is to close this gap.</p></div><note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="1" xml:id="foot_0"><p>We do not consider the asynchronous communication model<ref type="bibr">[9]</ref> in which Alice's outgoing onions (including her onion to her recipient Bob) can be delayed indefinitely. In such a case, we cannot even guarantee correctness (i.e., message delivery when no party deviates from the protocol).</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="2" xml:id="foot_1"><p>If we were to allow the adversary to adaptively corrupt parties, then the adversary could easily block all of Alice's onions. For every onion O sent by Alice, the adversary can corrupt the party P who receives O in time to direct P to drop the onion obtained from processing O before the next round.</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="3" xml:id="foot_2"><p>Technically, the view and the output may depend on other parameters, such as the public parameters I T C 2 0 2 1</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="4" xml:id="foot_3"><p>Technically, the input/output syntax and constructions of[2,<ref type="bibr">7]</ref> do not include the sequence (s1, . . . , s d ) of nonces but can easily be extended to do so; if we use layered CCA2-secure encryption instead of onion encryption -which is fine for this application -then incorporating the nonces is trivial.</p></note>
		</body>
		</text>
</TEI>
