Dining cryptographers problem

From Wikipedia, the free encyclopedia

In cryptography, the dining cryptographers problem studies how to perform a secure multi-
party computation of the boolean-OR function. David Chaum first proposed this problem in
1988, and used it as an illustrative example to show it was possible to send anonymous
messages with unconditional sender and recipient untraceability.[1] Anonymous
communication networks based on this problem are often referred to as DC-nets.

Despite the word dining, the dining cryptographers problem is unrelated to the dining
philosophers problem.

Contents
 1 Description
 2 Limitations
 3 Generalizations
o 3.1 Transmissions of longer messages
o 3.2 Larger group sizes
o 3.3 Sparse secret sharing graphs
o 3.4 Alternate alphabets and combining operators
 4 Handling or Avoiding Collisions
 5 Countering disruption attacks
 6 References

Description

Dining cryptographers problem illustration

Three cryptographers gather around a table for dinner. The waiter informs them that the meal
has been paid by someone, who could be one of the cryptographers or the National Security
Agency (NSA). The cryptographers respect each other's right to make an anonymous
payment, but want to find out whether the NSA paid. So they decide to execute a two-stage
protocol.

In the first stage, every two cryptographers establish a shared one-bit secret, say by tossing a
coin behind a menu so that only two cryptographers see the outcome in turn for each two
cryptographers. Suppose, after the coin tossing, cryptographer A and B share a secret bit , A
and C share , and B and C share .

In the second stage, each cryptographer publicly announces a bit, which is

 if they didn't pay the meal, the Exclusive OR (XOR) of the two shared bits they hold
with their two neighbours
 if they did pay the meal, the opposite of that XOR.

Suppose none of the cryptographers paid, then A would announce , B would

announce , and C would announce . On the other hand, if A paid, he would
announce .

After the second stage is the truth revealing. One simply performs XOR of all the announced
bits. If the result is 0, then it implies that none of the cryptographers paid (so NSA must have
paid). Otherwise, it would imply one of the cryptographers paid, but their identity remains
unknown to the other cryptographers.

The above protocol was named by David Chaum as the Dining Cryptographers network, or
DC-net.

Limitations
The DC-net protocol is simple and elegant. It has several limitations, however, some
solutions to which have been explored in follow-up research (see the References section
below).

1. Collision - If two cryptographers paid for the dinner, their messages will cancel each other
out, and the final XOR result will be . This is called a collision, and allows only one
participant to transmit at a time using this protocol. In a more general case, a collision
happens as long as any even number of participants send messages.

2. Disruption - Any malicious cryptographer who does not want the group to communicate
successfully can jam the protocol so that the final XOR result is useless, simply by sending
random bits instead of the correct result of the XOR. This problem occurs because the
original protocol was designed without using any public key technology, and lacks reliable
mechanisms to check whether participants honestly follow the protocol.

3. Complexity - The protocol requires pair-wise shared secret keys between the participants,
which may be problematic if there are many participants. Also, though the DC-net protocol is
"unconditionally secure", it actually depends on the assumption that "unconditionally secure"
channels already exist between pairs of the participants, which is not easy to achieve in
practice.

A related anonymous veto network algorithm computes the logical OR of several users'
inputs, rather than a logical XOR as in DC-nets, which may be useful in applications to which
a logical OR combining operation is naturally suited.

Generalizations
DC-nets generalizes readily to allow transmissions of more than one information bit per
round, to groups larger than three participants, and to arbitrary "alphabets" other than the
binary digits 0 and 1, as described below.

Transmissions of longer messages

To enable an anonymous sender to transmit more than one bit of information per DC-nets
round, the group of cryptographers can simply repeat the protocol as many times as desired to
create a desired number of bits worth of transmission bandwidth. These repetitions need not
be performed serially. In practical DC-net systems, it is typical for pairs of participants to
agree up-front on a single shared "master" secret, using Diffie–Hellman key exchange for
example. Each participant then locally feeds this shared master secret into a pseudorandom
number generator, in order to produce as many shared "coin flips" as desired to allow an
anonymous sender to transmit multiple bits of information.

Larger group sizes

The protocol can be generalized to a group of participants, each with a shared secret key in
common with each other participant. In each round of the protocol, if a participant wants to
transmit an untraceable message to the group, they invert their publicly announced bit. The
participants can be visualized as a fully connected graph with the vertices representing the
participants and the edges representing their shared secret keys.

Sparse secret sharing graphs

The protocol may be run with less than fully connected secret sharing graphs, which can
improve the performance and scalability of practical DC-net implementations, at the potential
risk of reducing anonymity if colluding participants can split the secret sharing graph into
separate connected components. For example, an intuitively appealing but less secure
generalization to participants using a ring topology, where each cryptographer sitting
around a table shares a secret only with the cryptographer to their immediate left and right,
and not with every other cryptographer. Such a topology is appealing because each
cryptographer needs to coordinate two coin flips per round, rather than . However, if Adam
and Charlie are actually NSA agents sitting immediately to the left and right of Bob, an
innocent victim, and if Adam and Charlie secretly collude to reveal their secrets to each
other, then they can determine with certainty whether or not Bob was the sender of a 1 bit in a
DC-net run, regardless of how many participants there are in total. This is because the
colluding participants Adam and Charlie effectively "split" the secret sharing graph into two
separate disconnected components, one containing only Bob, the other containing all other
honest participants.
Another compromise secret sharing DC-net topology, employed in the Dissent system for
scalability,[2] may be described as a client/server or user/trustee topology. In this variant, we
assume there are two types of participants playing different roles: a potentially large number
n of users who desire anonymity, and a much smaller number of trustees whose role is to
help the users obtain that anonymity. In this topology, each of the users shares a secret with
each of the trustees - but users share no secrets directly with other users, and trustees share
no secrets directly with other trustees - resulting in an secret sharing matrix. If the
number of trustees is small, then each user needs to manage only a few shared secrets,
improving efficiency for users in the same way the ring topology does. However, as long as
at least one trustee behaves honestly and does not leak his or her secrets or collude with other
participants, then that honest trustee forms a "hub" connecting all honest users into a single
fully connected component, regardless of which or how many other users and/or trustees
might be dishonestly colluding. Users need not know or guess which trustee is honest; their
security depends only on the existence of at least one honest, non-colluding trustee.

Alternate alphabets and combining operators

Though the simple DC-nets protocol uses binary digits as its transmission alphabet, and uses
the XOR operator to combine cipher texts, the basic protocol generalizes to any alphabet and
combining operator suitable for one-time pad encryption. This flexibility arises naturally
from the fact that the secrets shared between the many pairs of participants are, in effect,
merely one-time pads combined together symmetrically within a single DC-net round.

One useful alternate choice of DC-nets alphabet and combining operator is to use a finite
group suitable for public-key cryptography as the alphabet - such as a Schnorr group or
elliptic curve - and to use the associated group operator as the DC-net combining operator.
Such a choice of alphabet and operator makes it possible for clients to use zero-knowledge
proof techniques to prove correctness properties about the DC-net ciphertexts that they
produce - such as that the participant is not "jamming" the transmission channel - without
compromising the anonymity offered by the DC-net. This technique was first suggested by
Golle and Juels,[3] further developed by Franck,[4] and later implemented in Verdict, a
cryptographically verifiable implementation of the Dissent system.[5]

Handling or Avoiding Collisions

The measure originally suggested by David Chaum to avoid collisions is to re-transmit the
message once a collision is detected, but the paper does not explain exactly how to arrange
the re-transmission.

Dissent avoids the possibility of unintentional collisions by using a verifiable shuffle to

establish a DC-nets transmission schedule, such that each participant knows exactly which
bits in the schedule correspond to his own transmission slot, but does not know who owns
other transmission slots.[6]

Countering disruption attacks

Herbivore divides a large anonymity network into smaller DC-net groups, enabling
participants to evade disruption attempts by leaving a disrupted group and joining another
group, until the participant finds a group free of disruptors.[7] This evasion approach
introduces the risk that an adversary who owns many nodes could selectively disrupt only
groups the adversary has not completely compromised, thereby "herding" participants toward
groups that may be functional precisely because they are completely compromised.[8]

Dissent implements several schemes to counter disruption. The original protocol[6] used a
verifiable cryptographic shuffle to form a DC-net transmission schedule and distribute
"transmission assignments", allowing the correctness of subsequent DC-nets ciphertexts to be
verified with a simple cryptographic hash check. This technique required a fresh verifiable
before every DC-nets round, however, leading to high latencies. A later, more efficient
scheme allows a series of DC-net rounds to proceed without intervening shuffles in the
absence of disruption, but in response to a disruption event uses a shuffle to distribute
anonymous accusations enabling a disruption victim to expose and prove the identity of the
perpetrator.[2] Finally, more recent versions support fully verifiable DC-nets - at substantial
cost in computation efficiency due to the use of public-key cryptography in the DC-net - as
well as a hybrid mode that uses efficient XOR-based DC-nets in the normal case and
verifiable DC-nets only upon disruption, to distribute accusations more quickly than is
feasible using verifiable shuffles.[5]