Re: [patch] passphrase cache for GnuPG

["Jacob A. Perkins" <jap1 cec wustl edu>]

This kind of thing would probably be better handled by the gpg folks,
though it certainly wouldn't be added to the gpgme-0.3 series. I would
imagine they could provide a cache option parameter for the passphrase
callback definition that would determine if the passphrase is cached and
for how long. There is also gpg-agent in the newpg package, though I have
no idea how that works (but kmail uses it).
I have also heard talk of gnome-vfs or some other gnome system library
offering a passphrase dialog in the future, which could also implement
caching.
Anyway, this feature would be better if it could be easily shared between
any applications that need it, so I suggest implementing it in balsa now
and advocating its inclusion in a shared library in the future (maybe in
gnome 2.4?)

> Hi all,
>
> attached is a patch (against today's cvs) to implement a passphrase
> cache  for the gpg stuff. As this might be a highly controversial
> issue, I try to  explain my approach in greater depth...
>
> In general, it's a bad idea to remember a passphrase anywhere else than
> in  your brain, because (as Carlos pointed out) it is impossible to
> protect it  against an attack by root. On the other hand, it's annoying
> to type a  really good (and therefore complex) passphrase 10, 20, 30
> times per day. People prone to use weak passphrases or don't
> sign/encrypt messages any  more as a consequence, which isn't good
> either.
>
> Taking this into account, I hope my solution is an acceptable
> compromise:
>
> * to enforce site-wide rules, root must enable the use of the
> passphrase  cache and define an upper limit for the time the passphrase
> may be kept;
>
> * the user can enable caching a passphrase and set the time for which
> it  is held, up to the limit above. The number of cached passphrases is
> not limited, but usually there will be just one for each identity.
>
> The cache holds pairs of name and passphrase. To protect against simply
>  grepping through the strings of a core file or the contents of the
> swap  partition, the name is stored as md5 hash, and the passphrase
> 128-bit  blowfish encrypted using a random session key (ok, this is
> also an excuse  for me to play with openssl...). Therefore, you must
> have ssl support  enabled to use the cache.
>
> When balsa segfaults (does it? ;-)), the blowfish key is destroyed to
> make  analysing the core more difficult (Your friends from domestic
> intelligence  might prefer to put you in a bird cage in Guantánamo to
> get your secrets,  though).
>
> Please note that root could still attach a gdb session to your running
> balsa process, read the keys and the cache data, and decrypt the
> passphrase. You have been warned!!! (Of course root could also write a
> simple "logging wrapper" for gpg or libgpgme or even balsa to get all
> passphrases. See above...)
>
> To enable the cache, you must create the file ${prefix}/share/balsa/
> gpg-cache with the contents:
>
> ~~~snip here~~~
> [PassphraseCache]
> enable=true
> minutesMax=???
> ~~~snip here~~~
>
> Obviously, enable must be true and minutesMax any value >= 0, e.g. 60
> for  (surprise) 1 hour... Note that the file also must be owened by
> root and  must not be group/world writable.
>
> As always, *any* comment or suggestion (in this case especially from
> the  security gurus, of course) is really welcome!
>
> Cheers, Albrecht.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn
>  (Germany)
>        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
> _________________________________________________________________________