A last word on --passphrase-fd

[Chuck Robey]

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.
----------------------------------------------------------------------------