DC-Net proposal, comments requested

[Timothy Newsham <newsham@wiliki.eng.hawaii.edu>]

proposal:
   Dining Cryptographer's (DC) net built on top of TCP/IP.

purpose:
   To explore the problems in implementing a useable DC net.  

description:
   The Net would allow connections to a PAD machine,  the PAD machine
   would be used to establish a "connection" across the DC-Net to
   another PAD machine which would then allow an outgoing TCP connection.
   The connection through the DC-NET would be transparent and untraceable.
   Machines that are part of the DC-NET could talk to each other 
   untraceably through the network.

discussion:
   This net would allow a user to set up an 'untraceable' connection
from one point on the internet to another.  The NET would be made
up of one or more actual DC-Nets.  

A DC-NET
   This net is broadcast in nature (data written by one machine can be
seen by all other machines on the network) but with the characteristic 
that it is impossible to tell which machine on a particular DC-Net 
wrote out the data (except if all other machines are controlled by the 
same person?).  The DC-NET itself is bit oriented.  Such a DC-network would
be the underlying layer for the packet network.  The actual DC-Network
would be made up of processes on various (or even the same,  for testing 
purposes) machines all connected together with TCP.  
 

The Packet Net
   The Packet Network would be built with the DC-Net as a base.  In order
to send useful information across the network a single node would form
data into packets.  These packets would be outputted to the network a
bit at a time.  Since the DC-Net is bit oriented it is possible for
another node to send some bits after one node has started to write out
its packets.  As a node writes out a packet it should listen to the
network for "collisions" and if a collision is detected it would 
"give up" on the current transmission and wait for some time to start
again.  Packets from one machine to another must have some sort of
addressing.  The packet could be encrypted entirely in the public
key of the destination if there is only a single DC net.  If there
are multiple DC-Nets with packet forwarding between them then there
must be some sort of plaintext address information in the packets.
The return address should *never* be in plaintext.  Probably the
data and return address of a packet would be encrypted in the public
key of the destination or in a private key shared with the destination.

Sessions
  Virtual connections can be built on top of the packet network in
the same way as they are on top of other packet networks.  Some protocol
like TCP (or even the TCP protocol) could be used.


Why should this be built on the internet?
    Writting and debugging a network of this sort on top of the internet
should be easier than writing it and implementing it from scratch.  Some
people have proposed neighborhood networks that would be used to
implement untraceable and unstoppable connections.  This is an excellent
way to develop and debug such a network.

What needs to be resolved
   Alot!  This is just something I threw together.  There are alot of
   questions.  In fact most of it is still a question.  The protocol
   of the underlying DC-Net needs to be written.  A packet layer must
   be written or adapted from current protocols.  The issues of addressing
   need to be addressed.  There are also sure to be alot of politically
   oriented questions as well.


                                  Tim N.