From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Mon, 14 Dec 92 10:31:18 PST
To: 74076.1041@CompuServe.COM (Hal)
Subject: Re: dcnets...
In-Reply-To: <921214043710_74076.1041_DHJ56-1@CompuServe.COM>
Message-ID: <9212141634.AA01103@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain



> I have a few general comments about the system.  First, I like the
> idea of splitting the key information management from the communication
> management.  That way people can choose their level of security, all
> the way up to one-time pads if they want.

I tried to make the system as modular as possible, so any part could be
improved or changed with minimal effects on the rest of the system.
 
> Dc-nets really eat up the bandwidth.  Yanek estimates using 125
> kb per message sent!  And having to send one-time key information

This is due to two factors.  First, right now there is no way to specify
the size of a message.  Every message is assumed to be 5K so bandwidth is
wasted for any message smaller than that.  As I mentioned in "FUTURE 
ENHANCEMENTS" section, I will make message size be part of the reservation
block structure, so small messages will be transferred more efficiently.

Second, I am using point-to-point transmission.  When I want to broadcast
a message, I need to send it individually to each participant.  Use of
a broadcast media such as ethernet multicast or satellite or radio will
dramatically decrease communications load.  

> as you're doing that for this initial experiment, why not save yourself
> a lot of trouble.  Just exchange an IDEA (or DES) seed, then cycle it
> repeatedly through IDEA (or DES), taking the low order bit or few bits

This is a good idea.  I will do it this way unless anyone else can
see any problems with this.
 
> Another point is the amount of messaging people will do.  I think the
> system should be enhanced to allow people to send and receive messages
> to/from non-DC-net participants.  

If a broadcast system could be used, anyone that can receive the broadcast
will be able to reconstruct the messages, even if they are not participating
in the net.  If this project works successfully, I will try it using usenet
as the medium.  So anyone can scan alt.dcnets and get the message.

> and if so, something which just recognized a special message header and
> took it as "Request-Remailing-To:" should be easy to add.  Likewise,

Yes it is easy to add.  Eventually you will be able to request forwarding
to a mail address (or a mix-net remailer), an anonymous post to a usenet
newsgroup, or retransmission to another dc-net.

The only small problem is that everyone gets the message, and I don't want
the message sent out 15 times.  So there must be some way to decide who
does the remailing.  I could just have one person act as the forwarder,
but it would be more interesting (and harder to break) if the net somehow
dynamically assigned a random forwarder for each message.

> incoming messages to the Dc-net (which would be sent to some random
> person in the group) should be easily forwardable to the DC-net system

Yes.  Mix-net remailers could also be participants in a dc-net, so a
message could be sent without anyone even knowing which remailer it
came from, for people that want untraceability but don't want to or can't
participate in a net themselves.

> from outside.  I don't have a clear picture of the user interface from
> Yanek's description so I'm not sure how easy/hard these would be to do.

Very easy.  To send out a message on a dc-net you just drop it into it's
outgoing directory, the next round it gets transmitted.  

Any messages received are piped to "incoming" program in that dcnet's 
directory.  That program initially will just put the message in your
mailbox, but you can make it do anything, such as drop it in another
dc-net's incoming directory, or remail it, or post it somewhere.

 
> One other thing I'd mention: the mechanism of reserving a slot and then
> sending a message is discussed at some length in the Ph.D. thesis of
> Jurgen Bos.  Tim May kindly sent me an excerpt from the thesis which
> included this discussion; I think it may have been part of the original
> cypherpunk meeting handout.

Can someone forward it to me?

> Yanek asks about sending encrypted traffic over amateur bands.  This
> is definately illegal in the U.S.  The reason is that the amateur bands
> can't be used for commercial purposes, so the FCC demands to be able
> to know everything that is being sent to make sure this rule is being

But the messages become public.  Anyone can see what the message is, they
just can't see who it came from.  If all messages are transmitted as
plaintext, it is fairly easy to see that no commercial traffic is occurring.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819