From: Hal <74076.1041@CompuServe.COM>
Date: Sun, 13 Dec 92 20:43:46 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: dcnets...
Message-ID: <921214043710_74076.1041_DHJ56-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


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

I thought I would reply here to Yanek's message about dc-nets
since it is a topic that should be of interest to the list.

I think it's great that someone is going to start experimenting
with these systems.  The sooner we start playing with this technology,
the better.

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.

However, I think there should be another system chosen for exchanging
key information initially than using PGP to send large one-time pads.
Dc-nets really eat up the bandwidth.  Yanek estimates using 125
kb per message sent!  And having to send one-time key information
around doubles the bandwidth.

Also, Eric Hughes pointed out to me in private mail once that a system
like this for key information exchange is only computationally secure.
You are basically relying on RSA and IDEA not to be broken.  As long
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
as new random ones.  If two people have the same seed, they will generate
the same random bits.  And if IDEA is secure, your bits should be
secure.  If they aren't, PGP isn't secure.  PGP has code to do this.
I think it's in the IDEA.C module.  Also see strong_pseudorandom in
CRYPTO.C.

So, I'd suggest that the key exchange part just exchange a short key
and then a program generates the new random bits as needed for the
messaging.  Keep the key stuff separate, though, so people really can
do one-time pads if they want to eventually.

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.  Otherwise you have 10 or 20 people
who hardly know each other.  What will they have to say to each other?
You won't get a good picture of message loads.

I don't foresee everybody in the world being hooked into interlocking
DC-nets any time soon (if ever).  But I do think there will be DC-nets
for some interested people.  They will achieve anonymity amongst
the group for messages sent beyond the group.  In other words, it will
be known that a message comes from a certain DC-net group, but it will
be impossible to tell which person in the group sent it.  Likewise,
messages could be sent to a DC-net group without it being known to whom
they are sent.

I think this capability should be added very soon to the DC-net software.
It sounds like the software may include automatic message-sending capability
and if so, something which just recognized a special message header and
took it as "Request-Remailing-To:" should be easy to add.  Likewise,
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
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.

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.  Bos compares several message reservation
schemes and discusses which are the best.  It might be good for Yanek
to take a look at this document.

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
complied with.  However, there are some commercial packet-radio systems
starting up and presumably they won't be subject to this limitation.

It may not be practical to incorporate all of these suggestions at first,
but I do think that using PGP to exchange a RNG seed would be better
than using it to exchange one-time pads.  I'm looking forward to seeing
the system in operation.

Hal
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyvk8qgTA69YIUw3AQHyuQP/fXIkyCWR5GCiZsiRvMThcJK5xMbOQEIF
ow9S9xQ+7kiiJuF4dVp7NRyNTBjO2tBiQDh4JRKb4Pl7LGq+KKYQSTDzGgEo7hOw
dkgujwxbCAXjn2XEMewRHprZMPV4XB+iGIZzQ4piqubzWg8hOV8sMhduGaHKnhGc
MlhbbmhToOc=
=+cPN
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM