Implications of a common private keys directory in 2.1

[Stephan Beck]

Carola Grunwald:
> Peter Lebbing wrote:
>> On 25/11/16 00:03, Carola Grunwald wrote:

[...]
>> An option --only-try-secret <keyID> would solve both (your software
>> would know which to try for a given nym account), but such an option is
>> not available. You could try to make the case that such an option would
>> be a good idea to implement. It would serve more scenarios than just
>> yours. For instance, people with smartcards could use it when a message
>> is also encrypted to an on-disk key, when they can't or don't want to
>> insert their smartcard. And if somebody knows which key is the hidden
>> recipient, but has multiple secret keys, it would save them declining
>> all the dialogs for the keys that aren't the recipient.
> 
> I'm not sure whether gpg.exe can handle the concatenation of dozens of
> '--try-secret-key A7DD28F363B0924E3B735F22A49104AD3835E227' parameters
> and stop using keys not on that list even with their passphrases in the
> cache.

If you created a special (secret) keyring file (being encrypted to your
server's subkey as an additional security measure) containing all secret
keys you'd need to have in there (=all those keys your particular agent
instance has to serve), and use it as in
gpg2 --no-default-keyring --secret-keyring file --try-secret-key
[NAME=aspecificlongKeyID | fingerprint] --decrypt
any_signedANDencrypted_message.txt.gpg ?
Would that work? Would that be feasible?
This option should be available for GNuPG's Windows version as well. (I
understand that you're in a Windows (server) environment and are talking
about gpg4win, are you?)
Wouldn't gpg 2.1 then just use this one and only key for decryption
(which is part of that secret keyring file) and, otherwise (if this key
fails to decrypt), give up on decrypting?

I can't reproduce your environment right now, so I can't try it out,
it's just a guess.

Cheers

Stephan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x4218732B.asc
Type: application/pgp-keys
Size: 4089 bytes
Desc: not available
URL: </pipermail/attachments/20161206/867f1d36/attachment.key>
-------------- 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/20161206/867f1d36/attachment.sig>