Implications of a common private keys directory in 2.1

[Carola Grunwald]

Stephan Beck wrote:
>Carola Grunwald:
>> Peter Lebbing wrote:

>>>> 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).

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?

>
>
>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."

That's what I actually do:

| G:\MyGnuPG\gpg\gpg.exe --pinentry-mode loopback --no-default-recipient --no-default-keyring --keyring "G:\MyGnuPG\key\rcp.kbx" --status-fd 2 [...] --decrypt --command-fd 0 --try-secret-key F69A3C70E1A93A2A --passphrase "DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM" --output "G:\MyGnuPG\gpg\tmp\txt_clr.906" "G:\MyGnuPG\gpg\tmp\txt_enc.906"

There's the id of a secret key with its passphrase, but if decoding
doesn't succeed with that key-passphrase combination or if the key
doesn't exist there are decryption attempts with all other secret keys
in the private-keys-v1.d folder, which only waste time:

| [GNUPG:] ENC_TO 0000000000000000 18 0
| [GNUPG:] KEY_CONSIDERED B5A49F253CE924DD2978A2C1F69A3C70E1A93A2A 0 <- the targeted one
| [GNUPG:] KEY_CONSIDERED 5A2915D0E26A7FD3301A35D82F1E01D95F23CBA9 0
| [GNUPG:] KEY_CONSIDERED A2C2DA81C60217BA9FC60295F021F62304A579D2 0
| [GNUPG:] KEY_CONSIDERED ...

AFAICS it always uses the same given passphrase with all the keys, which
is good:

| gpg: DBG: chan_0x0000009c <- INQUIRE PASSPHRASE
| gpg: DBG: chan_0x0000009c -> D DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM

What I need here is the restriction to just the given key.

>
>
>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.

I appreciate every hint I can get on my way back to a fully operational
stable system. :-)

Many thanks and
kind regards

Caro