Announcing Astroid v0.11
Gaute Hope
eg at gaute.vetsj.com
Sun Feb 4 09:52:22 PST 2018
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20180204/36865359/attachment-0001.sig>
More information about the notmuch
mailing list