Re: Secure comm program, Sockets + LINK

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'

> 
>    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.)

This is a matter of perspective.  You are thinking of the matching
keys as being 'public' and 'private'.  You can also think of them
both being half of a key, both being unknown to any third parties.
In such a case the mere possession of a matching key is a type of
authentication.   This because you only gave out one half to a
specific person in a private way, and you kept the other half for
yourself.

This is half way true in the sense of my link program but not
totally true, because both halves were generated on one machine
and one half transmitted (probably over an insecure channel) to
the remote.  This second key is secure in that it only got transfered
once and then exists in only one place that may be secure.  It is
insecure in that it might have been observed in that window of
vulnerability.  

Why is it that you want both sides to authenticate, btw?
In the case of a human<->human connection?
I can definitely add authentication (two way).