Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!husc6!hao!gatech!udel!galvin
From: galvin@udel.UUCP
Newsgroups: rec.ham-radio.packet,sci.crypt
Subject: Re: passwd security
Message-ID: <280@louie.udel.EDU>
Date: Wed, 10-Jun-87 16:58:28 EDT
Article-I.D.: louie.280
Posted: Wed Jun 10 16:58:28 1987
Date-Received: Sat, 13-Jun-87 08:44:12 EDT
References: <1012@chinet.UUCP> <1615@Umunhum.STANFORD.EDU> <581@faline.bellcore.com> <3569@osu-eddie.UUCP> <1370@aw.sei.cmu.edu>
Reply-To: galvin@udel.EDU (James M Galvin)
Distribution: world
Organization: University of Delaware
Lines: 25
Xref: utgpu rec.ham-radio.packet:367 sci.crypt:414

In article <1370@aw.sei.cmu.edu> pdb@sei.cmu.edu.UUCP (Pat Barron) writes:
>In article <3569@osu-eddie.UUCP> verber@osu-eddie.UUCP (Mark A. Verber) writes:
>>It would seem to me that a public key crypto-system would be perfect
>>for this kind of application.  You could query the machine for its
>>public key, encrypt your password using that key and then transmit
>>your encrypted password.
>Two problems with this:
>2)  If the machine only has it's private key and a single public key, what's
>    to stop the Bad Guy from listening to what my password looks like when
>    transmitted back to the system, and just using that?

This is easily corrected with a "nonce identifier".  You are missing the
more fundamental problem of an active eavesdropper who simple substitutes
his/her favorite public key.

Jim

ARPA:	galvin@udel.edu
BITNET:	galvin@udel.edu
CSNET:	galvin%udel.edu@csnet-relay
UUCP:	...!ihnp4!seismo	-\
	...!allegra!seismo	-->!galvin@udel.edu
	...!harvard		-/
-- 
James M Galvin