Heya Tim,
Tim Wilde:
> Hey All!
>
> Question for Torbirdy folks - what is the rationale for using
> --throw-keyids in the gpg command-line when using Enigmail together
> with Torbirdy (looks like it was initially committed in
> d1d5c28ade6b28693b1f2b1cc35fe4d17eb02ed0, and the commit log is
> nothing more than "--throw-keyids" :))? I see the code comment
> mentions that --hidden-recipient for each person would be
> better/preferred (though I think throw-keyids is identical if you're
> doing hidden-recipient for every recipient), but, again, I'm having a
> hard time understanding the rationale for doing either of these.
>
The gpg manpage says the following:
Do not put the recipient key IDs into encrypted messages. This
helps to hide the receivers of the message and is a limited
countermeasure against traffic analysis. ([Using a little social
engineering anyone who is able to decrypt the message can check
whether one of the other recipients is the one he suspects.])
On the receiving side, it may slow down the decryption process
because all available secret keys must be tried. --no-throw-
keyids disables this option. This option is essentially the same
as using --hidden-recipient for all recipients.
So lets say that I use gpg to encrypt the message to you, to me, and to
an additional key. I would reveal my own gpg key (which you may not
know, which may not be public), your key (which may be used to ask you
to disclose a specific key), and finally - it reveals the third party
which is not otherwise involved in the email message headers at all.
I'd prefer that this isn't revealed at all and lucky for us, gpg allows
us to hide that information.
> The recipients of the message are already clearly disclosed in the
> message headers, and Enigmail's default behavior is to use
> hidden-recipient for any BCC'd recipients. I would argue that forcing
> all recipients to be hidden a) makes Torbirdy more fingerprintable
> because it's a non-standard behavior
While we want TorBirdy to not be obviously fingerprintable - I care more
about the social graph being hidden than I care about TorBirdy being known.
> and b) is a royal PITA for
> recipients of encrypted messages from Torbirdy users if those
> recipients have a lot of candidate private keys to test decryption
> with. Reason b), in case you can't guess, is why I came across this
> in the first place. :)
Perhaps there is a good solution to this problem that does not also
reveal the social graph?
>
> If the goal is to hide the sender's encrypt-to key and thus protect
> their identity, --hidden-encrypt-to is actually the option that would
> seem to make the most sense:
>
> http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html
>
I'd take a patch that ensured that the only key revealed was the one in
the To: field. It sounds a bit error prone but at least that as a
compromise would fix your issue and not really reveal a terribly large
amount of the social graph that isn't already leaked by required email
headers.
> Please, for the sanity of people receiving encrypted mail from
> Torbirdy users, reconsider defaulting to --throw-keyids, or at least
> educate me on the aspect of protection it provides that I'm missing. :)
Patches welcome... :)
All the best,
Jake
_______________________________________________
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
