A last word on --passphrase-fd

Chuck Robey chuckr@picnic.mat.net
Fri, 21 Jan 2000 12:08:36 -0500 (EST)

On Fri, 21 Jan 2000, Werner Koch wrote:

> Hi,
> there was quite a long thread about how to feed the passphrase to gpg
> in a shell script.
> What most folks want to do is to take the passphrase from a file and
> feed it to gpg. If you think you gain more security from this than
> simply removing the secret key protection entirely from the secret
> keyring, you are wrong. If someone has access to the secret keyring
> he will also have access to the file or script which contains the
> passphrase. It does not increase security by requiring an attacker to
> look at 2 files on your system. Make your system immune against all
> ways to gain root access and to your account and you are done.
> Because this is not really possible, do at least the best to detect
> intrusion and revoke the keys as soon as you have a reason to believe
> someone got access to the secret keyring or the passphrase file (if
> you still believe this last one is needed).
> Doing tricky stuff to feed the passphrase to gpg is futile and only
> makes the code more complex and error prone.
> There are two scenarios I can see for that --passphrase-fd makes sense:
> * You have an interactive program which asks for the passphrase and
> then feeds it down a pipe to gpg. And here we don't wont files or
> any other buffering mechanisms. (see Mutt)
> * You have a daemon or a special kernel service which stores that
> passphrase for you in RAM after asking the operator on startup for
> it.
How does either of your two options deal with a process started on a regular basis by cron? No daemon to store the passphrase in ram with, and impossible to make interactive input.
> Remember, the weakest link determines the overall security: So
> 1024/128 bit keys are much more than needed on todays networked
> operating systems. There are so many published (and unpublished)
> exploits for all OSes - and this not only for MS-Windows but also
> for all Unices; maybe OpenBSD does the best job to avoid them, but
> the probability that there are ways to become root on OpenBSD is still
> *much* higher than to calculate the DL for a 1024 bit key.
> To increase the security you need OSes designed with security in mind
> (e.g. EROS, VSTa projects).
> Well, these are just my 2 cents,
> Werner
---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ----------------------------------------------------------------------------