Automate decryption

[David Shaw]

On Tue, Sep 02, 2008 at 11:38:17AM -0500, Duwaine Robinson wrote:
> 
> David,
> 
> I think I might want to test your suggestion about storing the
> passphrase on disk or not using one at all to see how it works for what
> I need to accomplish. Can you give me some details about how to go about
> doing that?

Sure.  Storing the passphrase on disk just means that you stick it in
the script you use to call gpg, and give the passphrase right on the
command line:

  gpg --passphrase foobar --encrypt ... etc.

Or you can put it in a file and give gpg the filename:

  gpg --passphrase-file my-passphrase.txt --encrypt ... etc.

The danger here is that if someone can steal the script or the
passphrase file, then they have the passphrase for your key.  In most
cases, you can protect the passphrase file or script so that
unauthorized users cannot read them, even if they can log into the box
in question, but in practice, it is usually best to assume that anyone
who can log into a box can subvert this.  That doesn't mean there is
no point in protecting the file, of course, just that the file
protection should be regarded as something that will slow the attacker
down (perhaps a lot, depending on the abilities of the attacker), and
not something that will stop them cold.

Running without a passphrase just involves removing the passphrase
from the key altogether:

  gpg --edit-key (thekeyid)
  passwd
    (just hit enter for the new passphrase)
  save

In most uses, it's more or less as secure as storing a passphrase on
disk or in a script: just protect the secret key file (secring.gpg)
instead of protecting a passphrase file.  It's simpler than the above,
which is appealing as well.

This is such a common request, I wonder if we should be looking for
better solutions.  The big problem is that most of the obvious
solutions require a human being at some point to type a passphrase,
which is fine for desktop machines, but is a nonstarter for server
machines that need to be able to run in a lights-out environment
without a human being anywhere near them.  Without a change to the
fundamentals of the question, it's hard to see an alternative: the
server needs to boot without human assistance, therefore the key needs
to be accessible to the server.  If the key is accessible to the
server, it is accessible to someone who cracks the server...

David