Some paper reading shows that while interesting, the technique being used has issues with churn. This means small, reliable groups can use a tool like this. Anonymity is only provided within the group! You cannot hide your membership. In such a situation, anonymity is only improved by making the group larger and because their solution cannot handle churn, it will not scale larger.
In general anonymity and scalability seem to be at odds, so this is not surprising. A breakthrough showing this to be the case would be awesome but (I think) unlikely.
Dissent is robust to churn among clients: communication rounds need not wait for the slowest client, and rounds can complete if some clients fail to show up. See the "Dissent in Numbers" paper for the details on how this works: http://dedis.cs.yale.edu/dissent/papers/osdi12-abs
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
Churn is when members join and/or leave. This protocol requires a fixed set of participants to start and they must all participate for it to succeed. So If I join late, I have to wait a cycle. If I leave prematurely, the cycle fails. The more participants, the more likely this is to happen.
Could that be mitigated by having a fixed number of available slots for participants, with each person taking an available slot, and random data submitted for any unused slots? Anyone leaving the cycle could send the same random data as if their slot hadn't been used, and in the next cycle random data would be submitted. Obviously there's a flaw that you'd need to predetermine the number of participants and choose a number of slots higher than that, and it'd be less efficient because you'd be sending data that isn't necessary, but might be worthwhile if the benefit of the communication is great enough.
"Neighbor nodes" have to share cryptology data with one another for verification. If you simply join a session and you inherent data from the old seat, how do you know that the data you are being handed is valid?
You don't unless you rebuild the cryptology verification with your "neighbor nodes".
The problem is the theory and documents kinda of just hand-waves inter-node communication as being "unconditionally secure", which in practice is difficult to obtain.
> "Dissent seeks to offer accountable anonymity, giving users strong guarantees of anonymity while also protecting online groups or forums from anonymous abuse such as spam, Sybil attacks, and sockpuppetry. Unlike other systems, Dissent can guarantee that each user of an online forum gets exactly one bandwidth share, one vote, or one pseudonym, which other users can block in the event of misbehavior."
Looking at some of the documentation this doesn't seem correct. It seems I could still connect multiple devices to this pool as different entities even if they are all still me.
Perhaps they mean that I would have to have multiple connections open to send multiple votes/messages. One connection cannot send multiple votes/messages.
Dissent does not specify or care how exactly a group is formed, and the sybil/sockpuppetry attack protection it provides is inevitably only as strong as the group formation mechanism. Dissent's accountability guarantee basically means that - unlike most anonymity protocols - it is not any more vulnerable to sybil or sockpuppetry attacks than (say) an otherwise-comparable group communication protocol offering no anonymity.
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.
Here's the claim in the article: Unlike other systems, Dissent can guarantee that each user of an online forum gets exactly one bandwidth share, one vote, or one pseudonym, which other users can block in the event of misbehavior. That's a very useful property. We really need something that allows creation of pseudonyms without allowing one party to create lots of them cheaply and spam. Facebook, Yelp, and Wikipedia would be standing in line to buy a technology for that.
Unfortunately, Dissent can't do that. All the system really does is guarantee that in an established, stable group, each group member can vote anonymously, but not more than once. That's much less generally useful. It doesn't help with sockpuppets.
If you make people pay for a pseudonym/account, that helps, but then you don't need Dissent.
Won't this suffer from scaling issues? Provided I'm understanding the theory correctly.
Please correct me if I'm wrong.
For every bit sent on the network to all users, each node has to transmit 3 bits to check if that 1 bit was sent by either a member of the mesh, OR an outside forgery.
While you don't authenticate the check bits (aka recurse infinitely), you do want the communication between node to node to be unconditionally secure which is fine in theory, but practice its complicated.
Also each 1 message bit, translates into 3 authentication bits (2 to neighbors, 1 to general network). Which works out to:
of network traffic as it has to be relayed to each node. So the cost is in practice (without multicast) is exponential. Sending 1 bit to 10 people costs 310 bit transfers, while 1 bit to 100 is 30100. Communicating 1 bit to ~1000 people costs ~300Mb.
In principle the DC-nets scales just as well, asymptotically, as non-anonymous multicast communication.
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".
With a tree based multi-cast protocol you have to have 1 node act as an authority over all others, which defeats the point of the DC-Net, as that node can simply lie provided its corrupted? While you can claim the network is distributed provided the root node changes at a constant interval, there will the chance that [1/nodes] messages can be forged. (if it doesn't changed you don't have a distributed network).
You could reduce this chance by having multiple root nodes.
While this would increase traffic redundancy
roots * traffic
you would lower the probability of a forged message by
nodes ** roots
And still allow for each client to verify each root node's results with each other.
With as few as 3 root nodes and 15 nodes you'd be around <0.05% of forged messages. If you increase to ~100+ scale nodes only 2 root nodes are necessary.
Thanks, this seems to be a great next step after reading the Dining Cryptographers Problem [1]! Any recommendations for papers that describe this specific implementation?
Interesting and surely useful, but it has a ways to go yet. I think that their nod to defense against sockpuppeting is going to become increasingly necessary to platforms/systems whose main purpose is anonymous discussion.
Any difficulties in scaling will be a major obstacle to mainstreamization of this technology, as others have mentioned.
On the one hand, I am glad that people are working on tools like this, but on the other hand, it seems to silently reiterate the elephant in the room: our government fights against us. The public is still a bit behind in the information technology arms race.
> Dissent can guarantee that each user of an online forum gets exactly one bandwidth share, one vote, or one pseudonym, which other users can block in the event of misbehavior.
Dissent seems like a strange name for a protocol that enables minorities within the group to be silenced.
The Dissent protocol itself only guarantees proportionality: each group member gets one and only one transmission slot in a given communications round, with exactly one fair-share quantum of transmission bandwidth. So at this level the protocol definitely does not enable minorities within the group to be silenced; it just prevents minorities (or any subset) from using more than one slot per round.
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.
I think they mean "block" in the sense of "don't show me anything else from this person" rather than the sense of "remove this person from the community".
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.
In general anonymity and scalability seem to be at odds, so this is not surprising. A breakthrough showing this to be the case would be awesome but (I think) unlikely.