Implications of a common private keys directory in 2.1

[Stephan Beck]

Hi,

Carola Grunwald:
> Stephan Beck wrote:
>> Carola Grunwald:
>>> Stephan Beck wrote:
>>>> Carola Grunwald:
>>>>> Peter Lebbing wrote:
>>>
[...]
> 
> Removing all cached passphrases sounds great. But does that mean I have
> to invoke the agent directly using the Assuan protocol? And what would
> be the way to get a list of all valid cache_ids?

I thought that after paying attention to the fact that, in your example,
there was only one single passphrase for all the different WME keys
(that's what I had understood), thinking of ways to remove the (one and
only) passphrase would make no sense. Sorry for my confusion!

But, effectively, every passphrase cache entry consists of a cache ID
which can be expressed as the keygrip of the key, so there are really
several different cached passphrase entries=cacheIDs.

Please see [BEGIN QUOTE]

This is gnupg.info, produced by makeinfo version 5.2 from gnupg.texi.

This is the 'The GNU Privacy Guard Manual' (version 2.1.16-beta394,
November 2016).

   (C) 2002, 2004, 2005, 2006, 2007, 2010 Free Software Foundation, Inc.
(C) 2013, 2014, 2015 Werner Koch.
(C) 2015 g10 Code GmbH.

     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU General Public License as
     published by the Free Software Foundation; either version 3 of the
     License, or (at your option) any later version.  The text of the
     license can be found in the section entitled "Copying".


2.6.7 Ask for a passphrase
--------------------------

[...]
   CACHE_ID is expected to be a string used to identify a cached
passphrase.  Use a 'X' to bypass the cache.  With no other arguments the
agent returns a cached passphrase or an error.  By convention either the
hexified fingerprint of the key shall be used for CACHE_ID or an
arbitrary string prefixed with the name of the calling application and a
colon: Like 'gpg:somestring'.
[END QUOTE]

So, yes, and sorry for my hesitation, the only way (I see) is to
invalidate the passphrase cache removing all its entries and manually
presetting the one keygrip/key to use on the command line.

(If it was about ssh keys and the ssh control file you could precede a !
to the respective entry in order to disable the corresponding key. But
in the info manual this is only mentioned in the context of ssh control
file)

So, given that "your" passphrase cache contains keygrips for all the
keys in your secret keyring (the private-keys folder):
gpg --with-keygrip -K

outputs all keygrips.

A SIGHUP sent to the agent flushes the passphrase cache.
[There may be other ways of invalidating cache entries.]

Then you add the --allow-preset-passphrase and the --preset-passphrase
[keygrip of the targeted key]
options to your command line and it should work (i.e. no other key will
be used for decryption - there isn't any other in the passphrase cache!)
Given that I can't reproduce your environment this is not validated by
testing, though.

>>> What I need here is the restriction to just the given key.
>>
>> And the agent's SETKEY command?
>> gpg-connect-agent
>>> help SETKEY
>> SIGKEY <heystring with keygrip>
>> SETKEY <hexstring with keygrip>
>> Set the key used for a sign or decrypt operation.
> 
> Isn't there a gpg SETKEY option for decryption? AFAICS --default-key is
> only for signing, --recipient for encryption. Is --try-secret-key the
> SETKEY equivalent for decryption? Can a developer shed light on this?

Well, as mentioned above, I guess that the interesting gpg option would
be the

--preset-passphrase [keygrip]

option, associating the passphrase with the keygrip (SHA-1 hash of the
canonical encoded S-expression of the key).

Interestingly, the thread about the "gpg-agent 2.1.16 needs about 10s
for initialization saying need_entropy before it completes its first op"
reproduces watchgnupg's debugging output of such a SETKEY --> PKDECRYPT
operation.

>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 99BBCCA120222186A19AC89190ECEE7EF87997A0 87AAAE497897F9936043F9C3B20CE5FDDCD489C2
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- RESET
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- SETKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Expired+<expired at test.trojita.flaska.net>%22%0A1024-bit+RSA+key,+ID+D4EA7265FDDDE374,%0Acreated+2016-12-17+(main+key+ID+35927423786DCCCE).%0A
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- PKDECRYPT
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> S INQUIRE_MAXLEN 4096
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> INQUIRE CIPHERTEXT
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a 72 ...(147 byte(s) skipped) ]
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- END
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> [ 44 20 28 35 3a 76 61 6c 75 65 31 32 37 3a 02 f8 ...(127 byte(s) skipped) ]
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK
>  4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- [eof] 

The first action after INQUIRE CIPHERTEXT is the decryption, the second
(just before the final 'eof' has to be the verifying.
Generally speaking, HAVEKEY given with more than one keygrip outputs OK
if at least for one of the given keygrips there is a secret key held by
the agent in its passphrase cache. So we wouldn't be able to say that
the example above on its own proves that there is really more than one
key in the cache...
But then one has to ask how can it (within the message decryption
workflow) happen that there is a second HAVEKEY request that outputs an
additional keygrip: only when there is a second recipient to whom the
message is encrypted to, the second HAVEKEY request is being emitted.

So, final conclusion: the SETKEY, as seen here, sets the key to use when
there is a hidden recipient the message is encrypted to, and IS another
way of saying --try-secret-key.

Cheers

Stephan




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161219/1300df9b/attachment.sig>