

Dissent – Accountable anonymous group communication - geographomics
http://dedis.cs.yale.edu/dissent

======
Rhapso
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.

~~~
coldcode
What does this churn involve? Too much traffic?

~~~
Rhapso
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.

~~~
onion2k
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.

~~~
valarauca1
Not exactly.

"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.

------
Xeoncross
> "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.

~~~
brynosaurus
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.

~~~
Animats
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.

------
valarauca1
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:

    
    
        1 + 3 * nodes  //with multicast
         nodes + 3 * (nodes ** 2) //without multicast
    

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.

~~~
brynosaurus
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".

~~~
valarauca1
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.

But as always the devil is in the details.

------
rdrey
I'm impressed by the number of papers already written about this. Which one is
the 'canonical' paper to read first?

~~~
ropman76
Try this one
[http://www.cs.cornell.edu/People/egs/herbivore/dcnets.html](http://www.cs.cornell.edu/People/egs/herbivore/dcnets.html)

~~~
rdrey
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?

[1]
[http://en.wikipedia.org/wiki/Dining_cryptographers_problem](http://en.wikipedia.org/wiki/Dining_cryptographers_problem)

------
btown
Here's a slide deck on how it works:
[http://dedis.cs.yale.edu/dissent/papers/ccs10/dissent-
slides...](http://dedis.cs.yale.edu/dissent/papers/ccs10/dissent-slides.pdf)

Very interesting work!

------
cryoshon
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.

------
foolinaround
What are some of the potential usecases where this could be used, in place of
Tor?

------
jlev
Dissent, paid for by DARPA.

------
ada1981
Curious to see this sitting atop HN with no discussion. What do folks think
about this?

~~~
ropman76
While Cryto is interesting, it is also very easy to get wrong. Hence the high
interest but low comments. The comments on password hashing in article
illustrate that [http://arstechnica.com/staff/2014/12/ars-was-briefly-
hacked-...](http://arstechnica.com/staff/2014/12/ars-was-briefly-hacked-
yesterday-heres-what-we-know/)

------
tatterdemalion
> 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.

~~~
brynosaurus
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.

~~~
tatterdemalion
Thankyou for clarifying.

