Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!ames!ptsfa!ihnp4!chinet!steinmetz!davidsen
From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr)
Newsgroups: comp.unix.wizards
Subject: Re: file protection with NFS
Message-ID: <1430@steinmetz.steinmetz.UUCP>
Date: Mon, 13-Apr-87 13:18:47 EST
Article-I.D.: steinmet.1430
Posted: Mon Apr 13 13:18:47 1987
Date-Received: Sat, 18-Apr-87 23:56:15 EST
References: <5462@shemp.CS.UCLA.EDU> <16425@sun.uucp>
Reply-To: davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr)
Organization: General Electric CRD, Schenectady, NY
Lines: 54


Assuming that there is a public key encryption program available on the
client and server, there are a number of ways to obtain (relatively)
secure connections, validated in both directions. One very simple
variation on this:

1) client sends a message "Hi I'm so-and-so" encrypted with the
server's public key. The server must have the private key to decode the
message and discover the prospective clients identity.
2) the server generates a temporary key pair, and sends the public key
to the client encrypted with the client's public key. The client must
have the client private key to discover the session key.
3) the session key is used to encrypt the rest of the communication.

Notes:
 A public key system is one in which there are two complementary keys,
and encrypting a message with one requires decryption with the other.
One key can be "public", because having the public key does not allow
the message to be read. A return message, encrypted with the private
key, will return to clear text when decrypted with the public key.

    a message sent using the public key can be read only with the
    private key. Anyone can send a message using the public key but
    only the holder of the private key can read it.

    If the holder of the private key encrypts a message, anyone with
    the public key can read it, but the sender must be in possesion of
    the private key. This validates the sender.

 The above is a very simple case of this type of connection, and will
fail of (a) the identitfy of the client is known at the time of
connection (without reading the "here I am") message, and (b) there is a
false server intercepting the messages. Methods of avoiding
this are relatively easy to devise, but require more handshaking and
may involve several session keys.

 Encryption may be nested. A message may be encrypted with the senders
private key and the recipients public key, which can be decrypted only
by having the senders public key (proving the senders identity by being
able to generate the message) and the recipients private key (proving
the recipients identity by being able to read the message).

 Sometimes only the login sequence is carried out in encrypted fashion if
the messages are not critical, since the time to encrypt and decrypt
messages is fairly long on most systems.
----------------
Feel free to clarify this posting, I was trying to present an overview
to the original poster. If you must flame, do it by mail.

-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)