Dissent – Accountable anonymous group communication

There are caveats of course. This version of Dissent depends on a (small) number of servers, which are only collectively (not individually) trusted - only one of those servers needs to be honest and not colluding with the others for the security guarantees to hold, which is good for security. On the downside this means that the protocol is not robust to server churn - i.e., if one server fails, everything does grind to a halt. Other liveness/security balances are possible: e.g., we could require only a threshold number of servers to be live, at the cost of vulnerability to smaller colluding sets of malicious servers.

Another caveat is that in any anonymity system in which client churn is present AND users maintain long-lived pseudonyms of any kind, client churn can be used by a smart attacker to de-anonymize clients via intersection attacks. This basically means that if you want "the strongest possible" anonymity protection, you basically either have to (a) never maintain pseudonyms or use time-linkable communication sessions at all (difficult!), or (b) eliminate client churn completely (also difficult!). Our Buddies paper explores this tradeoff and the (admittedly limited, so far) practical defenses that we can build against intersection attacks: http://dedis.cs.yale.edu/dissent/papers/buddies-abs

Cheers Bryan

For example, if Dissent is used within a completely closed group setting, in which all members are convinced that all other members are real people and not sockpuppets, then Dissent will guarantee that no real group member will get more than one pseudonym or bandwidth share in any given communication round. At the other end of the spectrum, if Dissent is deployed in a completely open setting that allows anyone to join at any time with no barrier to entry at all, then any user will be able to create sybils or sockpuppets just by joining multiple times, and Dissent offers no sockpuppet protection - but neither would a non-anonymous group communication protocol.

More realistically, groups might operate at intermediate levels of openness with different sybil/sockpuppet protection tradeoffs, and Dissent preserves whatever protection that group management mechanism provides. For example, a group might require users to deposit a bitcoin in an escrow account on joining, which they would forfeit if the group later votes that the user is misbehaving and should be banned. Sybil attacks would still be possible but would cost money.

Consider a standard tree-based multicast protocol, where in every "communication round" the root node sends an L-bit message to its B immediate children, those children resend the message to their <=B immediate children, etc. Each node receives L bits and sends BL bits in one round.

Now consider how we could (in principle) implement DC-nets in the same tree, this time with a plaintext message originating anonymously at one of the N leaves of the tree. All N nodes create L-bit DC-net ciphertexts and send them up the tree. Each interior node obtains the <=B cipher texts from its children, XORs them together with its own L-bit ciphertext, and passes the result up the tree. The root gets the XOR of all N of the L-bit cipher texts, the (anonymous) sender's plaintext pops out, and the root broadcasts that plaintext down the tree exactly as for standard tree-based multicast. During the DC-nets phase each node receives <=B*L bits from its children and sends L bits to its parent, exactly equal to the bandwidth total cost of the (subsequent) downward multicast phase.

So in principle the fundamental cost of adding DC-nets anonymity to a tree-based multicast protocol, via this approach, is thus basically 2x over non-anonymous multicast. This applies equally to bandwidth, latency, and processing costs.

This is "in principle" of course, because there are many caveats: it's not so obvious how to make this theoretically scalable tree-based approach deal with churn or disruption, or do all the other things Dissent and other more practical systems have to deal with. Actually bringing this theoretically achievable level of scalability into practical reality is one of our goals but still very much "work-in-progress".

You can't force people to read things they don't want to, after all, and not having a way to do this programmatically leaves one vulnerable to trolls, spammers, and other bad actors.

How groups are formed and managed is another issue that Dissent doesn't determine, and group management policy may or may not enable minorities within the group to be silenced. For example, one group might have a policy in which a majority of group members can vote to silence or outright ban some member; in that case certainly the majority has the ability to silence the minority. But the Dissent protocol itself in no way endorses or requires such a policy. Another group policy might be not to provide any group-wide silencing mechanism, but only an individual-block mechanism - where any user can opt to stop seeing messages from any pseudonym they deem annoying, without affecting any other member's ability to continue seeing messages from that pseudonym.

In short, Dissent the protocol is completely agnostic to what kind of blocking mechanisms you might deploy, if any: it just provides the proportionality property you need to implement whatever voting or blocking mechanisms you might want reliably.