XRD: Scalable Messaging System with Cryptographic Privacy Albert Kwon David Lu Srinivas Devadas MIT MIT PRIMES MIT Abstract As such, many recent messaging systems have been tar- geting scalability as well as formal security guarantees. Sys- Even as end-to-end encrypted communication becomes tems like Stadium [52] and Karaoke [37], for instance, use more popular, private messaging remains a challenging prob- differential privacy [22] to bound the information leakage lem due to metadata leakages, such as who is communicat- on the metadata. Though this has allowed the systems to ing with whom. Most existing systems that hide commu- scale to more users with better performance, both systems nication metadata either (1) do not scale easily, (2) incur leak a small bounded amount of metadata for each message, significant overheads, or (3) provide weaker guarantees than and thus have a notion of “privacy budget”. A user in these cryptographic privacy, such as differential privacy or heuris- systems then spends a small amount of privacy budget ev- tic privacy. This paper presents XRD (short for Crossroads), ery time she sends a sensitive message, and eventually is not a metadata private messaging system that provides crypto- guaranteed strong privacy. Users with high volumes of com- graphic privacy, while scaling easily to support more users munication could quickly exhaust this budget, and there is no by adding more servers. At a high level, XRD uses multiple clear mechanism to increase the privacy budget once it runs mix networks in parallel with several techniques, including out. Scalable systems that provide stronger cryptographic a novel technique we call aggregate hybrid shuffle. As a re- privacy like Atom [34] or Pung [5], on the other hand, do sult, XRD can support 2 million users with 228 seconds of not have such a privacy budget. However, they rely heav- latency with 100 servers. This is 13.3× and 4× faster than ily on expensive cryptographic primitives such as public key Atom and Pung, respectively, which are prior scalable mes- encryption and private information retrieval [3]. As a result, saging systems with cryptographic privacy. they suffer from high latency, in the order of ten minutes or 1 Introduction longer for a few million users, which impedes their adoption. This paper presents a point-to-point metadata private mes- Many Internet users today have turned to end-to-end en- saging system called XRD that aims to marry the best aspects crypted communication like TLS [18] and Signal [40], to of prior systems. Similar to several recent works [5, 34, 52], protect the content of their communication in the face of XRD scales with the number of servers. At the same time, widespread surveillance. While these techniques are starting the system cryptographically hides all communication meta- to see wide adoption, they unfortunately do not protect the data from an adversary who controls the entire network, a metadata of communication, such as the timing, the size, and constant fraction of the servers, and any number of users. the identities of the end-points. In scenarios where the meta- Consequently, it can support virtually unlimited amount of data are sensitive (e.g., a government officer talking with a communication without leaking privacy against such an ad- journalist for whistleblowing), encryption alone is not suffi- versary. Moreover, XRD only uses cryptographic primitives cient to protect users’ privacy. that are significantly faster than the ones used by prior works, Given its importance, there is a rich history of works and can thus provide lower latency and higher throughput that aim to hide the communication metadata, starting with than prior systems with cryptographic security. mix networks (mix-nets) [10] and dining-cryptographers net- A XRD deployment consists of many servers. These works (DC-Nets) [11] in the 80s. Both works provide for- servers are organized into many small chains, each of which mal privacy guarantees against global adversaries, which acts as a local mix-net. Before any communication, each user has inspired many systems with strong security guaran- creates a mailbox that is uniquely associated with her, akin tees [14, 55, 35, 53]. However, mix-nets and DC-nets re- to an e-mail address. In order for two users Alice and Bob to quire the users’ messages to be processed by either central- have a conversation in the system, they first pick a number ized servers or every user in the system, making them dif- of chains using a specific algorithm that XRD provides. The ficult to scale to millions of users. Systems that build on algorithm guarantees that every pair of users intersects at one them typically inherit the scalability limitation as well, with of the chains. Then, Alice and Bob send messages addressed overheads increasing (often superlinearly) with the number to their own mailboxes to all chosen chains, except to the of users or servers [14, 55, 35, 53]. For private communi- chain where their choices of chains align, where they send cation systems, however, supporting a large user base is im- their messages for each other. Once all users submit their perative to providing strong security; as aptly stated by prior messages, each chain shuffles and decrypts the messages, works, “anonymity loves company” [20, 49]. Intuitively, the and forwards the shuffled messages to the appropriate mail- adversary’s goal of learning information about a user natu- boxes. Intuitively, XRD protects the communication meta- rally becomes harder as the number of users increases. data because (1) every pair of users is guaranteed to meet at a chain which makes it equally likely for any pair of users to 2 Related work be communicating, and (2) the mix-net chains hide whether In this section, we discuss related work by categorizing a user sent a message to another user or herself. the prior systems primarily by their privacy properties, and One of the main challenges of XRD is addressing active at- also discuss the scalability and performance of each system. tacks by malicious servers, where they tamper with some of Systems with cryptographic privacy. Mix-nets [10] and the users’ messages. This challenge is not new to our system, DC-Nets [11] are the earliest examples of works that provide and several prior works have employed expensive crypto- cryptographic (or even information theoretic) privacy guar- graphic primitives like verifiable shuffle [14, 55, 35, 52, 34] antees against global adversaries. Unfortunately, they have or incurred significant bandwidth overheads [34] to prevent two major issues. First, they are weak against active attack- such attacks. In XRD, we instead propose a new technique ers: adversaries can deanonymize users in mix-nets by tam- called aggregate hybrid shuffle that can verify the correctness pering with messages, and can anonymously deny service in of shuffling more efficiently than traditional techniques. DC-Nets. Second, they do not scale to large numbers of users XRD has two significant drawbacks compared to prior√ sys- because all messages must be processed by either a small tems. First, with N servers, each user must send O( N) number of servers or every user in the system. Many systems messages in order to ensure that every pair√ of users inter- that improved on the security of these systems against active sects. Second, because each user sends O√( N) messages, attacks [14, 55, 35, 53] suffer from similar scalability bottle- the workload of each XRD server is O(M/ N) for M users, necks. Riposte [13], a system that uses “private information rather than O(M/N) like many prior scalable messaging sys- storage” to provide anonymous broadcast, also requires all tems [34, 52, 37]. Thus, prior systems could outperform servers to handle a number of messages proportional to the XRD in deployment scenarios with large numbers of servers number of users, and thus faces similar scalability issues. and users, since the cost of adding a single user is higher and A recent system Atom [34] targets both scalability and adding servers is not as beneficial in XRD. strong anonymity. Specifically, Atom can scale horizon- Nevertheless, our evaluation suggests that XRD outper- tally, allowing it to scale to larger numbers of users simply forms prior systems with cryptographic guarantees if there by adding more servers to the network. At the same time, are less than a few thousand servers in the network. XRD it provides sender anonymity [46] (i.e., no one, including can handle 2 million users (comparable to the number of the recipients, learns who sent which message) against an daily Tor users [1]) in 228 seconds with 100 servers. For adversary that can compromise any fraction of the servers Atom [34] and Pung [5, 4], two prior scalable messaging and users. However, Atom employs expensive cryptography, systems with cryptographic privacy, it would take over 50 and requires the message to be routed through hundreds of minutes and 15 minutes, respectively. (These systems, how- servers in series. Thus, Atom incurs high latency, in the or- ever, can defend against stronger adversaries, as we detail in der of tens of minutes for a few million users. §2 and §7.) Moreover, the performance gap grows with more Pung [5, 4] is a system that aims to provide metadata pri- users, and we estimate that Atom and Pung require at least vate messaging between honest users with cryptographic pri- 1,000 servers in the network to achieve comparable latency vacy. This is a weaker notion of privacy than that of Atom, with 2 million or more users. While promising, we find that as the recipients (who are assumed to be honest) learn the XRD is not as fast as systems with weaker security guaran- senders of the messages. However, unlike most prior works, tees: Stadium [52] and Karaoke [37], for example, would Pung can provide private communication even if all servers be 3× and 23× faster than XRD, respectively, in the same are malicious by using a cryptographic primitive called com- deployment scenario. In terms of user costs, we estimate putational private information retrieval (CPIR) [12, 3]. Its that 40 Kbps of bandwidth is sufficient for users in a XRD powerful threat model comes unfortunately at the cost of per- network with 2,000 servers, and the bandwidth requirement formance: Though Pung scales horizontally, the amount of scales down to 1 Kbps with 100 servers. work required per user is proportional to the total number of In summary, we make the following contributions: users, resulting in the total work growing superlinearly with the number of users. Moreover, PIR is computationally ex- • Design and analyze XRD, a metadata private messaging pensive, resulting in throughput of only a few hundred or system that can scale by distributing the workload across thousand messages per minute per server. many servers while providing cryptographic privacy. Systems with differential privacy. Vuvuzela [53] and its • Design a technique called aggregate hybrid shuffle that horizontally scalable siblings Stadium [52] and Karaoke [37] can efficiently protect users’ privacy under active attacks. aim to provide differentially private (rather than crypto- graphically private) messaging. At a high level, they hide the • Implement and evaluate a prototype of XRD on a net- communication patterns of honest users by inserting dummy work of commodity servers, and show that XRD outper- messages that are indistinguishable from real messages, and forms existing cryptographically secure designs. reason carefully about how much information is leaked at each round. They then set the system parameters such that mix-nets [44, 24, 49, 15, 39] (distributed mix-nets where they could support a number of sensitive messages; for in- each messages is routed through a small subset of servers) stance, Stadium and Karaoke target 104 and 106 messages, cannot provide strong privacy against powerful adversaries respectively. Up to that number of messages, the systems al- due to traffic analysis and active attacks. low users to provide a plausible cover story to “deny” their Loopix [47] is a recent iteration on free-route mix-nets, actual actions. Specifically, the system ensures that the prob- and can provide fast asynchronous messaging. To do so, each ability of Alice conversing with Bob from the adversary’s user interacts with a semi-trusted server (called “provider” in perspective is within eε (typically, eε ∈ [3,10]) of the prob- the paper), and routes her messages through a small number ability of Alice conversing with any other user with only of servers (e.g., 3 servers). Each server inserts small amounts a small failure probability δ (typically, δ = 0.0001). This of random delays before routing the messages. Loopix then paradigm shift has allowed the systems to support larger reasons about privacy using entropy. Unfortunately, the pri- numbers of users with lower latency than prior works. vacy guarantee of Loopix weakens quickly as the adversary Unfortunately, systems with differential privacy suffer compromises more servers. Moreover, Loopix requires the from two drawbacks. First, the probability gap between two recipients to trust the provider to protect themselves. events may be sufficient for strong adversaries to act on. For 3 System model and goals instance, if Alice is ten times as likely to talk to Bob than aims to achieve the best of all worlds by providing Charlie, the adversary may act assuming that Alice is talking XRD cryptographic metadata privacy while scaling horizontally to Bob, despite the plausible deniability. Second, there is a without relying on expensive cryptographic primitives. In “privacy budget” (e.g., 104 to 106 messages), meaning that this section, we present our threat model and system goals. a user can deny a limited number of messages with strong guarantees. Moreover, for best possible security, users must 3.1 Threat model and assumptions constantly send messages, and deny every message. For in- A deployment of XRD would consist of hundreds to thou- stance, Alice may admit that she is not in any conversation sands of servers and a large number of users, in the order (thinking this information is not sensitive), but this could of millions. Similar to several prior works on distributed have unintended consequences on the privacy of another user private communication systems [34, 52], XRD assumes an who uses the cover story that she is talking with Alice. The adversary that can monitor the entire network, control a frac- budget could then run out quickly if users want the strongest tion f of the servers, and control up to all but two honest privacy possible: If a user sends a message every minute, she users. We assume, however, that there exists a public key would run out of her budget in a few days or years with 104 6 infrastructure that can be used to securely share public keys to 10 messages. Although the privacy guarantee weakens of online servers and users with all participants at any given gradually after the privacy budget is exhausted, it is unclear time. These keys, for example, could be maintained by key how to raise the privacy levels once they have been lowered. transparency schemes [36, 42, 51]. These shortcomings can particularly affect journalists and XRD does not hide the fact that users are using XRD. their sources. Many journalists mention the importance of Thus, for best possible security, users should stay online to long-term relationships with their sources for their journalis- avoid intersection attacks [31, 16]. XRD also does not pro- tic process [41, 43], and the difficulty of maintaining private tect against large scale denial-of-service (DoS) attacks. It relationships with them. In a differentially private system, can, however, recover from a small number of benign server if the journalist and the source are ten times as likely to be failures or disruptions from malicious users. In addition, talking as two other users, then the adversary might simply XRD provides privacy even under DoS, server churn, and assume the journalist and the source’s relationship. Further- user churn (e.g., Alice goes offline unexpectedly without her more, these relationships often last many years [43], which conversation partner knowing). We discuss the availability could cause the privacy budget to run out. This may put the properties further in §5 and §7.3. journalist and the source in jeopardy. Finally, XRD assumes that the users can agree to start talk- ing at a certain time out-of-band. This could be done, for ex- Scalable systems with other privacy guarantees. The only ample, via two users exchanging this information offline, or private communication system in wide-deployment today is by using systems like Alpenhorn [38] that can initiate con- Tor [21]. Tor currently supports over 2 million daily users versations privately. using over 6,000 servers [1], and can scale to more users easily by adding more servers. However, Tor does not pro- Cryptographic primitives. XRD assumes existence of a vide privacy against an adversary that monitors significant group of prime order p with a generator g in which dis- portions of the network, and is susceptible to traffic analy- crete log is hard and the decisional Diffie-Hellman assump- sis attacks [19, 30]. Its privacy guarantee weakens further if tion holds. We will write DH(ga,b) = gab to denote Diffie- the adversary can control some servers, and if the adversary Hellman key exchange. In addition, XRD makes use of au- launches active attacks [29]. Similar to Tor, most free-route thenticated encryption. Users Servers (mix-chains) Mailboxes Authenticated encryption [6]: XRD relies on an authen- (1) (2) (3) (4) ticated encryption scheme for confidentiality and integrity, which consists of the following algorithms: ... • c ← AEnc(s,nonce,m). Encrypt message m and authen- ticate the ciphertext c using a symmetric key s and a ... nonce nonce. Typically, s is used to derive two other keys for encryption and authentication. ... • (b,m) ← ADec(s,nonce,c). Check the integrity of and (1) Users send (2) Servers shuffle (3) Servers deliver (4) Users fetch decrypt ciphertext c using the key s and a nonce nonce. messages to and decrypt users’ messages to messages from If the check fails, then b = 0 and m = ⊥. Otherwise, chosen mix-chains. messages. users’ mailboxes. mailboxes. b = 1 and m is the underlying plaintext. Figure 1: Overview of XRD operation. In general, the adversary cannot generate a correctly authen- out in discrete rounds. In each round, each user selects a ticated ciphertext without knowing the secret key used for fixed set of ` chains, where the set is determined by the user’s ADec. We use Encrypt-then-HMAC for authenticated en- public key. She then sends a fixed size message to each of cryption, which has the additional property that the cipher- the selected chains. (If the message is too small or large, then text serves as a commitment to the underlying plaintext with the user pads the message or breaks it into multiple pieces.) the secret key being the opening to the commitment [28]. Each message contains a destination mailbox, and is onion- 3.2 Goals encrypted for all servers in the chain. Once all users submit their messages, each chain acts as a XRD has three main goals. local mix-net [10], decrypting and shuffling messages. Dur- Correctness. Informally, the system is correct if every hon- ing shuffling, each server also generates a short proof that est user successfully communicates with her conversation allows other servers to check that it behaved correctly. If the partner after a successful execution of the system protocol. proof does not verify, then the servers can identify who mis- Privacy. Similar to prior messaging systems [53, 5, 52, behaved. If all verification succeeds, then the last server in 37], XRD aims to provide relationship unobservability [46], each chain forwards the messages to the appropriate mailbox meaning that the adversary cannot learn anything about the servers. (The protocol for proving and verifying the shuffle communication between two honest users. Informally, con- is described in §6.) Finally, the mailbox servers put the mes- sider any honest users Alice, Bob, and Charlie. The system sages into the appropriate mailboxes, and each user down- provides privacy if the adversary cannot distinguish whether loads all messages in her mailbox at the end of a round. Alice is communicating with Bob, Charlie, or neither. XRD The correctness and security of XRD is in large part due only guarantees this property among the honest users, as ma- to how each user selects the chains. As we will see in §5, licious conversation partners can trivially learn the metadata the users are required to follow a specific algorithm to se- of their communication. We provide a more formal defini- lect the chains. The algorithm guarantees that every pair of tion in Appendix B. (This is a weaker privacy goal than that users have at least one chain in common and the choices of of Atom [34], which aims for sender anonymity.) the chains are publicly computable. For example, every user selecting the same chain will achieve this property, and thus Scalability. Similar to prior work [34], we require that the correctness and security. In XRD, we achieve this property system can handle more users with more servers. If the while distributing the load evenly. number of messages processed by a server is C(M,N) for M Let us now consider two scenarios: (1) a user Alice is not users and N servers, we require that C(M,N) → 0 as N → ∞. in a conversation with anyone, or (2) Alice is in a conver- C(M,N) should approach zero polynomially in N so that sation with another user Bob. In the first case, she sends a adding a server introduces significant performance benefits. dummy message encrypted for herself to each chain that will 4 XRD overview come back to her own mailbox. We call these messages loop- Figure 1 presents the overview of a XRD network. At a back messages. In the second case, Alice and Bob compute high level, XRD consists of three different entities: users, each other’s choices of chains, and discover at which chain mix servers, and mailbox servers. Every user in XRD has they will intersect. If there are multiple such chains, they a unique mailbox associated with her, similar to an e-mail break ties in a deterministic fashion. Then, Alice and Bob address. The mailbox servers maintain the mailboxes, and send the messages encrypted for the other person, which we are only trusted for availability and not privacy. call conversation messages, to their intersecting chain. They also send loopback messages on all other chains. To set up the network, XRD organizes the mix servers into many chains of servers such that there exists at least one hon- Security properties. We now argue the security informally. est server in each chain with overwhelming probability (i.e., We present a more formal definition and arguments of pri- an anytrust group [55]). Communication in XRD is carried vacy in Appendix B. Since both types of messages are en- crypted for owners of mailboxes and the mix-net hides the Algorithm 1 Mix server routing protocol origin of a message, the adversary cannot tell if a message Server i is in chain x which contains k servers mski going to Alice’s mailbox is a loopback message or a con- with its mixing key pair (mpki = g ,mski). versation message sent by a different user. This means that In each round r, it receives a set of ciphertexts j j the network pattern of all users is the same from the adver- {c gx j , ,x ,r|| ,c } , either i = ( AEnc(DH(mpki j) x i+1) j∈[M] sary’s perspective: each user sends and receives exactly ` from an upstream server if i =6 1, or from the users if i = 1. messages, each of which could be a loopback or a conversa- 1. Decrypt and shuffle: Compute tion message. As a result, the adversary cannot tell if a user j x j j ci+1 = ADec(DH(g ,mski),r||x,ci ) for each j, and is in a conversation or not. Moreover, we choose the chains j randomly shuffle {c }. such that every pair of users intersects at some chain (§5), i+1 j meaning the probability that Alice is talking to a particular 2a. Relay messages: If i < k, then send the shuffled {ci+1} honest user is the same for all honest users. This hides the to server i + 1. conversation metadata. 2b. Forward messages to mailbox: If i = k, then each de- The analysis above, however, only holds if the adversary crypted message is of the form (pku,AEnc(s,r||x,mu)), does not tamper with the messages. For instance, if the ad- where pku is the public key of a user u, s is a secret key, versary drops Alice’s message in a chain, then there are two and mu is a message for the user. Send the message to possible observable outcomes in this chain: Alice receives the mailbox server that manages mailbox pku. (1) no message, meaning Alice is not in a conversation in this chain, or (2) one message, meaning someone intersect- 5.2 Mix chains ing with Alice at this chain is chatting with Alice. This in- XRD uses many parallel mix-nets to process the messages. formation leakage breaks the security of XRD. We propose We now describe their formation and operations. a new protocol called aggregate hybrid shuffle (§6) that effi- 5.2.1 Forming mix chains ciently defends against such an attack. We require the existence of an honest server in every chain Scalability properties. Let n and N be the number of chains to guarantee privacy. To ensure this property, we use public and servers in the network, respectively. Each user must √ randomness sources [7, 50] that are unbiased and publicly send at least n messages to guarantee every pair of users available to randomly sample k servers to form a chain, sim- intersect. To see why, fix `, the number of chains a user ilar to prior works [34, 52]. We set k large enough such that selects. Those chains must connect a user Alice to all M the probability that all servers are malicious is negligible. users. Since the total number of messages sent by users is Concretely, the probability that a chain of length k consists M ·`, each chain should handle M·` messages if we distribute n f k n M·` only of malicious servers is . Then, if we have chains in the load evenly. We then need n · ` ≥ M because the left total, the probability there exists a group of only malicious hand side is the maximum number of√ users connected to the servers is less than n · f k via a union bound. Finally, we can chains that Alice chose. Thus, ` ≥ n. In√ §5, we present upper bound this to be negligible. For example, if we want an approximation algorithm that uses ` ≈ 2n to ensure all this probability to be less than 2−64 for f = 20%, then we users intersect with each other while evenly distributing√ the need k = 32 for n < 2000. This makes k depend logarithmi- √2M work. This means that each chain handles ≈ n messages, cally on N. In XRD, we set n = N for N servers, meaning and thus XRD scales with the number of chains. If we√ set each server appears in k chains on average. n = N and each server appears√ in k chains for k << N, We “stagger” the position of a server in the chains to en- which means C M,N k√2M → 0 polynomially as N → ∞ sure maximal server utilization. For instance, if a server is ( ) = N (§3.2). We show that k is logarithmic in N in §5.2.1. part of two chains, then it could be the first server in one chain and the second server in the other chain. This opti- 5 XRD design mization has no impact on the security, as we only require We now present the details of a XRD design that protects the existence of an honest server in each group. This helps against an adversary that does not launch active attacks. We minimize the idle time of each server. then describe modifications to this design that allows XRD 5.2.2 Processing user messages to protect against active attacks in §6. After the chains form, each mix server i generates a mixing 5.1 Mailboxes and mailbox servers mski key pair (mpki = g ,mski), where mski is a random value Every user in XRD has a mailbox that is publicly associ- in Zp. The public mixing keys {mpki} are made available ated with her. In our design, we use the public key of a user to all participants in the network, along with the ordering of as the identifier for the mailbox, though different public iden- the keys in each chain. Now, each chain behaves as a mix- tifiers like e-mail addresses can work as well. The mailboxes net [10]: users submit some messages onion-encrypted using are maintained by the mailbox servers, with simple put and the mixing keys (§5.3), and the servers decrypt and shuffle get functionalities to add and fetch messages to a mailbox. the messages in order. Algorithm 1 describes this protocol. 5.2.3 Server churn Algorithm 2 User conversation protocol Some servers may go offline in the middle of a round. Consider two users Alice and Bob with key pairs skA skB Though XRD does not provide additional fault tolerance (pkA = g ,skA) and (pkB = g ,skB) who are connected mechanisms, only the chains that contain failing servers are to sets of ` chains CA and CB (§5.3.1). The network consists affected. Furthermore, the failing chains do not affect the se- of chains 1,...,n, each with k servers. Alice and Bob pos- curity since they do not disturb the operations of other chains sess the set of mixing keys for each chain. Alice performs and the destination of the messages at the failing chain re- the following in round r. mains hidden to the adversary. Thus, conversations that use 1a. Generate loopback messages: If Alice is not in a con- chains with no failing servers are unaffected. We analyze the versation, then Alice generates ` loopback messages: x x empirical effects of server failures in §7.3. mx = (pkA,AEnc(sA,r||x,0)) for x ∈ CA, where sA is a chain-specific symmetric key known only to Alice. 5.3 Users 1b. Generate conversation message: If Alice is in a We now describe how users operate in . XRD conversation with Bob, then she first computes the 5.3.1 Selecting chains shared key sAB = DH(pkB,skA), and the symmet- XRD needs to ensure that all users’ choices of chains in- ric encryption key for Bob sB = KDF(sAB,pkB,r) tersect at least once, and that the choices are publicly com- where KDF is a secure key derivation function (e.g., putable. We present a scheme that achieves this property. HKDF [33]). Alice then generates the conversation mes-

Upon joining the network, every user is placed into one of sage: mxAB = (pkB,AEnc(sB,r||x,msg)), where msg is ` + 1 groups such that each group contains roughly the same the plaintext message for Bob and xAB ∈ CA ∩CB is the number of users, and such that the group of any user is pub- first chain in the intersection. She also generates ` − 1 licly computable. This could be done, for example, by as- loopback messages mx for x ∈ CA,x =6 xAB. signing each user to a pseudo-random group based on the 2. Onion-encrypt messages: For each message mx, let hash of the user’s public key. Every user in a group is con- ck+1 = mx, and let {mpki} be the mixing keys for chain nected to the same ` servers specified as follows. Let C i x ∈ CA. For i = k to 1, generate a random value xi ∈ Zp, be the ordered set of chains that users in group i are con- xi and compute ci = (g ,AEnc(DH(mpki,xi),r||x,ci+1)). nected to. We start with C1 = {1,...,`}, and build the other Send c1 to chain x. sets inductively: For i = 1,...,`, group i + 1 is connected 3. Fetch messages: At the end of the round, fetch and to C = {C [i],C [i],...,C [i],C [`] + 1,...,C [`] + (` − i)}, i+1 1 2 i i i decrypt the messages in her mailbox, using ADec with where C [y] is the yth entry in C . x x matching sx or s = KDF(s ,pk ,r). By construction, every group is connected to every other A A AB A group: Group i is connected to group j via Ci[ j] for all i < j. ice and Bob shares. Finally, Alice sends the message for Bob As a result, every user in group i is connected to all others to the intersecting chain, and sends the loopback messages to in the same group (they meet at all chains in Ci), and is con- the other chains. Bob mirrors Alice’s actions. nected to users in group j via chain C [ j]. i 5.3.3 User churn To find the concrete value of `, let us consider C`. The Like servers, users might go offline in the middle of a last chain of C`, which is the chain with the largest index, is 2 round, and XRD aims to provide privacy in such situations. C [`] = `2 − ∑`−1 i = ` +` . This value should be as close as ` i=1 2 However, the protocol presented thus far does not achieve possible to n, the number of chains, to maximize utilization. √ √ √ this goal. If Alice and Bob are conversing and Alice goes of- Thus, ` = d 2n + 0.25 − 0.5e ≈ d 2ne. Given that ` ≥ n √ fline without Bob knowing, then Alice’s mailbox will receive (§4), this is a 2-approximation. Bob’s message while Bob’s mailbox will get one fewer mes- 5.3.2 Sending messages sage. Thus, by observing mailbox access counts and Alice’s After choosing the ` mix chains, the users send one mes- availability, the adversary can infer their communication. sage to each of the chosen chains as described in Algo- To solve this issue, we require Alice to submit two sets of rithm 2. At a high level, if Alice is not talking with anyone, messages in round r: the messages for the current round r, Alice generates ` loopback messages by encrypting dummy and cover messages for round r + 1. If Alice is not commu- messages (e.g., messages with all zeroes) using a secret key nicating with anyone, then the cover messages will be loop- known only to her, and submits them to the chosen chains. back messages. If Alice is communicating with another user, If she is talking with another user Bob, then she first finds then one of the cover messages will be a conversation mes- where they intersect by computing the intersection of Bob’s sage indicating that Alice has gone offline. group and her group (§5.3.1). If there is more than one such If Alice goes offline in round τ, then the servers use the chain, then she breaks the tie by selecting the chain with the cover messages submitted in τ −1 to carry out round τ. Now, smallest index. Alice then generates ` − 1 loopback mes- there are two possibilities. If Alice is not in a conversation, sages and one encrypted message using a secret key that Al- then Alice’s cover loopback messages are routed in round τ, and nothing needs to happen afterwards. If Alice is convers- 6.1 Key generation with AHS ing with Bob, then at the end of round τ, Bob will get the When the chain is created, the servers generate three key message that Alice is offline via one of the cover messages. pairs: blinding, mixing, and inner key pairs. The inner Starting from round τ + 1, Bob now sends loopback mes- keys are per-round keys, and each server i generates its sages instead of conversation messages to hide the fact that iski own inner key pair (ipki = g ,iski). The other two keys Bob was talking with Alice in previous rounds. This could be are long-term keys, and are generated in order starting with used to end conversations as well. Malicious servers cannot the first server in the chain. Let bpk0 = g. Starting with fool Bob into thinking Alice has gone offline by replacing bski server 1, server i = 1,...,k generates (bpk = bpk ,bski) Alice’s messages with her cover messages because the hon- i i−1 and mski , in order. In other words, the base est servers will ensure Alice’s real messages are accounted (mpki = bpki−1 mski) ∏acrypt each message. Each message is of the that ( X )bskA = X ; otherwise it would fail the NIZK j j j ∏ 1 ∏ h form (Xi ,ci = AEnc(DH(mpki,x j),r||x,ci+1). Thus, verification in step 3 of §6.3. Let XT =6 /0be the set of honest j j j j (b ,ci+1) = ADec(DH(Xi ,mski),r||x,ci ). If any de- users whose messages were tampered. The adversary needs cryption fails (i.e., b j = 0 for some j), then mixing halts to know the keys used for authenticated decryption to gen- and the server can start the blame protocol described in erate valid ciphertexts that differ from the users’ ciphertexts. j However, the adversary cannot compute ((gx j )bskA )mskh for §6.4. Randomly shuffle {ci+1}. j ∈ X (the keys used for authenticated encryption), since x 2. Blind and shuffle: Blind the users’ Diffie-Hellman keys T j j j j and msk are unknown random values and Diffie-Hellman {X } using the blinding key: X = (X )bski for each j. h i i+1 i is hard. Thus, to tamper with messages undetected, the ad- Then, shuffle the keys using the same permutation as the versary needs to change the users’ Diffie-Hellman keys (i.e., one used to shuffle the ciphertexts. j j bskA Xh =6 (X1 ) for j ∈ XT ), such that it can compute the keys 3. Generate zero-knowledge proof: Generate a proof that j mskh j j used for authenticated decryption (i.e., (Xh ) for j ∈ XT ). X bski X (∏ j i ) = ∏ j i+1 by generating a NIZK that shows In the beginning of a round, the adversary controlled j log j (∏ j Xi 1) = logbpk bpki(= bski). Send the users have to prove their knowledge of discrete logs of ∏ j(Xi ) + i−1 j their Diffie-Hellman keys after seeing the honest users’ NIZK with the shuffled {Xi+1} to all other servers in the j keys. The adversarial user are thus forced to generate chain. All other servers verify this proof using {Xi } they j keys independently of the honest users’ input. Then, j received previously, {Xi+1}, bpki−1, and bpki. the adversary’s goal is essentially to find {Xh } j∈XT such j bskA j j bskA j 4. Forward messages: If i < k, then send the shuffled that (∏ j∈X X ) = ∏ j∈X X , with (X ) =6 X . As- j j T 1 T h 1 h {(Xi+1,ci+1)} to server i + 1. sume the adversary is successful. Then, it could j j When the last server finishes shuffling and no server reports bskA mskh mskh compute ((∏ j∈XT X1 ) ) = ∏ j∈XT (Xh ) , since it any errors during mixing, our protocol guarantees that the j mskh knows (Xh ) for j ∈ XT (recall that these are the honest server mixed all the honest users’ messages success- keys used for authenticated decryption, which the adver- fully. At this point, the servers reveal their private per-round sary must know). This means that the adversary com- j msk ·bsk · x inner keys {iski}. With this, the last server can decrypt the bskA mskh h A ∑ j∈XT j puted ((∏ j∈XT X1 ) ) = g only given inner ciphertexts to recover the users’ messages. x j bskA mskh {g } j∈XT , bskA, and (g ) , where {x j} j∈XT and mskh Analysis. We first argue correctness of AHS (i.e., every are random values independent of bskA. This breaks the message is successfully delivered if every participant fol- Diffie-Hellman assumption, and thus the adversary must not lowed the protocol) by showing that the encryption and de- be able to tamper with messages undetected. cryption keys match at all layers. Consider the key user 6.4 Blame protocol j used to encrypt the message for server i and the Diffie- Hellman key server i receives. User j encrypts the message There are two ways an honest server can detect misbehav- x j·mski ∏a

0.2 1000 927s 897s 800 0.1 706s Bandwidth (MB)

Latency (s) 600 0.0 450s 0 250 500 750 1000 1250 1500 1750 2000 400 272s Number of servers 228s 200 114s 138s Figure 2: Required user bandwidth per round as a function 64s 10s 16s 22s 0 of number of servers in the network. 1 2 3 4 5 6 7 8 Number of users (millions)

0.5 Figure 4: End-to-end latency of XRD and prior systems with varying numbers of users with 100 servers. 0.4 XRD 7.2 End-to-end latency 0.3 Pung (XPIR; 4M users) Atom Experiment setup. To evaluate the end-to-end perfor- 0.2 Pung (XPIR; 1M users) Stadium mance, we created a testbed consisting of up to 200 Latency (s) Pung (SealPIR) 0.1 c4.8xlarge instances. We ran the instances within the same data center to avoid bandwidth costs, but added 40-100ms of 0.0 0 250 500 750 1000 1250 1500 1750 2000 round trip latency between servers using the Linux tc com- Number of servers mand to simulate a more realistic distributed network. Our evaluations consider all parts of the AHS protocol (§6), but Figure 3: Required user computation as a function of number assume all users are following the protocol. We then evaluate of servers with a single core. The computation could easily the blame protocol (§6.4) separately. be parallelized with more cores for XRD. We used many c4.8xlarge instances to simulate millions the overheads for users increase as we add more servers to of users, and also used ten more c4.8xlarge instances to sim- the network, as shown in Figure 2 and 3. This is a primary ulate the mailboxes. We generate all users’ messages before weakness of XRD, since our horizontal scalability comes at the round starts, and measure the critical path of our system a higher cost for users. Still, the cost remains reasonable by measuring the time between the last user submitting her even for large numbers of servers. With 2,000 servers, each message and the last user downloading her message. user must submit about 238 KB of data. For 1 minute rounds, We estimate the latency of Pung with M users and N this translates to about 40 Kbps of bandwidth requirement. A servers by evaluating it on a single c4.8xlarge instance with similar trend exists for computation overhead as well, though M/N users. This is the best possible latency Pung can it remains relatively small: it takes less than 0.5s with fewer achieve because (1) Pung is embarrassingly parallel, so than 2,000 servers in the network. Computation could also evenly dividing users across all the servers should be ideal [5, be easily parallelized with more cores, since users can gen- §7.3], and (2) we are ignoring the extra work needed for erate the messages for different chains independently. The coordination between the servers (e.g., for message replica- cover messages make up half of the client overhead (§5.3.3). tion). For Stadium, we report the latency when the length of each mix chain is nine servers. For Karaoke, we report the User costs in prior works do not increase with the number numbers reported in their paper. of servers. Still, Pung with XPIR incurs heavy user band- We focus on the following questions in this section, and width overheads due to the cost of PIR. With 1 million users, compare against prior work: Pung users transmit about 5.8 MB, which is about 25× worse • What is the end-to-end latency of , and how does it than XRD when there are fewer than 2,000 servers. More- XRD over, per user cost of XPIR is proportional to the total num- change with the number of users? ber of users: the bandwidth cost increases to 11 MB of band- • How does XRD scale with more servers? width for 4 million users. The SealPIR variant, however, is • What is the effect of f , the fraction of malicious servers, comparable to that of XRD, as the users can compress the on latency? communication using cryptographic techniques. Stadium, Karaoke, and Atom incur minimal user bandwidth cost, with • How fast is the blame protocol? less than a kilobyte of bandwidth overhead (only Stadium is Number of users. Figure 4 shows the end-to-end latency shown Figure 2). Thus, for users with heavily limited re- of XRD and prior works with 100 servers. XRD was able to sources, prior works can be more desirable than XRD. handle 2 million users in 228s, and the latency scales linearly Atom Pung XRD Stadium Karaoke 400 XRD (2M users; 100 servers) 6000 350 4000 300

2000 250 Latency (s) 200

300 0.1 0.2 0.3 0.4 250 f (Fraction of malicious servers)

Latency (s) 200 150 Figure 6: Latency of XRD for different values of f . 100 50 150 XRD(100 servers; f = 0.2) 0 50 100 150 200 Number of servers 100

Figure 5: End-to-end latency of XRD for varying numbers 50 of servers with 2 million users. We show Pung and Atom on Latency (s) a different time scale. 5000 20000 50000 80000 100000 with the number of users. This is 13.3× and 4× faster than Number of malicious users Atom and Pung, and 3× and 22.8× worse than Stadium and Figure 7: Latency of blame protocol. Karaoke for the same deployment scenario. Though process- ing a single message in XRD is faster than doing so in Sta- gap increases with more users, as described previously. For dium (since Stadium relies on verifiable shuffle, while XRD Atom and Pung, we estimate that the latency would be com- uses AHS), the overall system is still slower. This is because parable to XRD with about 3,000 servers and 1,000 servers each XRD user submits many messages. For example, each in the network, respectively, for 2 million users. Pung would user submits 15 messages with 100 servers, which is almost need more servers with more users to catch up to XRD due to equivalent to adding 15 users who each submit one mes- the superlinear increase in latency with the number of users. sage. Unfortunately, the performance gap would grow with Impact of f . During setup, the system administrator should more servers due to each user submitting more messages√ (the make a conservative estimate of f to form the chains. Larger rate at which the gap grows would be proportional to 2N). f affects latency because it increases in the length of the While XRD cannot provide the same performance as Sta- chains k (§5.2.1). Concretely, with n = 100, k must satisfy − dium or Karaoke with large numbers of users and servers, k −64 log(2 64/100) 100 · f < 2 . Thus, k > log( f ) , which means that XRD can provide stronger cryptographic privacy. the length of a chain (and the latency) grows as a function of When compared to Pung, the speed-up increases further −1 log( f ) . Figure 6 demonstrates this effect. The latency grows with the number of users since the latency of Pung grows su- slowly for f < 0.5. This function, however, grows rapidly perlinearly. This is because the server computation per user when f >> 0.5, and thus the latency would be significantly increases with the number of users. With 4 million users, for worse when considering larger values of f . example, XRD is 8× faster. For Atom, the latency increases Atom would experience the same effect since its mix linearly, but with higher slope. This is due to its heavy re- chains are created using the same strategy as XRD. Karaoke liance on expensive public key cryptography and long routes also experiences similar increase in latency with f , as every for the messages (over 300 servers). message must be routed through a number of servers propor- 1 Scalability. Figure 5 shows how the latency decreases with tional to | log f | as well. Stadium would face more signifi- the number of servers with 2 million users.We experimented cant increase in latency with f as its mix chains similarly get with up to 200 servers, and observed the expected scaling longer with f , and the length of the chains has a superlinear p pattern: the latency of XRD reduces as 2/N with N servers effect on the latency due to zero-knowledge proof verifica- (§4). In contrast, prior works scale as 1/N, and thus will out- tion [52, §10.3]. The latency of Pung does not increase with perform XRD with enough servers. Still, because XRD em- f since it already assumes f = 1. ploys more efficient cryptography, XRD outperforms Atom Blame protocol. Malicious users could send misauthenti- and Pung with less than 200 servers. cated ciphertexts to trigger the blame protocol, and slow To estimate the performance of larger deployments, we ex- down the system. Since malicious users’ messages are re- trapolated our results to more servers. We estimate that XRD moved as soon as servers find them, the users cause the most can support 2 million users with 1,000 servers in about 84s, slowdown when the misauthenticated ciphertexts are discov- while Stadium and Karaoke can do so in about 8s and 2s, re- ered at the last server. The performance of the blame proto- spectively. (At this point, the latency between servers would col also depends on the number of malicious users. In Fig- be the dominating factor for Stadium and Karaoke.) This ure 7, we therefore show the latency of the blame protocol 0.8 about 27% of the conversations to experience failure, and 0.7 XRD (1000 servers) XRD (500 servers) the end-points would have to resend their conversation mes- 0.6 XRD (100 servers) 0.5 sages. Unfortunately, the failure rate quickly increases with 0.4 the server churn rates, reaching 70% with 4% server fail- 0.3 ures, as more chains contain at least one failing server. Thus, 0.2 it would be easy for the adversary who controls a non-trivial 0.1

Conversation failure0 rate .0 fraction of the servers to launch a denial-of-service attack. 0.000 0.005 0.010 0.015 0.020 0.025 0.030 0.035 0.040 Addressing this concern remains important future work. Server churn rate When compared to Pung, the availability guarantees can Figure 8: Fraction of conversations that fail in a given round be significantly worse, assuming Pung replicates all users’ due to server failures for different server churn rates. messages across all servers. In this case, the conversation as a function of the number of malicious users in a chain failure rate would be equal to the server churn rate with users of 32 servers when the last server detects misbehavior. The evenly distributed across all Pung servers, and the users con- blame protocol requires two discrete log equivalence proofs nected to the failing servers could be rerouted to other servers and decryption per user for each layer of encryption (§6.4). to continue communication. Atom can tolerate any fraction γ Concretely, if 5,000 users misbehave in a chain, the blame of the servers failing using threshold cryptography [17], but protocol takes about 13s. This cost increases linearly with the latency grows with γ. For example, to tolerate γ = 1% the number of users: if 100,000 users misbehave in a chain servers failing, we estimate that Atom would be about 10% (which corresponds to approximately a third of all users be- slower [34, Appendix B]. Stadium and Karaoke, however, ing malicious with 100 servers and 2 million users in the net- are more affected by server churn. Stadium uses two lay- work), the protocol takes about 150s. As a result, the overall ers of parallel mix-nets, and fully connects the chains across round would take 378s, instead of 228s, for 2 million users. the two layers. As a result, even one server failure would Still, this is 8× and 2.4× faster than Atom and Pung. In cause the whole system to come to a halt. (Stadium does not practice, the blame protocol could be faster since the hon- provide a fault recovery mechanism, and the security impli- est server is likely to be not the last server. For example, if cations of continuing the protocol without the failing chains the honest server is the 16th server, then the blame protocol are not analyzed [52].) Similarly, Karaoke uses layers of would take half the time. The overall round would then take interconnected mixing servers, and a single server failure re- around 303s. sults in the failure of the whole network. While this is a significant increase in latency, malicious 8 Conclusion users are removed from the network once servers identify them. To cause serious slowdowns across many rounds, the XRD provides a unique design point in the space of meta- adversary needs to constantly create new malicious users. data private communication systems by achieving crypto- Then, by employing defenses against Sybil attacks (e.g., im- graphic privacy and horizontal scalability using efficient posing a small cost for user registration such as proof-of- cryptographic primitives. XRD organizes the servers into work [23] or CAPTCHA [54]), we could limit the effective- multiple small chains that process messages in parallel, and ness of an adversary. can scale easily with the number of servers by adding more Malicious users can have varying degree of impact in prior chains. We hide users’ communication patterns by ensuring systems. Pung and Karaoke are not affected by malicious every user is equally likely to be talking to any other user, and users, and Stadium has a blame protocol similar to XRD to hiding the origins of users’ messages through mix-nets. We handle malicious users. Atom, however, is the significantly then efficiently protect against active attacks using a novel affected: a single malicious user can launch a DoS attack in technique called aggregate hybrid shuffle. Our evaluation on the faster variant used for comparison in this paper [34, §4.4]. a network of 100 servers demonstrates that XRD can support The slower variant of Atom that can handle adversarial users 2 million users in 228 seconds, which is 13× and 4× faster is at least 4× slower [34, §6], meaning it would be at least than Atom and Pung, two prior systems with cryptographic 30× slower than XRD overall. privacy guarantees. 7.3 Availability Acknowledgements To estimate the effect of server churn on a XRD network, We thank Jun Wan, Daniel Grier, Ling Ren, Alin Tomescu, we simulated deployment scenarios with 2 million users and Zack Newman and Kyle Hogan for valuable feedback and different numbers of servers. We assumed that all users were discussion during this project. We also thank Paul Grubbs in a conversation, and show the fraction of the users whose for pointing out a flaw in our initial proof. Finally, we thank conversation messages did not reach their partner in Fig- the anonymous reviewers of NSDI, and our shepherd Raluca ure 8. For example, if 1% of the servers fail in a given round Ada Popa. This work was partially supported by a National (comparable to server churn rate in Tor [1]), then we expect Science Foundation grant (1813087). References [15] George Danezis, Roger Dingledine, David Hopwood, [1] Tor metrics portal. https://metrics.torproject.org. and Nick Mathewson. Mixminion: Design of a type III anonymous remailer protocol. In IEEE Symposium on [2] Mehmet Adalier. Efficient and secure elliptic curve Security and Privacy, pages 2–15, 2003. cryptography implementation of curve p-256. 2015. [16] George Danezis and Andrei Serjantov. Statistical dis- [3] Carlos Aguilar-Melchor, Joris Barrier, Laurent Fousse, closure or intersection attacks on anonymity systems. and Marc-Olivier Killijian. Xpir: Private information In Jessica Fridrich, editor, Information Hiding, pages retrieval for everyone. PETS, 2016(2):155–174, 2016. 293–308, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg. [4] Sebastian Angel, Hao Chen, Kim Laine, and Srinath Setty. Pir with compressed queries and amortized query [17] Alfredo De Santis, Yvo Desmedt, Yair Frankel, and processing. In 2018 IEEE Symposium on Security and Moti Yung. How to share a function securely. In Pro- Privacy (SP), volume 00, pages 1011–1028. ceedings of the Twenty-sixth Annual ACM Symposium on Theory of Computing, STOC ’94, pages 522–533, [5] Sebastian Angel and Srinath Setty. Unobservable New York, NY, USA, 1994. ACM. communication over fully untrusted infrastructure. In OSDI, pages 551–569, GA, 2016. USENIX Associa- [18] Tim Dierks and Eric Rescorla. The transport layer secu- tion. rity (tls) protocol version 1.2. RFC 5246, RFC Editor, August 2008. http://www.rfc-editor.org/rfc/ [6] Mihir Bellare, Phillip Rogaway, and David Wagner. rfc5246.txt. Eax: A conventional authenticated-encryption mode. [19] Roger Dingledine. One cell is enough to break Cryptology ePrint Archive, Report 2003/069, 2003. tor’s anonymity. https://blog.torproject. https://eprint.iacr.org/2003/069. org/one-cell-enough-break-tors-anonymity, [7] Joseph Bonneau, Jeremy Clark, and Steven Goldfeder. February 2009. On Bitcoin as a public randomness source. https: [20] Roger Dingledine and Nick Mathewson. Anonymity //eprint.iacr.org/2015/1015.pdf, 2015. loves company: Usability and the network effect.

[8] Justin Brickell and Vitaly Shmatikov. Efficient [21] Roger Dingledine, Nick Mathewson, and Paul Syver- anonymity-preserving data collection. In KDD, pages son. Tor: The Second-Generation Onion Router. 76–85, New York, NY, USA, 2006. ACM. In USENIX Security Symposium, pages 303–320. USENIX Association, August 2004. [9] Jan Camenisch and Markus Stadler. Proof systems for general statements about discrete logarithms. Technical [22] Cynthia Dwork. Differential privacy. In Proceedings of report, 1997. the 33rd International Conference on Automata, Lan- guages and Programming - Volume Part II, ICALP’06, [10] David Chaum. Untraceable electronic mail, return ad- pages 1–12, Berlin, Heidelberg, 2006. Springer-Verlag. dresses, and digital pseudonyms. Communications of the ACM, 24(2):84–90, February 1981. [23] Cynthia Dwork and Moni Naor. Pricing via process- ing or combatting junk mail. In Ernest F. Brickell, [11] David Chaum. The dining cryptographers prob- editor, CRYPTO, pages 139–147, Berlin, Heidelberg, lem: Unconditional sender and recipient untraceability. 1993. Springer Berlin Heidelberg. Journal of Cryptology, 1(1):65–75, March 1988. [24] Michael J. Freedman and Robert Morris. Tarzan: A [12] Benny Chor, Eyal Kushilevitz, Oded Goldreich, and peer-to-peer anonymizing network layer. In CCS, CCS Madhu Sudan. Private information retrieval. Journal ’02, pages 193–206, New York, NY, USA, 2002. ACM. of the ACM, 45(6):965–981, November 1998. [25] Jun Furukawa and Kazue Sako. An efficient scheme [13] Henry Corrigan-Gibbs, Dan Boneh, and David for proving a shuffle. In CRYPTO, pages 368–387. Mazieres.` Riposte: An anonymous messaging system Springer-Verlag, 2001. handling millions of users. In IEEE Symposium on Se- curity and Privacy, pages 321–338, May 2015. [26] Philippe Golle, Sheng Zhong, Dan Boneh, Markus Jakobsson, and Ari Juels. Optimistic mixing for exit- [14] Henry Corrigan-Gibbs and Bryan Ford. Dissent: Ac- polls. In International Conference on the Theory and countable anonymous group messaging. In CCS, pages Application of Cryptology and Information Security, 340–350, New York, NY, USA, 2010. ACM. pages 451–465. Springer, 2002. [27] Jens Groth and Steve Lu. Verifiable shuffle of large size [39] Stevens Le Blond, David Choffnes, Wenxuan Zhou, ciphertexts. In PKC, pages 377–392, 2007. Peter Druschel, Hitesh Ballani, and Paul Francis. To- wards efficient traffic-analysis resistant anonymity net- [28] Paul Grubbs, Jiahui Lu, and Thomas Ristenpart. Mes- works. In SIGCOMM, pages 303–314, New York, NY, sage franking via committing authenticated encryp- USA, 2013. ACM. tion. In Jonathan Katz and Hovav Shacham, editors, CRYPTO, pages 66–97. Springer International Publish- [40] Moxie Marlinspike and Trevor Perrin. Signal specifi- ing, 2017. cations. https://https://signal.org/docs/.

[29] Amir Houmansadr and Nikita Borisov. The need [41] Susan E. McGregor, Polina Charters, Tobin Holliday, for flow fingerprints to link correlated network flows. and Franziska Roesner. Investigating the computer se- In Emiliano De Cristofaro and Matthew Wright, edi- curity practices and needs of journalists. In USENIX tors, Privacy Enhancing Technologies, pages 205–224, Security, pages 399–414, Washington, D.C., August Berlin, Heidelberg, 2013. Springer Berlin Heidelberg. 2015. USENIX Association.

[30] Aaron Johnson, Chris Wacek, Rob Jansen, Micah [42] Marcela S. Melara, Aaron Blankstein, Joseph Bon- Sherr, and Paul Syverson. Users get routed: Traffic neau, Edward W. Felten, and Michael J. Freedman. correlation on Tor by realistic adversaries. In CCS, CONIKS: Bringing key transparency to end users. In November 2013. 24th USENIX Security Symposium (USENIX Security 15), pages 383–398, Washington, D.C., 2015. USENIX [31] Dogan Kedogan, Dakshi Agrawal, and Stefan Penz. Association. Limits of anonymity in open environments. In Fabien [43] Steve Mills. Defining the delicate and often dif- A. P. Petitcolas, editor, Information Hiding, pages 53– ficult relationship between reporters and sources. 69, Berlin, Heidelberg, 2003. Springer Berlin Heidel- https://www.propublica.org/article/ berg. ask-propublica-illinois-reporters\ [32] H. Krawczyk, M. Bellare, and R. Canetti. Hmac: -and-sources-relationship, April 2018. Keyed-hashing for message authentication. RFC 2104, [44] Prateek Mittal and Nikita Borisov. Shadowwalker: RFC Editor, February 1997. Peer-to-peer anonymous communication using redun- dant structured topologies. In CCS, CCS ’09, pages [33] H. Krawczyk and P. Eronen. Hmac-based extract-and- 161–172, New York, NY, USA, 2009. ACM. expand key derivation function (hkdf). RFC 5869, RFC Editor, May 2010. [45] C. Andrew Neff. A verifiable secret shuffle and its ap- plication to e-voting. In CCS, pages 116–125, New [34] Albert Kwon, Henry Corrigan-Gibbs, Srinivas De- York, NY, USA, 2001. ACM. vadas, and Bryan Ford. Atom: Horizontally scaling strong anonymity. In Proceedings of the 26th Sym- [46] Andreas Pfitzmann and Marit Hansen. A terminol- posium on Operating Systems Principles, SOSP ’17, ogy for talking about privacy by data minimization: pages 406–422, New York, NY, USA, 2017. ACM. Anonymity, unlinkability, undetectability, unobserv- ability, pseudonymity, and identity management. Au- [35] Albert Kwon, David Lazar, Srinivas Devadas, and gust 2010. Bryan Ford. Riffle: An efficient communication sys- tem with strong anonymity. In PETS, volume 2016, [47] Ania M. Piotrowska, Jamie Hayes, Tariq Elahi, Se- pages 115–134, 2015. bastian Meiser, and George Danezis. The loopix anonymity system. In USENIX Security Symposium, [36] Ben Laurie, Adam Langley, and Emilia Kasper. Certifi- pages 1199–1216, Vancouver, BC, 2017. USENIX As- cate transparency. RFC 6962, RFC Editor, June 2013. sociation.

[37] David Lazar, Yossi Gilad, and Nickolai Zeldovich. [48] David Pointcheval and Jacques Stern. Security proofs Karaoke: Fast and strong metadata privacy with low for signature schemes. In Ueli Maurer, editor, EU- noise. In OSDI, Carlsbad, CA, 2018. USENIX Associ- ROCRYPT, pages 387–398, Berlin, Heidelberg, 1996. ation. Springer Berlin Heidelberg.

[38] David Lazar and Nickolai Zeldovich. Alpenhorn: [49] Michael K. Reiter and Aviel D. Rubin. Anonymous Bootstrapping secure communication without leaking web transactions with crowds. Communications of the metadata. In OSDI, 2016. ACM, 42(2):32–48, February 1999. mskh [50] Ewa Syta, Philipp Jovanovic, Eleftherios Kokoris Ko- (mpkh = bpki−1 ,mskh), and (ipkh,iskh), and sends the gias, Nicolas Gailly, Linus Gasser, Ismail Khoffi, public keys to the client and the adversary. Michael J. Fischer, and Bryan Ford. Scalable bias- 3. The client generates random {x j} j∈XH , and resistant distributed randomness. In IEEE Symposium j j {c j = (X = gx j ,c )} using the protocol de- on Security and Privacy, pages 444–460, May 2017. 1 1 j∈XH scribed in §6.2. It also generates a NIZK that it knows x j j j [51] Alin Tomescu and Srinivas Devadas. Catena: Efficient that corresponds to X1 for each j, and sends both {c } non-equivocation via bitcoin. In 2017 IEEE Sympo- and the NIZKs to the adversary and the verifier. sium on Security and Privacy (SP), pages 393–409, 4. The adversary generates its input messages May 2017. j j j {c = (X1 ,c1)} j∈XA (not necessarily by following [52] Nirvan Tyagi, Yossi Gilad, Derek Leung, Matei Za- the protocol in §6.2). It generates a NIZK that shows it X j {c j} haria, and Nickolai Zeldovich. Stadium: A distributed knows the discrete log of 1 and sends j∈XA and the metadata-private messaging system. In SOSP, SOSP NIZKs to the client and the verifier. ’17, pages 423–440, New York, NY, USA, 2017. ACM. 5. The verifier verifies all NIZKs. 6. For i = 1,...,h − 1, the adversary sends the verifier [53] Jelle Van Den Hooff, David Lazar, Matei Zaharia, and j Nickolai Zeldovich. Vuvuzela: Scalable private mes- {Xi+1} j∈[M], and a NIZK that shows saging resistant to traffic analysis. In SOSP, pages 137– bsk M ! i M 152. ACM, 2015. j j ∏ Xi = ∏ Xi+1 [54] Luis von Ahn, Manuel Blum, Nicholas J. Hopper, and j=1 j=1 John Langford. Captcha: Using hard ai problems for security. In Eli Biham, editor, EUROCRYPT, pages by proving that

294–311, Berlin, Heidelberg, 2003. Springer Berlin M ! j Heidelberg. log j X = log (bpk ) . ∏M X ∏ i+1 bpki−1 i j=1 i j=1 [55] David Isaac Wolinsky, Henry Corrigan-Gibbs, Bryan Ford, and Aaron Johnson. Dissent in numbers: Mak- j 0 It also sends the ciphertexts {c } to the verifier. ing strong anonymity scale. In OSDI, pages 179–182, h Hollywood, CA, 2012. USENIX Association. 7. The verifier verifies all NIZKs, and checks that 0 j mskh j ADec((Xh ) ,ch ) = (1,·) for all j ∈ [M]. A Security of aggregate hybrid shuffle The game halts if the verifier fails to verify any NIZKs or The adversary’s goal is to have an upstream server suc- authenticated decryption ever fails (i.e., returns (0,·)). The cessfully tamper with some messages without getting de- adversary wins the game if the game does not halt and it has tected by the honest server. To model this, we consider the successfully tampered with some messages. In other words, following security game between three parties: the client, the adversary wins if bsk the adversary, and the verifier. All parties are given the total  M j i M j 1. ∏ j=1 Xi = ∏ j=1 Xi+1 for all i = 1,...,h − 1, number of users M. The client controls users in set XH ⊂ [M] (this models the honest users), and the adversary controls 2. there exists XT ⊂ XH such that |XT | > 0 and for all j ∈ XT j j X M \X ∏i

j bskA·mskh j mskh each combination for j ∈ XH . We indicate which combina- different keys (X1 ) and (Xh ) . However, if tions are possible for the adversary to satisfy, given that all we model the underlying hash function of HMAC as a authenticated decryptions were successful. random oracle, then the HMAC instantiated with a ran- 0 j j j bskA j j mskh dom key is a random function. This implies that the 1. ch =6 ch , (X1 ) =6 Xh , KNOW((Xh ) ) = 0: IM- POSSIBLE. Since the adversary does not know the key probability that the same ciphertext authenticates under j mskh two different keys (i.e., collision of two random func- used to decrypt (i.e., (Xh ) ), it cannot generate a valid ciphertext. tions) is negligible when using Encrypt-then-HMAC. 0 j j 0 j j j j j j bsk j j msk bskA mskh 6. c = c , (X ) A =6 X , KNOW((X ) h ) = 1: POS- 2. ch =6 ch , (X1 ) =6 Xh , KNOW((Xh ) ) = 1: POSSI- h h 1 h h BLE. Since the adversary knows the key used to decrypt SIBLE. Since the adversary knows and controls the key it could generate a valid ciphertext. used for decryption (in particular, the HMAC), it may be 0 able to find a key that is different from the key used to j j j bskA j j mskh 3. ch =6 ch , (X1 ) = Xh , KNOW((Xh ) ) = 0: IM- encrypt that results in valid decryption. POSSIBLE. Same argument as case 1. 0 j j j bskA j j mskh 0 7. ch = ch , (X1 ) = Xh , KNOW((Xh ) ) = 0: POS- j j j bskA j j mskh 4. ch =6 ch , (X1 ) = Xh , KNOW((Xh ) ) = 1: IM- SIBLE. This corresponds to an untampered message. POSSIBLE. If possible, then the adversary can break 0 j j j bskA j j mskh the Diffie-Hellman assumption. Namely, given only 8. ch = ch , (X1 ) = Xh , KNOW((Xh ) ) = 1: IM- j x j bskA mskh X1 = g , bskA, and (g ) for random x j and mskh POSSIBLE. Same argument as case 4. and an independently generated bskA, it can compute Thus, there are three possible combinations of predicates: j mskh x j·bskA·mskh j j 0 j bsk j j msk j (Xh ) = g . If this were possible, then given (c =6 c , (X ) A =6 X , KNOW((X ) h ) = 1), (c = a b h h 1 h h h g and g for random a and b, the adversary could gen- j 0 j j j j j 0 c , (X )bskA =6 X , KNOW((X )mskh ) = 1), and (c = c , b bskA a·b·bskA h 1 h h h h erate an bskA, compute (g ) , and compute g . j j j X bskA X X mskh It could then break the Diffie-Hellman assumption and ( 1 ) = h , KNOW(( h ) ) = 0). The first two cases ab a·b·bskA −1 correspond to XT (tampered messages), and the second cor- compute g by raising g to bskA . responds exactly to XH \ XT (untampered messages). 0 j j j bskA j j mskh 5. ch = ch , (X1 ) =6 Xh , KNOW((Xh ) ) = 0: IM- Similarly, consider j ∈ XA. The adversary generates the j j 0 POSSIBLE. If possible, then ch authenticates under two ciphertexts {ch } for the verifier. Thus, the adversary must j mskh know (Xh ) , the key used to authenticate the ciphertext, and the honest server. To do so, ADH chooses the blinding bski b b bskA for j ∈ XA. keys {bski}, and sets mpkh = (∏i g ) = (g ) ; i.e., the Now, we consider the product of the users’ Diffie-Hellman private mixing key of the honest server is b. Then, it gener- keys. Because all NIZKs have to be verified, we have that ates the inputs from the client by generating a random r j for x a+r j ∈ XH and setting g j = g j . It also generates the inputs bsk M ! A M ! j j associated with each message. The adversary (a simulator) ∏ X1 = ∏ Xh . can generate valid NIZKs of knowledge of discrete logs in j j =1 =1 the random oracle model [48]. For the first layer of encryp- X X \ X tion (which is for the “honest server” whose secret key is Consider U = H T , i.e., the set of messages that did j not change. Then, we can divide both sides by the values the unknown b), generate random values for ch, since cipher- j bskA j texts are indistinguishable from random values. For the other associated with XU since (X1 ) = Xh for j ∈ XU : layers of encryption, it can generate correctly authenticated bsk x ! A ! ciphertexts by using g j , {bski}i

! mskh Diffie-Hellman is hard, meaning that it could satisfy at most  mskh  bskA  j j two out of the three conditions to win the game. In turn, this ∏ Xh / ∏ X1 . j∈XT ∪XA j∈XA implies that the honest server will always catch an upstream malicious server misbehaving. This, however, is B Security game and proof sketches !  mskh  jmskh  jbskA We define the security of our system using the following ∏ Xh / ∏ X1 j∈XT ∪XA j∈XA security game played between a challenger and an adversary. msk Both the challenger and the adversary are given the set of  ! !bskA  h users [M] = {1,2,...,M}, the set of servers [N], the fraction X j / X j =  ∏ h ∏ 1  f of servers the adversary can compromise, and the number j∈X ∪X j∈X T A A of chains n.  mskh !bskA 1. The adversary selects the set of malicious servers j =  ∏ X1  , As ⊂ [N] such that |As| ≤ f · N, and the set of malicious j∈XT users Ac ⊂ [M] such that |Ac| ≤ M − 2. The adversary sends As and Ac to the challenger. Let Hs = [M] \ As and where the last step uses the equality from equation 1. This Hc = [N] \ Ac denote the set of honest servers and users. j x bsk msk means that given {X = g j }, bskA, and (g A ) h for un- 1 2. The challenger computes the size of each chain k as a known random {x j} and mskh, and bskA that was generated function of f and n, as described in §5.2. Then, it cre- independently of {x j} and mskh, the adversary was able to bsk ·msk ·∑ x ates n mix chains by repeatedly sampling k servers per compute g A h j∈XT j . This essentially breaks Diffie- group at random. The challenger sends the chain config- Hellman. urations to the adversary. In more detail, consider the following adversary ADH that a b tries to break Diffie-Hellman. ADH is given g and g for 3. The adversary and the challenger generate blinding keys, random a and b, and is asked to compute gab. To compute mixing keys, and inner keys as described in §6.1 and Ap- this, ADH simulates the above game by simulating the clients pendix A. 4. The adversary picks some honest users Ht ⊂ Hc such that Note that this game models a stronger version of XRD, which |Ht | ≥ 2. It generates sets of chains {Cx} for x ∈ Ht allows users to communicate with multiple users on different such that Cx ∩Cy =6 /0for all x,y ∈ Ht . For c ∈ [n], let chains rather than only one user. We could change the game Uc = {x ∈ Ht : c ∈ Cx}. For each chain c, it also gener- slightly to force the challenger to send loopback messages in c c ates the potential messages {mxy} for x,y ∈ Uc where mxy step 5 to model having just one conversation. is the message that may be sent from user x to user y in c Proof sketches. First, we argue that the adversary needs to chain c. The adversary sends Ht , {{mxy}}, and {Cx} to tamper with messages prior to the last honest server shuf- the challenger. fling, as stated in §6. To see why, consider an adversary that 5. The challenger first verifies that every pair of Cx and Cy only tampers with the messages after the last honest server. intersects at least once. If this is not the case, the game The adversary can learn the recipients of all messages, but halts. The challenger then performs the following for not the senders. As a result, the adversary does not learn each chain c ∈ [n]. First, it creates conversation pairs for anything about whether two users x,y ∈ Uc received mes- each chain c {(Xi,Yi)c} ⊂ Uc ×Uc at random such that sages because there exists a conversation pair (x,y)c, or be- every x ∈ Uc appears in exactly one of the pairs. In other cause there were two conversation pairs (x,x)c and (y,y)c. words, every user has a unique conversation partner per This means that any set of conversation pairs is equally likely chain. (If Xi = Yi, then that user is talking with her- to be sampled by the challenger from the adversary’s view, self.) For each (x,y) ∈ {(Xi,Yi)c}, the challenger onion- meaning that the adversary does not gain any advantage. c c encrypts the messages mxy from x to y and myx from y to Thus, we consider an adversary who tampers with messages x with the keys of servers in chain c. Then, it uses the prior to the honest server processing the messages. protocol described in §6.2 to submit the ciphertexts and In this scenario, the adversary in step 7 must follow the the necessary NIZKs. protocol (e.g., no tampering with the messages), as analyzed 6. The adversary generates inputs to the chains for the users in Appendix A. Given this restriction, we now argue that the adversary does not learn anything after playing the security in Ac, and sends them to the chains. game by describing how a simulator of an adversary could 7. The challenger and the adversary take turns processing simulate the whole game with only the public inputs and the the messages in each chain. Within a chain, they perform private values of the adversary. the following for i = 1,...,k: The simulator can simulate step 3 by generating random

(a) If server i ∈ Hs, the challenger performs protocol de- public keys. It can simulate step 5 by generating random scribed in §6.3 to shuffle and decrypt the messages, values in place of the ciphertexts that encrypt the users’ mes- c and also generate an AHS proof. The challenger then sages {{mxy}}, since the ciphertexts are indistinguishable sends the proof to the adversary, and the resulting from random. It then randomly matches a user in Uc to messages to the owner of server i + 1. one of the generated random values for each chain c, and sets the destination of each message as the matched user. It (b) If server i ∈ As, the adversary generates some mes- sages along with an AHS proof. Then, sends the onion-encrypts the final message using the randomly gener- AHS proof to the challenger, and sends the messages ated public keys and the adversary’s public keys. In step 7, the adversary simulates the challenger by randomly permut- to the owner of server i + 1. ing the messages, and removing a layer of the encryption The challenger verifies all AHS proofs. from the messages. (It can remove a layer of encryption 8. The challenger and the adversary decrypt the final result since it knows all layers of onion-encryption.) Finally, it of the shuffle (i.e., the inner ciphertexts). could simulate the challenger’s last challenge by picking sets of randomly generated conversation pairs, subject to the con- 9. The challenger samples a random bit b ← 0,1. If straints in step 5. The distribution of the messages generated b 0, then send the adversary { X ,Y } for ∈ n . = ( i i)c c [ ] and exchanged in the security game and in the simulator are If b = 1, then sample random conversation pairs 0 0 indistinguishable for a computationally limited adversary. {(Xi ,Yi )c} ⊂ Uc ×Uc for each chain with the same con- straint as in step 5, and send the adversary the newly sampled pairs. 10. The adversary makes a guess b0 for b. The adversary wins the game if the game does not come to a halt before the last step and b0 = b. The adversary need not follow the protocol described in this paper. The advantage 0 1 of the adversary in this game is |Pr[b = b] − 2 |. We say that the system provides metadata private communication if the advantage is negligible in the implicit security parameter.