An Analysis of Chaum's Dining Cryptographer's Problem and Development of
Protocols for Enhanced Functionality in a Real-World Implementation
========================================================================

Introduction
============

It would probably be beneficial for a reader of this paper to have read
David Chaum's "The Dining Cryptographer's Problem", in particular to be able
to follow when I mention things that Chaum develops in that paper that I feel
were ill-considered from a real-world standpoint.  However, to be as
accessible as possible this introduction will introduce enough of the 
information from that paper to allow a reader to follow what I'm doing.

The following is a direct quote from that paper describing the basis of the
Dining Cryptographer's Problem, as Chaum does a better job of this than I can:

    Three cryptographers are sitting down to dinner at their favorite 
    three-star restaurant. Their waiter informs them that arrangements 
    have been made with the maitre d'hotel for the bill to be paid 
    anonymously. One of the cryptographers might be paying for the dinner, 
    or it might have been NSA (U.S. National Security Agency). The three 
    cryptographers respect each other's right to make an anonymous 
    payment, but they wonder if NSA is paying. They resolve their 
    uncertainty fairly by carrying out the following protocol:
     
    Each cryptographer flips an unbiased coin behind his menu, between 
    him and the cryptographer on his right, so that only the two of them can 
    see the outcome. Each cryptographer then states aloud whether the two 
    coins he can see--the one he flipped and the one his left-hand neighbor 
    flipped--fell on the same side or on different sides. If one of the 
    cryptographers is the payer, he states the opposite of what he sees. An 
    odd number of differences uttered at the table indicates that a 
    cryptographer is paying; an even number indicates that NSA is paying 
    (assuming that the dinner was paid for only once). Yet if a 
    cryptographer is paying, neither of the other two learns anything from 
    the utterances about which cryptographer it is.

The proof of this statement will be taken as read, the reader can look at
Chaum's paper to find out more.  Chaum then goes on to expand this protocol
for an arbitrary number of players, and has them sharing what I call coin keys
rather than flipping coins.  In the most basic and secure form of this
protocol, and the only one I will consider for purposes of this paper, every
member shares a coin key with every other member.  Each round, each member
XOR's together the least significant bit of all of his coin keys, and, if he
wishes to transmit a bit for that round, inverts the result, which he then
announces (one of the important issues Chaum neglects is how this announcement
is made).  Everyone's announced results are XOR'd together to get the one-bit
result for that round.  Since each coin key generated bit is XOR'd into the
total exactly twice, once by each person sharing the key, the final total will
be zero if any even number of people invert their result, and 1 if any odd 
number do so.

I prefer to extend Chaum's original description of the problem, quoted above,
in a more direct way by having members flip coins and show them to a neighbour
and so on around a ring.  The fact that the final result is what it should be
will be shown towards the end of the paper.  This methodology, in its most
basic form, is not as secure as Chaum's, but is much easier to implement in a
real-world application and I will be expanding on it to make it much more
secure in the course of this paper.

These generalised algorithms are known as Dining Cryptographer's Networks, or
DC-nets.  I will refer to them as such throughout, reserving the term
'network' to refer to the communications medium over which the DC-net is
implemented.  The primary purpose of a DC-net is to allow untraceable
communication between a group of participants.  Chaum's focus was provable
untraceability amongst a group of participants who all knew of each other's
presence and could communicate to the rest of the group freely.  My focus is
on computationally secure untraceability amongst possibly arbitrary groups of
people, using Chaum's work as a basis in that if everyone on the DC-net acts
fairly, the result will be a network as provably untraceable as Chaum's.  How
to deal with colluders and eavesdroppers will be the subject of most of the
rest of this paper.  The primary real-world uses of DC-nets would be support
groups, secret-sharing groups (i.e. conspiracy theorists and cryptographers)
and organised secret societies.
 
Security Issues
===============

Internal Anonymity (or Untraceability) in the Absence of Spoofing
-----------------------------------------------------------------

In the absence of collusion, this is an non-issue, by definition of the DC-net
protocol (that's sort of the point of it, after all).  A reasonable goal,
then, is to maximise the number of colluders that must be present to identify
then location (on the network) of the current speaker.  Note that spoofing, in
this case, refers to telling a person joining the DC-net that it is not laid
out in the way it actually is, that people have different keys then they
actually do, et cetera.  In other words, in the absence of spoofing
participants are expected to all share the same information about what the
network looks like (and for them all to be sharing the same _correct_
information!).

The following protocol only allows identification of a speaker's position on
the DC-net in the trivial case, when all other members collude.  It uses coin
tossing rather than coin-key-sharing, has a ring as the communications model
and uses TCP/IP as the communications medium.  Also, connections and
disconnections are assumed to occur regularly, with the only adjustment being
that others on the DC-net add or remove people's public keys as appropriate
and that the ring is restored after someone leaves.

Each participant creates a temporary public/private key pair for each time
they join a DC-net session.  The key need not be exceptionally secure because
if colluders collect all of the information from a session and crack keys
later, the breaking of anything less than all non-colluder held keys will
reveal _no_ additional information!  So, as long as there is at least one
other honest member, an honest member can be assured of the strength of his
key being increased (significantly) by the need to crack everyone else's keys
as well.  For a good combination of security and speed, which is very
necessary, I would suggest a 256-bit key length, given current cracking
technologies.  The key length should be decided on by everyone on the network
beforehand.

As previously stated, the communications structure is a ring.   Each person
flips a coin, and passes a message stating the value of the flip to the person
on their right, as per the original DC problem.  The person on their right
then flips a coin, and compares their coin with the one they were passed to
arrive at what we will call an inversion value (IV), for reasons to be explained
later.  If the two coins are the same, the IV=0, otherwise the IV=1.  If this
person wishes to transmit a bit this round, they invert their IV.  

When a new user joins, he transmits his temporary key around the ring.  It is
highly desirable that said key not identify the real-world user in any way,
although it could be bound to a handle's name that the user frequently uses.
After coin flipping, each member generates a set of messages, each one bit
long, whose XOR total is their IV.  Each of these messages is encrypted to a
different member of the network, so if there are n members on the DC-net, each
member will generate up to n such messages.  Note that if all of the
recipients of these messages for the person who is currently sending to the
DC-net are colluders, the sender's position may be compromised.  The minimum
requirement to avoid compromise is that one such message is sent from one
honest user to another.  For this reason, sending these messages to every one
(i.e. sending out n of them), including yourself for obscurity purposes, is
recommended.

This encrypted-bit messages are distributed around the ring.  Then, in a
second pass, or third if you include the original coin-flipping pass, each
member decrypts all the encrypted-bit messages for them, XOR's them together,
and XOR's this to the total so far, which the first person to perform this
step should initialise to 0.  Since the whole point of this is that no-one can
identify which public key a message belongs to unless they hold the private
key, it is _vital_ the the PKES in question be able to quickly check if, given
a private key, that private key can decrypt a particular message, since each
member will be testing n squared messages, assuming everyone sends messages to
everyone.

The final XOR'd result will be the bit for this round. As usual in this paper, 
disruption is not considered, as the ways to disrupt this scheme are legion,
but do not generate any additional information for colluders.

As a final note, it may seem to the reader that this scheme substitutes
unconditional untraceability with only computationally secure untraceability,
but this is only the case when colluders have complete information about the
coins that were tossed in some portion of the DC-net.  In the case where the
protocol is carried out faithfully, it is as unconditionally secure  as 
Chaum's original description of the protocol.  It is possible have everyone
toss coins with everyone else (the best way to do this would be for two
members to each toss a coin which they tell each other and use the XOR of the
two as their shared coin) in a fashion similar to Chaum's original extension
of the protocol to arbitrary numbers of users, but the exchange of tosses
would some form of secure channel, and hence not be an improvement over the
method given above.  In fact, if the most obvious means of doing things,
having every member make a network connection to every other member, was used,
it would have severe consequences for the issues discussed in the next
section.

External Anonymity in the Absence of Spoofing
---------------------------------------------

The idea is that, in some cases, we want to make it as difficult to determine
who (in a communications network address sense) is on the DC-net.
Depending on the type of motivation behind the DC-net, this may or may not be
an important goal, and certainly is not considered important in traditional
discussions of DC-nets.  I consider important, however, for certain real-world
applications.  A support group would probably want this as, for example,
simply being a member of AA casts certain suspicions.  Note that we are
assuming that members do not know each other's network addresses either.

The primary tool of the eavesdropper, call here Eve as usual, will be packet 
sniffing. Traffic analysis may come into play, but unless _very_ interesting 
things are done with routing, this is unlikely to be an issue as the main tool 
in defeating traffic analysis, long randomised delays, is impossible to use 
here.  In other words, simply looking at the right packet tells you all you 
need to know, and these packets will be coming by quite often, so traffic 
analysis is useless.

The minimum number of connections required by each member, in the absence of 
a server of some kind, is two: one to the right partner and one to the left
partner.    We could structure things in a line, with messages bouncing at the
ends, but still two links are required for all but the end points, at least if
there are more than two people on the network.  This was the motivation for
the choice of a ring as the communication structure: it minimises the number
of connections made by each member, hence minimising the information that can
be gained by packet sniffing any one member.

It also seems that it would be ideal to always connect to the same left and
right partners, and in cases where every member should always be present any
time the DC-net is in use, as Chaum seems to assume, this is quite plausible.
Unfortunately, it isn't plausible in general.  We are assuming here that Eve
is not all powerful, and we want to minimise the information she gets for each
machine she can sniff freely.

If the protocol calls for a server and the server's only use is for the
DC-net, clearly sniffing the server reveals all players.  In this case, it is
best to have the DC-net server doing as many other things as possible,
although it is probably not feasible to disguise which messages are related to
the DC-net.  A good way to get around this is to have the server be able to
respond to queries from anyone by giving them information about the current
state of the DC-net, such as number of members on and their temporary keys.
This will at least make Eve's job harder, as a connection to the server only
proves interest in the DC-net, not membership.  In general, though, using a
server makes external anonymity a very hard problem.


Connections and Spoofing
------------------------

Various mechanisms for joining the network exist, depending on the type of
usage the network is being put to and the security requirements this entails.
The simplest solution, by far, is for all members to know each other and to
arrange ahead of time, through some well authenticated means, when each DC-net
session is to take place and who it is to involve.  They should also, again
through some authenticated means, exchange ahead of time what their temporary
keys will be for the upcoming DC-net session in question, and who will be
their left and right partners. At this point, everyone to be involved has 
complete information about the session, so spoofing is impossible.

The above design, however, has two major real world flaws: sessions are
completely static (i.e. no-one can leave or join a session in progress) and
all members must know each other, which can be a security risk if external
anonymity is important, as well as being difficult to administer.

The problem with more dynamic alternatives is that they are vulnerable to
spoofing, as I shall now describe.  Note that even Chaum's methodology of
sharing keys instead of coin tossing, even in a completely connected graph, is
vulnerable to this attack if people are allowed to leave and join a DC-net
session in progress.  I will assume here that a server is not being used, but
of course everything here applies equally well to server solutions if the
server is corrupt.

Let's say that A wishes to join the DC-net, which currently has 8 members.
She asks for, or is given, a spot between two colluders, call them B and C, so
the ring looks like ...->B->A->C->..., and when she joins she is given
information about the current state of the ring, either from B and C or from a
server of some kind.  Remember, we are assuming here that A does not know who
is currently on the ring.  Let's say that A is lied to, and is told that A, B
and C are the only members on the ring at the moment, so A believes that the
ring consists of B->A->C->B.  Let's further assume that the last time A was on
the DC-net, she was having a compromising conversation (untraceably, of
course) with someone on the real DC-net who is not B or C.  What B and C now
do is transfer A's messages to the real ring and transfer selected messages
from the real ring to the small, virtual ring they share with A.  Since A's
previous conversation was untraceable, she has no reason to believe that she
was not communicating with one of B or C, and since she is only passing
messages with them, they can trivially collude to determine which speaker she
is in the conversation, even though both A and the person she is talking to 
see everything as OK!  B and C and even add a fake public key, of their own
choosing, to the real ring to simulate A's joining, and can spoof a bunch of
fake public keys at A to make her think that the correct number of people are
on the ring!  The only indication A might have of things being untoward would
be unusual time delays.  As an added bonus for the colluders, they know what 
network location A is connecting from.

This attack, which to my knowledge I am the first to invent for DC-nets, will
be the motivation for the rest of the discussion on connection methods.  
I have thought of no cryptographic means of solving this problem.  In
the absence of a server of some kind to manage the connections, the best way
to handle this attack is to always join to the same people, and make them
people you trust.  Colluders can still partition the ring, but they can only
narrow messages down to having come from one ring or this other, so if you
always join with two trusted friends in tow, they can tell one of you was
sending, but not which one.

In the case where there is a server to manage the connections, the server will
presumably have complete knowledge about the current state of the DC-net.
Note that the server could be the user who initiated the session, or could be
a permanent feature.  In this case, the server must be trusted.  That's all
there is to it.  If the server is corrupt, it can arrange to have people
placed with known colluders at its leisure.  It can in fact cycle through
members, placing a different member between colluders during each session
until the member who is saying certain compromising things is determined.  This
is unfortunate, as having a server allows there to be a master list of users
of the DC-net, and the server can only allow those people on the ring.  On the
other hand, this can also be solved by connecting to the same person (or
persons) every time you join the DC-net, as described above.


Design Issues
=============

Server Usage
------------

-Discuss Pros & Cons

Coin Tossing Versus Shared Keys
-------------------------------

In the introductions I mentioned that Chaum generalises DC-nets to an
arbitrary number of users by having them share coin keys rather than flipping
coins as in the original statement of the problem.  I dislike this solution
because it requires a very large amount of preparation beforehand, makes
non-static DC-net sessions hard, and makes it difficult to arrange things so
that people on the DC-net do not know who is on with them.  Besides all that,
it's not necessary to do things this way.

    Theorem
    -------

    In the model described above, in the Untraceability section, if no-one 
    is sending, the XOR total of all participants' IVs will be 0.

    Proof
    -----
    Proof is by induction on n, where n is the number of coins in a ring with
    m participants that have the value 1 (whether 1 is defined to map to
    heads or tails is irrelevant, as long as we're consistent).  When n=0, all
    coins show 0.  Note that coins are changed from 0 to 1 as n increases,
    not inserted.

    In the base case, n=0, so everyones IVs will equal 0.
    Assuming that result holds for n, we will now show that it holds for n+1.
    At n+1 a new coin of value 1 is added.  There are three cases:
    Case 1: The new coin has coins with value 0 on either side.  In this case,
    the person holding the new one coin has his IV change from 0 to 1, as does
    the person on his right.  The XOR total of these two changes is 0.
    Case 2: The new coin has a coin with value 1 on one side.  The person
    holding the coin changes his IV from 0 to 1, and the person beside him
    holding a 1 changes his IV from 1 to 0, for no net change.
    Case 3: The new coin has coins with value 1 on both sides.  The person
    holding the coin changes his IV from 1 to 0, as does the person on his
    right, for no net change.
    Therefore, the property holds for n+1.

    Therefore, by the principle of mathematical induction, the theorem is
    true for all n and m, as m was never used in the proof.

So, clearly coin tossing works fine for an arbitrary number of users.  A
potential problem is the necessity for truly random coin tossing but, in
fact, this is not necessary.  The reason is that, in the absence of spoofing,
a member can have colluders on both sides, who can trivially share information
about the coin he tossed and still not be able to tell if he is sending a
message, as they cannot decrypt all of the messages he sends out.  So
predicting the value of the coin he tossed is of no use to them.  In fact,
with complete information about all coins tossed, as in a DC-net of 4 members
with two of them colluding, the colluders _still_ can't tell which of the two
honest members sent a message, because they can't calculate the honest
members' IVs.  For this reason, a possible extension is for everyone to assume
that 0s have been tossed and send out encrypted bit messages appropriately.

Large Rounds
------------

While the above model works, there is a certain... inefficiency involved in
sending more than n squared messages (n the number of users on the DC-net) per
bit of output.  Never mind the cryptographic overhead.  A good way to deal
with this is for participants to flip and compare more than one bit each
round.  For example, a randomly generated byte can be produced by each
participant each round, which is then shown to their right-hand neighbour, who
does similarly and compares each bit as per normal.  In fact, since the
comparison is exactly an XOR, and XOR of the two bytes will suffice.  The
result is the initial IV for the member, who then XOR's it with the byte he
wishes to transmit, if any.  Since each bit is being treated as in the proof
above, the result is the same.  This basic method can, naturally, be extended
to an arbitrary number of bytes.

Conclusion: The Perfect DC-Net Model
====================================

In close, I will be describing my model for the 'perfect' implementation of a 
DC-net that drove the rest of the paper.  The key word here is 'implementation',
I will not be suggesting anything that is impossible, although it may be 
infeasible or difficult to arrange in practice.

Firstly, for reasons described above, such a model would have a ring
communications structure, mostly (see below).  This is to preserve external
anonymity.  The most important aspect of the model is that there needs to be a
central variable for holding the XOR total of the round that can be modified
by any user without any other use being able to see them do it.  This model is
what my algorithm with encrypting messages to every other participant was
intending to do.  A better way might be a good blind computation algorithm for
the XOR function over an arbitrary number of users, but I don't know of any
such algorithm (although I'm sure to be used).

The final portion of the model, and probably the most difficult to implement
in practice while still preserving anonymity between members of the DC-net,
is what I call an inviolate complete knowledge server, in other words some
means for the users of the DC-net to get complete, unspoofed information about
the current state of the network.  The best way to do this is to have a
broadcast network of some type used by the members of the DC-net onto which
they can periodically state their existence and public key.  This is easily
handled by having on the members on, say, the same ethernet, but how to
handler it in the general case while still preserving members' anonymity and a
ring communication structure is something that thus far escapes me.
