The Loopix Anonymity System - USENIX Loopix Anonymity System Ania M. Piotrowska University College London Jamie Hayes University College London Tariq Elahi KU Leuven Sebastian Meiser

This paper is included in the Proceedings of the 26th USENIX Security SymposiumAugust 16–18, 2017 • Vancouver, BC, Canada

ISBN 978-1-931971-40-9

Open access to the Proceedings of the 26th USENIX Security Symposium

is sponsored by USENIX

The Loopix Anonymity SystemAnia M. Piotrowska and Jamie Hayes, University College London; Tariq Elahi, KU Leuven;

Sebastian Meiser and George Danezis, University College London

https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/piotrowska

The Loopix Anonymity System

Ania M. PiotrowskaUniversity College London

Jamie HayesUniversity College London

Tariq ElahiKU Leuven

Sebastian MeiserUniversity College London

George DanezisUniversity College London

Abstract

We present Loopix, a low-latency anonymous commu-nication system that provides bi-directional ‘third-party’sender and receiver anonymity and unobservability.Loopix leverages cover traffic and Poisson mixing—briefindependent message delays—to provide anonymity andto achieve traffic analysis resistance against, includingbut not limited to, a global network adversary. Mixes andclients self-monitor and protect against active attacks viaself-injected loops of traffic. The traffic loops also serveas cover traffic to provide stronger anonymity and a mea-sure of sender and receiver unobservability. Loopix isinstantiated as a network of Poisson mix nodes in a strat-ified topology with a low number of links, which serve tofurther concentrate cover traffic. Service providers medi-ate access in and out of the network to facilitate account-ing and off-line message reception.

We provide a theoretical analysis of the Poisson mix-ing strategy as well as an empirical evaluation of theanonymity provided by the protocol and a functional im-plementation that we analyze in terms of scalability byrunning it on AWS EC2. We show that mix nodes inLoopix can handle upwards of 300 messages per sec-ond, at a small delay overhead of less than 1.5ms ontop of the delays introduced into messages to provide se-curity. Overall message latency is on the order of sec-onds – which is relatively low for a mix-system. Fur-thermore, many mix nodes can be securely added to thestratified topology to scale throughput without sacrific-ing anonymity.

1 Introduction

In traditional communication security, the confidential-ity of messages is protected through encryption, but thisexposes meta-data, such as who is sending messages towhom, to network eavesdroppers. As illustrated by re-

cent leaks of extensive mass surveillance programs1, ex-posing such meta-data leads to significant privacy risks.

Since 2004, Tor [20], a practical manifestation ofcircuit-based onion routing, has become the most popu-lar anonymous communication tool, with systems suchas Herd [33], Riposte [11], HORNET [10] and Vu-vuzela [46] extending and strengthening this paradigm.In contrast, message-based architectures, based on mixnetworks, have become unfashionable due to perceivedhigher latencies, that cannot accommodate real-timecommunications. However, unless cover traffic is em-ployed, onion routing is susceptible to traffic analysis at-tacks [7] by an adversary that can monitor network linksbetween nodes. Recent revelations suggest that capabili-ties of large intelligence agencies approach that of globalpassive observers—the most powerful form of this typeof adversary.

It is not sufficient to provide strong anonymity againstsuch an adversary while providing low-latency commu-nication. A successful system additionally needs to re-sist powerful active attacks and use an efficient, yet se-cure way of transmitting messages. Moreover, the sys-tem needs to be scalable to a large number of clients,which makes classical approaches based on synchro-nized rounds infeasible.

For this reason we reexamine and reinvent mix-basedarchitectures, in the form of the Loopix anonymity sys-tem. Loopix is resists powerful adversaries who are ca-pable of observing all communications and performingactive attacks. We demonstrate that such a mix archi-tecture can support low-latency communications that cantolerate small delays, at the cost of using some extrabandwidth for cover traffic. Message delay and the ra-tio of cover to real traffic can all be flexibly traded-offagainst each other to offer resistance to traffic analysis.Loopix provides ‘third-party’ anonymity, namely it hidesthe sender-receiver relationships from third parties, but

1See EFF’s guide at https://www.eff.org/files/2014/05/29/unnecessary_and_disproportionate.pdf

USENIX Association 26th USENIX Security Symposium 1199

https://www.eff.org/files/2014/05/29/unnecessary_and_disproportionate.pdf

https://www.eff.org/files/2014/05/29/unnecessary_and_disproportionate.pdf

senders and recipients can identify one another. Thissimplifies the design of the system, prevents abuse, andprovides security guarantees against powerful active ad-versaries performing (n−1) attacks [41].

Loopix provides anonymity for private email or instantmessaging applications. For this reason, we adopt andleverage an architecture by which users of Loopix areassociated with service providers that mediate their ac-cess to a stratified anonymity system. Such providers areonly semi-trusted2, and are largely present to maintainaccounting, enforce rate limiting, and ensure messagessent to off-line users can be retrieved at a later time. Toprovide maximal flexibility, Loopix only guarantees un-reliable datagram transmission and is carried over UDP.Reliable transport is left to the application as an end-to-end concern [39].

Contributions. In this paper we make the following con-tributions:• We introduce Loopix, a new message-based anony-

mous communication system. It allows for a tun-able trade-off between latency and genuine andcover traffic volume to foil traffic analysis.• As a building block of Loopix we present the Pois-

son Mix, and provide novel theorems about its prop-erties and ways to analyze it as a pool-mix. Pois-son mixing does not require synchronized rounds,can be used for low-latency anonymous communi-cation, and provides resistance to traffic analysis.• We analyze the Loopix system against a strong,

global passive adversary. Moreover, we show thatLoopix provides resistance against active attacks,such as trickling and flooding. We also present amethodology to empirically estimate the securityprovided by particular mix topologies and other se-curity parameter values.• We provide a full implementation of Loopix and

measure its performance and scalability in a cloudhosting environment.

Outline. The remainder of this paper is organized asfollows. In Section 2, we present a brief, high-leveloverview of Loopix and define the security goals andthreat model. In Section 3, we detail the design of Loopixand describe Poisson mixes, upon which Loopix is basedand introduce their properties. In Section 4, we presentthe analysis of Loopix’s security properties and discussthe resistance against traffic analysis and active attacks.In Section 5, we discuss the implementation of Loopixand evaluate its performance. In Section 6, we surveyrelated works and compare Loopix with recent designsof anonymity systems. In Section 7, we discuss remain-ing open problems and possible future work. Finally, weconclude in Section 8.

2Details about the threat model are in Section 2.3

2 Model and Goals

In this section, we first outline the design of Loopix.Then we discuss the security goals and types of adver-saries that Loopix guarantees users’ privacy against.

2.1 High-level overview

Loopix is a mix network [8] based architecture allow-ing users, distinguished as senders and receivers, to routemessages anonymously to each other using an infrastruc-ture of mix servers, acting as relays. These mix serversare arranged in a stratified topology [21] to ensure bothhorizontal scalability and a sparse topology that concen-trates traffic on a few links [13]. In a stratified topology,mixes are arranged in a fixed number of layers. Eachmix, at any given time, is assigned to one specific layer.Each mix in layer i is connected with every mix in layersi−1 and i+1. Each user is allowed to access the Loopixnetwork through their association with a provider, a spe-cial type of mix server. Each provider has a long-termrelationship with its users and may authenticate them,potentially bill them, or discontinue their access to thenetwork. Each provider is connected to each mix in thefirst layer, in order to inject packets into the mix net-work, and also to every mix in the last layer, to receiveegress packets. The provider not only serves as an accesspoint, but also stores users’ incoming messages. In con-trast to previous anonymous messaging designs [46, 11],Loopix does not operate in deterministic rounds, but runsas a continuous system. This means that incoming mes-sages can be retrieved at any time, hence users do nothave to worry about lost messages when they are off-line. Additionally, Loopix uses the Poisson mixing tech-nique that is based on the independent delaying of mes-sages, which makes the timings of packets unlinkable.This approach does not require the synchronization ofclient-provider rounds and does not degrade the usabilityof the system for temporarily off-line clients. Moreover,Loopix introduces different types of cover traffic to foilde-anonymization attacks.

2.2 Threat Model

Loopix assumes sophisticated, strategic, and well-resourced adversaries concerned with linking users totheir communications and/or their communication part-ner(s). As such, Loopix considers adversaries with threedistinct capabilities, that are described next.

Firstly, a global passive adversary (GPA) is able to ob-serve all network traffic between users and providers andbetween mix servers. This adversary is able to observethe entire network infrastructure, launch network attackssuch as BGP re-routing [4], or conduct indirect observa-

1200 26th USENIX Security Symposium USENIX Association

GPA Corrupt mixes Corrupt provider InsiderSender-Recipient Third-Party Unobservability X X X XSender online unobservability X X X •Sender anonymity X X X XReceiver unobservability X X •Receiver anonymity X X •

Table 1: The summary of security properties of the Loopix system in face of different threats. For the insider column we write • todenote that this concept doesn’t apply to the respective notion.

tions such as load monitoring and off-path attacks [25].Thus, the GPA is an abstraction that represents many dif-ferent classes of adversaries able to observe some or allinformation between network nodes.

Secondly, the adversary has the ability to observe allof the internal state of some corrupted or malicious mixrelays. The adversary may inject, drop, or delay mes-sages. She also has access to, and leverages, all se-crets of those compromised parties. Furthermore, suchcorrupted nodes may deviate from the protocol, or in-ject malformed messages. A variation of this ability iswhere the mix relay is also the provider node meaningthat the adversary additionally knows the mapping be-tween clients and their mailboxes. When we say that aprovider node is corrupt, we restrict that node to beinghonest but curious. In Loopix, we assume that a fractionof mix/provider relays can be corrupted or are operatedby the adversary.

Finally, the adversary has the ability to participate inthe Loopix system as a compromised user, who mayalso deviate from the protocol. We assume that the ad-versary can control a limited number of such users—effectively excluding Sybil attacks [22] from the Loopixthreat model—since we assume that honest providers areable to ensure that at least a large fraction of their usersbase are genuine users faithfully following all Loopixprotocols. Thus, the fraction of users controlled by theadversary may be capped to a small known fraction of theuser base. We further assume that the adversary is ableto control a compromised user in a conversation with anhonest user, and become a conversation insider.

An adversary is always assumed to have the GPA ca-pability, but other additional capabilities depend on theadversary. We evaluate the security of Loopix in refer-ence to these capabilities.

2.3 Security GoalsThe Loopix system aims to provide the following secu-rity properties against both passive and active attacks—including end-to-end correlation and (n − 1) attacks.These properties are inspired by the formal definitionsfrom AnoA [3]. All security notions assume a strong ad-versary with information on all users, with up to one bit

of uncertainty. In the following we write {S→ R} to de-note a communication from the sender S to the receiverR, {S→} to denote that there is a communication from Sto any receiver and {S 6→} to denote that there is no com-munication from S to any receiver (S may still send covermessages). Analogously, we write {→ R} to denote thatthere is a communication from any sender to the receiverR and {6→ R} to denote that there is no communicationfrom any sender to R (however, R may still receive covermessages).

Sender-Receiver Third-party Unlinkability. Thesenders and receivers should be unlinkable by any unau-thorized party. Thus, we consider an adversary thatwants to infer whether two users are communicating. Wedefine sender-receiver third party unlinkability as the in-ability of the adversary to distinguish whether {S1→ R1,S2 → R2} or {S1 → R2,S2 → R1} for any online honestsenders S1,S2 and honest receivers R1,R2 of the adver-sary’s choice.

Loopix provides strong sender-receiver third-party un-linkability against the GPA even in collaboration withcorrupt mix nodes. We refer to Section 4.1.3 forour analysis of the unlinkability provided by individ-ual mix nodes, Section 4.3 for a quantitative analysisof the sender-receiver third-party unlinkability of Loopixagainst the GPA and honest-but-curious mix nodes, andSection 4.2 for our discussion on malicious mixes per-forming active attacks.

Sender online unobservability. Whether or not sendersare communicating should be hidden from an unautho-rized party. We define sender online unobservability asthe inability of an adversary to decide whether a specificsender S is communicating with any receiver {S→} ornot {S 6→}, for any concurrently online honest sender Sof the adversary’s choice.

Loopix provides strong sender online unobservabilityagainst the GPA and even against a corrupt provider. Werefer to Section 4.1.2 for our analysis of the latter.

Note, that sender online unobservability directly im-plies the notion of sender anonymity where the adver-sary tries to distinguish between two possible senderscommunicating with a target receiver. Formally, {S1 →R,S2 6→} or {S1 6→,S2→ R} for any concurrently online


honest senders S1 and S2 and any receiver of the adver-sary’s choice. Loopix provides sender anonymity evenin light of a conversation insider, i.e., against a corruptreceiver.

Receiver unobservability. Whether or not receivers arecommunicating should be hidden from an unauthorizedparty. We define receiver unobservability as the inabilityof an adversary to decide whether any sender is commu-nicating with a specific receiver R {→ R} or not {6→ R},for any online or offline honest receiver R of the adver-sary’s choice.

Loopix provides strong receiver unobservabilityagainst the GPA, under the condition of an honestprovider. We show in Section 4.1.2 how an honestprovider assists the receiver in hiding received messagesfrom third party observers.

Note, that receiver unobservability directly implies thenotion of receiver anonymity where the adversary tries todistinguish between two possible receivers in communi-cation with a target sender. Formally, {S→ R1, 6→ R2}or {6→ R1,S→ R2} for any concurrently online honestsender S and any two honest receivers R1,R2 of the ad-versary’s choice. 3

Non-Goals. Loopix provides anonymous unreliabledatagram transmission and facilities replying to sentmessages (through add-ons). This choice allows for flex-ible traffic management, cover traffic, and traffic shap-ing. On the downside, higher-level applications usingLoopix need to take care of reliable end-to-end trans-mission and session management. We leave the detailedstudy of those mechanisms as future work.

The provider-based architecture supported by Loopixaims to enable managed access to the network, anony-mous blacklisting to combat abuse [27], and paymentsfor differential access to the network [2]. However, wedo not discuss these aspects of Loopix in this work, andconcentrate instead on the core anonymity features andsecurity properties described above.

3 The Loopix Architecture

In this section we describe the Loopix system in detail—Figure 1 provides an overview. We also introduce the no-tation used further in the paper, summarized in Table 2.

3.1 System SetupThe Loopix system consists of a set of mix nodes, N,and providers, P. We consider a population of U users

3If the receiver’s provider is honest, Loopix provides a form ofreceiver anonymity even in light of a conversation insider: a corruptsender that only knows the pseudonym of a receiver cannot learn whichhonest client of a provider is behind the pseudonym.

Symbol Description

N Mix nodesP ProvidersλL Loop traffic rate (user)λD Drop cover traffic rate (user)λP Payload traffic rate (user)l Path length (user)µ The mean delay at mix MiλM Loop traffic rate (mix)

Table 2: Summary of notation

communicating through Loopix, each of which can act assender and receiver, denoted by indices Si, Ri, where i ∈{1, . . . ,U} respectively. Each entity of the Loopix infras-tructure has its unique public-private key pair (sk, pk). Inorder for a sender Si, with a key pair (skSi , pkSi), to senda message to a receiver R j, with a key pair (skR j , pkR j),the sender needs to know the receiver’s Loopix networklocation, i.e., the IP address of the user’s provider andan identifier of the user, as well as the public encryptionkey pkR j . Since it is out of scope for this work, we willassume this information can be made available through aprivacy-friendly lookup or introduction system for initi-ating secure connections [32].

3.2 Format, Paths and Cover Traffic

Message packet format. All messages in Loopix areend-to-end encrypted and encapsulated into packets to beprocessed by the mix network. We use the Sphinx packetdesign [16], to ensure that intermediate mixes learn noadditional information beyond some routing information.All messages are padded to the same length, which hidesthe path length and the relay position and guarantees un-linkability at each hop of the messages’ journey over thenetwork. The Sphinx packet format allows for detectionof tagging attacks and replay attacks.

Each message wrapped into the Sphinx packet consistsof a concatenation of two separate parts: a header, car-rying the layered encryption of meta-data for each hop,and the encrypted payload, which allows for confidentialmessage exchange. The header provides each mix serveron the path with confidential meta-data, which is neces-sary to verify packet integrity and correctly process thepacket. The structure of the header consists of (I) a singleelement of a cyclic group that is re-randomized at eachhop, (II) an onion-encrypted vector, with each layer con-taining the routing information for one hop, and (III) themessage authentication code MACi, which allows headerintegrity checking. The payload is encrypted using theLIONESS cipher [1], which guarantees that in case theadversary modifies the payload in transit, any informa-


Storage

Storage

Storage

Storage

Users’ loop cover trafficgenerates trafficin two directions

Mixes can detectn-1 attacks

Providers offeroffline storage

when user is offline

Figure 1: The Loopix Architecture. Clients pass the messagesto the providers, which are responsible for injecting traffic intothe network. The received messages are stored in individualinboxes and retrieved by clients when they are online.

tion contained in it becomes irrecoverable. Thanks to themessage authentication code in the header and the LI-ONESS encryption the Sphinx packet format thus allowsfor detection of tagging attacks.Sphinx packet generation: The sender, given the publickeys of the recipient and the nodes in the path, computesthe sequence of shared secrets and blinded group ele-ments. Next, the sender encrypts with the derived secretkeys the vector of routing information and correspondingmessage authentication codes. The sender concatenatesthe computed header and onion-encrypted payload en-capsulating confidential message to send to the recipient.Sphinx packet processing: Each node after receiv-ing the packet proceeds as follows. First, it computesa shared key using the group element included in thepacket header and its private key. Next, using the com-puted shared key, the node validates the integrity of thepacket by computing the hash of the encrypted routinginformation vector and comparing it with the receivedMAC. If the MAC is correct, the node, using the obtainedkey, strips off a single layer of encryption from the rout-ing information and payload. The decryption operationreturns the routing commands and a new packet, whichshould be forwarded to the next hop.

We extend the Sphinx packet format to carry addi-tional routing commands in the header to each interme-diate relay, including a delay and additional flags.

Path selection. As opposed to circuit-based onionrouting, in Loopix the communication path for every sin-gle message is chosen independently, even between thesame pair of users.

Messages are routed through l layers of mix nodes, as-sembled in a stratified topology [13, 21]. Each mix nodeis connected only with all the mix nodes from adjacent

layers. This ensures that few links are used, and thosefew links are well covered in traffic; stratified topologiesmix well in few layers [21]. Providers act as the first andlast layer of mix servers.

Preparing message for sending. To send a message,the sender generates a random path, as described above.For each hop in the path the sender samples a delayfrom an exponential distribution with parameter µ , andincludes it in the vector of routing commends, togetherwith any other auxiliary information, to the correspond-ing relay. Given the message, recipient, path and rout-ing commends the client encapsulates them into a Sphinxpacket format.

Sending messages and cover traffic. Users and mixservers continuously generate a bed of real and covertraffic that is injected into the network. Our design guar-antees that all outgoing traffic sent by users can by mod-eled by a Poisson process.

To send a message, a user packages their message intoa mix packet and places it into their buffer—a first-in-first-out (FIFO) queue that stores all the messages sched-uled to be sent.

Each sender periodically checks, following the expo-nential distribution with parameter 1

λP, whether there is

any scheduled message to be sent in their buffer. If thereis a scheduled message, the sender pops this messagefrom the buffer queue and sends it, otherwise a dropcover message is generated (in the same manner as a reg-ular message) and sent (depicted as the four middle blue,solid arrows in Figure 1). Cover messages are routedthrough the sender’s provider and a chain of mix nodes toa random destination provider. The destination providerdetects the message is cover based on the special dropflag encapsulated into the packet header, and drops it.Thus, regardless of whether a user actually wants to senda message or not, there is always a stream of messagesbeing sent according to a Poisson process Pois(λP).

Moreover, independently from the above, all usersemit separate streams of special indistinguishable typesof cover messages, which also follow a Poisson process.The first type of cover messages are Poisson distributedloops emitted at rate λL. These are routed through thenetwork and looped back to the senders (the upper fourred arrows in Figure 1), by specifying the sending user asthe recipient. These “loops” inspire the system’s name.Users also inject a separate stream of drop cover mes-sages, defined before, following the Poisson distributionPois(λD). Additionally, each user sends a stream of pullrequests at a fixed frequency to its provider in order toretrieve received messages, described in Section 3.2.


• Packs message m inthe Sphinx packetformat and put itinto the outboxbuffer;

• Continuously gener-ates loop and dropcover traffic;

• When the buffer ischecked, pops theencrypted messageand sends to theprovider.

Sender• Processes the

received packet,checks the in-tegrity and detectsreplays,

• If the processingsucceeded, injectsthe packet into themix network afterthe required delay.

Ingress Provider

• Processes thereceived packet,checks the in-tegrity and detectsreplays,

• If the process-ing succeeded,forwards the de-crypted packet tothe next hop afterthe required delay.

Mix• Processes the

received packet,checks the in-tegrity and detectsreplays,

• Stores the packet inthe client’s inbox.

Egress Provider

• Retrieves a fixednumber of mes-sages from theinbox,

• Unwraps the lastlayer of encryptionand reads thecontent.

Recipient

Figure 2: Sending a single message between two users using the Loopix system. For simplicity, we present the mix networkas a single mix; however, all mixes in the network perform the same operations. The mail client, besides sending the messages,generates constant streams of loop and drop cover traffic, independently of the user activity. The dotted line depicts retrieving ofmessages.

Each mix also injects its own loop cover traffic, drawnfrom a Poisson process with rate Pois(λM), into the net-work. Mix servers inject mix packets that are loopedthrough a path, made up of a subset of other mix serversand one randomly selected provider, back to the sendingmix server, creating a second type of “loop”. This looporiginates and ends in a mix server (shown as the lowerfour green arrows in Figure 1). In Section 4 we exam-ine how these loops and the drop cover messages helpprotect against passive and active attacks.

Processing messages. Upon receiving a packet, eachnode, i.e., each mix and provider, performs the opera-tion of processing the Sphinx packet. While processingthe packet, the server recomputes the shared secret andchecks the MAC’s correctness. If this integrity test fails,the packet is dropped. Otherwise, the unwrapping func-tion returns the replay detection tag and the vector ofrouting commands, as well the new packet. The vectorof routing commands includes, among others, the rout-ing flag, the address of the next hop and the delay. Afterunwrapping the packet, the node checks whether the re-turned replay detection tag has been already seen and ifso, drops the packet. This allows for detection and pro-tection against replay attacks. Otherwise, the node savesthe tag in a data structure that stores previously observedtags. Next, it checks whether the routing flag is set toRelay or Dest. The Dest flag means that the receivedmessage is a loop message transferred back to the node.In the case of the Relay flag, we consider two scenariosdepending on whether the processing node is a mix or aprovider. In the case of a mix, the decrypted new packetis send to the next hop, specified by address, after the de-lay has elapsed. In the case of a provider, the new packet

is either forwarded as before or saved in the inbox of oneof the provider’s clients specified by the address.

Message storing and retrieving. Providers do not for-ward the incoming mix packets to users but insteadbuffer them in clients’ inboxes. Users, when online, pollproviders or register their online status to download afixed subset of stored messages, allowing for the recep-tion of the off-line messages. Recall that cover loops aregenerated by users and traverse through the network andcome back to the sender. Cover loops serve as a coverset of outgoing and incoming real messages. Whenevera user requests messages, their provider responds with aconstant number of messages, which includes their coverloop messages and real messages. If the inbox of a par-ticular user contains fewer messages than this constantnumber, the provider generates and sends dummy mes-sages to the sender up to that number.

3.3 The Poisson Mix Strategy

Loopix leverages cover traffic to resist traffic analysiswhile still achieving low- to mid-latency. To this endLoopix employs a mixing strategy that we call a Pois-son Mix, to foil observers from learning about the cor-respondences between input and output messages. ThePoisson Mix is a simplification of the Stop-and-go mixstrategy [29]. A similar strategy has been used to modeltraffic in onion routing servers [12]. In contrast, recallthat in Loopix each message is source routed through anindependent route in the network.

The Poisson Mix functions as follows: mix servers lis-ten for the incoming mix packets and received messagesare checked for duplication and decoded using the mix


Event i−1

Pool i−1

Event i

Pool i

Event i+1

Pool i+1

Event i+2

Figure 3: The Poisson Mix strategy mapped to a Pool mixstrategy. Each single message sending or receiving event leadsto a new pool of messages that are exchangeable and indistin-guishable with respect to their departure times.

node’s private keys. The detected duplicates are dropped.Next, the mix node extracts a subsequent mix packet.Decoded mix packets are not forwarded immediately,but each of them is delayed according to a source pre-determined delay di. Honest clients chose these delays,independently for each hop, from an exponential distri-bution with a parameter µ that is assumed to be publicand the same for all mix nodes. This parameter deter-mines how long the message is queued in the mix. Thus,the end-to-end latency of the messages depends on theselected parameter µ .

Mathematical model of a Poisson Mix. Honestclients and mixes generate drop cover traffic, loop traf-fic, and messaging traffic following a Poisson process.Aggregating Poisson processes results in a Poisson pro-cess with the sum of their rates, therefore we may modelthe streams of traffic received by a Poisson mix as a Pois-son process. It is the superposition of traffic streams frommultiple clients. It has a rate λn depending on the numberof clients and the number of mix nodes.

Since this input process is a Poisson process and eachmessage is independently delayed using an exponentialdistribution with parameter µ , the Poisson Mix may bemodeled as an M/M/∞ queuing system – for which wehave a number of well known theorems [5]. We knowthat output stream of messages is also a Poisson processwith the parameter λn as the the input process. We canalso derive the distribution of the number of messageswithin a Poisson Mix in a steady state [34]. By the steadystate we mean the state of the system in which all entitieshave already generated and processed messages for somereasonable period of time. By the convergence of the sys-tem to the equilibrium, this guarantees that the observedtraffic closely follows the assumed distribution.

Lemma 1. The mean number of messages in the PoissonMix with input Poisson process Pois(λ ) and exponentialdelay parameter µ at a steady state follows the Poissondistribution Pois(λ/µ).

These characteristics, which give the Poisson Mix itsname, allow us to calculate the mean number of mes-

sages perfectly mixed together at any time, as well as theprobability that the number of messages falls below orabove certain thresholds.

The Poisson Mix, under the assumption that it approx-imates an M/M/∞ queue is a stochastic variant of a poolmixing strategy [42]. Conceptually, every message sentor received leads to a pool within which messages areindistinguishable due to the memoryless property of theexponential delay distribution.

Lemma 2 (Memoryless property [34]). For an exponen-tial random variable X with parameter µ holds Pr[X >s+ t|X > t] = Pr[X > s].

Intuitively, any two messages in the same pool areemitted next with equal probability – no matter how longthey have been waiting. As illustrated in Figure 3, thereceiving event i− 1 leads to a pool of messages i− 1,until the sending event i. From the perspective of the ad-versary observing all inputs and outputs, all messages inthe pool i−1 are indistinguishable from each other. Onlythe presence of those messages in the pool is necessary tocharacterize the hidden state of the mix (not their delayso far). Relating the Poisson mix to a pool mix allowsus to compute easily and exactly both the entropy metricfor the anonymity it provides [40] within a trace (used inSection 4.1.3). It also allows us to compute the likelihoodthat an emitted message was any specific input messageused in our security evaluation.

Synchronous variant of Loopix. While Loopix oper-ates asynchronously by design, we now consider a syn-chronous Loopix variant that operates in discrete roundsand thus cannot use the exponential mixing strategy,where delays attached to the packets are drawn from acontinuous distribution. However, note that in a sin-gle round of the synchronous system the mixes gatherpackets - thus creating pools of packets - which are thenflushed following the mixing strategy. All the messagesgathered in the pool during a single round are indistin-guishable from each other. Hence, since we have shownearlier that the Poisson mix can be modeled as a poolmix, the security analysis of mixing we present next canbe applied both in the asynchronous and synchronous de-sign.

4 Analysis of Loopix security properties

In this section we present the analytical and experimentalevaluation of the security of Loopix and argue its resis-tance to traffic analysis and active attacks.


4.1 Passive attack resistance

4.1.1 Message Indistinguishability

Loopix relies on the Sphinx packet format [16] to providebitwise unlinkability of incoming and outgoing messagesfrom a mix server; it does not leak information about thenumber of hops a single message has traversed or thetotal path length; and it is resistant to tagging attacks.

For Loopix, we make minor modifications to Sphinxto allow auxiliary meta-information to be passed to dif-ferent mix servers. Since all the auxiliary information isencapsulated into the header of the packet in the samemanner as any meta-information was encapsulated in theSphinx design, the security properties are unchanged. Anexternal adversary and a corrupt intermediate mix nodeor a corrupt provider will not be able to distinguish realmessages from cover messages of any type. Thus, theGPA observing the network cannot infer any informationabout the type of the transmitted messages, and interme-diate nodes cannot distinguish real messages, drop covermessages or loops of clients and other nodes from eachother. Providers are able to distinguish drop cover mes-sage destined for them from other messages, since theylearn the drop flag attached in the header of the packet.Each mix node learns the delay chosen by clients for thisparticular mix node, but all delays are chosen indepen-dently from each other.

4.1.2 Client-Provider unobservability

In this section, we argue the sender and receiver un-observability against different adversaries in our threatmodel. Users emit payload messages following a Pois-son distribution with parameter λP. All messages sched-uled for sending by the user are placed within a first-in-first-out buffer. According to a Poisson process, a sin-gle message is popped out of the buffer and sent, or adrop cover message is sent in case the buffer is empty.Thus, from an adversarial perspective, there is alwaystraffic emitted modeled by Pois(λP). Since clients sendalso streams of cover traffic messages with rates λL forloops and λD for drop cover messages, the traffic sent bythe client follows Pois(λP +λL +λD). Thus, we achieveperfect sender unobservability, since the adversary can-not tell whether a genuine message or a drop cover mes-sage is sent.

When clients query providers for received messages,the providers always send a constant number of messagesto the client. If the number of messages in client’s inboxis smaller than a constant threshold, the provider gen-erates additional dummy messages. Thus, the adversaryobserving the client-provider connection, as presented onFigure 4, cannot learn how many messages were in theuser’s inbox. Note that, as long as the providers are hon-

Inbox I

Inbox II

Inbox III

Figure 4: Provider stores messages destined for assignedclients in a particular inbox. When users pull messages fromthe mix node, the provider generates cover messages to guar-antee that the adversary cannot learn how many messages arein the users inbox. The messages from the inbox and dummiesare indistinguishable.

est, the protection and receiver unobservability is perfectand the adversary cannot learn any information about theinbox and outbox of any client.

Corrupt providers: We distinguish the sender’s andrecipient’s providers by calling them the ingress andegress providers respectively. If the ingress provider iscompromised, all security properties of the Loopix sys-tem are still preserved, since the ingress provider ob-serves a rate of traffic shaped by the Poisson distributioncoming from the client and cannot distinguish whetherthe received packets carry real, loop or drop messages.

If the egress provider is malicious it can reveal to theadversary whether a particular client is receiving mes-sages or not since the provider is responsible for man-aging the clients’ inboxes. However, even an egressprovider is still uncertain whether a received message isgenuine or the result of a client loop – this cannot bedetermined from their bit pattern alone. Further statis-tical attacks may be possible, and we leave quantifyingthe exact information leakage against this threat modelas future work. Thus, Loopix does not guarantee perfectreceiver unobservability in the presence of a corruptedegress provider.

4.1.3 Poisson mix security

We first show that a single honest Poisson mix provides ameasure of sender-receiver unlinkability. From the prop-erties of Poisson mix, we know that the number of mes-sages in the mix server at a steady state depends on theratio of the incoming traffic (λ ) and the delay parameter(µ) (from Section 3.3). The number of messages in eachmix node at any time will on average be λ

µ. However, an

adversary observing the messages flowing into and outof a single mix node could estimate the exact number of


messages within a mix with better accuracy – hinderedonly by the mix loop cover traffic.

We first consider, conservatively, the case where a mixnode is not generating any loops and the adversary cancount the exact number of messages in the mix. Let usdefine on,k,l as an adversary A observing a mix in whichn messages arrive and are mixed together. The adversarythen observes an outgoing set of n− k messages and caninfer that there are now k < n messages in the mix. Next,l additional messages arrive at the mix before any mes-sage leaves, and the pool now mixes k+ l messages. Theadversary then observes exactly one outgoing messagem and tries to correlate it with any of the n+ l messageswhich she has observed arriving at the mix node.

The following lemma is based on the memorylessproperty of the Poisson mix. It provides an upper boundon the probability that the adversary A correctly links theoutgoing message m with one of the previously observedarrivals in observation on,k,l .

Theorem 1. Let m1 be any of the initial n messages inthe mix node in scenario on,k,l , and let m2 be any of the lmessages that arrive later. Then

Pr(m = m1) =k

n(l + k), (1)

Pr(m = m2) =1

l + k. (2)

Note that the last l messages that arrived at the mixnode have equal probabilities of being the outgoing mes-sage m, independently of their arrival times. Thus, thearrival and departure times of the messages cannot becorrelated, and the adversary learns no additional infor-mation by observing the timings. Note that 1

l+k is anupper bound on the probability that the adversary A cor-rectly links the outgoing message to an incoming mes-sage. Thus, continuous observation of a Poisson mixleaks no additional information other than the numberof messages present in the mix. We leverage those re-sults for a single Poisson Mix to simulate the informationpropagated withing a the whole network observed by theadversary (c.f. Section 4.3).

We quantify the anonymity of messages in the mixnode empirically, using an information theory based met-ric introduced in [40, 18]. We record the traffic flowfor a single mix node and compute the distribution ofprobabilities that the outgoing message is the adversary’starget message. Given this distribution we compute thevalue of Shannon entropy (see Appendix A), a measureof unlinkability of incoming to outgoing messages. Wecompute this using the simpy package in Python. Alldata points are averaged over 50 simulations.

Figure 5 depicts the change of entropy against an in-creasing rate of incoming mix traffic λ . We simulate the

Figure 5: Entropy versus the changing rate of the incomingtraffic for different delays with mean 1

µ. In order to measure

the entropy we run a simulation of traffic arriving at a singleLoopix mix node.

dependency between entropy and traffic rate for differ-ent mix delay parameter µ by recording the traffic flowand changing state of the mix node’s pool. As expected,we observe that for a fixed delay, the entropy increaseswhen the rate of traffic increases. Higher delay also re-sults in an increase in entropy, denoting a larger potentialanonymity set, since more messages are mixed together.

In case the mix node emits loop cover traffic, the ad-versary with observation on,k,l , tries to estimate the prob-ability that the observed outgoing message is a particulartarget message she observed coming into the mix node.An outgoing message can be either input message or aloop message generated by the mix node – resulting inadditional uncertainty for the adversary.

Theorem 2. Let m1 be any of the initial n messages inthe mix node in scenario on,k,l , and let m2 be any of thel messages that arrive later. Let λM denote the rate atwhich mix node generates loop cover traffic. Then,

Pr(m = m1) =kn· µ

(l + k)µ +λM,

Pr(m = m2) =µ

(l + k)µ +λM.

We refer to Appendix A for the proof. We concludethat the loops generated by the mix node obfuscate theadversary’s view and decrease the probability of success-fully linking input and output of the mix node. In Sec-tion 4.2 we show that those types of loops also protectagainst active attacks.

4.2 Active-attack ResistanceLemma 1 gives the direct relationship between the ex-pected number of messages in a mix node, the rate of in-coming traffic, and the delay induced on a message whiletransiting through a mix. By increasing the rate of covertraffic, λD and λL, users can collectively maintain strong


anonymity with low message delay. However, once thevolume of real communication traffic λP increases, userscan tune down the rate of cover traffic in comparisonto the real traffic, while maintaining a small delay andbe confident their messages are mixed with a sufficientnumber of messages.

In the previous section, we analyze the security prop-erties of Loopix when the adversary observes the stateof a single mix node and the traffic flowing through it.We show, that the adversary’s advantage is bounded dueto the indistinguishability of messages and the memory-less property of the Poisson mixing strategy. We now in-vestigate how Loopix can protect users’ communicationsagainst active adversaries conducting the (n−1) attack.

4.2.1 Active attacks

We consider an attack at a mix node where an adversaryblocks all but a target message from entering in orderto follow the target message when it exits the mix node.This is referred to as an (n-1) attack [41].

A mix node needs to distinguish between an active at-tack and loop messages dropped due to congestion. Weassume that each mix node chooses some public param-eter r, which is a fraction of the number of loops thatare expected to return. If the mix node does not see thisfraction of loops returning they alter their behavior. Inextremis such a mix could refuse to emit any messages– but this would escalate this attack to full denial-of-service. A gentler approach involves generating morecover traffic on outgoing links [17].

To attempt an (n-1) attack, the adversary could simplyblock all incoming messages to the mix node except for atarget message. The Loopix mix node can notice that theself-loops are not returning and deduce it is under attack.Therefore, an adversary that wants to perform a stealthyattack has to be judicious when blocking messages, toensure that a fraction r of loops return to the mix node,i.e. the adversary must distinguish loop cover traffic fromother types of traffic. However, traffic generated by mixloops is indistinguishable from other network traffic andthey cannot do this better than by chance. Thereforegiven a threshold r = λM

s ,s ∈ R>1 of expected returningloops when a mix observes fewer returning it deploys ap-propriate countermeasures.

We analyze this strategy: since the adversary cannotdistinguish loops from other traffic the adversary can dono better than block traffic uniformly such that a fractionR = λ

s = λR+λMs enter the mix, where λR is the rate of

incoming traffic that is not the mix node’s loops. If weassume a steady state, the target message can expect tobe mixed with λR

s·µ messages that entered this mix, andλMµ

loop messages generated at the mix node. Thus, theprobability of correctly blocking a sufficient number of

messages entering the mix node so as not to alter the be-havior of the mix is:

Pr(x = target) =1

λR/s ·µ +λM/µ=

sµ

sλM +λR

Due to the stratified topology, providers are able to dis-tinguish mix loop messages sent from other traffic, sincethey are unique in not being routed to or from a client.This is not a substantial attack vector since mix loopmessages are evenly distributed among all providers, ofwhich a small fraction are corrupt and providers do notlearn which mix node sent the loop to target it.

4.3 End-to-End Anonymity EvaluationWe evaluate the sender-receiver third-party unlinkabilityof the full Loopix system through an empirical analysisof the propagation of messages in the network. Our keymetric is the expected difference in likelihood that a mes-sage leaving the last mix node is sent from one senderin comparison to another sender. Given two probabilitiesp0 = Pr[S0] and p1 = Pr[S1] that the message was sent bysenders S0 and S1, respectively, we calculate

ε = |log(p0/p1)| . (3)

To approximate the probabilities p0 and p1, we pro-ceed as follows. We simulate U = 100 senders that gen-erate and send messages (both payload and cover mes-sages) with a rate λ = 2. Among them are two challengesenders S0 and S1 that send payload messages at a con-stant rate, i.e, they add one messages to their sendingbuffer every time unit.

Whenever a challenge sender S0 or S1 sends a payloadmessage from its buffer, we tag the message with a la-bel S0 or S1, respectively. All other messages, includingmessages from the remaining 98 clients and the covermessages of S0 and S1 are unlabeled. At every mix wetrack the probability that an outgoing message is labeledS0 or S1, depending on the messages that entered the mixnode and the number of messages that already left themix node, as in Theorem 1. Thus, messages leaving amix node carry a probability distribution over labels S0,S1, or ‘unlabeled’. Corrupt mix nodes, assign to outgoingmessages their input distributions. The probabilities nat-urally add up to 1. For example, a message leaving a mixcan be labeled as {S0 : 12%,S1 : 15%,unlabeled : 73%}.

In a burn-in phase of 2500 time units, the 98 senderswithout S0 or S1 communicate. Then we start the twochallenge senders and then simulate the network for an-other 100 time units, before we compute the expecteddifference in likelihood metric. We pick a final mix nodeand using probabilities of labels S0 and S1 for any mes-sage in the pool we calculate ε as in Equation (3).


Figure 6: Likelihood difference ε depending on the delay pa-rameter µ of mix nodes. We use λ = 2, a topology of 3 layerswith 3 nodes per layer and no corruption.

This is a conservative approximation: we tell the ad-versary which of the messages leaving senders S0 and S1are payload messages; and we do not consider mix orclient loop messages confusing them. 4 However, whenwe calculate our anonymity metric at a mix node we as-sume this mix node to be honest.

4.3.1 Results

We compare our metric for different parameters: depend-ing on the delay parameter µ , the number of layers inour topology l and the percentage of corrupt mix nodesin the network. All simulations are averaged over 100repetitions and the error bars are the standard deviation.

Delay. Increasing the average delay (by decreasing pa-rameter µ) with respect to the rate of message sendingλ immediately increases anonymity (decreases ε) (Fig-ure 6). For µ = 2.0 and λ/µ = 1, Loopix still provides aweak form of anonymity. As this fraction increases, thelog likelihood ratio grow closer and closer to zero. Weconsider values λ/µ ≥ 2 to be a good choice in terms ofanonymity.

Number of layers. By increasing the number of layersof mix nodes, we can further strengthen the anonymity ofLoopix users. As expected, using only one or two layersof mix nodes leads to high values of adversary advantageε . For a increasing number of layers, ε approaches zero(Figure 7). We consider a number of 3 or more layersto be a good choice. We believe the bump between 5–8layers is due to messages not reaching latter layers within100 time units. Results from experiments with increasedduration do not display such a bump.

4The soundness of our simplification can be seen by the fact that wecould tell the adversary which messages are loops and the adversarycould thus ignore them. This is equivalent to removing them, as anadversary could also simulate loop messages.

Figure 7: Likelihood difference ε depending on the number oflayers of mix nodes with 3 mix nodes per layer. We use λ = 2,µ = 1, and no corruption.

Figure 8: Likelihood difference ε depending on the percentageof (passively) corrupted mix nodes. We use λ = 2, µ = 1 anda topology of 3 layers with 3 nodes per layer.

Corruption. Finally, we analyze the impact that cor-rupt mix nodes have on the adversary advantage ε (Fig-ure 8). We assume that the adversary randomly corruptsmix nodes. Naturally, the advantage ε increases with thepercentage of corrupt mix nodes in the network. In areal-world deployment we do not expect a large fractionof mix nodes to be corrupt. While the adversary maybe able to observe the entire network, to control a largenumber of nodes would be more costly.

5 Performance Evaluation

Implementation. We implement the Loopix systemprototype in 4000 lines of Python 2.7 code for mixnodes, providers and clients, including unit-tests, de-ployment, and orchestration code. Loopix source codeis available under an open-source license5. We use theTwisted 15.5.0 network library for networking; as wellas the Sphinx mix packet format6 and the cryptographictools from the petlib7 library. We modify Sphinx touse NIST/SEGS-p224 curves and to accommodate addi-tional information inside the packet, including the delay

5https://github.com/UCL-InfoSec/loopix6http://sphinxmix.readthedocs.io/en/latest/7http://petlib.readthedocs.org


https://github.com/UCL-InfoSec/loopix

for each hop and auxiliary flags. We also optimize theSphinx implementation leading to processing times perpacket of less than 1ms.

The most computationally expensive part of Loopixis messages processing and packaging, which involvescryptographic operations. Thus, we implement Loopixas a multi-thread system, with cryptographic processinghappening in a thread pool separated from the rest of theoperations in the main thread loop. To recover from con-gestion we implement active queue management basedon a PID controller and we drop messages when the sizeof the queue reaches a (high) threshold.

Experimental Setup. We present an experimental per-formance evaluation of the Loopix system running onthe AWS EC2 platform. All mix nodes and providersrun as separate instances. Mix nodes are deployed onm4.4xlarge instances running EC2 Linux on 2.3GHzmachines with 64GB RAM memory. Providers, sincethey handle more traffic, storage and operations, are de-ployed on m4.16xlarge instances with 256GB RAM.We select large instances to ensure that the providersare not the bottleneck of the bandwidth transfer, evenwhen users send messages at a high rate. This reflectsreal-world deployments where providers are expected tobe well-resourced. We also run one m4.16xlarge in-stance supporting 500 clients. We only show results for500 clients, due to limitations of our experimental hard-ware setup such as ports and memory. A real world de-ployment of Loopix would scale to a larger client base.We believe that our empirical analysis is a more accu-rate assessment of real-world performance than those re-ported by other works, e.g. [45, 46], which depend onsimplish extrapolation. In order to measure the systemperformance, we run six mix nodes, arranged in a strat-ified topology with three layers, each layer composedof two mix nodes. Additionally, we run four providers,each serving approximately 125 clients. The delays ofall the messages are drawn from an exponential distri-bution with parameter µ , which is the same for all mixservers in the network. All measurements are taken fromnetwork traffic dumps using tcpdump.

Bandwidth. First, we evaluate the increase of band-width of mix nodes by measuring the rate at which asingle mix node processes messages, for an increasingoverall rate at which users send messages.

We set up the fixed delay parameter µ = 1000 (s.t.the average delay is 1ms). We have 500 clients ac-tively sending messages at rate λ each, which is thesum of payload, loop and drop rates, i.e., Pois(λ ) =Pois(λL + λD + λP). We start our simulation with pa-rameters λL = λD = 1 and λP = 3 messages per minutefor a single client. Mix nodes send loop cover traffic at

Figure 9: Overall bandwidth and good throughput per secondfor a single mix node.

rate starting from λM = 1. Next, we periodically increaseeach Poisson rate by another 2 messages per minute.Each packet sent through the network has a size of a fewkilobytes only, but this size is a parameter that can, ofcourse, be increased to fit the needs of a particular appli-cation.

In order to measure the overall bandwidth, i.e. thenumber of all messages processed by a single mix node,we use the network packet analyzer tcpdump. Sincereal and cover message packets are indistinguishable, wemeasure the good throughput by encapsulating an addi-tional, temporary, typeFlag in the packet header for thisevaluation, which leaks to the mix the message type—real or cover—and is recorded. Knowing the parametersλP, λL, and λD the adversary can try to estimate howmany messages on average in the outgoing stream arereal, loop or drop messages. However, the average es-timation does not give the adversary any significant in-formation, since the outgoing traffic may contain variousnumbers of each type of message which an adversary isnot able to distinguish between.

Figure 9 illustrates the number of total messages andthe number of payload messages that are processed bya single mix node versus the overall sending rate λ of asingle user. We observe that the bandwidth of the mixnode increases linearly until it reaches around 225 mes-sages per second. After that point the performance ofthe mix node stabilizes and we observe a much smallergrowth. We highlight that the amount of real traffic in thenetwork depends on the parameter λP within λ . A clientmay chose to tune up the rate of real messages sent, bytuning down the rate of loops and drop messages – atthe potential loss of security in case less cover traffic ispresent in the system overall. Thus, depending on thesize of the honest user population in Loopix, we can in-crease the rate of goodput.

Latency Overhead & Scalability. End-to-end latencyoverhead is the cost of routing and decoding relayed mes-sages, without any additional artificial delays. We run


Figure 10: Latency overhead of the system where 50 to 500users simultaneously send traffic at rates λP = λL = λD = 10per minute and mix nodes generate loop cover traffic at rateλM = 10 per minute. We assume that there is not additionaldelay added to the messages by the senders.

simulations to measure its sensitivity to the number ofusers participating in the system.

We measure the time needed to process a single packetby a mix node, which is approximately 0.6ms. This costis dominated by the scalar multiplication of an ellipticcurve point and symmetric cryptographic operations. Forthe end-to-end measurement, we run Loopix with a setupwhere all users have the same rates of sending real andcover messages, such that λP = λD = λL = 10 messagesper minute and mix servers generate loops at rate λM =10 messages per minute. All clients set a delay of 0.0seconds for all the hops of their messages – to ensurewe only measure the system overhead, not the artificialmixing delay.

Figure 10 shows that increasing the number of onlineclients, from 50 to 500, raises the latency overhead byonly 0.37ms. The variance of the processing delay in-creases with the amount of traffic in the network, butmore clients do not significantly influence the averagelatency overhead. Neither the computational power ofclients nor mix servers nor the communication betweenthem seem to become bottlenecks for these rates. Thoseresults show that the increasing number of users in thenetwork does not lead to any bottleneck for our parame-ters. The measurements presented here are for a networkof 6 mix nodes, however we can increase the system ca-pacity by adding more servers. Thus, Loopix scales wellfor an increasing number of users.

We also investigate how increasing the delays throughPoisson Mixing with µ = 2 affects the end-to-end la-tency of messages. We measure this latency through tim-ing mix heartbeat messages traversing the system. Fig-ure 11 illustrates that when the mean delay 1/µ sec. ishigher than the processing time (∼ 1ms−2ms), the end-to-end latency is determined by this delay, and followsthe Gamma distribution with parameter being the sum ofthe exponential distribution parameter over the numberof servers on the path. The good fit to a gamma distribu-

Figure 11: End-to-end latency histogram measured throughtiming mix node loops. We run 500 users actively commu-nicating via Loopix at rates λP = λL = λD = 60 per minute andλM = 60 per minute. The delay for each hop is drawn fromExp(2). The latency of the message is determined by the as-signed delay and fits the Gamma distribution with mean 1.93and standard deviation 0.87.

tion provides evidence that the implementation of Loopixis faithful to the queuing theory models our analysis as-sumes.

6 Related Work

All anonymous communication designs share the com-mon goal of hiding users’ communication patternsfrom adversaries. Simultaneously minimizing latencyand communication overhead while still providing highanonymity is challenging. We survey other anonymoussystems and compare them with Loopix (a summary isprovided in Table 3).

Early designs. Designs based on Chaum’s mixes [8]can support both high and low latency communication;all sharing the basic principles of mixing and layeredencryption. Mixmaster [35] supports sender anonymityusing messages encryption but does not ensure receiveranonymity. Mixminion [15] uses fixed sized messagesand supports anonymous replies and ensures forwardanonymity using link encryption between nodes. As adefense against traffic analysis, but at the cost of high-latencies, both designs delay incoming messages by col-lecting them in a pool that is flushed every t seconds (ifa fixed message threshold is reached).

In contrast, Onion routing [26] was developed for low-latency anonymous communication. Similar to mix de-signs, each packet is encrypted in layers, and is decryptedby a chain of authorized onion routers. Tor [20], themost popular low-latency anonymity system, is an over-lay network of onion routers. Tor protects against sender-receiver message linking against a partially global adver-sary and ensures perfect forward secrecy, integrity of the


messages, and congestion control. However, Tor is vul-nerable to traffic analysis attacks, if an adversary can ob-serve the ingress and egress points of the network. Agreat number of works have studied how mix networksand onion routing leak information, and how better de-sign such systems [36, 38, 44, 48].Recent designs. Vuvuzela [46] protects against bothpassive and active adversaries as long as there is onehonest mix node. Since Vuvuzela operates in rounds, of-fline users lose the ability to receive messages and allmessages must traverse a single chain of relay servers.Loopix does not operate in rounds, thus the end-to-endlatency can be significantly smaller than in Vuvuzela,depending on the delay parameter the senders choose.Moreover, Loopix allows off-line users to receive mes-sages and uses parallel mix nodes to improve the scala-bility of the network.

Stadium [45] and AnonPop [24] refine Vuvuzela; bothoperating in rounds making the routing of messages de-pendent on the dynamics of others. Stadium is scalable,but it lacks offline storage, whereas AnonPop does pro-vide offline message storage. Loopix also provides bothproperties, and because it operates continuously avoidsuser synchronization issues. Additionally, Loopix, incomparison to AnonPop, protects against active attacks.

Riposte [11] is based on a write PIR scheme in whichusers write their messages into a database, without re-vealing the row into which they wrote to the databaseserver. Riposte enjoys low communication-overhead andprotects against traffic analysis and denial of service at-tacks, but requires long epochs and a small number ofclients writing into the database simultaneously. In con-trast to Loopix, it is suitable for high-latency applica-tions.

Dissent [9], based on DC-networks [9], offers re-silience against a GPA and some active attacks, but at sig-nificantly higher delays and scales to only several thou-sand clients.

Riffle [31] introduces a new verifiable shuffle tech-nique to achieve sender anonymity. Using PIR, Rif-fle guarantees receiver anonymity in the presence of anactive adversary, as well as both sender and receiveranonymity, but it cannot support a large user base. Rifflealso utilizes rounds protect traffic analysis attacks. Riffleis not designed for Internet-scale anonymous communi-cation, like Loopix, but for supporting intra-group com-munication.

Finally, Atom [30] combines a number of novel tech-niques to provide mid-latency communication, strongprotection against passive adversaries and uses zeroknowledge proofs between servers to resist active at-tacks. Performance scales horizontally, however latencycomparisons between Loopix and Atom are difficult dueto the dependence on pre-computation in Atom. Un-

like Loopix, Atom is designed for latency tolerant uni-directional anonymous communication applications withonly sender anonymity in mind.

7 Discussion & Future Work

As shown in Section 4.1, the security of Loopix heavilydepends on the ratio of the rate of traffic sent through thenetwork and the mean delay at every mix node. Opti-mization of this ratio is application dependent. For ap-plications with small number of messages and delay tol-erance, a small amount of cover traffic can guarantee se-curity.

Loopix achieves its stated security and performancegoals. However, there are many other facets of the designspace that have been left for future work. For instance,reliable message delivery, session management, and flowcontrol while avoiding inherent risks, such as statisticaldisclosure attacks [14], are all fruitful avenues of pursuit.

We also leave the analysis of replies to messages asfuture work. Loopix currently allows two methods ifthe receiver does not already know the sender a priori:we either attach the address of the sender to each mes-sage payload, or provide a single-use anonymous replyblock [15, 16], which enables different use-cases.

The Loopix architecture deliberately relies on estab-lished providers to connect to and authenticate end-users.This architecture brings a number of potential benefits,such as resistance to Sybil attacks, enabling anonymousblacklisting [27] and payment gateways [2] to mitigateflooding attacks and other abuses of the system, and pri-vacy preserving measurements [23, 28] about client andnetwork trends and the security stance of the system. Allof this analysis is left for future work.

It is also apparent that an efficient and secure pri-vate lookup system, one that can deliver network stateand keying information to its users, is necessary to sup-port modern anonymous communications. Proposalsof stand-alone ‘presence’ systems such as DP5 [6] andMP3 [37] provide efficient lookup methods, however,we anticipate that tight integration between the lookupand anonymity systems may bring mutual performanceand security benefits, which is another avenue for futurework.

8 Conclusion

The Loopix mix system explores the design space fron-tiers of low-latency mixing. We balance cover trafficand message delays to achieve a tunable trade-off be-tween real traffic and cover traffic, and between latencyand good anonymity. Low-latency incentivizes earlyadopters to use the system, as they benefit from good


Low Low Communication Scalable Asynchronous Active Offline ResistanceLatency Overhead Deployment Messaging† Attack Resistant Storage* to GPA

Loopix X X X X X X X

Dissent [47] X X

Vuvuzela [46] X X X

Stadium [45] X X X X

Riposte [11] X X X

Atom [30] X X X X

Riffle [31] X X X X

AnonPoP [24] X X X X

Tor [20] X X X X

Table 3: Comparison of popular anonymous communication systems. By *, we mean if the design intentionally incorporatesprovisions for delivery of messages when a user is offline, perhaps for a long period of time. By †, we mean that the systemoperates continuously and does not depend on synchronized rounds for its security properties and users do not need to coordinateto communicate together.

performance. Moreover, the cover traffic introduced byboth clients and mix servers provides security in the pres-ence of a smaller user-base size. In turn this promotesgrowth in the user-base leading on one hand to greatersecurity [19], and on the other a tuning down of covertraffic over time.

Loopix is the first system to combine a number ofbest-of-breed techniques: we provide definitions inspiredby AnoA [3] for our security properties; improve theanalysis of simplified variants of stop-and-go-mixingas a Poisson mix [29]; we use restricted topologiesto promote good mixing [21]; we deploy modern ac-tive attack mitigations based on loops [17]; and we usemodified modern cryptographic packet formats, such asSphinx [16], for low information leakage. Our design,security and performance analysis, and empirical eval-uation shows they work well together to provide strongsecurity guarantees.

The result of composing these different techniques –previously explored as separate and abstract design op-tions – is a design that is strong against global net-work level adversaries without the very high-latenciestraditionally associated with mix systems [35, 15].Thus, Loopix revitalizes message-based mix systems andmakes them competitive once more against onion rout-ing [26] based solutions that have dominated the fieldof anonymity research since Tor [20] was proposed in2004.

Acknowledgments In memory of Len Sassaman. Wethank Claudia Diaz and Mary Maller for the helpful dis-cussions. This work was supported by NSERC througha Postdoctoral Fellowship Award, the Research Coun-cil KU Leuven: C16/15/058, the European Commis-sion through H2020-DS-2014-653497 PANORAMIX,

the EPSRC Grant EP/M013-286/1, and the UK Govern-ment Communications Headquarters (GCHQ), as part ofUniversity College London’s status as a recognised Aca-demic Centre of Excellence in Cyber Security Research.

References[1] ANDERSON, R., AND BIHAM, E. Two practical and provably

secure block ciphers: Bear and lion. In Fast Software Encryption(1996), Springer, pp. 113–120.

[2] ANDROULAKI, E., RAYKOVA, M., SRIVATSAN, S., STAVROU,A., AND BELLOVIN, S. M. PAR: Payment for Anonymous Rout-ing. In Privacy Enhancing Technologies, 8th International Sym-posium, PETS 2008, Leuven, Belgium, July 23-25, 2008, Pro-ceedings (2008), pp. 219–236.

[3] BACKES, M., KATE, A., MANOHARAN, P., MEISER, S., ANDMOHAMMADI, E. AnoA: A Framework for Analyzing Anony-mous Communication Protocols. In Computer Security Founda-tions Symposium (CSF), 2013 IEEE 26th (2013), IEEE, pp. 163–178.

[4] BALLANI, H., FRANCIS, P., AND ZHANG, X. A study ofprefix hijacking and interception in the Internet. In ACM SIG-COMM Computer Communication Review (2007), vol. 37, ACM,pp. 265–276.

[5] BOLCH, G., GREINER, S., DE MEER, H., AND TRIVEDI, K. S.Queueing networks and Markov chains: modeling and perfor-mance evaluation with computer science applications. John Wi-ley & Sons, 2006.

[6] BORISOV, N., DANEZIS, G., AND GOLDBERG, I. DP5: A pri-vate presence service. Proceedings on Privacy Enhancing Tech-nologies 2015, 2 (2015), 4–24.

[7] CAI, X., ZHANG, X. C., JOSHI, B., AND JOHNSON, R. Touch-ing from a distance: Website fingerprinting attacks and defenses.In Proceedings of the 2012 ACM conference on Computer andcommunications security (2012), ACM, pp. 605–616.

[8] CHAUM, D. Untraceable Electronic Mail, Return Addresses, andDigital Pseudonyms. Commun. ACM 24, 2 (1981), 84–88.

[9] CHAUM, D. The dining cryptographers problem: Unconditionalsender and recipient untraceability. Journal of cryptology 1, 1(1988), 65–75.


[10] CHEN, C., ASONI, D. E., BARRERA, D., DANEZIS, G., ANDPERRIG, A. HORNET: High-speed Onion Routing at the Net-work Layer. In Proceedings of the 22nd ACM SIGSAC Confer-ence on Computer and Communications Security, Denver, CO,USA, October 12-6, 2015 (2015), pp. 1441–1454.

[11] CORRIGAN-GIBBS, H., BONEH, D., AND MAZIÈRES, D. Ri-poste: An anonymous messaging system handling millions ofusers. In 2015 IEEE Symposium on Security and Privacy (2015),IEEE, pp. 321–338.

[12] DANEZIS, G. The Traffic Analysis of Continuous-Time Mixes.In Privacy Enhancing Technologies, 4th International Workshop,PET 2004, Toronto, Canada, May 26-28, 2004, pp. 35–50.

[13] DANEZIS, G. Mix-networks with restricted routes. In Inter-national Workshop on Privacy Enhancing Technologies (2003),Springer, pp. 1–17.

[14] DANEZIS, G. Statistical disclosure attacks. In Security and Pri-vacy in the Age of Uncertainty. Springer, 2003, pp. 421–426.

[15] DANEZIS, G., DINGLEDINE, R., AND MATHEWSON, N.Mixminion: Design of a type III anonymous remailer protocol.In Security and Privacy, 2003. Proceedings. 2003 Symposium on(2003), IEEE, pp. 2–15.

[16] DANEZIS, G., AND GOLDBERG, I. Sphinx: A compact andprovably secure mix format. In Security and Privacy, 2009 30thIEEE Symposium on (2009), IEEE, pp. 269–282.

[17] DANEZIS, G., AND SASSAMAN, L. Heartbeat traffic to counter(n-1) attacks: red-green-black mixes. In Proceedings of the 2003ACM workshop on Privacy in the electronic society (2003), ACM,pp. 89–93.

[18] DIAZ, C., SEYS, S., CLAESSENS, J., AND PRENEEL, B. To-wards measuring anonymity. In International Workshop on Pri-vacy Enhancing Technologies (2002), Springer, pp. 54–68.

[19] DINGLEDINE, R., AND MATHEWSON, N. June 2006. anonymityloves company: Usability and the network effect. In Proceedingsof the Fifth Workshop on the Economics of Information Security(WEIS 2006).

[20] DINGLEDINE, R., MATHEWSON, N., AND SYVERSON, P. Tor:The second-generation onion router. In Proceedings of the 13thconference on USENIX Security Symposium-Volume (2004).

[21] DINGLEDINE, R., SHMATIKOV, V., AND SYVERSON, P. Syn-chronous batching: From cascades to free routes. In InternationalWorkshop on Privacy Enhancing Technologies (2004), Springer,pp. 186–206.

[22] DOUCEUR, J. R. The sybil attack. In International Workshop onPeer-to-Peer Systems (2002), Springer, pp. 251–260.

[23] ELAHI, T., DANEZIS, G., AND GOLDBERG, I. PrivEx: PrivateCollection of Traffic Statistics for Anonymous CommunicationNetworks. In Proceedings of the 2014 ACM SIGSAC Conferenceon Computer and Communications Security, Scottsdale, Arizona,November 3-7, 2014 (2016), pp. 1068–1079.

[24] GELERNTER, N., HERZBERG, A., AND LEIBOWITZ, H. Twocents for strong anonymity: The anonymous post-office protocol.Proceedings on Privacy Enhancing Technologies 2 (2016), 1–20.

[25] GILAD, Y., AND HERZBERG, A. Spying in the dark: TCP andTor traffic analysis. In International Symposium on Privacy En-hancing Technologies Symposium (2012), Springer, pp. 100–119.

[26] GOLDSCHLAG, D., REED, M., AND SYVERSON, P. Onion rout-ing. Communications of the ACM 42, 2 (1999), 39–41.

[27] HENRY, R., AND GOLDBERG, I. Thinking inside the BLAC box:smarter protocols for faster anonymous blacklisting. In Proceed-ings of the 12th ACM workshop on Workshop on privacy in theelectronic society (2013), ACM, pp. 71–82.

[28] JANSEN, R., AND JOHNSON, A. Safely Measuring Tor. In Pro-ceedings of the 2016 ACM SIGSAC Conference on Computer andCommunications Security, Vienna, Austria, October 24-28, 2016(2016), pp. 1553–1567.

[29] KESDOGAN, D., EGNER, J., AND BÜSCHKES, R. Stop-and-go-mixes providing probabilistic anonymity in an open system. InInternational Workshop on Information Hiding (1998), Springer,pp. 83–98.

[30] KWON, A., CORRIGAN-GIBBS, H., DEVADAS, S., AND FORD,B. Atom: Scalable Anonymity Resistant to Traffic Analysis.CoRR abs/1612.07841 (2016).

[31] KWON, Y. H. Riffle: An efficient communication system withstrong anonymity. PhD thesis, Massachusetts Institute of Tech-nology, 2015.

[32] LAZAR, D., AND ZELDOVICH, N. Alpenhorn: Bootstrappingsecure communication without leaking metadata. In Proceedingsof the 12th Symposium on Operating Systems Design and Imple-mentation (OSDI), Savannah, GA (2016).

[33] LE BLOND, S., CHOFFNES, D., CALDWELL, W., DRUSCHEL,P., AND MERRITT, N. Herd: A Scalable, Traffic Analysis Re-sistant Anonymity Network for VoIP Systems. In ACM SIG-COMM Computer Communication Review (2015), vol. 45, ACM,pp. 639–652.

[34] MITZENMACHER, M., AND UPFAL, E. Probability and com-puting: Randomized algorithms and probabilistic analysis. Cam-bridge university press, 2005.

[35] MÖLLER, U., COTTRELL, L., PALFRADER, P., AND SAS-SAMAN, L. Mixmaster Protocol-Version 2. Draft. July, availableat: www. abditum. com/mixmaster-spec. txt (2003).

[36] NIPANE, N., DACOSTA, I., AND TRAYNOR, P. Mix-in-placeanonymous networking using secure function evaluation. InProceedings of the 27th Annual Computer Security ApplicationsConference (2011), ACM, pp. 63–72.

[37] PARHI, R., SCHLIEP, M., AND HOPPER, N. MP3: A More Effi-cient Private Presence Protocol. arXiv preprint arXiv:1609.02987(2016).

[38] REBOLLO-MONEDERO, D., PARRA-ARNAU, J., FORNÉ, J.,AND DIAZ, C. Optimizing the design parameters of thresholdpool mixes for anonymity and delay. Computer networks 67(2014), 180–200.

[39] SALTZER, J. H., REED, D. P., AND CLARK, D. D. End-to-endarguments in system design. ACM Transactions on ComputerSystems (TOCS) 2, 4 (1984), 277–288.

[40] SERJANTOV, A., AND DANEZIS, G. Towards an informationtheoretic metric for anonymity. In International Workshop onPrivacy Enhancing Technologies (2002), Springer, pp. 41–53.

[41] SERJANTOV, A., DINGLEDINE, R., AND SYVERSON, P. Froma trickle to a flood: Active attacks on several mix types. In In-ternational Workshop on Information Hiding (2002), Springer,pp. 36–52.

[42] SERJANTOV, A., AND NEWMAN, R. E. On the anonymity oftimed pool mixes. In Security and Privacy in the Age of Uncer-tainty. Springer, 2003, pp. 427–434.

[43] SHANNON, C. E. A mathematical theory of communication.ACM SIGMOBILE Mobile Computing and Communications Re-view 5, 1 (2001), 3–55.

[44] SHMATIKOV, V., AND WANG, M.-H. Timing analysis in low-latency mix networks: Attacks and defenses. Computer Security–ESORICS 2006 (2006), 18–33.

[45] TYAGI, N., GILAD, Y., ZAHARIA, M., AND ZELDOVICH,N. Stadium: A Distributed Metadata-Private Messaging Sys-tem. Cryptology ePrint Archive, Report 2016/943, 2016. http://eprint.iacr.org/2016/943.


http://eprint.iacr.org/2016/943

http://eprint.iacr.org/2016/943

[46] VAN DEN HOOFF, J., LAZAR, D., ZAHARIA, M., AND ZEL-DOVICH, N. Vuvuzela: Scalable private messaging resistant totraffic analysis. In Proceedings of the 25th Symposium on Oper-ating Systems Principles (2015), ACM, pp. 137–152.

[47] WOLINSKY, D. I., CORRIGAN-GIBBS, H., FORD, B., ANDJOHNSON, A. Dissent in numbers: Making strong anonymityscale. In Presented as part of the 10th USENIX Symposiumon Operating Systems Design and Implementation (OSDI 12)(2012), pp. 179–182.

[48] ZHU, Y., FU, X., BETTATI, R., AND ZHAO, W. Anonymityanalysis of mix networks against flow-correlation attacks. InGlobal Telecommunications Conference, 2005. GLOBECOM’05.IEEE, vol. 3, IEEE, pp. 5–pp.

A Appendix

A.1 Incremental Computation of the En-tropy Metric

Let X be a discrete random variable over the finite set Xwith probability mass function p(x) = Pr(X = x). TheShannon entropy H(X) [43] of a discrete random vari-able X is defined as

H(X) =− ∑x∈X

p(x) log p(x). (4)

Let on,k,l be an observation as defined in Section 4.1.3for a pool at time t. We note that any outgoing messagewill have a distribution over being linked with past inputmessages, and the entropy Ht of this distribution is ouranonymity metric. Ht can be computed incrementallygiven the size of the pool l (from previous mix rounds)and the entropy Ht−1 of the messages in this previouspool, and the number of messages k received since a mes-sage was last sent:

Ht =H({

kk+ l

,l

k+ l

})+

kk+ l

logk+l

k+ lHt−1,

(5)

for any t > 0 and H0 = 0. Thus for sequential obser-vations we can incrementally compute the entropy met-ric for each outgoing message, without remembering thefull history of the arrivals and departures at the Poissonmix. We use this method to compute the entropy metricillustrated in Figure 5.

A.2 Proof of Theorem 2Let us assume, that in mix node Mi there are n′ mes-sages at a given moment, among which is a target mes-sage mt . Each message has a delay di drawn from the ex-ponential distribution with parameter µ . The mix nodegenerates loops with distribution Pois(λM). The adver-sary observes an outgoing message m and wants to quan-tify whether this outgoing message is her target message.

The adversary knows, that the output of the mix node canbe either one of the messages inside the mix or its loopcover message. Thus, for any message mt , the followingholds

Pr [m = mt ] = Pr [m 6= loop] ·Pr [m = mt |m 6= loop] (6)

We note that the next message m is a loop if and only ifthe next loop message is sent before any of the messageswithin the mix, i.e., if the sampled time for the next loopmessage is smaller than any of the remaining delays of allmessages within the mix. We now leverage the memory-less property of the exponential distribution to model theremaining delays of all n′ messages in the mix as freshrandom samples from the same exponential distribution.

Pr [m 6= loop] = 1−Pr [m = loop]

= 1−Pr [X < d1∧X < d2∧ . . .∧X < dn′ ]

= 1−Pr [X < min{d1,d2, . . .dn′}](7)

We know, that di ∼ Exp(µ) for all i ∈ {1, . . . ,n′} andX ∼ Exp(λM). Moreover, we know that the minimumof n independent exponential random variables with rateµ is an exponential random variable with parameter∑

n′i µ . Since all the delays di are independent expo-

nential variables with the same parameter, we have forY = min{d1,d2, . . .dn′}, Y ∼ Exp(n′µ). Thus, we obtainthe following continuation of Equation (7).

Pr [m 6= loop] = 1−Pr [X < Y ]

= 1−∫

∞

0Pr [X < Y |X = x]Pr [X = x]dx

= 1−∫

∞

0Pr [x < Y ]λMe−λMxdx

= 1−∫

∞

0e−n′µx

λMe−λMxdx

= 1− λM

λM +nµ

=n′µ

n′µ +λM

(8)

Since the probability to send a loop depends only on thenumber of messages in a mix, but not on which messagesare in the mix, this probability is independent of the prob-ability from Theorem 1. Theorem 2 follows directly bycombining Theorem 1 and Equation (8), with n′ = k+ l.We get for messages m1 that previously were in the mix,

Pr [m = m1] = Pr [m 6= loop] ·Pr [m = m1|m 6= loop]

=(k+ l)µ

(k+ l)µ +λM· k

n(k+ l)

=kn· µ

(k+ l)µ +λM.


Analogously, we get for m2,

Pr [m = m2] = Pr [m 6= loop] ·Pr [m = m2|m 6= loop]

=(k+ l)µ

(k+ l)µ +λM· 1

k+ l

=µ

(k+ l)µ +λM.

This concludes the proof.


Documents

The Loopix Anonymity System - USENIX Loopix Anonymity System Ania M. Piotrowska University College London Jamie Hayes University College London Tariq Elahi KU Leuven Sebastian Meiser