From: mark@coombs.anu.edu.au (Mark)
Date: Sun, 29 Nov 92 14:20:56 PST
To: cypherpunks@toad.com
Subject: Secure PK swapping.. what are the methods?
Message-ID: <9211292219.AA28149@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


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