-----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