owned this note
owned this note
Published
Linked with GitHub
# Dissent: Accountable Anonymous Group Messaging
###### tags: `Tag(HashCloak - DC Net Readings)`
Authors: Henry Corrigan-Gibbs and Bryan Ford
Paper: [https://web.archive.org/web/20121207011906/http://dedis.cs.yale.edu/2010/anon/papers/ccs10/dissent.pdf](https://web.archive.org/web/20121207011906/http://dedis.cs.yale.edu/2010/anon/papers/ccs10/dissent.pdf)
Definitions:
### Table of Contents
[toc]
:::info
>Abstract: Users often wish to participate in online groups anonymously, but misbehaving users may abuse this anonymity to disrupt the group’s communication. Existing messaging protocols such as DC-nets leave groups vulnerable to denial-of-service and Sybil attacks, Mixnets are difficult to protect against traffic analysis, and accountable voting protocols are unsuited to general anonymous messaging. We present the first general messaging protocol that offers provable anonymity with accountability for moderate-size groups, and efficiently handles unbalanced loads where few members wish to transmit in a given round. The N group members first cooperatively shuffle an $N × N$ matrix of pseudorandom seeds, then use these seeds in $N$ “pre-planned” DC-nets protocol runs. Each DCnets run transmits the variable-length bulk data comprising one member’s message, using the minimum number of bits required for anonymity under our attack model. The protocol preserves message integrity and one-to-one correspondence between members and messages, makes denial-of-service attacks by members traceable to the culprit, and efficiently handles large, unbalanced message loads. A working prototype demonstrates the protocol’s practicality for anonymous messaging in groups of 40+ members.
:::
### 1. Introduction
Anonymous participation is often considered a basic right in free societies \[43\]. The limited form of anonymity the Internet provides is a widely cherished feature \[37, 41\], enabling people and groups with controversial or unpopular views to communicate and organize without fear of personal reprisal \[34\].
* Yet anonymity makes it difficult to trace or exclude misbehaving participants \[13\].
* Online protocols providing stronger anonymity.
* Further weaken accountability and yield forums in which no content may be considered trustworthy and no defense is available against anonymous misbehavior.
* This paper focuses on providing anonymous messaging within small, private online groups.
* We assume a group’s membership is closed and known to its members.
* Creating groups with secret membership is a related but orthogonal goal \[38\].
* We also wish to hold members accountable.
* By ensuring that no malicious member can abuse his (strong) anonymity to disrupt the group’s operation
* Not by compromising their anonymity and allowing some authority or majority quorum to unmask a member whose messages prove unpopular.
As a motivating example, suppose an international group of journalists wishes to form a “whistleblowing” publication analogous to WikiLeaks \[42\]:
* To protect journalists and their sources, member journalists wish to submit leaked documents and related information to the group anonymously.
* Member journalists need assurance that powerful organizations or governments cannot trace the leak to an individual journalist or her source.
* The journalists wish to prove to their readers that leaked documents come via a trustworthy channel, namely one of the group’s known and reputable members, and not from an outsider.
* The group must be able to analyze and vet each document thoroughly before collectively approving it for publication.
* The group must protect its internal operation and its members’ anonymity even from adversaries who have planted colluding spies within the group.
* And this security must come at acceptable time and resource costs.
We present an accountable anonymous messaging protocol called Dissent (Dining-cryptographers Shuffled-Send Network).
* The first we know of with the properties needed in scenarios like the one outlined above.
* Dissent offers integrity, anonymity, and accountability in the face of strong traffic analysis and compromised members.
* An experimental prototype shows Dissent to be efficient enough for latency-tolerant messaging in small distributed groups
In contrast with mix-networks \[9,21\] and DC-nets \[10,22,32,40\]:
* Dissent implements a shuffled send primitive, whereby each group member sends exactly one message per round, making it usable for voting or assigning pseudonyms with a 1-to-1 correspondence to real group members.
* While group and ring signatures \[4,11,30\] can anonymously authenticate messages transmitted via some anonymous transmission channel.
* Signatures offer no protection against anonymous denial-of-service (DoS).
* Or against Sybil attacks on the transmission channel itself, as Dissent does.
Dissent operates in two stages, shuffle and bulk transfer.
* The shuffle protocol builds on a data mining protocol by Brickell and Shmatikov \[7\] to permute a set of fixed-length messages, one from each group member, and broadcast the set of messages to all members with cryptographically strong anonymity.
* Like many anonymous messaging protocols, the original data mining protocol was vulnerable to untraceable DoS attacks by malicious group members.
* Our refinements remove this vulnerability by adding $go/nogo$ and $blame$ phases, which can trace and hold accountable any group member maliciously disrupting the protocol.
* Dissent’s bulk protocol builds on DC-nets to transmit variable-length messages anonymously.
* In place of the DoS-prone slot reservation systems in prior DC-nets schemes, however, Dissent leverages its shuffle protocol to prearrange the DC-nets transmission schedule.
* This guarantees each member exactly one message slot per round.
* In each round, all group members broadcast bit streams based on pseudorandom seeds distributed via the shuffle protocol.
* XORing all members’ bit streams together yields a permuted concatenation of all members’ variable-length messages.
* Cryptographic hashes distributed in the shuffle phase enable members to verify the correctness of each others’ bulk transmissions, ensuring message integrity and DoS protection throughout.
* Dissent has limitations, of course. It is not intended for largescale, “open-access” anonymous messaging or file sharing \[12,21\], although it might serve as a building block in such designs.
* Dissent’s accountability properties assume closed groups, and are ineffective if a malicious member can leave and rejoin the group under a new (public) identity after expulsion.
> Personal Note: PoS networks seem to be semi-open. Open, but not "free" to leave and rejoin.
* The serialized shuffle protocol imposes a per-round startup delay that makes Dissent impractical for latency-sensitive applications.
We built a working prototype of Dissent and tested it under Emulab \[18\] on groups of up to 44 nodes connected via simulated widearea links.
* Anonymously distributing messages up to 16MB in size among 16 nodes with 100ms inter-node delays, Dissent’s shuffle protocol and other startup costs incur a 1.4-minute latency.
> Personal Note: Still shorter than 6.4 minute epochs in ETH2.0 so if users had to wait one FULL epoch before joining the network there shoud not be an issue with membership churn specifically in regards to latency.
* Dissent handles large message loads, both balanced and unbalanced, in about 3.5× the time required for non-anonymized group messaging via TCP.
* Varying group size, Dissent can send a 1MB message anonymously:
* In less than 1 minute in a 4-node group.
* 4 minutes in a 20-node group.
* And 14 minutes in a 40-node group.
> What is the size of the message needed for a message anonymously within "Dark Rocket Pool"
This paper makes four main technical contributions:
1. It enhances Brickell/Shmatikov’s shuffle protocol \[7\] to make DoS attackers traceable without compromising anonymity.
2. It use this shuffle protocol to create a DoS-resistant DC-nets variant for bulk transfer.
* Guarantees each member exactly one transmission slot per round.
3. It introduces the first shuffle protocol that supports arbitrary-size and unbalanced message loads efficiently.
* e.g., when only one member has data to send.
4. It demonstrates through a working prototype the practicality of the protocol, at least for delay-tolerant applications.
## 2. Protocol Overview
This section first introduces the group communication model our protocol implements, outlines a few applications of this model, and defines the protocol’s precise security goals.
Dissent consists of two sub-protocols:
1. A shuffle protocol:
* The shuffle protocol has two practical limitations:
1. All messages must be of equal length $L$, incurring $O(NL)$ extra communication if only one member wishes to send.
2. Its decrypt-and-shuffle phase is inherently serial, incurring a long delay if $N$ or $L$ is large.
2. A bulk protocol:
* The bulk protocol addresses the problem of sending large, variable-length messages efficiently.
* Our shuffle protocol ensures integrity and anonymity exactly as in its precursor \[7\], but our new $go/no-go$ and $blame$ phases enable all group members to trace the culprit of any protocol malfunction.
### 2.1 The Shuffled Send Primitive
Dissent’s purpose is to provide a shuffled send communication primitive, providing sender anonymity among a well-defined group of nodes.
* We assume that the set of members comprising the group and each member’s public key (or certificate) is agreed upon and known to all group members.
* The group may initiate a run of the shuffled send protocol in any way that preserves anonymity.
* Each Dissent protocol run is independent and permits each group member to send exactly one variable-length message to some target designated for that run.
* Ongoing interaction requires multiple protocol runs.
* A run’s designated target may be:
* A particular group member.
* All members (for anonymous group multicast)
* Or another node such as a non-member “client” that initiated the run.
> Personal Note: WOuld this be the case in ETH2.0 if another network was used? The actual beacon node would run the shuffle to find a winner of the election?
* Group members might agree upon the target of a run using a higher-level “wrapper” protocol, for example, as described in Section 5.
Each protocol run operates as shown in Figure 1.
![](https://i.imgur.com/lS8ynyg.png)
* Every group member $i$ secretly creates a message mi and submits it to the protocol.
* The protocol:
* Collects all $N$ secret messages.
* Shuffles their order according to some random permutation $π$ that $no$ $one$ $knows$.
* Concatenates the messages in this shuffled order so that $m_i$ appears at position $π_i$.
* Sends the concatenated sequence of messages to the target.
* Each input message $m_i$ can have a different length $L_i$, and the protocol’s output has length $\sum_i L_i$.
### 2.2 Applications of Shuffled Send
The shuffled send model combines and generalizes the functionality of several classes of anonymity protocols.
* Although every participant must submit a message in a given protocol run, members with nothing to send can submit a message of length zero.
* Providing efficient single-sender as well as multiple-sender service.
* The protocol still requires each member to send a similar number of bits on the underlying network for traffic analysis protection.
* None of these bits are wasted for purposes of padding messages of unbalanced lengths.
* Members wishing receiver anonymity can first anonymously send a public encryption key to establish a pseudonym, then look for messages encrypted with that key in subsequent shuffled sends targeted at the whole group.
* Since each member submits exactly one message per shuffled send, one run’s messages can serve as ballots in an anonymous vote.
* A group can use one protocol run to establish a set of pseudonymous signing keys.
* Then use these pseudonyms in subsequent protocol runs for pseudonymous deliberation.
* Without permitting members to create unlimited pseudonyms for Sybil attacks \[17\] or sock puppetry \[36\].
The current version of Dissent has some notable limitations:
* E.g., it may not scale to large groups.
* It provides only a limited form of coercion resistance (described in Section 5.3).
* And the latency incurred by its shuffle protocol may make it unsuitable for interactive or real-time messaging.
### 2.3 Security Goals
> We now define Dissent’s attack model and security goals.
We assume the attacker is polynomial-time limited, but can monitor all network traffic and compromise any subset of group members.
* A member is honest if she follows the protocol exactly and is not under the attacker’s control,
* Is faulty otherwise.
* Faulty nodes are byzantine:
* They may collude and send arbitrary messages.
* For simplicity, our core protocol descriptions in Sections 3 and 4 assume that nodes never just go silent.
The formal security properties we wish the protocol to satisfy are integrity, anonymity, and accountability, as we define below:
* Integrity: The protocol maintains $integrity$ if, at the end of a protocol run involving $N$ group members, every honest member either:
* Obtains exactly $N$ messages, including each message submitted by an honest group member.
* Knows that the protocol did not complete successfully.
* Anonymity: Following Brickell and Shmatikov \[7\], the protocol maintains $anonymity$ if a group of $k ≤ N −2$ colluding members cannot match an honest participant’s message to its author with a probability significantly better than random guessing.
* If all but one member colludes, no anonymity is possible.
* Accountability: As in PeerReview \[23\], a member $i$ exposes a member $j$ if $i$ holds third-party verifiable proof of $j$’s misbehavior.
* The protocol maintains $accountability$ if no member ever exposes an honest member, and after a run, either:
* Each honest member successfully obtains every honest member’s message.
* All honest members expose at least one faulty member.
## 3. Shuffle Protocol
This section details the shuffle protocol, first covering its cryptographic building blocks, then formally describing the protocol, proving its correctness, and analyzing its complexity.
### 3.1 Cryptographic Primitives
Dissent relies on a conventional, possibly randomized signature scheme, which consists of:
* A key generation algorithm producing a private/public key pair $(u, v)$.
* A signing algorithm taking private key $u$ and message $m$ to produce signature $σ = SIG_u\{m\}$.
* And a deterministic verification algorithm taking:
* Public key $v$.
* Message $m$, and candidate signature $σ$, and returning true iff $σ$ is a correct signature of $m$ using $v$’s associated private key $u$.
* The notation $\{m\}SIG_u$ indicates the concatenation of message m with the signature $SIG_u\{m\}$.
A public-key cryptosystem is also required, which must be INDCCA2 secure \[2\].
* The cryptosystem must also provide access to the random bits it uses in key generation and encryption.
* Dissent’s accountability mechanisms use this capability for commitment and verification of behavior.
* A software implementation of RSA-OAEP \[19\] using a pseudorandom number generator meets these requirements,
We use a standard definition \[35\] of a collision-resistant $unkeyed$ $hash$ $function$ and will denote the hash of message $m$ as HASH$\{m\}$.
We use a standard definition \[35\] of a $pseudorandom$ $number$ $generator$ (PRNG). We will denote the first $L$ bits generated from a PRNG seeded with $s$ as PRNG$\{L, s\}$.
![](https://i.imgur.com/B8HHqW4.png)
### 3.2 Protocol Description
Each group member $i$ (for $i = 1, . . . , N)$ initially has a primary encryption key pair $(x_i, y_i)$, a signing key pair $(u_i, v_i)$, and a secret message $m_i$ of fixed length $L$ to send anonymously.
* Before a protocol run, all members agree on a session nonce $n_R$:
* Uniquely identifying this protocol run.
* The participants’ primary public encryption and signing keys.
* And a common ordering of all members $1, . . . , N$.
* The shuffle protocol operates in $phases$.
* Each honest member $i$ sends at most one unique message $µ_{i\phi}$ per $phase$ $\phi$.
* A member $i$ may send the same $µ_{i\phi}$ to all members.
* In which case we say $i$ $broadcasts$ $µ_{i\phi}$.
* An implementation of Dissent may use an underlying broadcast transmission primitive for this purpose.
* Or may simply send the same message $N$ times, once to each group member.
* A faulty node might equivocate during a broadcast by sending different messages to different members.
* Each group member maintains a $tamper-evident$ log of all messages it sends and receives in a protocol run \[23\].
* Member $i$ signs each $µ_{i\phi}$ it sends with its private key $u_i$, and includes in each message the session nonce $n_R$ and $a$ hash $h_{i\phi}$ of $i$’s current log head in phase $\phi$.
* Each $h_{i\phi}$ depends on all messages $i$ received up to phase $\phi$, before sending $µ_{i\phi}$.
* Members ignore any messages they receive containing a bad signature or session nonce.
![](https://i.imgur.com/ZK4LLqK.png)
![](https://i.imgur.com/4v41j1n.png)
### 3.3 Protocol Correctness
The shuffle protocol’s integrity and anonymity derive almost directly from Brickell/Shmatikov \[7\], so we only sketch proofs of these properties, focusing instead on the accountability property introduced by our enhancements.
#### 3.3.1 Integrity
To preserve integrity, after a protocol run every honest member must either:
* Hold the datum $m_i$ of every honest member $i$.
* Or, know that the protocol did not complete successfully.
#### 3.3.2 Anonymity
The protocol preserves anonymity if no group of $k ≤ N − 2$ colluding members can win an $anonymity$ $game$, determining with non-negligible probability which of two honest members submitted which of two plaintexts.
#### 3.3.3 Accountability
A member $i$ exposes another member $j$ if $i$ obtains proof of $j$’s misbehavior verifiable by a third party.
* To maintain accountability, no member may expose an honest member, and at the end of a protocol run, either:
* The protocol completes successfully, or
* Or, all honest members expose at least one faulty member.
### 3.4 Asymptotic Complexity
Since iterated public-key encryptions as performed in phase 2 typically involve plaintext expansion, let $\tilde{L} = L + O(N)$ be the size of an L-bit input message after these $2N$ encryptions.
* If the underlying network provides efficient broadcast, then each node transmits $O(N\tilde{L})$ bits during a run, for a total messaging cost of $O(N^2\tilde{L})$
* Without efficient broadcast, the “normal-case” phases 1 through 5a still require each node to transmit only $O(N\tilde{L})$ bits, for $O(N^2\tilde{L})$ overall cost, because all broadcasts in these phases are either single messages of length $O(N\tilde{L})$ or $N$ messages of length $O(\tilde{L})$.
* The blame phase in an unsuccessful run may require $O(N^3\tilde{L})$ total communication for all honest members to expose some faulty member.
* But an attacker can trigger at most O(N) such runs before the group exposes and removes all faulty members
* Latency is dominated by the N serial communication rounds in phase 3, in which each node must send $O(N\tilde{L})$ bits, for a total latency of $O(N^2\tilde{L})$ transmission bit-times.
* Other phases require a constant number of unicast messages or parallelizable broadcasts.
* Excluding the blame phase, each member’s computational cost is dominated by the $2N$ public-key encryptions and decryptions it performs.
* Each of these operations is on a plaintext of length $O(\tilde{L})$, for a processing cost of $O(N\tilde{L})$ per node or $O(N^2\tilde{L})$ total.
* The blame phase introduces an additional $O(N)$ factor if all members must replay all other members’ encryptions.
## 4. Bulk Protocol
> We now describe Dissent’s bulk protocol in detail, then analyze its correctness, security properties, and complexity.
### 4.1 Protocol Description
Members $1, . . . , N$ initially hold messages $m_1, . . . , m_N$ , now of varying lengths $L1, . . . , LN$.
* We reuse the cryptographic primitives described in Section 3.1.
* As before, each member $i$ has a signing key pair $(ui, vi)$ and a primary encryption key pair $(x_i, y_i)$.
* All members know each others’ public keys, and have agreed upon session nonce $n_R$ and an ordering of members.
![](https://i.imgur.com/Q2X2qI4.png)
![](https://i.imgur.com/Eb4Dd17.png)
### 4.2 Protocol Correctness
> We now sketch proofs of the bulk protocol’s correctness.
#### 4.2.1 Integrity
The shuffle protocol ensures that the message descriptor $di$ of each honest member $i$ is correctly included in the shuffled output.
* The target can use either the individual ciphertext hashes $H_{ij}$ or the cleartext hash HASH\{mi\}$ from $d_i$ to verify the integrity of $i$’s message in the bulk output. The cleartext hash HASH\{mi\} is technically redundant, but enables all members to verify the output if only one node collects and combines the ciphertexts for efficiency
#### 4.2.2 Anonymity
Suppose an attacker controls all but two honest members $i$ and $j$, and wishes to win the anonymity game \[7\] by determining with out formal definition or analysis, since it is intended only to illustrate one way to deploy Dissent in a realistic environment, and not to define the “right” way to do so.
* The wrapper protocol addresses five practical issues:
* Protocol initiation
* Member selection
* Deniable keying
* Liveness assurance
* And end-to-end reliability.
### 5.1 Protocol Initiation
Our shuffle and bulk protocols assume that all group members “just know” when to commence a protocol run, but in practice some node must initiate each run.
* Members must not initiate a protocol run out of a desire to send anonymously, however, since doing so would make the sender’s identity obvious to traffic analysis.
### 5.2 Selecting Available Participants
In practice at least a few members of a long-lived group are likely to be unavailable at any given time, making it pragmatically important for the group to be able to make progress in the absence of some members.
* The wrapper protocol therefore distinguishes a group’s long-term membership $M$ from the set of members $M_R$ participating in a particular run $R$, where $MR ⊆ M$.
* In the wrapper protocol, the leader of run $R$ is responsible for detecting which members are presently available, and for bringing those members available to a consensus on the precise set of participants $M_R$ for protocol run $R$.
* A key issue in choosing $M_R$ is preventing a malicious leader from packing $M_R$ with colluding members to the exclusion of most honest members, limiting the anonymity of the few honest members remaining.
* Group policy should therefore define some minimum quorum $Q$, and honest nodes must refuse to participate in a proposed run where $|M_R| < Q$.
* If there are at most $f ≤ Q − 2$ faulty nodes, honest nodes will be guaranteed at least $(Q − f)$ anonymity within a run, regardless of how $M_R$ is chosen.
* If members establish and reuse long-lived pseudonyms across multiple runs, however, then a quorum requirement may be insufficient to protect these pseudonyms from intersection attacks \[3\] by a malicious leader who selectively exludes different nodes in each run.
* As a further defense, honest members might protect each other against malicious exclusion as follows.
* If honest member $i$ receives a proposal from would-be leader $l_R$ to initiate run $R$ while excluding some other member $j$, but $i$ believes $j$ to be reachable, then $i$ demands that $l_R$ add $j$ to $M_R$ as a precondition to $i$ participating in round $R$.
* Forwarding messages between $l_R$ and $j$ if necessary.
### 5.3 Coercion Resistance via Deniable Keying
Dissent’s shuffle protocol assumes each group member $i$ has a signing key pair $(ui, vi)$ with which it signs all messages, creating the nonrepudiable “accountability trail” that the blame phase (5b) requires to trace a misbehaving member.
Our wrapper protocol can provide some repudiability or coercion resistance as follows.
* We assume each group member $i$’s well-known identity is defined $only$ by its primary encryption key pair $(x_i, y_i)$, and members now choose a fresh, temporary signing key pair $(u_i, v_i)$ for each protocol run.
* To initiate a run, the would-be leader $l$ uses a deniable authenticated key exchange algorithm such as SKEME \[28\] to form a secure channel with each potential participant $i$, using $l$’s and $i$’s primary encryption keys for this authentication.
* Each member $i$ uses this pairwise-authenticated channel to send the leader $i$’s fresh public signing key $v_i$ for the run.
* Once $l$ forms a tentative list of $N = |M_R|$ participants:
* $l$ broadcasts to all participants a round descriptor $D_R$ containing a round nonce.
* All participants’ primary public keys $y_1, . . . , y_N$
* And all participants’ temporary signing keys $v_1, . . . , v_N$ for the run.
* Each member $i$ now forms a challenge $c_{ij}$ for each node $j$.
* Containing a random seed $S_{ij}$ and a hash of $D_R$ keyed on $S_{ij}$.
* Member $i$ encrypts $c_{ij}$ with $j$’s public key $y_j$ to yield $C_{ij}$.
* Member $i$ sends its encrypted challenges to the leader, who forwards each $C_{ij}$ to member $j$.
* Member $j$ decrypts $C_{ij}$, verifies the keyed hash it contains against the $D_r$ that $j$ received from the leader, and returns $c_{ij}$ to the leader, who forwards it to $i$.
* On a decryption failure or challenge mismatch, the leader must decide whether to exclude $i$ or $j$ from a retry attempt;
* $i$ can prove its innocence by revealing the random bits it used to encrypt its original challenge to $j$.
* Once all members confirm $D_R$ with all other members, the shuffle proceeds using the temporary signing keys in $D_R$.
* These signing keys are nonrepudiable only $within$ $the$ $protocol$ $run$, so the leader can trace misbehaving members and exclude them from subsequent runs.
* No node is left with proof that any member $i$ actually used signing key $u_i$ during a given run, however.
* Since anyone can unilaterally forge all the authenticated key exchanges, challenges, and subsequent messages in the shuffle and bulk protocols.
### 5.4 Ensuring Liveness
> As we have seen, tracing active disruptors of the shuffle or bulk protocols presents particular technical challenges due to the need to protect the anonymity of honest senders
Each phase of the shuffle and bulk protocols demand that particular members send properly signed messages to other members.
* When the protocol demands that member $i$ send member $j$ a message, and member $j$ has not received such a (properly signed) message for some time, we say that $j$ suspects $i$.
* Once $j$ suspects $i$, $j$ informs another node $k$ (the leader, for example) of $j$’s suspicion;
* $k$ in turn contacts $i$ demanding a (signed) copy of $i$’s message to $j$.
* If $i$ fails to offer this message to $k$:
* Then after some time $k$ suspects $i$ as well and notifies other members in turn:
* Eventually causing all honest, connected members to suspect $i$.
* Member $i$ can dispel any honest member’s suspicion at any time by offering a copy of the demanded message.
* If $i$ honestly cannot send to $j$ due to asymmetric connectivity, for example:
* $i$ responds to $k$’s demand with the required message, which $k$ forwards back to $j$, dispelling both $j$’s and $k$’s suspicion and enabling the protocol to proceed.
> Since our wrapper protocol makes the leader responsible for initiating protocol runs, we also make it the leader’s responsibility to decide when a protocol run has failed due to a suspected node going offline—or deliberately withholding a required message—for too long. At this point, the leader starts a new protocol run, excluding any exposed or persistently suspected nodes from the previous run, and the remaining members attempt to resend their messages.
### 5.5 End-to-End Reliability
A corner-case liveness challenge for most protocols is closure:
* Determining when participants may consider the protocol “successfully concluded.”
In a byzantine model:
* While collecting the last messages of other members a malicious member might intentionally withhold:
* The last message it was supposed to send.
* Or its own ciphertext in the bulk protocol:
* Thereby learning the results of the protocol run while denying those results to other members.
We approach this class of problems in general by treating our shuffle and bulk protocols as a “best-effort” anonymous delivery substrate, atop which some higher-level protocol must provide end-to-end reliable delivery and graceful closure if desired.
## 6. Prototype Implementation
To evaluate Dissent’s practicality, we built and tested a simple proof-of-concept prototype implementing the protocol.
* The prototype is written in Python, using OpenSSL’s implementations of 1024-bit RSA-OAEP with AES-256 for public-key encryption and signing, AES-256 in counter mode as the bulk protocol’s pseudorandom number generator, and SHA-1 as the hash algorithm.
* We used the Emulab \[18\] network testbed to test the prototype under controlled network conditions.
* We ran the prototype on recent x86 PCs machines running Ubuntu 7.04 and Python 2.5, on a simulated star topology in which every node is connected to a central switch via a 5Mbps connection with a latency of 50ms (100ms node-to-node latency).
### 6.1 Performance Evaluation
![](https://i.imgur.com/yvrEhEf.png)
In each case, we test two message loads:
* A $Balanced$ load in which each node sends 1/16th of the total message data.
* And a $OneSender$ load in which one node sends all the data and other nodes send nothing.
![](https://i.imgur.com/LxT8CU3.png)
## 7. Related Work
Dissent’s shuffle protocol builds directly on an anonymous data collection protocol by Brickell and Shmatikov \[7\], adding DoS resistance via our new go/no-go and blame phases. Dissent’s bulk protocol is similarly inspired by DC-nets \[10\], which are computationally efficient and provide unconditional anonymity.
* Dissent’s use of a shuffle protocol to set up a deterministic DC-nets instance cleanly avoids DoS vulnerabilities while providing the additional guarantee that each member sends exactly one message per protocol run.
* A useful property for holding votes or assigning 1-to-1 pseudonyms.
* Cryptographically verifiable shuffles \[20, 26\] might replace our shuffle protocol, making the shuffle verifiable offline.
Tor \[14\] and Herbivore \[32\] are two well-known practical systems for providing anonymous communication over the Internet.
* These systems scale to far larger groups than Dissent does, and also permit interactive communication.
* These systems do not provide Dissent’s strong guarantees of anonymity or accountability, however.
* As a system based on mix-networks:
* Tor is vulnerable to traffic analysis attacks.
* Herbivore provides unconditional anonymity:
* But only within a small subgroup of the total group of participants.
* Dissent may be more suitable for non-interactive communication between participants willing to sacrifice protocol execution speed for strong assurances of anonymity and accountability.
## 8. Conclusion
Dissent is a novel protocol for anonymous and accountable group communication. Dissent allows a well-defined group of participants to exchange variable-length messages anonymously without the risks of traffic analysis or anonymous DoS attacks associated with mix-networks and DC-nets.
* Our implementation demonstrates Dissent to be practical, at least for non-interactive anonymous communication within moderate-size groups.