Re:Pseudo-DC-net Project

[mccoy@communities.com (Jim McCoy)]

janke@unixg.ubc.ca writes:
> 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.

Short version:

Your proposal will not work and is trivial for a TLA to break.

Long version:

There are two problems with this proposal, the star topology collapses the DC
network into a two-party version of the DC-net protocol (in which collusion
is trivial) and the shared PRNG allows _any_ participant to compromise a
target member of the network (or evesdrop at the server and decode all
traffic.)

A simple example of such an attack would be for the TLA to register a host on
the network and get the shared secret key for the PRNG.  The TLA then taps in

either to the server's internet connection or any point in the network which
divides the client graph into two parts, the server and a single client on
one side and the remaining clients on the other.  The TLA then just XORs out
the blinding data (which it knows because it is a member of the network) and
it has all of the connections.  Additionally, having a MAC is just plain
silly, the objective is to hide who is sending and having a MAC defeats the
entire purpose of the proposal.

You have basically created a simple packet anonymizer, which is not bad in
and of itself, but it is not even close to a true DC-net (at least I am
assuming so, based upon the initial description.) You have not mentioned
whether or not all traffic exits the network at the server, if this is the
case you are better off having each client establish a secure link to the
server, running a PRNG constantly that is mirrored by the server, and XORing
all of their traffic in to this stream.  The constant PRNG stream hides when
the client is sending or receiving and the secure channel to the server
discourages passive evesdropping. This does not defeat traffic analysis at
the server, but then again neither does your proposal.

Some other tips from someonw who has spent too much time thinking about
DC-net implementations:

        Ignore collision detection, just use ALOHA or a similar protocol.
        Until you get up to serious bandwidth the computational cost is
        not worth the effort.

        Don't abandon the ring topology (this is where the DC-net gets its
        security.)  Use multiple small (4-7 host) rings with overlap between
        the rings, think of each ring as a LAN and hosts which are on
        multiple rings as bridges/routers and you should get the picture...

        Bandwidth economy will always suck, you can use hash trees to get
        around a few of the problems but for the most part you have to accept
        the costs and work around them in other areas.

        You really, really need to read the 1987 Eurocrypt proceedings.


jim