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

Attachment: pgpvcIgmtx3pj.pgp
Description: PGP signature

notmuch mailing list

Reply via email to