This is the second posting I have posted about emucs (encrypted multi-user chat system) on the list. I am hoping to get a little more involvement from stable coders to help develop this product. Most of you are knowledgable of irc and how flawed it is, the ease of logging, and the fascism of the operators therof. I want to alleviate this problem by producing a multi-user chat system involving 1 server and up to 50 clients which is counterproductive to promoting logging and such. My design is easy: All messages sent from a user will be encrypted(pgp) by the pc(msdos machine initially) before its sent over the phone line, to the server. The server will then determine if the message is public or private (very easy to do) and if private, will decrypt it using the servers public key. It will then pass the message to all users on the server in unencrypted format. If it is private the server will pass it directly to the recieving party, who's client will decrypt it (if its private the sender must have the receiver's public key) and display it to their view screen. I was considering encrypting and handling everything in a private manner, but have decided that this would be more than too much load on the recieving pc's so have decided to keep only private messages completely secure. When the person wanting to engage in the chat decides to run the client, he would supply his pass phrase as a command line parameter, and it would be stored in memory until the chat is terminated. Any time a private message comes to him the client would automatically decrypt it with his key and pass phrase. There will be key handling and exchanging utilities built into the server. The client will allow for vt100 emulation and will work as a terminal program until the chat is entered, at which time, the client wwill be prompted by the server to start its new function(ie. encryption). If anyone has any ideas or wishes to help me with this, please respond to treason@gnu.ai.mit.edu and explain what you can do, or what ideas you have. On the last posting of this sort, there was very little response, which frightens me because of the serious need for this kind of software. Treason@gnu.ai.mit.edu
participants (1)
-
treason@gnu.ai.mit.edu