Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!rutgers!ucla-cs!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Destroying arguments
Message-ID: <19608@sun.uucp>
Date: Sun, 24-May-87 01:44:06 EDT
Article-I.D.: sun.19608
Posted: Sun May 24 01:44:06 1987
Date-Received: Sun, 24-May-87 08:44:35 EDT
References: <292@osupyr.UUCP> <239@polyof.UUCP> <485@bene.UUCP> <6723@mimsy.UUCP> <701@bsu-cs.UUCP>
Sender: news@sun.uucp
Distribution: comp.unix.questions
Lines: 50

> The problem I ran into was that there seemed to be no way (at that
> time, on a 4.2BSD system; I haven't tried recently under 4.3BSD) to let
> crypt read the password from the script.

All the versions of "crypt" I know of use "getpass" to read the
encryption key.  This means that the only ways to get any of them to
read the key from something other than the user's terminal would be:

	1) detach "crypt" from the terminal, in which case *some*
	   versions would read from the standard input.  The System V
	   version doesn't; the V7, 4BSD, and S3 versions do.

	2) somehow attach the "crypt" process to a pseudo-terminal so
	   that its "/dev/tty" is that pseudo-terminal, and feed it
	   the key through the pseudo-terminal.

The S5R3 version permits you to specify the encryption key with an
environment variable, which is more secure than specifying it as an
argument iff you have no version of "ps" that can look at environment
variables.  The one distributed with S5 doesn't, but that doesn't
mean you can't make one that does, and the one distributed with 4BSD
definitely does.

If you pass the key as an argument, the S5R3 version stuffs the key
into an environment variable and "exec"s itself with no arguments, in
an attempt to hide the key away.  (Null and void with a "ps" that
dumps the environment, of course.)  (BTW, the S5R3 manual lies; the
environment variable is named "CrYpTkEy", not "CRYPTKEY".)

Then again, I'd be a tad chary of typing such an encryption key to a
shell, unless I could make sure nobody was looking over my shoulder.
If at a printing terminal, you'd also have to safely discard the
printout, and if at a CRT terminal you'd have to make sure nobody
could somehow coax your terminal into transmitting the screen's
contents and read what it transmitted.

For that matter, you'd also have to make sure nobody had a
"crypt"-cracker handy.  See "File Security and the UNIX System Crypt
Command", J. A. Reeds and P. J. Weinberger, AT&T Bell Laboratories
Technical Journal, October 1984, Vol. 63, No. 8, Part 2.

> Reading from the terminal was not practical because I was
> using a script that encrypted a large number of files using the same
> password, and typing in the password multiple times is a pain.

The number of files would have to be *very* large for "a pain" to
imply "impractical".
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com