-----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
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
participants (2)
-
Hal -
yanek＠novavax.nova.edu