1993-07-14 - Re: Secure comm program, Sockets + LINK

Header Data

From: jpp@markv.com
To: newsham@wiliki.eng.hawaii.edu
Message Hash: 7404b4c89440d1a6d854632b90de7a1cac53748dfd10aa7b0a376ffb5ea7268e
Message ID: <9307132043.aa10612@hermix.markv.com>
Reply To: <9307111507.aa07868@hermix.markv.com>
UTC Datetime: 1993-07-14 03:43:52 UTC
Raw Date: Tue, 13 Jul 93 20:43:52 PDT

Raw message

From: jpp@markv.com
Date: Tue, 13 Jul 93 20:43:52 PDT
To: newsham@wiliki.eng.hawaii.edu
Subject: Re: Secure comm program, Sockets + LINK
In-Reply-To: <9307111507.aa07868@hermix.markv.com>
Message-ID: <9307132043.aa10612@hermix.markv.com>
MIME-Version: 1.0
Content-Type: text/plain


  My concerns about two way authentication become clear when you
concider the LINK+sockets program a substitute for rsh, rexec, login
or similar programs.  You don't want to be spoofed, and you don't want
others using your account.

  When you are using LINK in the way it was originaly designed, you
more or less *have* authentication in both directions.  From you to it
since discovering a private key given a public key is concidered
hard.  From it to you since *presumably* the only user able to read
the key file on the shared machine is you.

  The bootstrap problem (how you get the public key to the machine
with only unsecure chanels at your disposal) is interesting though.  I
wonder if it can be solved without DH key exchange?

j'





Thread