Daniel Kahn Gillmor writes on februar 4, 2018 16:37:
> On Sun 2018-02-04 11:46:20 +0100, Gaute Hope wrote:
>> * Always throw key-id when sending (using GMime 3)
> 
> Can you explain this choice?  As someone who receives mail with a thrown
> key-id, and as someone who has multiple secret keys, the user experience
> of receiving encrypted mail like this is *terrible*.  (terrible to the
> point of me wanting to ask people who do this for normal mail to just
> send me mail in the clear in the future :( )
> 
> In particular: GnuPG doesn't know which key to use, so it prompts me for
> passphrases for *all* of the secret keys i control, in succession.
> 
> I understand the desire to reduce metadata leakage.  But if you're
> wrapping the PGP/MIME application/pgp-encrypted part in an RFC822
> message that contains a header with the person's e-mail address anyway,
> it's not clear that there has been a significant reduction of cleartext
> metadata.  So this seems like a bad tradeoff for any case where the
> recipient is explicitly specified (i.e., not in Bcc:)

Hi Daniel,

This is done to hide Bcc-recipients. As you mention 
- and you know all this, but I'll list it for the sake of discussion - 
any Bcc-recipients would be listed as GPG recipients and would thus be 
exposed (which could be critical / embarassing). Of course the number 
of anonymous recipients does not match the visible receivers with 
Bcc-recipients. As a side-note it is theoretically possible to set the GPG-recipient-key to arbitrary values independent of the actual recipients. 

There has been some discussion on the issue on #astroid, and ideally we 
should make this optionable, default off (configurable) - with a warning 
before sending when Bcc-recipients are listed and keys are not thrown. 
(Note that this would also leak meta-data, since if keys are only thrown 
when there are Bcc-recipients you have another hint that there are Bcc-recipients, see above.)

As you say, GnuPG must try all the secret keys; but many 
users use some sort of keyring to unlock their keys - in which case 
the hassle is limited to a bit extra time. I don't have any stats on 
this though!

Regards, Gaute