To: Tom Jennings
Doesn't this imply that the unencrypted message would have to travel from the originator to the server? Or do you mean to send to X I'd request X's public key from the server, then encrypt, etc? <<
I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to
The bacteriophage virus replicates itself by injecting its own information into an existing system. The more copies of the phage,
Not at all. In its simplest form: We'd have a single secure-IRC-server. It would have its own public key, which ever secure-IRC-client would know. When I want to send a secure broadcast msg, I type it, my client encrypts it with the public key of the secure-IRC-server, and transmits it. The server picks it up, decrypts it in memory, then re-encrypts that original msg with the public key of each paritxxx participant in the particular room I'm in. So, if there are ten participants in the room, and I want all of them to know something, but not anyone else who might be tapping ixxx wires or catching packets somewhere in the ether, then I'd send a single broadcast msg to the server; the server would end up sending ten differently encrypted msgs -- one to each participant, encrypted with each of the participants' public keys (which the secure-irc-server would have to maintain; it would function as a key-server.) To send a private msg across the secure-IRC, I'd indicate that it was a "/msg", the recipeixxx recipient, and again, encrypt it with the public key of the server. The server would learn who the recipient was, and rebroadcast my message to that person, in that person's public key. public keys I receive over an unsecured email channel to begin with. No other method is practical. << Huh? I don't understand what you're pointing out. If I send you my public key -- even if I cc: dockmaster -- what does it matter that the NSA knows my public key (unoless they want to send me msgs, too)? The key itself is inherantly secure. Let your users decide on their public keys and register those keys with your key server. Not the other way around. Course, there's always the Kandinsky-Ogorov method of key exchange. To: St. Jude the worse for the bacteria etc etc. SO: in private, the planning, the designing, the coding... for public distribution as widely as possible. If the technology is intrinsically transformative, and if the process of distribution is engaging, even exciting, the revolution is next tuesday. << Providing the numbe r of cells you have access to and can anticipate influencyxxx incxxx influencing is large enough, and it isn't. Anyway, look, let's put our words into action. What makes code (programming, I mean) didxxx different from spoken language? The fact that you can communicate with a machine, and it will _act_ on what you say, no matter what. Theres beauty and there's magic in that. (And some of us have the same effect on people that we have on machines. ;-)) Instead of talking about all this, let's start doing it. What did I read the other day? "Hackers go where Angels fear to tread"? Let's have more ideas. This hopping remailer is exciting. So is passive encryption of electronic communications. When are we going totart xxx to start effecting de facto standards here? Once we start encrypting everything, then what? What do we do with this new tool? Communication of any kind (especially encrypted communication) presupposs that there are messages to be exchanged -- _ideas_! More ideas and less chatter. How can we have a revolution if we don't even know what we're trying to bring about? Maybe I was out of the loop. Maybe I was attending an Army/Navy game that day, but I don't know what we're trying to do here, exactly. What is this "revolution"? -- $33kr1t $kwurl. K.R.A.P. (K-Rad. A.SCII P.Ossee)
If I send you my public key -- even if I cc: dockmaster -- what does it matter that the NSA knows my public key (unoless they want to send me msgs, too)? The key itself is inherantly secure. Let your users decide on their public keys and register those keys with your key server. Not the other way around.
Let's make this short. The basic problem with public key systems is to make sure that what _I_ think is my public key is the same thing as what _you_ think is my public key. If these are not the same, something is wrong. At worst, an interposer is getting all your mail, decrypting with one public key and encrypting with a different one. Servers, generally, are not desirable because they are too prone to communications filters of the above sort. For a more detailed reference, read the excellent introduction to the whole topic of public key distribution in the PGP 2.0 documentation.
Course, there's always the Kandinsky-Ogorov method of key exchange.
Please elaborate. Eric
participants (2)
-
Eric Hughes
-
Secret_Squirrelï¼ Treehouse.ORG