Questions about --throw-keyids

[Daniel Kahn Gillmor]

On Mon 2017-02-13 11:54:04 -0500, Lukas Pitschl | GPGTools wrote:
>> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor <dkg at fifthhorseman.net>:
>> 
>> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
>>> Step two: Encrypt using gpg --throw-keyids.
>>> 
>>> This is easy on the sender's end, but whether this feature can be
>>> used as a matter of course depends on how it impacts the
>>> experience of the recipient.
>> 
>> It's almost like decryption of messages with hidden keyids and
>> per-decryption passphrase prompting (or even confirmation) are mutually
>> incompatible workflows :/
>
> Just thinking out loud here, but wouldn’t it be sensible for gnupg to have a „silent“ option,
> that only try keys for which a passphrase is cached in gpg-agent?

how about "--try-cached-secrets", by analogy with --try-all-secrets or
--try-secret-key?

I like this idea.

> While a fallback would have to be provided in case no matching key is found,
> it would make it easier for those users that cache their passphrases.
> As fallback gnupg could return the information that no cached passphrase was found,
> allowing the MUA or plugin to then re-try without the option that enables „silent“ checking.

Right, this makes sense.  It's also possible that the combination of the
tool invoking gpg and gpg itself can be cleverer about proposing
candidate keys.  For example, if the PKESK uses RSA, and the value is
4096-bits in size, and the thing being decrypted is an e-mail address
with a certain Date: header and specific addresses in the To: and Cc:
fields, then you could filter secret key material by creation/expiration
dates and User IDs and usage flags and key sizes.  This might also turn
out to mean that of all secret keys held, only one is even remotely
likely, in which case it could just be tried anyway.  You could use the
inbound e-mail address (enclosed in <>s) with --try-secret-key, but i
don't know how you could pass it the hints from the Date headers.

I wonder whether anyone is trying to do anything like this currently.
If so, i'd be happy to hear details about what you've tried and what you
think might be necessary to make it even better.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170213/ab705702/attachment.sig>