Divide and Funnel: A Scaling Technique for Mix-Networks

While many anonymous communication (AC) protocols have been proposed to provide anonymity over the internet, scaling to a large number of users while remaining provably secure is challenging. We tackle this challenge by proposing a new scaling technique to improve the scalability/anonymity of AC protocols that distributes the computational load over many nodes without completely disconnecting the paths different messages take through the network. We demonstrate that our scaling technique is useful and practical through a core sample anonymous broadcast protocol, Streams, that offers provable security guarantees and scales for a million messages. The scaling technique ensures that each node in the system does the computation-heavy public key operation only for a tiny fraction of the total messages routed through the Streams network while maximizing the mixing/shuffling in every round. Our experimental results show that Streams can scale well even if the system has a load of one million messages at any point in time, with a latency of 16 seconds while offering provable “one-in-a-billion” unlinkability, and can be leveraged for applications such as anonymous microblogging and network-level anonymity for blockchains. We also illustrate by examples that our scaling technique can be useful to other AC protocols to improve their scalability and privacy, and can be interesting to protocol developers.


Introduction
Anonymous communication (AC) protocols [1]- [11] have been on an eternal quest to be scalable in terms of computation and communication overhead while providing strong anonymity properties.AC protocols need to ensure that messages cannot be traced from source to sink, i.e., from sender to recipient.A mixing network or mixnet confuses curious observers and compromised protocol parties by routing each message through multiple parties and "mixing" it with other messages along the way.This mixing property naturally occurs in mixnets with network topologies where messages meet in an honest protocol node or mixnode.
However, a mixnode has to perform public-key cryptographic processing associated with layered encryption, and the scalability of those mixnets is bottlenecked by the computation capacity of the weakest node.Mixnets that attempt to distribute the processing load over several parties in order to (horizontally) scale for a large number of messages, naturally cause a network topology where not all messages meet each other easily.Such protocols compensate for the shortcoming in the network topology in two ways: either they route a message through more nodes, leading to high latency; or they send noise messages between nodes to create the appearance that two messages could have met, leading to high communication overhead.All existing mixnets in the literature that attempt to achieve scalability by distributing computation over multiple parties, either fail to provide provably strong mixing guarantees (such as sender anonymity or relationship anonymity) [1], [9] or unnecessarily amplify the latency or bandwidth overhead [4], [10], [11].
We close that gap by introducing a simple and efficient scaling technique with provably strong mixing guarantees, without introducing additional noise messages or amplifying the latency too much.Our method separates duties: heavy cryptographic public-key operations are performed by a large number of parties (in practice hundreds to thousands), ensuring some kind of unlinkability of the packets, while the mixing is performed in a computation-light manner by an ever changing selection of very few nodes (in practice 1 to 5), which we call the "funnels" for that round.With this construction, a large number of protocol parties perform the required (public-key) cryptographic computations for them before sending the processed messages to their next destination over secure channels (TLS).This way, our scaling technique distributes computation over an arbitrarily large set of parties while preserving almost the same degree of link saturation and the chance for messages to meet.This kind of funnel topology combined with a secure channel is a minor change to an AC protocol, but it seems to have eluded prior work and offers significant advantages for scalability.The simplicity of the construction enables us to prove strong anonymity properties with less noise messages and latency overhead than comparable provable AC protocols [10], [11].
We demonstrate the applicability of our scaling method on a simple anonymous broadcast protocol, Streams, for which we prove a strong mixing property.Streams might be of independent interest for applications such as blockchain access privacy and anonymous microblogging, as it scales to a million messages and achieves practical end-to-end latency with strong mixing against honest-but-curious global attack-ers; these attackers can have strong background knowledge and access to honest-but-curious nodes and clients.
With a prototype implementation with one funnel node we demonstrate that Streams can scale to a million messages with an end-to-end latency of 16 seconds for each message for a message size of 512 bytes.Our proofs formally show that mixing occurs in the presence of a global passive adversary that (passively) compromises a fraction of the protocol parties.For a fraction of 10% compromised nodes in the system, Streams offers provable security of δ ≤ 2 −30 . 1e find our scaling method for distributing computation over many parties to be not only relevant to Streams but also encouraging for protocol designers interested in scaling up other AC protocols.As three representative examples, we consider the prominent Loopix [9], Karaoke [4], and Vuvuzela [12] protocols, and describe how our method of divide and funnel can enhance their mixing properties.

Existing Mixnet Protocols and (Lack of) Provable Guarantees
Most mixnet-based anonymous communication (AC) protocols, that can scale to a large number of users, do so by splitting the traffic over multiple paths [1], [4], [9], [10], [13]- [17].However, that also decreases the chance of two messages mixing with each other on a given hop -either those protocol need to increase the latency overhead almost linearly to maintain the same level of security [10], [17], or compensate with additional bandwidth overhead (by adding cover traffic) [4], [9], [13]- [15] or settle for a weaker level of anonymity [1], [9], [16].With our scaling strategy, we aim to achieve a balance among those worlds: maximize the chance of mixing for two messages while not increasing the latency overhead linearly or introduce additional bandwidth overhead, and scale for a million messages in the system.To further motivate the requirement of a scaling technique with strong security guarantees, we discuss the tradeoffs provided by existing mixnet-based protocols below.
The recently proposed AC protocol Loopix [9] combines a stratified mix network architecture with exponentially distributed delays to achieve a flexible mixing protocol that does not require fixed rounds; and scales for many users by employing multiple paths.Loopix offers tuneable parameters that balances latency overhead and the required traffic volume to offer protection against traffic analyses, without providing a formal proof on the degree of anonymity/mixing for any given parameter set.It is not clear whether Loopix offers strong pairwise unlinkability for interesting latency numbers.In Section 9, we discuss how Loopix could improve their degree of mixing while scaling up by utilizing our scaling approach.
In Vuvuzela [12] each node processes all messages in the system, and hence, is limited by the processing power of each node, leading to a large latency (around 37 seconds with one million messages, with a chain of only 3 nodes).Our technique specifically circumvents such bottlenecks.
Karaoke [4] and Stadium [13] can scale to millions of users by allowing multiple paths.To achieve link saturation, they leverage a number of noise messages in Θ(|servers|2 ), which yields a property similar to relationship anonymity.Additionally, by requiring the clients to send dummy messages whenever they don't have a real message to send, they allow the clients to hide when they are sending messages.However, these protocols only satisfy differential privacy (DP) guarantees.Differentially private AC protocols allow an attacker to develop a strong suspicion about who sent a message, which we strive to avoid in Streams.In our extended report [18, Appendix A.2], we discuss how group privacy artifacts and millions of users render (ε, δ)-DP guarantees unsuited for providing strong anonymity guarantees, unless ε and δ are very small.In Section 9, we discuss how to scale up Karaoke with our approach without this explosion of noise messages.
Against passive attackers, Karaoke does not only claim to provide DP guarantees but statistical indistinguishability (negligible δ for ε = 0).The proof outline of Karaoke is, however, inaccurate; we show a counter-example in the extended report [18,Appendix A.1].As Karaoke uses the same flawed argument to prove their DP guarantees, the soundness of their DP guarantees is not clear either.
Atom's [10] horizontal scaling technique also can handle a million short messages (up to 160 bytes) with strong mixing guarantees within a reasonable amount of time (around 28 minutes).However, our scaling technique allows our example protocol Streams to offer a significantly shorter end to end latency in the order of a few seconds.To demonstrate the effectiveness of our technique, we compare Streams with Atom and other protocols in Table 1, in terms of the number of communication hops required to achieve the security guarantees they aim for.
Ando et al. [17] propose a butterfly topology to achieve scalability and prove a mixing property.Butterfly networks are extremely effective in shuffling messages in the absence of compromised parties, but are not resistant in their presence.Even individual compromised nodes can jeopardize the mixing properties of the network.To overcome this challenge, Ando et al. propose to use Ω(log 2 (η)) many rounds for the security parameter η in order to provide mixing in the presence of passively compromised nodes.As Streams funnels messages through single nodes it can resist passively compromised nodes with just O(log(η)) rounds.
Kwon et al. [15] propose XRD that can achieve unobservability with O(log K) rounds of latency, where K is the total number of nodes in the system.For K ∈ poly(η), their latency is polylogarithmic in the security parameter η.However, each user is required to send the expensive system setup after every broadcast round, messages from the same user are linkable with each other on the last mixnode layer.
Most protocols require all clients to actively participate in the protocol to avoid leakage from user behaviour (e.g., if Bob is not active when a message is sent, Bob could not have been the sender); and Streams is no exception to that.However, many protocols (e.g., Vuvuzela, Stadium, Karaoke, XRD, Trellis) require all the clients to send messages in batches to help their mixing process, and/or to add strategic noise messages to the batches.This kind of synchronization among millions of clients is very difficult to achieve in a real world scenario.Our scaling technique does not require the help of noise messages from the servers to achieve mixing.Moreover, we disentangle the mixing property from user behavior.Hence, we only require the servers to have synchronized clocks but not the clients to use a synchronized usage pattern.We explain in Section 4.1 how our mixing property combined with such restricted client behavior directly implies the traditional anonymity notions achieved by the above protocols.Not requiring the messages to be processed in batches is a design advantage in itself.

Problem Overview And Design Roadmap
System Model.We consider a typical mix network based architecture [9], [10] allowing users to send messages anonymously using an overlay network of mix nodes.A set S of users communicate to a set R of recipients through a set I of intermediate nodes (or just 'nodes').In real life, the same user can act as sender as well as recipient, however, we consider the sender role and recipient role as two separate logical entities.Each sender is denoted by u i where i ∈ {1, . . ., N} and |S| = N.Similarly, each recipient is denoted by R i where i ∈ {1, . . ., N ′ } and |R| = N ′ .We summarize the system parameters in Figure 1.Our main objective is to demonstrate our scaling technique by designing an end-to-end provably secure and scalable AC protocol.Similar to provably-secure mix-net systems such as [4], [10], [12], [13], [15], [16], [19], our protocol uses a round-based communication model and synchronized clocks.In Section 7.1 we extend our results to loosely synchronized clocks.

Attacker Model and Security Goals
We consider global network level adversaries that can also statically compromise all except two clients and up to c out of K = |I| nodes.We formally prove mixing properties against passive attackers and consider passive corruptions: the compromised protocol parties still follow the protocol specifications, however the adversary has access to all the internal states of a compromised party.In the extended report [18, Appendix B] we discuss the necessary adaptations for the protocol against active adversaries based on existing techniques.
Our scaling technique improves the core building block for anonymous communication.   the security notion that we consider, we utilize a property that we call pairwise unlinkability: the attacker shall not be able to figure out which of two messages entering a system at a similar time corresponds to which of the two same messages leaving the system at a later point.However, an adversary can additionally leverage differences in user behavior (e.g, if Alice is active only at a specific time of the day) to guess who might have sent a message.Even a trusted-third-party anonymizer can not defend against such leakage.Some AC protocols [4], [9], [10], [13] defend against that by restricting/enforcing how the protocol clients can behave.We consider that problem to be orthogonal and focus on the "mixing" problem.Our notion of pairwise unlinkability suitably captures that notion of mixing.It is also closely related to other prominent anonymity notions -in Section 4.1 we relate it to notions like sender anonymity [20] (which of two potential senders has sent a specific message?) and relationship anonymity [20] (who is in communication with who?).
As with other works on anonymous communication [3], [4], [6], [10], [13], [19], [21]- [23], our formal security analysis does not consider an adversary whose sole purpose is to launch denial-of-service (DoS) attacks.Any technique that can be deployed for other protocols against attacks like targeted flooding to degrade the performance of a node can be deployed in our system as well.However, we incorporate integrity protections in our sample protocol Streams using the standard cryptographic methods [24], and deploy countermeasures against DoS-anonymity attacks (loop messages) from the literature [9].Additionally, in Sections 5.2 and 7.2 we discuss techniques to defend against some DoS attacks relevant to our scaling technique.We also leave the detailed analyses of fingerprinting of web-browsing and other sidechannels that might arise in specific application scenarios for future work.

A Layman's Protocol With Provable Security
The ideal functionality presented in anonymity trilemma work [25] provides an important insight: mixnets can achieve strongest degree of mixing by keeping all the messages together in every round.Following that insight, let us first consider a round-based mixnet protocol that routes all the messages in the system via a common path, which 51 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.In our comparisons we consider the trap variant of Atom [10], since the NIZK (non-interactive zero knowledge) variant is significantly slower.Atom* denotes the estimated values for Atom to achieve δ < 2 −30 with 10% corrupted nodes.For XRD [15], K denotes the total number of servers in their system.GPA refers to global passive adversaries.

Our Scaling Technique
Setup assumptions.We assume that each pair of nodes in the system maintain a persistent SSL/TLS session between them.Additionally, we leverage the Sphinx packet format [24] that provides end-to-end encryption for all messages and ensures that a node does not learn the path length and its own relay position on the path of a packet.Scaling Technique (Divide and Funnel).We propose to separate duties such that, instead of one node processing all the onion packets in a round, many nodes come together to share the processing load, while the messages can "mix" in one node.Each round is separated into a compute phase, where the task of onion decryption to prohibit linking is distributed over all nodes, and a funnel phase, where a randomly chosen node collects and mixes all the messages. 3he compute phase does not have a fixed time span.Immediately after processing, each compute node forwards the packet to the next funnel node.The funnel node uses the full time of each round.At the end of the round, the funnel node forwards the shuffled packets to the respective subsequent compute nodes based on the next node information in the Sphinx packet header.Figure 2 illustrates these compute and funnel phases.
We assume an authenticated and encrypted channel (using persistent TLS connections) between each pair of nodes.Therefore, even a global network level adversary cannot see the content of a packet passed between two nodes unless one of them is compromised; however the adversary can observe that a packet is passed between them.
The separation into funnel or compute node is conceptual: the same node can act as a funnel node or a compute node in different rounds.The funnel node in a round is picked using the value emitted by the randomness beacon.The client picks the compute nodes {x 1 , . . ., x d } uniformly at random (with replacement) from all available nodes for each hop of an onion packet independent of any other packet or any other hop of the same packet, and constructs the onion packet for the path {x 1 , . . ., x d }.The client decides the delay d by picking a number from [ ℓ 2 , ℓ − 1] following a distribution D. In general D can be any discrete probability distribution; however, in a typical setting we assume D to be uniform in [ ℓ 2 , ℓ − 1].4 Funnel nodes act as mix nodes.All messages meet in the same funnel nodes as their paths are coordinated by the randomness beacon: A node acts as a funnel node in a round if the output of the beacon in that round matches its own id.The funnel node is a bottleneck of the system in terms of network bandwidth; however, it does not perform any heavy cryptographic computations, allowing the system to scale up to the full bandwidth capabilities.Compute nodes act similar to onion routers [1], [26]: in every round a compute node peels an onion-layer for each packet and immediately forwards them to the designated funnel node.The pseudocode representations of the protocols run by honest clients and nodes are presented in Fig. 3. in each round messages fan out in the compute phase to all available nodes to distribute the computation-heavy task, then they are funneled through a small number of nodes in the funnel phase to achieve better mixing.When Alice sends an onion packet in round x with onion layers for nodes {5, 1, 2}, the packet also goes through the funnel nodes {3, 1} respectively, however onion decryption happens only on the compute nodes.
If two messages are processed by some honest compute nodes (not necessarily same) in round r, and then both of them go through the same honest funnel node in round r + 1, the two messages achieve "mixing" even if the whole network before and after is compromised.In Figure 4, we pictorially show the possible cases when two messages can mix (or not).
Clients in Streams do not need to be synchronized: clients choose the path of compute nodes for their messages and then send them to the first such compute node.Clients need not be aware of the succession of funnel nodes or any round times.

Security Definition And Background
Anonymity properties, such as sender anonymity or relationship anonymity, depend heavily on the behavior of clients and their choices for the overall message latency: Even if the protocol in question implements a trusted third party it cannot hide which clients are sending messages at which time; moreover, if Alice and Bob send messages at different times, but the overall latency of each of those messages is drawn from the same (independent) distribution, then the recipients of said messages as well as a passive observer can learn information about the potential sender simply by analyzing the timing.
To avoid dealing with these client-dependent and distribution dependent aspects of anonymity we here focus on the degree of mixing provided by AC protocols.We formalize the question if the adversary could distinguish whether or not two messages, that spent at least a given amount of shared time in the protocol, could have been swapped along the way.This property is close to message swapping properties from the literature, such as tail indistinguishability by Kuhn et al. [27] and unlinkability by Kate et al. [28].We assume an honest-but-curious global network level attacker that can eavesdrop on a fraction of the nodes (statically chosen), and has strong background knowledge about the behavior of the clients, formally the attacker controls all but two users.
The Pairwise Unlinkability game G Π,A,c,t PU (1 η ) for protocol Π against adversary A can be described as follows: • The challenger Ch provides the adversary A with the description of Π (that includes the description of the sets S, R, and I).Node Protocol: Q f , Qc := queues to store incoming messages.
to Ch where u is the sender of the message, m the content, t s the time the message enters the system, t f the time the message leaves the system, and R the receiver of the message, with min (t f,0 , t f,1 ) − max (t s,0 , t s,1 ) ≥ t and t ′ < min (t s,0 , t s,1 ).-If b = 0, Π transmits the messages (u 0 , m 0 , t s,0 , t f,0 , R 0 ) and (u 1 , m 1 , t s,1 , t f,1 , R 1 ).
• A can terminate the game any time by outputting a bit b * , as a guess for the challenge bit b. • The game returns 1 if and only if b * = b (i.e., A guesses correctly), otherwise the game returns 0.
Definition 1 (Pairwise unlinkability).A protocol Π provides pairwise unlinkability of messages over time t and c compromise up to probability δ for 0 ≤ δ < 1 if, for all probabilistic polynomial time (PPT) adversaries A passively and statically compromising at most c nodes, the following holds: Informally, we say that the two messages are shuffled from the adversary's point of view if a protocol achieves pairwise unlinkability, which means that the messages are shuffled almost as good as a trusted-third-party anonymizer could shuffle them.We say that a protocol achieves strong pairwise unlinkability if δ is negligible in a security parameter η.
Ideally, we want our protocol to achieve strong pairwise unlinkability.We discuss below how pairwise unlinkability relates to sender anonymity and relationship anonymity.

Pairwise Unlinkability and Anonymity
Pairwise unlinkability is closely related to well-known anonymity notions like sender anonymity and relationship anonymity, while avoids the leakage from client behaviour.We informally explain their relationship below, and refer to our extended report [18, Appendix D] for a more formal argument.Sender anonymity.The common anonymity notion sender anonymity states that the recipient of a message cannot distinguish whether the message originated in one sender over another sender, even for a pair of potential senders of the adversary's choice.This closely resembles pairwise unlinkability with one key difference: sender anonymity typically talks about a single challenge message, not about a pair of messages.To bridge the gap between sender anonymity and pairwise unlinkability we can require a degree of bandwidth overhead, such as ensuring that all senders communicate regularly or send dummy messages.However, even if dummy messages are sent, an adversary might still deduce the challenge sender from timings alone.
If, say, the adversary observes Alice sending a message in round t and Bob sending a message in round t + 2, the arrival time of the challenge message together with the distribution of the latency might tell the adversary who of them is more likely to have sent the challenge message.In the simplest example, for a constant latency, the adversary could immediately exclude one of them from being the challenge sender.This apparent attack is independent of how a protocol achieves anonymity and even applies if the messages are kept in a trusted third party for the same amount of time.However, if a protocol follows batch processing (i.e., all the messages are sent in the same round as in Karaoke and Atom), pairwise unlinkability immediately implies sender anonymity.Relationship anonymity.A similar notion states that if two senders send one message each to two receivers, a third party is unable to determine which sender talks to which receiver significantly better than purely guessing.Loopix [9] calls this property Sender-Receiver Third-party Unlinkability.Given that the two messages in question are sent in the same round and that both senders choose the latencies from the same distribution, pairwise unlinkability immediately implies this anonymity property.

Formal Protocol Description
We use a hybrid world UC model [29] to present our scaling technique with our core protocol Streamswhere the protocol has access to some additional ideal (hybrid) functionalities that is available to the protocol as well as the adversary.A protocol party (an honest user or node) or the adversary can access such a functionality through an incorruptible ITI F that provides certain ideal guarantees, e.g., clock time, key registration etc.More specifically, our formalization uses four such functionalities: a round-based communication functionality F round , a globally available if Round Functionality F round .We introduce a hybrid functionality F round (see Figure 5) to enforce rounds on the protocol parties.We ensure that the environment E activates the honest parties in every round.F round ensure, though, that the environment E cannot activate a protocol party multiple times in the same round by keeping track of the Rounds[i] flag for each party i (including both clients and nodes).Additionally, it ensures that all the network packets intended to send for a given round is not send before or after that round to an honest protocol party.As a consequence, the environment can stop the entire protocol at anytime.As then no messages would be delivered anymore, stopping the entire execution does not leak any information to the environment.
Randomness Beacon Functionality F CRF .We assume that each protocol party (including the adversary) has access to an incorruptible randomness beacon.In particular, future values of this beacon are not known to the adversary.We model this beacon with the ideal functionality F CRF (see Fig. 6) that outputs each time a ℓ-long substring of an infinite random string beacon.Using that ℓ-length string a protocol party can derive the next ℓ funnel nodes.
Secure Channel Functionality F SCS .We also use the secure communications sessions functionality F SCS from the work of Gajek et al. [30,Figure 4].They show that F SCS abstracts the TLS [31] protocol.It is crucial to note here that all the protocol parties in our model work in rounds, crf = an infinitely long random string.

GetFunnels(ℓ):
rnd, ← QueryRound() and therefore, F SCS as well forwards all the messages to the F round functionality instead of the environment; the F round functionality in turn forwards those messages to the environment when the round ends.Packet format.We use an improved version [32] of the Sphinx packet design [24] to ensure that all messages are end-to-end encrypted; we call them "onion packets".The Sphinx packet design guarantees that an intermediate node, just by looking at a packet, does not learn anything other than the next node on the path -it hides the path length and the position of the node on the path.The security properties of the packet design is already incorporated in the onion routing subprotocol Π sub that we use from the work of Kuhn et al. [27].Key registration functionality.Practical realizations of onion encryption functionality and secure channel functionality in turn assume the availability of a public key infrastructure (PKI) to all the users and nodes -which is no different from any other mixnet-based design.We consider the key registration functionality F RKR that realizes such PKI setups, and handles all cryptographic operations.F RKR is solely used by the subprotocols Π sub and F SCS , which are treated in a black-box manner throughout this section.
For completeness, we provide a more detailed description of Π sub , F SCS and F RKR in our extended report [18].

The Core Protocol
Our protocol has two kinds of parties -clients and nodes.So we define our protocol in two parts as wellclients and nodes.Additionally, the protocol parties as well as the adversary have access to the hybrid functionalities as described above.
Each round is then separated into a compute phase, where the task of onion decryption to prohibit linking is distributed over all nodes, and a funnel phase, where a randomly chosen node collects and mixes all the messages.In UC-realization of our protocol, we split those two phases into two separate rounds, to avoid having two sequential communications within a single round.Therefore, one single round of our original protocol maps to two rounds in the UCversion.In the compute round, each compute node processes the packets with them and forwards them to the designated funnel node, then in the funnel round, the funnel node shuffles all the messages received in the last round, and forwards them to the respective subsequent compute nodes.
The funnel nodes are picked using the string emitted by the randomness beacon F CRF .Each client picks the  compute nodes uniformly at random (with replacement) from all available nodes for each hop of an onion packet independent of any other packet or any other hop of the same packet.All the packets in every even round go to the next designated funnel node.Then in the next (odd) round, the funnel node shuffles all the received packets and forwards them (without any cryptographic operation) to the compute nodes based on the next node information in the Sphinx packet header.Then, again in the even round, the compute node removes one layer of the onion packet, and forwards the packet immediately to the next designated funnel node.The packets are onion encrypted only for the compute nodes, not for the funnel nodes.Additionally, we assume authenticated and encrypted channel between each pair of nodes which is realized by the F SCS functionality.The   The design remains the same with multiple funnels per round (as described in Section 5.2), except the set funnels contains multiple elements.The corresponding statements are colored with teal.
pseudocode representations of the protocols run by each honest client and each honest node are presented in Fig. 7 and Fig. 9 respectively.We aim for anonymous broadcast to the network.Therefore, in our protocol Streams, messages from our last node are sent to the environment instead of delivering them to an explicit receiver.The delivery of messages occurs through the environment which controls the network functionality.

Multiple Funnel Nodes Per Round: Performance vs. Resiliency Tradeoff
Having a single funnel in Streams inherently creates single points of failure: if a malicious node is chosen as funnel it can perform denial-of-service (DoS) attacks by dropping packets.Arguably this is not a new concern for anonymous communication protocols -corrupted mixnodes in existing mixnet designs can drop all packets passing through them, and those protocols use additional integrity measure to defend agianst them.However, funneling every packet through the same node gives this node the power to disrupt the entire stream of packets and makes the ρ := number of funnels per round.node a prime target for external DoS attackers.Our scaling methodology can be extended to several funnel nodes at a time, which presents a trade-off between performance and robustness against such DoS attacks.We additionally refer to our extended report [18] for the heuristic mechanisms that would allow detecting and defending against such active attacks; and would deter a funnel from launching such a disruption.

GetFunnels(ℓ):
Instead of a single funnel node per round, the packets are distributed among ρ funnel nodes, each of which is still chosen based on the randomness beacon.We suggest that ρ remains a small number (between 2 and 5) chosen based on the desired level of robustness.Compute nodes can distribute packets among the h funnel nodes based on a deterministic function applied to the packet digest and the randomness beacon, e.g., a hash function with the (encrypted) packet content and the beacon's current randomness as inputs.
The pseudocode representation of the client (c.f.Fig. 7) and the node (c.f.Fig. 9) remains mostly same as the core protocol (with single funnel) with minor modifications which we present in Fig. 10.

Security Analysis
Here we analyze the security of the core protocol against a global passive adversary that can passively compromise (the compromised parties still follow the protocol) a portion of the nodes.We use existing techniques from the literature to provide integrity measures against active adversaries and discuss them in our extended report [18, Appendix B].

Key Proof Ideas
The key idea is that two messages get shuffled if they go through an honest funnel node right after going through honest compute nodes (c.f. Figure 4).It is not necessary that they pass through the same honest compute node, however, they need to pass through some honest compute nodes in the same round just before passing through an honest funnel node.If the messages stay in the system long enough (L is 57 sufficiently high), with high probability such a sequence will occur at least once.Single Funnel Per Round.Let a be the probability of a randomly picked node being honest; a = K−c K .Since both the funnel node and each compute node are picked uniformly at random (with replacement, and independent of all other nodes), the probability that the funnel node or compute node chosen in any round is compromised is c K = (1 − a), and the probability that it is honest is a.Therefore, the probability that the two messages mix in for a given pair of compute nodes in round r and funnel node in round (r + 1) is a 3 , and the probability that they don't mix in this pair of rounds is (1 − a 3 ).If two messages both stay in the system for L rounds, the probability that they don't mix is at most δ < 1 − a 3 L .Multiple Funnels Per Round.When there are ρ funnel nodes per round, we need to consider the probability that the two messages might not go through the same funnel node in a round.For any given round, the probability that the pair of messages meet in the same funnel node is 1 ρ .Given that they have met on a funnel node in a given round, the probability of that specific funnel node being compromised is still c K = (1 − a); and the probability that it is honest is a.Overall, the probability that the two packets mix in a given round is bounded by Y = 1 ρ × a 3 .The probability that they do not mix is at most δ ≤ (1 − a 3 ρ ) L .

Proof Roadmap
For proving security, we first prove that an intermediary representation, a UC ideal functionality F Streams (defined in Figure 11), of Streams that does not rely on cryptographic operations but on shared memory.This ideal functionality F Streams is carefully crafted such that all attacks on Streams can be mounted on F Streams as well, against a wide range of attacker capabilities.In a second step, we prove pairwise unlinkability for the faithfully abstracted ideal functionality, which in turn implies pairwise unlinkability for Streams.
Here we present the main security theorems and their implications, and refer to our extended report [18] for the detailed proofs.
We can say that, at the expense of latency, our ideal functionality provides pairwise unlinkability -if two messages stay together in F Streams for a sufficiently long time (polylogarithmic in the security parameter), they get shuffled.
Theorem 1 (Pairwise unlinkability of F Streams ).Given a constant integer ρ, if the amount of compromised nodes is a constant fraction c K < 1, F Streams provides pairwise unlinkability of messages over L rounds up to probability δ as in Definition 1, where δ < γ L/2 with γ = 1 − an ideal functionality F is realized by a protocol Π if all attacks (within the execution model) that can be mounted on Π can be translated to attacks on Π, for a wide range of attacker capabilities.An ideal functionality, like From the work by Kuhn et al. [27] we know that the Sphinx version [32] we use in our protocol UC realizes F sub under a PKI setup (realized by the hybrid functionality F RKR ), and we can state the following lemma.
Lemma 1. Sphinx packet format from [32] UC realizes F sub in the F RKR hybrid model.
As a corollary to Theorem 2, Theorem 1, and Lemma 1 we can state the following for our protocol Streams.
Theorem 3 (Security of Streams).In the F RKR -hybrid model, given a constant integer ρ and a constant fraction c K < 1, Streams provides pairwise unlinkability of messages over L rounds up to probability δ as in Definition 1, where As a corollary to the above theorem, we can state the following about the core protocol from Section 5.1 for ρ = 1 (single funnel per round).
Theorem 4 (Security of Streams core).In the F RKR -hybrid model, given a constant fraction c K < 1, Streams from Section 5.1 provides pairwise unlinkability of messages over L rounds up to probability δ as in Definition 1, where δ < γ L/2 where γ = 1 In Theorems 3 and 4, for all L ∈ ω(log η) for a security parameter η the δ is negligible, and all pair of messages that stays together in the protocol for at least L rounds, get shuffled with overwhelming probability.Recall that L rounds of the protocol in the UC-framework translates to L = L/2 rounds (considering the compute phase and the funnel phase as a single round) in the original protocol.

Analysis
Here we first analyze Theorem 4 to evaluate the simple case of introducing single funnel node per round, and then we evaluate the impact of introducing multiple funnel by analyzing Theorem 3.
In Theorem 4, γ = 1 − ( K−c K ) 3 is conceptually the proportion of compute node and funnel node pairs in a round where the two messages cannot mix. Figure 13a plots the relationship between γ and the fraction c K of compromised parties.If we want to have the same level of concrete security as without compute and funnel nodes, we need to increase latency, or with similar latency the protocol can only be resilient against lesser fraction of compromised nodes.However, one advantage of this construction is that the cost or overhead does not increase linearly with the number of clients, or more importantly, does not even depend on the number of clients.In Fig. 13b, we compare the latency overhead needed for our protocol (with compute and funnel separation) to achieve a given level of security with the scenario where the compute and funnel separation is not required (refer to our extended report [18] for security of our layman's protocol).For c K ≤ 0.2 the number of rounds only doubles with the separation of duties to achieve the same level of security.Even though the compute and funnel method provides scalability at the cost of security, δ still decreases exponentially with latency.We show the relationship between them in Fig. 13c.Impact of Multiple Funnels.We plot the trade-off between performance and the choice of ρ (up to ρ = 4) in Fig. 14, with a security goal of δ < 2 −30 and the system handles one million packets per round.As we show in Fig. 14, the latency needs to increase with the number of funnel nodes per round, to process the same total number of messages (1 million) and to achieve the same level of security (δ ≤ 2 −30 ).Note that the funnel nodes are only restricted by bandwidth availability, but not processing power in our system: it takes less than 120 milliseconds to process one million messages by a single funnel node, c.f. Figure 15c.Therefore, we can decrease the duration of each round with the number of funnel nodes ρ (to process one million messages per round) For example: for ρ = 4, the average processing time for each funnel is around 30 milliseconds; an overall round duration of 250 milliseconds still leaves more than 200 milliseconds for communication delay and loose synchronization.

Resiliency for Loose Synchronization
So far we assumed that all protocol parties are perfectly synchronized (c.f.Section 5).As maintaining such a synchronization continuously can be challenging, we here discuss relaxing that assumption by allowing each protocol party to follow their own local clock.
We assume that the maximum difference between the local clocks of any two nodes is bounded by µ milliseconds.The clients do not need to keep track of rounds and can send messages to the system whenever they want.A client sends an onion packet to the first compute node on the onion path.The compute node, based on its local clock, decides which funnel node to forward the packets to.As long as µ is lower than a few hundred milliseconds, we can add µ to duration of our rounds to handle the synchronization gap among the nodes.We can still have a reference global clock which the nodes can synchronize their local clocks with from time-to-time.We only need equivocation protection from that global clock -Streams does not depend on that clock for anonymity.
However, suppose some nodes (at most 10% for example) differ by more than few hundred milliseconds from 59 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.with funnels, δ < 2 −30 without funnels, δ < 2 −30 (b) corruption ratio c K vs. the required latency (in rounds) to achieve different levels of security, viz, one in a billion (δ < 2 −30 ) and one in a trillion (δ < 2 −40 ) security.
(a) c K vs. the required latency ℓ (number of hops) for different values of ρ to achieve one in a billion (δ < 2 −30 ) security.the reference global clock.Such compute nodes can send packets to wrong funnel nodes.If a node receives an onion packet that it is not supposed to receive, the node just forwards the packet to the correct compute node (according to the onion packet header) at the end of the round.Thus, the protocol still functions properly, although the latency needs to be increased based on the amount of such unsynchronized (and compromised) nodes to guarantee the same degree of mixing.With this modified approach, a node does not have to derive in which round to act as a funnel node.For all the onion packets (according to the onion headers) if it is the intended compute node, it acts as a compute node; for all the rest of the packets it acts as a funnel node and forwards them to the next corresponding compute nodes at the end of the round.
Note that the messages that are transmitted by out-ofsync nodes in a round might not mix with other messages.However, it does not impact the mixing of the rest of the messages.In the F RKR -hybrid model, we can model the out-of-sync nodes as compromised parties.If there are at most ψ out-of-sync nodes, and c additional compromised nodes, as a corollary to Theorem 3 we can state: Theorem 5.In the F RKR -hybrid model, given a constant integer ρ, a constant fraction c K , and another constant fraction ψ K such that c K + ψ K < 1 Streams provides pairwise unlinkability of messages over L rounds up to probability δ as in Definition 1, where δ < γ L/2 and γ = 1− For simplicity, the above theorem overapproximates the states for synchronization: either the nodes and in-sync, or they are out-of-sync.A thorough security proof with variable network delays and variable level of synchronization is left for future work.

DoS Attacks Against Funnel Nodes
Although our formal security analysis does not consider DoS attacks by external parties, our design of having few funnel nodes per round introduces such possibilities.If a powerful adversary is able to redirect the DoS attack to the next funnel node within a span of one round, and can keep doing that, the adversary will be able to block the system.
To defend against such attacks, we utilize the fact that each pair of nodes have a persistent TLS connection between them.If a funnel node is under attack, when the compute nodes send packets to the funnel they will not receive any TCP/IP acknowledgments for the dropped packets.In our defense strategy, whenever the compute nodes detect such an attack against the funnel nodes, the compute nodes will shuffle the packets they locally have and directly forward them to the next compute nodes at the end of the round.This will compromise anonymity but provide availability for the system when the funnel nodes are under attack.
If we assume that the adversary has a limited capacity to perform DoS attacks on the funnel nodes, we can consider that only up to ι funnel nodes will be under attack; and the compute nodes will forward to the next compute nodes the messages that are supposed to go to those funnel nodes.Those messages will not have a chance to mix with other messages.If a strong adversary can attack all funnel nodes in succession, Streams will effectively be the same Karaoke, but without the noise messages.
Even though, any protocol can be susceptible to external DoS attacks, this attack against funnel nodes is amplified in Streams compared to other protocol when an adaptive adversary can quickly redirect their attack to new nodes in every round, because of the small number of funnel nodes.However, if the adversary cannot adapt quickly to redirect the attack, the use of randomness beacons alleviates this problem, since the funnels nodes for the next round are not predictable in the current round.Against a static adversary or slowly adaptive adversary, the funnel nodes in Streams are as vulnerable as the compute nodes.

Implementation Details
We evaluate our scaling technique by individually evaluating the performance of compute and funnel nodes and then evaluating Streams, using a proof-of-concept implementation in Go language (v1.15). 5The implementation uses the standard crypto library in Go, and elliptic curve P25519 from NaCl library to implement cryptographic and sphinx packet operations.We take all measurements by repeating an experiment 10 times and taking an average of those.We make the following system considerations.Synchronization.For the prototype implementation we consider a global clock that every protocol party (clients and nodes) follows.For real deployments, the global clock can be replaced with local clocks in combination with the idea of loose synchronization technique described in Section 7.1.About Rounds.In our implementation we choose one second as the duration for each round.This decision is 5.The source code is available at: https://github.com/dedas111/protocolXinfluenced by our scalability goal of processing one million messages every round.We show in Section 8.3 that the round duration determines how many messages can be processed in a round.Random Shuffle.We implement the Fisher-Yates shuffle [33] to achieve in-memory shuffle of n elements with Θ(n) computational complexity.This algorithm requires a continual source of randomness -each funnel node uses a locally stored random number table for that purpose.

Processing Capacity of Compute Nodes
We first evaluate how many onion packets can be processed by a single compute node in a given amount of time, which also reflects how a naive protocol can scale without the divide and funnel technique.To that end, we run a standalone compute node on an AWS t3.2xlarge instance (8 virtual processors), and measure the time spent to process different number of onion packets.Each sphinx packet is constructed with 512 bytes of plaintext and 16 layers of onion encryption.In Figure 15a, we plot a graph between number of onion packets given to a compute node vs. time taken to process those packets.This demonstrates that a compute node (or nodes in a protocol without funnel compute separation) cannot process more than 30000 packets in one second.

Processing Capacity of Funnel Nodes
We evaluate how our funnel nodes can scale for different numbers (200K, 400K, . . ., 1M) of onion packets in the system even with slow compute nodes.As the number of compute nodes is expandable, funnel nodes dictate the round duration.We measure for funnels how much time is taken by the TLS layer to process different number of packets and how much time is taken to run the shuffle algorithm.Experimental Setup.To evaluate the performance/scalability of funnel node, we run a standalone funnel node on an AWS t3.2xlarge instance (8 virtual processors), and send varying number of onion packets to that node to measure the time taken for the following two operations: (i) computation time on the TLS layers to process different number of packets; (ii) run the Fisher-Yates shuffle for those packets.Each sphinx packet is constructed with 512 bytes of plaintext and 16 layers of onion encryption, however we do not decrypt any packets during this experiment since we run a standalone funnel.Results.We plot our findings in Figure 15b and Fig. 15c.All the measurements are average of 10 runs approximated to the nearest integer.Since we achieve in-memory shuffle using Fisher-Yates algorithm, the observed shuffle time is only around 10 ms even for a million packets (cf.Fig. 15b), even though shuffle algorithm runs in a single thread.
The TLS layer processing of 1M packets takes around 112 milliseconds (compared to 1 second round duration, cf.Fig. 15b).The overhead mainly involves AES encryption/decryption for TLS.These experiments show that the funnel is not restricted by computation.(f) end-to-end latency plotting number of packets (Tin) sent to the protocol (x-axis) vs. the time in milliseconds (y-axis) to deliver the slowest packet for a limit of ℓ hops.Memory and Network Overhead.We also measure the memory usage of the process and the throughput requirements (amount of data received by the funnel node over the network) for varying number of packets -we plot them in Fig. 15d.We observe that for 1M packets the memory utilization by the server process remains below 3GB; however, the network throughput requirement can become a bottleneck (receives a total of 2.1GB in messages).
If we choose round duration to be 1 second, to handle 1M packets the responsible funnel node requires a burst network capacity of around 17 Gbps.We additionally demonstrate the practicality of our system by running the following experiment: We run a funnel node on an AWS EC2 c5.18xlarge instance that supports 25 Gbps [34].We use such a powerful instance only to fulfil the network requirements, we have already shown that funnels are not restricted by computation overhead.Now we send varying number of sphinx packets from another AWS instance such that the next hop is also the sender machine.Then we measure the round-trip time for those packets.If the round-trip-times for all packets are between 1 second to 2 seconds, that means all the packets were received and processed by the funnel within a single round.We plot our results in Fig. 15e, which shows that 1 second round duration is adequate for even 1M total messages in the system -which is more than 30x higher than what a compute node can process.
Many service providers [35], [36] support up to 40 Gbps network speed.Streams nodes do not continuously need a high network capacity, a high burst capacity and a moderate average capacity suffices.If the system needs to support more than 1M messages per round, the servers can set up Multipath-TCP [37], [38] to fulfill the GBps requirement.

Scalability for Streams
To demonstrate that Streams can scale to 1M messages, we deploy our prototype of the core protocol of Streams (single funnel) using AWS instances distributed over us-east and eu-central regions, we choose EC2 c5.18xlarge instances to satisfy the bandwidth requirement.Then we send varying number of messages in batches and measure how much time it takes for the whole batch to be delivered to the recipients.We simulate sender and recipient by a single AWS EC2 c5.18xlarge instance.In the same batch, we choose same latency (rounds) for every message in the batch for each of execution.We choose the round duration to be 1 second.If the delay (from the time the first message is sent by the sender to the time the last message is received by the recipient) for a batch is chosen to be X rounds, we expect all the messages to be delivered within X+1 seconds 6 , otherwise the funnel nodes are not able to process all the messages within the given round duration. 7esults.In Fig. 15f we plot the end-to-end latency of batches of different sizes for chosen delays (number of rounds), the measurements are average of 10 individual instances.In the figure we observe that, when the delay is chosen to be 8 rounds (for example), even for a total number of messages of around 1.1M in a batch, the the total delay does not exceed 9 seconds.It shows that our scaling technique and our protocol can easily scale for 1M messages.End-to-end Latency.From Fig. 13b we know the number of rounds required for Streams to achieve δ ≤ 2 −30 is 16 -that makes the end-to-end latency 16 seconds for the round duration of 1 second (to scale for 1M messages).Atom is closely related to Streams in terms of security guarantees provided and its scalability.However, Atom requires around 28 minutes for their recommended parameters.On the other hand, Atom provides stronger security guarantees (δ < 2 −64 ) than Streams.We estimate the end-to-end latency of Atom (in their trap message scenario with no churn) from their measurements [10], for δ ≤ 2 −30 and c K = 10%; the estimated end-to-end latency is around 630 seconds -still an order of magnitude higher than that of Streams.The setup requirements of Atom are slightly different from Streams: Atom requires computationally powerful nodes for a large number of computation-heavy cryptographic operations, but can tolerate some nodes with low bandwidth availability.The computation becomes the bottleneck for Atom with larger messages (they use 160 byte messages in their evaluation), whereas our funnel nodes are mainly restricted by bandwidth requirement.

Application Considerations
Below we describe how our scaling technique can be used to improve some example protocols other than Streams: Loopix [9].Loopix employs multiple paths to scale for many users, which in turn reduces the chance of two messages mixing with each other.Instead Loopix can split the responsibilities in the following way: the randomized delay and mixing of messages happens at a funnel node, while the onion decryption happens at a compute node.This separation of duties would not introduce fixed-length rounds to Loopix, thus allowing Loopix to keep the desired asynchronous model.To keep a comparable level of security as well as the overall structure of the protocol, the paths chosen by clients now include both funnel nodes and compute nodes.In exchange, the separation of duties could drastically reduce the requirement to expand the number parallel paths for Loopix, and hence, could guarantee better mixing.Karaoke [4].Since Karaoke already works in rounds, it is easier to adopt our scaling technique.Depending on the number of messages that have to be processed per round, the nodes would choose one or more funnel nodes after the compute phase (e.g., one funnel node per million of messages).If the number of users in the system exceeds several million, the messages can be randomly distributed among a few funnel nodes, e.g., by using a hash function with the message and the random number from the randomness beacon as input.In that case, each honest funnel node will achieve shuffling for the subset of messages it receives.As this subset would be randomly chosen, over logmany rounds pairwise shuffling will occur.As a result, this separation of duties increases the chance of mixing, and it reduces the number of parallel paths.Reducing the number of in parallel paths in turn further improves the required number of round until messages mix, i.e., until mixing can be proven.Additionally, our scaling method will reduce the required number of messages drastically to achieve the same level of link saturation -the noise requirement will reduce from Θ(|servers| 2 ) to Θ(|funnels| 2 ).Vuvuzela [12].Vuvuzela employs a single chain of nodes and can directly enjoy the benefits of efficient scaling using our technique.The extension is very similar to how Streams employs the scaling technique in this paper: each Vuvuzela node is replaced with a funnel node and many compute nodes.By employing many compute nodes, Vuvuzela can significantly reduce the time required to process packets in a round, and thus reduce the end-to-end latency by a significant factor, or scale for more number of users with similar end-to-end latency.

Conclusion
In this paper we introduced a scaling technique for AC protocols that horizontally scale (public-key) cryptographic computations while still allowing messages to meet and mix.Our experiments demonstrate that the funnel node is 30x more efficient than a compute node, which clearly demonstrate usefulness of the proposed divide-and-funnel strategy across applications.We demonstrated the applicability of the technique with the protocol Streams by scaling it for a million messages while keeping the end-to-end latency as low as 16 seconds, and guaranteeing good pairwise unlinkability of messages with 10% compromised nodes in the system.An added advantage over other round-based protocols like Karaoke, XRD, or Atom is that Streams (and our scaling technique in general) does not require the users to be synchronized with rounds.Our scaling technique can be leveraged by other protocol designers (demonstrated through the examples of Loopix, Vuvuzela, and Karaoke) to improve scalability and mixing guarantees through network link saturation.

Figure 1 :
Figure 1: Protocol and system parameters

Figure 2 :
Figure2: Divide and funnel routing strategy in Streams: in each round messages fan out in the compute phase to all available nodes to distribute the computation-heavy task, then they are funneled through a small number of nodes in the funnel phase to achieve better mixing.When Alice sends an onion packet in round x with onion layers for nodes {5, 1, 2}, the packet also goes through the funnel nodes {3, 1} respectively, however onion decryption happens only on the compute nodes.

Figure 4 :
Figure 4: Cases where two messages mix (or not).

Figure 8 :
Figure 8: Π T and Π rer for the core Streams protocol (with single funnel every round).
INPUT QUEUE = queue to store incoming messages OUTPUT QUEUE = queue to store outgoing messages nodeID := a unique ID in [0, K − 1]

Figure 9 :
Figure 9: Node Protocol Design as described in Section 5.1.The design remains the same with multiple funnels per round (as described in Section 5.2), except the set funnels contains multiple elements.The corresponding statements are colored with teal.

Figure 10 :
Figure 10: Modifications for Streams with multiple funnel nodes per round.
corruption ratio c K vs. the probability γ of two messages not mixing in a randomly chosen funnel node and its predecessors (compute nodes) in a pair of paths.δ < 2 −40 without funnels, δ < 2 −40

Figure 13 :
Figure 13: Effective security after introducing compute and funnel phases c K vs. latency (seconds) for different values of ρ to achieve δ < 2 −30 security, to process one million packets per round.
(in seconds) vs. log δ for c K = 0.1 and ρ = 1, 2, 4. The linear decrease in log δ means exponential decrease in the δ.

Figure 14 :
Figure14: Performance vs. Resiliency against single point of failure (ρ = #funnels per round) for Streams.Note that the round size decreases with ρ for the same number of messages in the system, since the funnels are only restricted by available bandwidth, not by their processing power.

Figure 15 :
Figure 15: Scalability of Streams and performance of subcomponents To precisely characterize ℓ Maximum latency allowed for a message L Minimum required latency of a message I Set of all nodes I h Set of all honest nodes K Total number of nodes |I| c Number of compromised nodes |I − I h | O An onion packet η The security parameter δ the adversarial advantage

TABLE 1 :
Different tradeoffs offered by Streams compared to other protocols that can handle a total system load of one million messages.
The clients agree on the common path based on a randomness beacon; 2 for a given round r if the randomness beacon returns the string {x r , x r+1 , . . ., x r+ℓ }, any packet constructed at round r will be onion encrypted for the path of nodes {x r , . . ., x r+d , R} for a delay d ≤ ℓ and recipient R intended by the client.If ℓ is polylogarithmic in the security parameter η, this protocol achieves provable mixing guarantees, however, the scalability is limited by the number of packets a node can process in a round.
Construct onion packet O with path p and content (R, msg) / * R is the intended recipient for msg.* / Send (⊥, O) to x1.
• A statically corrupts all recipients in R, all senders in S except from a pair u 0 , u 1 , and a subset of I denoted by I corr , such that |I corr | ≤ c (i.e., no more than c nodes Client Protocol: SendMessage(msg): d ← DelayDistribution (ℓ/2, ℓ − 1) p := {x1, . . ., x d } $ ← − I d ; Ch and A engage in an execution of Π where Ch acts on behalf of u 0 , u 1 and the honest nodes, while A controls the corrupted parties and monitors the network traffic as a global passive adversary.•At any time t ′ , A sends a pair of challenge messages round number r): / * Compute phase in round r. * / / * All nodes act as compute nodes in compute phases.* / funnel := Query the randomness beacon tempQ := Dequeue all the elements from Qc while tempQ is not empty do O := dequeue an element from tempQ {x, O ′ } := Remove one onion layer from O if x ∈ R then deliver O ′ to x else Forward the pair {x, O ′ } to funnel over TLS end if if nodeID = funnel then / * funnel phase in round r. * / Wait for all the messages for round r from all nodes tempQ := Dequeue all elements from Q f and shuffle while tempQ is not empty do {x, O} := dequeue the first element from tempQ Forward (⊥, O) to node x over TLS Figure 3: Protocol design of Streams with divide-and-funnel scaling technique, where each round has compute and funnel phases -in the compute phase the task of onion decryption to prohibit linking is distributed over all nodes, and in the funnel phase all the messages are collected and mixed by a single randomly chosen funnel node.are corrupted).• all elements of QUEUE to A; empty QUEUE Upon receiving msg (P, Pnext, O, round) from Streams if round = Round then ADD (P, Pnext, O, Round) to QUEUE Figure 5: Round Functionality F round randomness beacon F CRF , a key registration functionality F RKR , and a secure channel functionality F SCS .The environment E can access those ideal functionalities either through the protocol parties or through the adversary.
QUEUE = a FIFO queue.SendMessage(msg, R) from party i r ← QueryRound() if round ̸ = r then reject packet and exit ADD (msg, R) to QUEUE Upon new round from E: boolean flag := RequestRound() //defined in F round if flag ̸ = true then return "invalid action" if round mod 2 = 0 // compute round then while QUEUE is not empty do m := (msg, R) ← dequeue QUEUE; d ← DelayDistribution ℓ 2 , ℓ − 1 p := {x1, ..., x d } Upon receiving a message m from Π sub : Output "Message m received" to EFigure 7: Client Protocol Design Π client as described in Section 5.1.Call Process new onion(self, msg, d + 1, p) from Π sub .Intercept the network packet packet and send it to Πrer.Call Forward Onion(O) in the subprotocol Π sub .Intercept the network packet packet and send it to Πrer.
Upon input message (onion packet O): Shuffle OUTPUT QUEUE while OUTPUT QUEUE is not empty do O ← dequeue first element from OUTPUT QUEUE Forward O to FSCS Π worker : while OUTPUT QUEUE is not empty do O ← dequeue first element from OUTPUT QUEUE call ΠT : Forward Onion(O) mod K} F Streams , inputBuffer [] array of queues to store messages for nodes crf = an infinitely long random string queue = a hashmap round := 0; newRound[] := {false, false, . . .}; partyCount := 0 Upon new round from E for party P : if newRound(P ) = true then return "invalid action" set newRound(P ) := true ; partyCount+ = 1 if round is odd (funnel round) AND P is a client then (m, t) ← dequeue inputBuffer [P ] d ← DelayDistribution( ℓ 2 , ℓ − 1); {x1, . . ., x d } I d if !∃x ∈ {x1, . . ., x d } such that x ∈ Ih then Send (m, x1, . . ., x d ) to S else let xa := the first honest party on the path {P, x1, . . ., x d } Generate a random message q Send (q, x1, . . ., xa) to S store (q, xa, m, xa+1, . . ., x d ) in queue(round + a) if round is even (compute round) AND partyCount = N + K then Upon input message (m, t) from E for party P : if round ̸ = t then reject packet and exit Add (m, t) in inputBuffer [P ] Upon receiving a message m for party P : := next honest node on the path {xa+1, . . ., x d } if there is no such x ϕ then Add (link, m, xa+1, . . ., x d ) in a temporary queue Q else generate a random message q ′ Add (link, q ′ , xa+1, . . ., x ϕ ) in Q Add (q ′ , x ϕ , m, x ϕ+1 , . . ., x d ) to queue(round+ϕ− a) Shuffle the elements of Q and send them to S Figure 12: Leakage from the ideal functionality F Streams 58 can abstract away from cryptographic details while faithfully modeling all weaknesses of the protocol.Our protocol Streams UC-realizes the ideal functionality F Streams .Theorem 2. For any subprotocol Π sub in the F RKRhybrid model that UC realizes F sub , the anonymity protocol Streams from Section 5.2 using the subprotocol Π sub in the F CRF , F RKR , F SCS , F round -hybrid model UC-realizes F Streams in the F round -hybrid model.