Since Im not sure this got through to the list last time I'll resend. Certainly I havent had any pointers to where to find the information I need.... ------------------------------------------------------------------------ Below is a letter Ive sent to a person designing a communications system similar to IRC but designed with the ability to be anonymous and as secure as possible. Further details will be announced soon when it's stable. --------------------Begin letter----------Begin letter------------------- Before you get too involved with the client in the comm system I was thinking of a way of having secure privmsgs, two forms depending on how open one chose to be: Messages are exchanged via UDP to hide from the netstat junkies... When someone does a msg the first time and the client doesnt know about that user it queries the server to either get a hostname/port pair for that user and/or a public key. The data is then stored in an internal attribute bank. Format of a private message: ._________________________________________________________. | Nickname Plaintext | dest IP | dest udp port | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | `---------------------------------------------------------' [Return host/port/public key are encrypted into the PGP? message] The above message is then sent to the delivery module of the client. The above host and port are either the recipeints or the server's depending on what type of message is being sent. Thus the same message can go to the server or the recipient direct per se: 1) Using the hostname/port + public key for that user the sender's client encrypts the message and udp transmits a message to that port on the other users host. That remote client has set up a socket to listen on that udp port for messages. The remote client unpacks the message with it's private key and extracts the message, a reply host and port and the senders public key. He can then reply to the sender and they both can talk without loading down the server. Plus, unless someone is logging the ethernet, no one can ascetain wether they are talking. There is only the initial request of the users public key from the server which each client sends in automatically when it connects. You might also have an option in the client to auto download a block/all of the users nicks and their keys so no-one can detect the initial query of a user. 2) The other, differently secure :), form is because the server has been told to hide the users username + hostname from the /who information. All there exists for that person is a nickname and a public key. The senders client gets individually/block downloads the key he wants and proceeds to udp a message to the server which has the udp port and hostname of the recipient as normal from the client connect. It acts as IRC does now, as a middle man for messages. Less secure because the server admin can ascetain that there is a message being sent between the two people and also he can slip in his *OWN* keys to basically grab and decipher messages between the two parties. i.e he sends his own key to the sender and decrypts the incoming message and then sends the message out to the recipient using their encryption key. neither user could tell there was a switch in between. (There are schemes to get past this however). Both ways have their flaws because you are relying on the non-hackedness of the server to give you the right keys and hostnames and ports. A bad admin could easily, knowing enough about coding, disrupt the entire process if we didnt from the start ensure the right protocols were used. It has to be done right the first time or not at all. I'll echo this letter to a cryptography mailing list to ask for details of schemes that will allow each user to know they have a valid, secure public key of the other. One possible solution would be to do a mass query of all the online servers at once and if they didnt report the same keys sound a Real Big Alarm (tm). Maybe an automatom could sit there randomly checking keys :) (Can hear the cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your doing a query for a user... that may or may not bother the sender/recipient. Doing a block transfer from all the servers at once isnt net.nice) Comments? ------------------End of Letter----------------End of Letter---------------- Now what Im curious about is any other methods of secure key exchange where the exchange mid point may be lying about the keys, the hosts and the ports. Assume each person knows the others 'style' etc. How does one get the real keys to each other with an unreliable "medium"? (It might slip in it's PK). Assume that they havent previously organised a key exchange. Replies to me or the list.. (but not both please.. my mbox is busy enuff :) Mark mark@coombs.anu.edu.au