owned this note
owned this note
Published
Linked with GitHub
# Dissent in Numbers: Making Strong Anonymity Scale
###### tags: `Tag(HashCloak - DC Net Readings)`
Authors: David Isaac Wolinsky, Henry Corrigan-Gibbs, and Bryan Ford
Yale University
Aaron Johnson
U.S. Naval Research Laboratory
Paper: https://dedis.cs.yale.edu/dissent/papers/osdi12.pdf
Definitions:
### Table of Contents
[toc]
:::info
>Abstract: Current anonymous communication systems make a trade-off between weak anonymity among many nodes, via onion routing, and strong anonymity among few nodes, via DC-nets.
> Dissent derives its scalability from a client/server architecture, in which many unreliable clients depend on a smaller and more robust, but administratively decentralized, set of servers. Clients trust only that at least one server in the set is honest, but need not know or choose which server to trust. Unlike the quadratic costs of prior peer-to-peer DC-nets schemes, Dissent’s client/server design makes communication and processing costs linear in the number of clients, and hence in anonymity set size. Further, Dissent’s servers can unilaterally ensure progress, even if clients respond slowly or disconnect at arbitrary times, ensuring robustness against client churn, tail latencies, and DoS attacks.
:::
### 1 Introduction
> Introduction Anonymous communication is a fundamental component of democratic culture and critical to freedom of speech.
Anonymous relay tools such as Tor offer the
strongest practical identity protection currently available,
but exhibit several classes of weaknesses:
1. First, relay systems are vulnerable to traffic analysis. A state-controlled ISP, for example, who can monitor both a user’s “first-hop” link to Tor and the “last-hop” link from Tor to the user’s communication partner, can correlate packets to de-anonymize flows.
2. Second, active disruption attacks can not only “deny service” but de-anonymize flows as well.
3. Third, independent of the underlying anonymity protocols in use, widely deployed tools often fail to isolate anonymous from non-anonymous communication state adequately, causing application-layer identity leaks via third-party browser plug-ins for example.
**Dissent**
A practical anonymous group group communication system resistant to traffic analysis. Dissent builds on and derives its strength from dining cryptographers or DC-nets and verifiable shuffles. Prior systems to adopt these techniques, such as Herbivore and an earlier version of Dissent, demonstrated usability for anonymity sets only up to 40–50 participants, due to challenges in scaling and handling network dynamics.
This paper improves the scalability of these strong anonymity techniques by at least two orders of magnitude, substantially narrowing the gap compared with relaying approaches.
> Dissent derives scalability from an anytrust architecture.
A Dissent group consists of a potentially large set of client nodes representing users, and a smaller set of servers, facilitators of anonymous communication. Each client trusts that at least any one server will behave honestly and not collude with the others against it, but the client need not know or choose which server to trust.
While anytrust is not a new idea, Dissent rethinks DC-nets communication around this model by sharing secret “coins” only between client/server pairs rather than between all node pairs, yielding a novel, practical and scalable system design. This design reduces clients’ computation and communication burdens, and crucially in practical networks, decouples a group’s overall communication performance from long “tail latencies” caused by slow, abruptly disconnected, or disruptive clients.
In Tor and prior DC-nets schemes, an adversary who controls many nodes can anonymously disrupt partiallycompromised circuits to increase the chance of complete compromise as circuits or groups re-form.
Dissent closes this vector with an accusation mechanism adapted to its anytrust network model, enabling a partially-compromised group to identify and expel disruptors without re-forming from scratch.
> Personal Note: Is this the direction that bring low-latency? How would this look in ETH 2.0 validators? In other PoS networks reforming groups?
In local-area settings with low delay and ample bandwidth, Dissent can be used for anonymous interactive browsing with performance comparable to Tor. In this context Dissent can offer a strong local-area anonymity set complementing Tor’s larger-scale but weaker anonymity.
> Personal Note: Is strong local-area anonymity enough?
Dissent addresses an important class of anonymous browsing vulnerabilities, due to application-level information leaks by confining the complete browser used for anonymous communication—including plug-ins, cookies, and other state—in a virtual machine (VM) that has no access to non-anonymous user state, and which has network access only via Dissent’s anonymizing protocols.
Dissent has many limitations and does not yet address other weaknesses, such as long-term intersection attacks.
As a step toward stronger practical anonymity, however, this paper makes the following contributions:
1. An existence proof that traffic analysis resistant anonymity is feasible among thousands of participants.
2. A client/server design for DC-nets communication that tolerates slow or abruptly disconnecting clients.
3. A accusation mechanism offering disruption resistance in large-scale, low-latency DC-nets designs.
4. A VM-based browsing architecture enforcing a separation between anonymous and non-anonymous state.
5. Experiments demonstrating Dissent’s usability in wide-area messaging applications, local-area interactive anonymity groups, and as a complement to Tor.
### 2 Background and Related Work
> This section outlines the state of the art in both practical anonymity systems and theoretical protocols, with a focus on the key security weaknesses that Dissent addresses.
#### 2.1 Practical Anonymity on the Internet
> Users can set “Do Not Track” flags asking web sites not to track them. This advisory mechanisms asks the fox to guard the henhouse, however, relying on honest behavior from the web site and all network intermediaries.
For active protection against tracking or identification,
centralized relay services such as Anonymizer offer
convenience but limited security, since one compromised
server—or one subpoena—can break a user’s anonymity.
Users can create accounts under false names on popular services such as Facebook and Google+, but risk account loss due to Terms of Service violations—often for dubious reasons and may still be traceable by IP address.
For stronger protection without a single point of failure, decentralized relay networks have proven practical and scalable. Relaying generally trades convenience against security, however, with some caveats:
**Mixminion** - Forwards E-mail through a series of relays, delaying and batching messages at each hop to offer some traffic analysis protection.
**Tor** - In contrast, consciously sacrifices traffic analysis protection to achieve low latencies for interactive Web browsing.
#### 2.2 Anonymity Sets: Size versus Strength
> The convenience that “weaker” systems such as Tor offer users may paradoxically give them a security advantage over “stronger” but less convenient systems such as Mixminion, because convenience attracts more users and thus yields much larger effective anonymity sets for their users to hide in.
> Personal Note: Very interesting analysis would be to figure out what that number is? How many nodes does it take for the added anonymity of set size to outweigh the weaker anonymity provided by Tor and low-latency systems like it? Could more nodes offset this metric even more?
Tor only offers these large anonymity sets, however, provided the attacker is not capable of traffic analysis-likely a reasonable assumption when Tor was designed.
In today’s more diverse global Internet, however, the adversary from whom users need identity protection may often be a national ISP controlled by an authoritarian state. Such an adversary realistically can monitor and “fingerprint” the traffic patterns of users and web sites en masse, completely de-anonymizing Tor flows that start and end within the same state.
Thus, Tor may informally be viewed as offering a potentially large but weak anonymity set.
> Personal Note: Seems as though Tor is useless in the face of a GPA? Which means peer-to-peer networks are also useless (for anonymity) in the face of a GPA?
Two other approaches to anonymity theoretically offer security even against traffic analysis:
1. Verifiable shuffles
2. DCnets
Communication and computation costs have in practice limited these methods to small anonymity sets, however.
* Herbivore supports mass participation by securely dividing large networks into smaller DC-nets groups, but guarantees each node anonymity only within its own group, showing scalability only to 40-node groups.
* The first version of Dissent focused on accountability rather than scalability, combining verifiable shuffles with DC-nets to prevent anonymous disruption, but scaled only to 44-node groups. These techniques thus have so far offered strong but small anonymity sets.
Today’s anonymity techniques thus present even well informed users with a security conundrum:
* to use a tool like Tor that under favorable conditions hides them among tens of thousands of others, but under unfavorable conditions may not hide them at all;
* or to use a tool that can offer only a small anonymity set but with higher confidence.
Dissent’s goal is to alleviate this conundrum.
### 3 Dissent Architecture
> This section first summarizes DC-nets, then details how Dissent achieves scalability and resilience to slow or unreliable clients.
#### 3.1 DC-nets Overview and Challenges
> Overview: In classic DC-nets, one anonymous sender in a group wishes to share a message with fellow group members. To exchange a 1-bit message, every member shares a secret random coin with each of the other N −1 members. Every pair together first flips their shared coin, agreeing on the outcome. Then each member individually XORs together the values of all the coins he shares, while the anonymous sender additionally XORs in his 1-bit message, to produce the member’s ciphertext. Finally, all members broadcast their ciphertexts to each other. Since each coin is XORed into exactly two members’ ciphertexts, all shared coins cancel, revealing the anonymous sender’s message without revealing who sent it. For longer messages, the group uses multiple coin flips—in practice, cryptographic pseudo-random number generators (PRNGs) seeded by pairwise shared secrets.
Practical implementations of this conceptually simple
design face four key challenges:
1. Scheduling
2. Disruption
3. Scalability
4. Network churn
Scheduling: Since DC-nets yield an Ethernet-like broadcast channel, in which only one member can transmit anonymously in each bit-time without colliding and yielding garbled output, an arbitration or scheduling mechanism is needed.
Disruption: Any misbehaving member can anonymously disrupt or “jam” the channel simply by transmitting random bits all the time.
> Dissent builds on and extends several prior approaches to
address these challenges
Scalability: Every member normally shares coins (or keys) with every other member, so each node must compute and combine O(N) coins for every bit of shared channel bandwidth. Computing ciphertexts via modular arithmetic instead of XORed bits can address this issue asymptotically, but at a large constant-factor cost. Communication cost can also limit scalability if every node broadcasts its ciphertext to every other.
Network Churn: As each member shares a coin with every other, a round’s output is indecipherable until all members submit their ciphertexts. Thus, one slow member delays the entire group’s progress. If any member disconnects during a round, all other members must recompute and rebroadcast their ciphertexts anew.
> Personal Note: Slashing should mitigate this and strengthen the network as attacks fail.
Beyond “normal-case” churn, an adversary who controls f group members can take them offline one one at a time to force a communication round to timeout and restart f times in succession.
> Threshold cryptography can address this issue in non-interactive scenarios, but may be too heavyweight for interactive communication.
#### 3.2 Design and Deployment Assumptions
> Dissent assumes a cloud-like multi-provider deployment
model.
A Dissent group consists of a possibly large number of client nodes representing individual users desiring anonymity within the group, supported by a small number of reliable and well-provisioned cloud of servers.
We assume each server is run by a respected, technically competent, and administratively independent anonymity service provider. We envision several commercial or non profit organizations each deploying a cluster of Dissent servers to support groups, as either a for-profit or donation-funded community service.
Clients need not rely on all or even particular providers or their servers being honest. Instead, each client trusts only that there exists at least one provider—any provider—who is honest, technically competent, and uncompromised.
> Dissent’s design relies on this assumption to achieve scalability.
![](https://i.imgur.com/qcOZzIr.png)
#### 3.3 Dissent Protocol Outline
> To initiate communication, a group’s servers periodically
run a scheduling process.
This process yields a list of pseudonym keypairs, one for each participating client. All nodes know and agree on the list of public keys and their order, and each client knows the private key for its slot in the DC-net defined by the ordered list of pseudonym keypairs, but neither clients nor servers know which clients hold which other slots.
> This list schedules subsequent DC-nets rounds, and enables the protocol to offer accountability.
![](https://i.imgur.com/T9PQXMw.png)
After setup, group members commence a continuous series of rounds.
* Each round allows the owner of each slot to transmit one or more bits anonymously, as defined by the schedule and information from prior rounds.
* During a round, each client first generates M pseudo-random strings, each based on a secret key he shares with each of the M servers, and XORs these strings together.
* To send a message, the client additionally XORs his cleartext message into the bit positions corresponding to his anonymous transmission slot.
* The client then transmits his ciphertexts to one or more servers, then waits.
The servers collect as many client ciphertexts as possible within a time window.
* At the end of this window, the servers exchange with each other the list of clients whose ciphertexts they have received.
* Each server then computes one pseudo-random string for each client that submitted a ciphertext, using the secret shared with that client.
* The server XORs these strings, together with with the client ciphertexts the server received, to form the server’s ciphertext.
* The servers then distribute their ciphertexts among themselves.
* Upon collecting all server ciphertexts, each server XORs them to reveal the clients’ cleartexts, and distributes the cleartexts to the clients connected to them, completing one DC-net round.
#### 3.4 Secret Sharing in the Anytrust Model
> The key to Dissent’s scalability and resilience to churn is its client/server secret-sharing graph. Unlike the “all-toall” secret-sharing graph in most DC-nets designs, Dissent shares secrets only between all client/server pairs
The anonymity set an honest node obtains via DC-nets consists of the node’s connected component in the secret-sharing graph, after removing dishonest nodes and their incident edges from the graph.
A sparser secret-sharing graph thus reduces a node’s anonymity, compared with the ideal anonymity set consisting of all honest nodes, if and only if the dishonest nodes partition the honest nodes into multiple connected components. Because each Dissent client shares a secret with each server, the honest nodes remain connected— yielding an ideal anonymity set—if and only if there is at least one honest server.
![](https://i.imgur.com/i21T4oD.png)
This is precisely what Dissent’s anytrust model assumes. The downside is that if all servers maliciously collude, clients obtain no anonymity.
> Personal Note: Even with nodes that are honest, if these servers were all attacked, the anonymity of the entire system would collapse.
A direct benefit of Dissent’s client/server secret-sharing is that clients enjoy a lighter computational load during exchanges. Each client shares secrets with only the M ≪ N servers, thus clients need only compute M pseudo-random bits for each effective bit of DC-net channel bandwidth.
Each of the servers must compute N pseudo-random bits per cleartext bit, as in traditional DCnets, but these computations are parallelizable, and Dissent assumes that the servers are provisioned with enough computing capacity to handle this load.
#### 3.5 Optimizing Network Communication
> Dissent leverages its client/server architecture to reduce network communication overhead.
![](https://i.imgur.com/Gdwojxq.png)
Dissent reduces the number of communication channels by a factor of N by organizing clients and servers into a two level hierarchy. Clients communicate with only a single server, and servers communicate with all other servers.
This optimization does not make a client’s anonymity dependent on the particular server it chooses to connect to, because anonymity depends on the secret-sharing graph described above and not on physical communication topology.
Since each client shares a secret with all servers, even if a client’s directly upstream server is malicious, that server cannot decode the client’s anonymous transmissions except with the cooperation of all the servers, including the honest one we assume exists.
A server can DoS-attack an attached client by persistently dropping its submitted ciphertexts, but the client will recognize such an attack from the absence of its cleartexts in the group’s output—which all servers must sign— signaling the client to switch to a different server.
> Personal Note: Could these servers be the ~8 ETH2.0 Clients (prysm, sigma...) that validator nodes connect to. If all clients colluded they could take away all anonymity, but if even once client team was honest, all users using that client would be anonymous? Would work agains a GPA, but not a Global active advisary since those client teams are public.
![](https://i.imgur.com/JhmxfBP.png)
To reduce communication costs further, servers locally combine their pseudo-random strings with their clients’ ciphertexts. Servers thus avoid forwarding individual client ciphertexts to other servers, reducing total communication complexity from O(N2) to O(N + M2) when M ≪ N. Related optimizations reduce the number of signature verifications a client performs from O(N)to O(M) and the number of messages clients must parse from O(N) to O(1).
#### 3.6 Tolerating Network Churn
> More important than reducing the computational load on clients, Dissent’s client/server secret-sharing graph enables the servers to collaborate to reduce the group’s vulnerability to client disconnection and churn, as well as deliberate DoS attacks by malicious clients.
In conventional online DC-nets, if any member goes offline, all other members must recompute and resend new ciphertexts, omitting the PRNG stream they shared with the failed member. The chance that a given round will have to be “re-run” in this way increases dramatically as group size and client churn increase.
> Personal Note: Clearly unrealistic for peer-to-peer networks
![](https://i.imgur.com/0UCD4O2.png)
Since Dissent clients share secrets only with the servers and not with other clients, a client’s ciphertext is independent of the online status of other clients.
> Personal Note: As long as one ETH 2.- client team was honest, this would reduce latency without adding privacy issues. Security issues seem apparent with a more centralized attack surface.
The servers can therefore complete a messaging round even if some clients disconnect at arbitrary points during the round, or otherwise fail to deliver their ciphertexts before a deadline.
The servers first collect those client ciphertexts that arrive in time, then agree among each other on the complete set of client ciphertexts available (the union of all servers’ client ciphertext sets), and finally XOR these client ciphertexts with the pseudo-random strings each server shares with those clients to form the servers’ ciphertexts.
> Personal Note: Consensus is achieved between the clients instead of between users (which is where it seems the lower-latency comes from?)
Thus, client delays or disconnections never require servers to interact with clients iteratively within the same round, as they would in standard DC-nets to obtain revised ciphertexts.
#### 3.7 Participation and Anonymity Metrics
> To ensure “strength in numbers,” users may wish to send anonymous messages only when at least some number of other group members are online and participating.
Since the servers know the set of clients who are online and successfully deliver ciphertexts each round, the servers publish a participation count for each round. A user who judges this count to be too low can continue to participate passively in the group but send only an empty (“null”) message in each round until participation increases.
> Personal Note: Could random data in the data set remove this need (all servers state the same number of clients)? Seems like this would lead to users always choosing the client/server with the most users so the anonomity set would be larger?
A client thus might decide to send a message on the basis of one round’s high participation count, and submit a sensitive message in the next round, only to discover after the round completes that far fewer clients remained online or delivered their ciphertexts in time. A powerful adversary might even start a DoS attack against many honest clients just as a sensitive anonymous posting is anticipated, in hopes of isolating and exposing the poster this way.
To address such risks, if the last round’s participation count was P, the servers will not complete the next round until at least αP clients submit ciphertexts, where 0 ≤ α ≤ 1 is a policy constant defined at group creation time.
> Personal Note: Could P stay constant (for each round) among servers (eth 2.0 clients)?
If fewer than αP clients submit ciphertexts by the round’s deadline, the servers keep waiting until at least αP clients show up, or until a much longer hard timeout occurs. On a hard timeout, the servers discard all clients’ ciphertexts, report the round as failed, and publish a new participation count on whose basis the clients make fresh decisions for the next round. The fraction α thus limits the rate at which participation may decrease unexpectedly round-to-round.
> Personal Note: There is still a solution for making sure consensus is reached even if the decision is to try again.
While Dissent can guarantee users that a sensitive message will be posted only when participation is at some threshold level, participation count unfortunately offers only an estimate of anonymity set size. If some participants are dishonestly colluding with the adversary, a client is anonymous only among the set of honest participants.
A group’s risk of infiltration of course depends on how it is formed and managed. In our current approach where a group is defined by a static list of public keys, the dishonest members are those whose public keys the adversary manages to persuade the group creator to include in the list at definition time, plus any formerly-honest members who the adversary might compromise after group formation. Since users cannot ultimately know how many of their peers may be “spies,” estimating anonymity necessarily remains subjective.
#### 3.8 Eliminating Empty Slot Overhead
> In typical blogging or chat applications we expect many
clients to be silent much of the time, sending null messages in most rounds and real messages only occasionally
To optimize this common case, Dissent’s scheduling scheme gives each client two slots: a one-bit request slot and a variable-length message slot. Initially the message slot is closed, with length 0. When a client sets its request bit in round r, its message slot opens to a fixed size in round r+ 1. The message slot includes a length field, with which the client can adjust the slot’s length in subsequent rounds: to send a larger message efficiently in round r+2, for example, or to close its message slot back to length 0.
A dishonest member could DoS attack another client by guessing when the victim will transmit and sending a 1 in the victim’s request slot, cancelling the victim’s open request. To address such attacks, a client first sets its request bit unconditionally, but if its slot fails to open, the client randomizes its request bit in subsequent rounds, ensuring success after t + 1 rounds with probability 1 − (1/2) t.
#### 3.9 The accusation Process
> Dishonest members can disrupt DC-nets in general by XORing non-zero bits into other members’ slots, corrupting the victim’s cleartext.
Earlier approaches to this challenge used:
* complex trap protocols
* expensive pairing-based cryptography
* or required a costly shuffle before every DC-nets round
Dissent introduces a new accusation scheme that adds little overhead in the absence of disruptors, but enables the servers to identify and expel a persistent disruptor quickly with high probability.
The overall scheme operates in three stages:
1. First, the victim of a disruption must find a witness bit in some round’s DC-net output, which we define as a bit that was 0 in the victim’s cleartext, but which the disruptor flipped to a 1.
2. Second, the victim anonymously broadcasts an accusation, a message signed with the victim’s pseudonym key identifying the witness bit.
3. Finally, the servers publish all PRNG outputs that contributed to the client and server ciphertexts at the witness bit position, using them to trace the client or server that XORed an unmatched 1 bit into this position.
The signed accusation attests that the traced node must be a disruptor.
> Personal Note: DDos'ing the network should lead to the attacker quickly losing funds in a PoS network and those funds being used to secure the network. The added overhead required from the servers could be afforded by the slashing of the attackers funds and giving those funds to the servers for the service they provide.
**The first challenge** is ensuring that a disruption victim can find a witness bit. If a disruptor could predict the victim’s cleartext output—or discover it from other honest nodes’ ciphertexts before computing its own ciphertext— then the disruptor could avoid leaving witness bits by flipping only 1 bits to 0 in the victim’s slot. To make all cleartext bits unpredictable, clients apply a cryptographic padding scheme analogous to OAEP.
The client picks a random seed r, generates a one-time pad s = PRNG{r}, XORs it with the original message m, and transmits r||m ⊕ s in the client’s message slot. Since clients submit their ciphertexts before the servers compute theirs, and the commitment phase in Algorithm 2 prevents dishonest servers from learning honest servers’ ciphertexts before computing their own, any disruptive bit-flip has a 1/2 chance of producing a witness bit.
**The second challenge** is enabling the victim to transmit its accusation: if it did so via DC-nets, the disruptor could simply corrupt that transmission as well. To avoid this catch-22, Dissent falls back on the less efficient but disruption-resistant verifiable shuffle it uses for scheduling. Each client’s DC-net message slot includes a k bit shuffle request field, which the client normally sets to 0.
When a disruption victim identifies a witness bit, it sets its shuffle request field in subsequent rounds to a k-bit random value. Any nonzero value signals the servers to start an accusation shuffle, in which the victim transmits its signed accusation. The disruptor may try to squash the shuffle request, but succeeds with at most 1−(1/2)^k chance, and the victim simply retries until it succeeds.
**The final challenge** is tracing the actual disruptor. An accusation consists of the round number in which the disruption occurred, a slot index π(i), and the index k of a bit the disruptor flipped from 0 to 1 in this slot, all signed by the slot owner’s pseudonym key, k′π(i). On receiving an accusation, the servers verify its signature, and check that the indicated bit was indeed output as 1.
The servers then recompute and exchange all the individual PRNG bits that the clients and servers should have XORed together to compute their ciphertexts: cij [k] in Algorithm 1 and sij [k] in Algorithm 2. Each server independently attempts to find a mismatch, where:
1. A server did not transmit the full set of client ciphertext bits;
2. The accumulation of transmitted bits do not match what the server sent out earlier:
* ![](https://i.imgur.com/s7x7iaN.png)
3. The client’s ciphertext bit does not match the accumulation across servers: , for some client i
* ![](https://i.imgur.com/CDJooVy.png)
#### 3.10 Scheduling via Verifiable Shuffles
> Dissent uses verifiable shuffles both to schedule and distribute pseudonym keys for subsequent DCnets rounds, and for transmitting accusations to servers.
Clients submit messages (or keys to be anonymized) to the shuffle protocol, and the shuffle outputs a random permutation of these messages (or keys), such that no subset of clients or servers knows the permutation. Dissent depends minimally on the shuffle’s implementation details, so many shuffle algorithms should be usable.
Dissent uses Neff’s verifiable shuffle to create verifiable secret permutations, and Chaum-Pedersen
proofs for verifiable decryptions.
To shuffle, each client submits an ElGamal-encrypted group element. In a general message shuffle, clients embed their messages within a group element, encrypt it with a combination of all server keys, then transmit it to first server, who shuffles the input and removes a layer of encryption. Each server shuffles and decrypts in turn, until the last server reveals the cleartexts and distributes them to all clients.
> Personal Note: So the servers work together and only one has to be honest for the anonymity assumptions to hold.
The design supports both general message shuffles and more efficient key shuffles. Key shuffles also permit the use of more computationally efficient groups that are suitable for keys but not for message embedding.
#### 3.11 Limitations
> This section discusses a few of Dissent’s shortcomings and possible ways to address them in future work.
**Large networks with many groups**
> Our evaluations demonstrate that a single Dissent network can accommodate over 5,000 clients.
To be broadly usable at Internet scale, Dissent must scale to much larger network sizes, of hundreds of thousands of nodes or more. One way to serve very large networks would be to:break the overall network into smaller parallel Dissent groups—with tens of servers and thousands of clients each. A secure join protocol, as in Herbivore, could protect a single session from being overrun with Sybil identities.
**Intersection attacks**
> Dissent’s traffic analysis resistance does not protect against membership intersection attacks, where an adversary correlates linkable anonymous transmissions to changes in clients’ online status.
If an anonymous blogger posts a series of messages, each signed by the same pseudonym but posted in different rounds, and the adversary sees that only Alice was online in all of those rounds (though many other group members were present in some rounds), the adversary might pinpoint Alice as the blogger.
> Personal Note: Would this be an issue in ETH2.0 and related peer-to-peer networks since all the validators are always voting?
Users could adopt a “buddy system,” transmitting linkable cleartexts only when all of a fixed set of “buddies” are also online. With certain caveats, this discipline ensures that a user’s anonymity set includes at least his honest buddies, at the availability cost of making the user unable to transmit (safely) when any buddy is offline.
**Handling server failure**
> Dissent addresses network churn only among clients: if a server goes offline, the protocol halts completely until all servers are available again or the group is administratively re-formed to exclude the failed server (which currently amounts to creating a new group)
We expect that Byzantine fault-tolerance techniques could be adapted to mask benign or malicious server failures, at a cost of imposing a stronger security assumption on the servers. In a BFT group designed to tolerate f concurrent failures, for example, client anonymity would likely depend on at least f +1 servers being honest, rather than just one. A malicious group leader could form a live “view” deliberately excluding up to f honest and online servers, replacing them with f dishonest servers who appear live and well-behaved but privately collude in attempt to de-anonymize clients.
> Personal Note: In the ETH2.0 scope, servers would lose a lot of reputation if they were offline or malicious. Is it reasonable to assume this would be enough for at least once server to act honestly and provide privacy for the entire network?
**Group management and server selection**
**Mobile devices**
> In the United States, consumers now use mobile phones more for Internet browsing and nonvoice data transfer than for making phone calls.
### 4 Implementation
> This section describes the current Dissent prototype and how we have applied it to two anonymous communication use cases: wide-area group messaging and local-area anonymous Web browsing.
#### 4.1 Prototype Overview
> We have implemented Dissent in C++ with the Qt framework and the CryptoPP cryptography library. The prototype implements the complete Dissent anonymity protocol along with the accountability sub-protocols.
As everyday computing shifts to mobile devices, an ongoing challenge is to offer users the same privacy protections on phones as they would have on desktop computers.
> If this system was not directly attached to validators, but it's own platform that PoS chains could connect to, is there a way to make it run on mobile phones? There are a lot of them, all over the world. Seems as though "hiding among the crowd" would mean hiding among the billions (3.8 billion as of 2020 apparently https://www.statista.com/statistics/330695/number-of-smartphone-users-worldwide/)
> How many of those users have enough bandwidth/storage to even participate in a network like this?
> How will this change as bandwidth/storage constraints are lowered by tech advances?
The prototype also assumes that participants have used an outside channel to agree upon a common set of servers.
* User applications interact with a node running our Dissent prototype using HTTP API calls or a SOCKS proxy interface.
* The HTTP API allows clients to post raw messages (byte-strings) directly into the protocol session.
* The prototype’s SOCKS v5 proxy allows users to tunnel TCP and UDP traffic flows transparently through the Dissent protocol session.
* One or more nodes in the Dissent network serve as SOCKS entry nodes, which listen for incoming SOCKS proxy requests from user applications (e.g., Skype or Firefox).
* The entry node accepts SOCKSified traffic flow from the user application, assigns the flow a random identifier (to allow a receiving node to distinguish between many flows), adds destination IP and port headers to the flow, and sends it into the active Dissent protocol round.
* A single SOCKS exit node (who is a nonanonymous protocol participant) reads the tunneled traffic from the Dissent protocol round, forwards it over the public network to the destination server, and sends the response back through the Dissent session.
#### 4.2 Anonymous Microblogging Application
> Dissent’s decentralized architecture and trust model make it potentially attractive as a substitute for commercial microblogs in high-risk anonymous communication scenarios.
Since Dissent relies on no single trusted party, we expect it to be much more challenging even for a powerful adversary—such as an authoritarian government or its state-controlled ISP—to identify an anonymous blogger without compromising all participating Dissent servers.
In our evaluation section, we present performance results for a prototype microblogging system running on PlanetLab with up to 2,000 nodes and DeterLab with up to 5,000 nodes. A simple chat-like Web interface allows users to post short messages into an Dissent protocol session using our HTTP API. Our results suggest Dissent could form a practical platform for Internet-scale microblogging in situations requiring stronger security properties than the current commercial platforms offer.
#### 4.3 Local-Area Web Browsing
> When deployed in a local-area network, Dissent
can provide interactive communication with local-area anonymity: requests are anonymous among a local set of users.
In WiNoN, depicted in Figure 5, the Dissent client software runs on the host OS with network traffic from the WiNoN VM tunneled through the Dissent SOCKS proxy. Since applications in the WiNoN VM have no access to the network interface or to the user’s non-anonymous storage, they are unable to learn the user’s long-term identity (unless the user inadvertently enters some identifiable information into the WiNoN VM).
![](https://i.imgur.com/innwnmr.png)
On simulated WiFi networks with tens of nodes and typical bandwidth and delay parameters, we find the WiNoN anonymization network fast enough for browsing the Internet and streaming videos. Prior work uses virtual machines to isolate network environments [41] and tunnel traffic through Tor [55]. No previous system to our knowledge, however, enables a user to run Flash movies, Skype, and other untrusted applications safely and anonymously.
### 5 Evaluation
* This section first examines Dissent’s ability to handle unreliable client nodes.
* Next we evaluate Dissent’s performance and scalability in instant-messaging and data sharing scenarios with varying numbers of clients and servers.
* We then explore the costs of different protocol stages: the initial key shuffle, a DC-net exchange, and finally the accusation process.
* Finally, we evaluate the performance of Dissent applied to the WiNoN Internet browsing application described in section 4.3.
#### 5.1 Slow and Unreliable Clients
> On public networks, distributed systems must cope with
slow and unreliable machines.
Dissent’s servers prevent slow nodes from impeding the protocol’s overall progress by imposing a ciphertext submission window. Once the client submission time window has closed, servers continue executing the protocol even if every client has not submitted a ciphertext. Larger windows potentially allow more clients to participate in each message exchange, but increase message latency. Smaller windows size reduce latency of exchanges but might prevent slower clients from participating.
> Personal Note: Whatever latency needs were required could be met? Start with a long window (high-latency) and as consumer hardware/software improves, so would the number of users who could reasonably take part in the network. (maximizing for slow clients)
#### 5.2 Wide-Area Applications
> To evaluate Dissent’s usability in wide-area microblogging or data sharing scenarios, we evaluated the protocol on both DeterLab and PlanetLab.
* On DeterLab, which offered controlled test conditions and greater hardware resources, we evaluated both a microblog and data sharing like behavior.
* We evaluated only the microblog scenario on PlanetLab.
* To simulate a plausible traffic load in the microblog scenario, a random 1% of all clients submit 128-byte messages during any particular round.
* In the data sharing scenario, one client transmits a 128KB message per round.
* Due to time and resource limitations, the DeterLab evaluation used two system topologies: 32 servers with 10 client machines per server, and 24 servers with 12 client machines per server, for a total of 320 and 288 client machines respectively.
* To simulate a larger number of Dissent client participants than we had physical testbed machines for, we ran up to 16 Dissent client processes on each client machine, for up to 5120 client processes.
* In the testbed topology, servers shared a common 100 Mbps network with 10 ms latency, while clients shared a 100 Mbps uplink with 50 ms latency to their common server.
* We intended the servers to share a 1000 Mbps network, but the testbed did not support this configuration.
* For the PlanetLab tests, we deployed 17 servers: 16 on EC2 using US East servers and one control server located at Yale University.
> The latency between Yale and EC2 was approximately 14 ms round trip. This clustered setup is intended to represent a deployment scenario in which multiple organizations offer independently-managed Dissent servers physically co-located in the same or geographically nearby data centers, facilitating high-bandwidth and low-latency communication among the servers while keeping their management decentralized for security.
![](https://i.imgur.com/6HvBuDZ.png)
> Figure 7 shows the system’s scalability with client load by varying the number of clients relying on a static set of 32 servers.
![](https://i.imgur.com/o4JY9Wj.png)
> Figure 8 in turn varies the number of servers while maintaining a static set of 640 clients. At smaller group sizes, additional servers do not benefit performance.
In the static client network, varying server count, showed time increases on server-related aspects of the protocol but reduced time on client-related aspects. We therefore expect that with greater demand—either in terms of nodes or bandwidth—client-related costs are likely to dominate.
In comparing the microblogging and 128K message scenarios, the graphs suggest that bandwidth tends to dominate for larger messages and latency for smaller messages.
> Most importantly, the evaluations suggest that Dissent can support delay-sensitive applications like microblogs and instant messaging.
#### 5.3 Full System Evaluation
> While the previous experiments focused on measuring DC-nets rounds, the primary focus of this paper, we now explore time durations in a single full execution of the entire Dissent protocol: key shuffle, a single DC-net exchange, accusation shuffle, and accusation tracing.
![](https://i.imgur.com/yWuArmu.png)
Our results shown in Figure 9 used the same DeterLab configuration consisting of 24 servers with 12 clients each configuration as described in the previous section. In contrast to verifiable mix-nets, the Dissent protocol’s DC-nets round is extremely efficient, accounting for a negligible portion of total time in large groups. The time difference between accusation and key shuffles illustrate the performance benefits of the key shuffle discussed in Section 3.10. In small groups the accusation shuffle is reasonably fast, but in larger groups its cost increases quickly, to over an hour for 1,000-client groups.
#### 5.4 Web Browsing: Dissent and Tor
> To explore the practicality of Dissent for local-area anonymity as described in section 4.3, we deployed a smaller-scale Dissent network of 5 servers and 24 clients on the Emulab network testbed.
The testbed’s experimental network topology approximated the characteristics of a small WiFi network: each node was connected to a central switch via a 24 Mbps link with 10 ms of latency. One of the servers acted as a gateway connecting the private test network to the public Internet.
![](https://i.imgur.com/c1tYboc.png)
The results in Figure 10 indicate that anonymous web browsing under the local-area deployment of Dissent we tested performs comparably to Tor, suggesting that users are likely to find some Dissent configurations similarly usable under appropriate network conditions.
Figure 11 shows a CDF of page download times, showing that a client using Tor downloads the first 50% of Web pages in 15 seconds, while a client using Dissent+Tor downloads 50% of Web pages in just under 20 seconds.
On average, downloading 1MB of Web content took 10 seconds with no anonymization, it took 40 seconds through Tor, 45 seconds with Dissent, and 55 seconds with Dissent and Tor together.
Comparing Dissent+Tor with Tor alone, this data suggests that a user willing to tolerate a 35% slowdown could retain Tor’s wide-area benefits while gaining traffic analysis resistant anonymity in the user’s local area.
### 6 Conclusion
> This paper has made the case that by delegating collective trust to a decentralized group of servers, strong anonymity techniques offering traffic analysis resistance may be adapted and scaled to offer anonymity in groups of thousands of nodes, two orders of magnitude larger than previous systems offering strong anonymity.
Through its novel client/server DC-nets model, Dissent is able to accommodate anonymity set sizes of up to 5,000 members, while maintaining end-to-end latency low enough to enable wide-area interactive messaging. In local-area settings, Dissent is fast enough to handle interactive Web browsing while still offering users strong local anonymity guarantees. Although Dissent represents a step towards strong anonymous communication at large Internet scales, many challenges remain for future work, such as further scalability and robustness improvements and protection against long-term intersection attacks.