From: janke@unixg.ubc.ca
Date: Tue, 9 Jul 1996 08:44:30 +0800
To: cypherpunks@toad.com
Subject: Pseudo-DC-net Project
Message-ID: <199607081845.LAA00269@clouds.heaven.org>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

I am working on a project to implement a variation of a DC-net to be run
over the Internet. I am posting this summary to find out if it overlaps
with projects others are working on; to see what members of the lists think
of the general ideas for the network I have in mind; and to see if anyone
is interested in helping me out.

The variation of a DC-net I have in mind will vary in three important ways 
from a true DC-net: 

Difference (1) (Pseudo-random numbers) 

It will use pseudo-random numbers in place of true random numbers. 

Difference (2) (Star shaped network)

The graph of the network will be star shaped instead of completely
connected. 

Difference (3) (MACs)

Messages broadcast on the pseudo-DC-net will have a MAC appended in a key 
shared by the channel participants.

Difference (4) (Encryption)

Messages sent to the channel will be encrypted in a key shared by the
participants.

Because of these difference from a true DC-net I will refer to the network
I have in mind as a "pseudo-DC-net". Difference (1) is desirable since
current techniques for generating true random numbers on PC's are slow, and
distribution of the resulting true random numbers is enormously consumptive
in terms of bandwidth. Difference (2) is made possible by the use of
pseudo-random number generators, and is desirable since it reduces the
total number of messages that need to transferred.  Difference (3) is
desirable to identify messages broadcast by unauthorized parties to the
network, and, as a side benefit, to help clients filter out collisions---
when two parties try to broadcast at the same time. Difference (4) is 
desirable so that eavesdroppers cannot determine what messages are 
being broadcast to the network.   

Difference (1) implies a downgrading of the level of anonymity from
unconditional to cryptographic, and difference (2) opens the possibility for
protocol attacks.  

I would like to break this project up into three parts: a formal protocol
specification, a client implementation or implementations, and a server
implementation or implementations. I would like the formal protocol
specification to be publicly available to allow anyone to write their own
clients and servers, and to communicate their criticisms of the protocol.
The protocol will not dictate what pseudo-random number generator is to be
used, although there will be a note of a rule to ensure that pairs of users
are using the same generator for the "coin flips" they share. Similarly,
the protocol should be flexible enough to allow the use of any reasonable
length MAC.  

A general outline of the protocols I have in mind are as follows: 

Protocol (1) (Channel registration protocol) 

Channels will be registered with the server. A channel will be specified by
a time frame in which a pseudo-DC-net is to be run; the IP address and port
to which clients are to connect to join the channel; the length of each
message block to be transmitted to the channel; and a channel ID. 

Protocol (2) (Pseudo-DC-net real-time protocol)

The protocol for running the channel will consist of a series of "rounds". 
Each round will consist of the following steps:

 Step (1) The transmission of a round synchronization number from the server
 to the clients, along with a string of bits specifying the set of users 
 connected. Old clients should make sure that the synchronization number 
 is consistent with the synchronization number of the previous round. 

 Step (2) Receipt by the server from each client of a block of input
 for that round. (If the user does not wish to broadcast, this will be the 
 XOR sum of the next blocks in the the pseudo-random number streams shared 
 by the user with the other users (call this sum S). If the user wishes 
 to broadcast, it will be the encryption of the following: the XOR of S 
 with a message consisting of the concatenation of the channel id, round 
 number, message length, message, message padding, and MAC of these five 
 components.) 

 Step (3) Transmission from the server to each client of the XOR sum of 
 the blocks received.

Protocol (3) (Optional Payment Protocol)

I would like to add the option for the server to charge e-cash for the
administration of the channel.

I have also thought about an extension in which messages to the server
would be signed so that the server could prevent an unauthorized user
from hijacking a connection and disrupting a channel. 

If you would like to help me out with this project, if it overlaps with
something you are already doing or have done, or you just think my ideas
are no good (or good! :) ), please let me know. I am especially interested
in attacks in which the server lies about the round number or set of
connected users. 

If this project is works out well, I would like to later work on protocols 
for voting using a pseudo-DC-net. 

Leonard Janke
(pgp key id 0xF4118611)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQEVAwUBMeFVY0MBIFf0EYYRAQErKwf+OcQjqoODovlRJZtrXuqTGeiRHTobFDa+
DFWEmGl+yditRBt9nAlCgXGiRkCXhqroX30M+SEVw02trc1eBMCeJUSvxB9d0pN6
9x3vDN/XB4Kj6kAuAypulBCa0f74Uim4nJvZDw7boEW/hXY3Yuf7d3mgOsNY/LRT
p62FL24wnz8aeBAVYnE6SJp59u9Yssrvb2lez1IuKIdN8Rqx590Fwn1VBZ2oqGk8
6UucJkvTht7XmKPuckND+Lhq7jv1vVZKZD3NRe4Uy21JstwKwwpuVXVX98YlNc+Y
a15wW4WstZIzsKuPrYVsLsb+wXsETp1sgp5jDkKQABfit7XS8FVC9g==
=KZsI
-----END PGP SIGNATURE-----