Implications of a common private keys directory in 2.1

Stephan Beck stebe at mailbox.org
Mon Dec 12 18:20:00 CET 2016



Carola Grunwald:
> Peter Lebbing wrote:
> 
>> On 11/12/16 20:58, Carola Grunwald wrote:
>>> With 'problems' i referred to the GenKey bug/feature I reported a few
>>> hours ago and the IPC instabilities I experienced. Sure, the
>>> single-sec-keys-depository : multiple-pub-keyrings configuration is a
>>> design decision, though one I don't quite understand.
>>
>> Oh, I thought you were referring to my warning that running the agent
>> with lots of private keys might hit some unforeseen issues.
>>
>>> You mean --try-secret-key doesn't overrule the key parameter that comes
>>> along with the encoded material?
>>
>> No, it specifies which keys to try for a hidden recipient. This is easy
>> to investigate if you create a few test private keys and create some
>> test messages. I did that earlier, and I could see no overruling
>> behaviour or even a preference to --default-key or --try-secret-key.
> 
> You're right, unbelievable. I specify --try-secret-key with a
> 
> [GNUPG:] ENC_TO 0000000000000000 18 0
> 
> message and gpg still tries out two dozen WME keys with a passphrase not
> valid for them. What a waste of time!

If you knew the cacheIDs of all cached passphrases you could use

"2.6.8 Remove a cached passphrase
--------------------------------

Use this command to remove a cached passphrase.

       CLEAR_PASSPHRASE [--mode=normal] <cache_id>

   The '--mode=normal' option can be used to clear a CACHE_ID that was
set by gpg-agent."

for removing all passphrases but one (the one you would like to be used).


If you'd want to make sure that the right passphrase is provided, why
don't you use --pinentry-mode loopback
"Use a loopback pinentry.  This fakes a pinentry by using
          inquiries back to the caller to ask for a passphrase."


Sorry, I can't reproduce your environment for now and only have these
"dispersed notes" exposed here (but found your description of your
system very instructive and largely followed it). I merely point you to
options the usefulness of which you are more experienced to assess.


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/20161212/f7d17189/attachment.sig>


More information about the Gnupg-users mailing list