[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Torbirdy and gpg --throw-keyids

Hash: SHA1

I agree with Jake.  Less information disclosed is better.

Under some circumstances I will encrypt a message to recipients not in the email.  For example, if I am emailing on behalf of a group, I will encrypt to the group, even if I do not CC/BCC them, because I consider it a 'trust' thing.  I never intended them to not be able to read that message, so I portray it.  (It's also super-handy if I need to forward the email from a phone w/o my key.)  Another situation could be encrypting emails to a backup key of my own.  Or even (whip me for suggesting it) encrypting to a message escrow service of some kind.

So throwing the keyids of everyone but the recipient and sender is very good, and should be done.  I argue strongly for that.

Under some strange circumstances, the receiver and/or sender may have a non-public key that the message would be encrypted to, that they would not like to disclose the existence of.  It could be used to segment working vs personal relationships, keep a high-security key under wraps for use with your spouse, be a project specific key, or perhaps be used to bypass a previously theorized key escrow service.  If I was performing reconnaissance on someone, and say 85% of their traffic went to a public key on a keyserver, and 15% went to an undisclosed key - that's strange.

But on the flip side, it's obvious the message is encrypted to the recipient(s) specified on the email and the sender saw it unencrypted... and in some cases those recipients may be greatly inconvenienced by throwing the keyids - as in your case.  So throwing the keyids of the recipient(s) is still arguably important, but less so than third-parties.  I could go either way on it.

It almost seems like it could be worth codifying a preference in the OpenPGP standard. Potentially interpreting http://tools.ietf.org/html/rfc4880#section- to also imply throw-keyid or adding a new option.

- -tom

tor-talk mailing list