How should a front-end handle a stored passphrase

Frank Tobin
Thu Jan 17 05:29:01 2002, at 19:40 -0800 on 2002-01-16, wrote:

> I am revisiting a program I started about three years ago.  As it may
> sign more than one file during an execution run, it asks the user to
> enter the passphrase which it later passes to gpg using a file
> descriptor.  The descriptor prevents the passphrase from appearing on a
> command line or within a file.  Still, the passphrase is stored in
> memory during program execution.  Is there some precation I should take
> with how it is stored?

First, I would highly recommend looking at using a program like
Quintuple-Agent to do passphrase-caching for you.  It is a generic
secret-holding program, and wraps nicely and transparently around GnuPG.

A lot depends on the language you are using.  If you are using a low-level
language like C on a POSIX system you might want to try memory-locking and
such.  But your users may not trust having your program be setuid root.
You also have strong control of actually wiping the memory-in-place if
need be.

If you are using a higher-level language, which abstracts the machine a
great deal, there isn't much you can do; they can have multiple copies of
data hanging all around the place.

You need to understand the threat models before you go off on a limb,
though.  Normally the threat is having the passphrase temporary swapped
out to disk, in a swap file/partition of sorts, or your program core-dumps
and is publicly viewable.  The swap partition problem is not too much of
an issue for most people; as long as the machine's superuser is trusted
(and the box is physically secure), even having the passphrase swapped out
isn't going to expose it.  And some OS's have encrypted swap so that
periodically (maybe only upon reboot?) all previous swap becomes
unavailable, so this threat is even minimized even further.

Frank Tobin