[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documenting gpg-agent

From: Ken Manheimer
Subject: Re: Documenting gpg-agent
Date: Mon, 25 Dec 2006 12:39:51 -0500

On 12/24/06, Daiki Ueno <address@hidden> wrote:
>>>>> In <address@hidden>
>>>>>   Richard Stallman <address@hidden> wrote:
>                      when the agent is active, passphrases passed in to
>     pgg are effectively ignored, such that pgg-agent continues to prompt
>     (via pinentry) for the passphrase.

> That sounds like a bug in pgg or gpg-agent.  Passing in passphrases
> from the caller may not be recommended use, but it shouldn't just stop
> working.

Since allout exploits the use of PGG's passphrase handling functions to
provide a custom passphrase handling, it's not a bug in PGG or gpg-agent,
I think.

the thing i'm seeing as a problem is that allout is passing in the
right passphrase to pgg, but gpg-agent is still prompting for the
passphrase if it doesn't already have it cached.  it seems to me that
if the calling routine is doing its own passphrase handling, pgg
should respect that.

that said, i agree that it's preferable to have gpg-agent do the
passphrase handling when gpg-agent is available and applicable.

unfortunately, i would expect that gpg-agent is *not* applicable when
it comes to symmetric keys, because symmetric keys are not specific to
any signature of the encrypted text's envelope.  ie, i don't think
that gpg-agent can, in principle, cache symmetric keys, because it
can't know which key belongs to which message - and in practice, that
seems to be the case.  (let me know if i'm mistaken here.)

symmetric keys are a particular concern for allout, because allout
enables having myriad independently encrypted messages in an outline.
varying keys for various symmetric-key-encoded messages in an
outline/file would easily grow to an unmanagable burden for the user,
so allout provides file-specific key verification and user-set
reminder for a single symmetric key per file.  this makes symmetric
keys quite useful with allout, and i expect is way outside the purview
of gpg-agent.  so it looks like i need to have allout continue using
its internal passphrase caching for symmetric keys.

so i will arrange for allout to take care of symmetric-key caching,
but defer to pgg when it comes to keypair passphrases.  (i could
arrange for allout to do keypair caching when pgg-gpg-use-agent is
nil, but i think i want to get allout out of the business of touching
the much more sensitive keypair keys, so i'll submit a patch that has
allout doing the caching for symmetric keys only.)

Ken, is it hard to make allout skip its own passphrase handling if
pgg-gpg-use-agent is t, as PGG does?  I know it disables passphrase
caching for symmetric encryption, but it seems a practical solution for
the release.

i think the balance the patch i propose, above, is a good one.

as far as i can tell, gpg-agent doesn't and can't provide for
symmetric key caching, and it definitely can't provide for the special
considerations that come with having multiple independently
symmetrically-encrypted messages in a file.  the allout provisions for
multiple independently encrypted symmetric messages entails an extra
decryption (to decrypt a random string, stored on an emacs file local
variable, which acts as a verifier for user passphrase input) on any
symmetric-key encryption or decryption, which intensifies the need for
symmetric key caching.  the patch i'll submit will leave
responsibility for symmetric keys to allout's caching, which will
cover all these concerns while gpg-agent wouldn't.

keypair keys, on the other hand, don't need those other provisions,
and are more sensitive secrets, so i'm happier to leave responsibilty
for them outside of allout.  the patch will leave that responsibility
to pgg, which will defer to gpg-agent when available.

the only downside to this late change is that i will likely not have
time to tend to problems if it introduces any.  i'm confident enough
about it that i'm willing to go with that, though i'm not crazy about
the timing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]