From: Timothy Newsham <newsham@wiliki.eng.hawaii.edu> I assume you're talking about the link program I wrote. Yes, I was talking about your program Link. If so: I never really considered the RSA exchange as authentication although it can be thought of that way I guess. Right. The only person who can participate (on one side) of the exchange is the one with the private key which matches the other side's public key. This does provide a weak level of authentication. (An opponent can record 'authentication' sequences, and replay them later. For this to be usefull, the opponent will have to have discovered the session key which is/was being selected by the sequence.) If (when) I implement DH key exchange I guess I should add some sort of authentication. I was concidering a different authentication, and secret session key selection protocol (the one that got away :>). It would only use RSA (or any other suitable public key system) to sign and check signatures, as well as encrypt and decrypt data. No new number theory. However, it would require both parties to know the public key of the other. This sort of protocol would be ideal for logins. Both parties authenticate the other, and no-one else can read the channel. No passwords are ever transmitted over the channel either. You and I use a "sum" (xor perhaps?) of our two key halves as the session key. At any time one of us can simultaneously request changeing the sesion key, and chalange the identity of the other. To do this, I send you a new key half encrypted under your public key. You respond with a signature of the resulting session key encrypted under my public key. We then start using the new sesion key. At this point both directions are authenticated, and observers can't determin the new sesion key. Things are complicated a little by the fact that all comunication is done under a secret session key. Things also become a bit more complex because there may be data you sent before recieving my key change request. j'