How to prevent passphrase caching in 2.1

[Carola Grunwald]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

>On Wed 2016-11-23 03:46:57 -0500, Carola Grunwald wrote:
>> With GnuPG 1.4 I had no agent. And, in case it is, I've no idea why with
>> 2.x such a passphrase cache with all its risks has to be mandatory.
>
>in 2.0, the agent is a passphrase cache.  in 2.1, the agent is a proper
>cryptographic agent, which does not release any secret key material to
>the calling process.  This isolation is actually offers reduced risks in
>the contexts in which gpg is expected to be invoked (by a single user,
>who is managing their own keys).

What are your objections to an option to deactivate that caching
feature, which, as I explained, under certain circumstances may turn
into a severe security risk? Are there any technical reasons why GnuPG
absolutely can't do without a cache? Or is it merely user convenience
you trade security for?

Think of a single-user configuration, where that guy enters a (wrong)
passphrase, GPG uses a different one from a cache of unknown contents
and decrypts his data, at worst without telling him about that
substitution required to complete the task. The user tries to memorize
his allegedly valid passphrase. And next time, same key, same
passphrase, but the cache no longer in favour of him - hard luck!

Is that correct? Or is there any chance for the user to get knowledge of
that passphrase substitution?

>
>that said, i understand why it doesn't meet your needs.  unfortunately,
>you're using these tools in a framework that they generally weren't
>expected to be used.

And which Open Source OpenPGP engine have you in mind that suits my
needs?

>
>You've said already that you don't want to run a different gpg-agent for
>each user account that is currently authenticated to your server.  can i
>ask why not?  the agent is a pretty lightweight process, and setting one
>up on login and tearing it down on shutdown seems like it could be a
>fairly convenient approach.

Please don't underestimate the complexity of your proposal. It isn't
only about starting and shutting down a service with every single mail
server connection, which by itself would be bad enough. You also have to
deal with the creation and manipulation of lots of keyrings, one for
every private key, with multiple public key copies of potential
recipients added and removed. And each instance has to have its own home
directory. What would that mean for my test environment, where I
currently manage way more than a hundred identities. Horrible!

Kind regards

Caro