[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Torbirdy and gpg --throw-keyids
-----BEGIN PGP SIGNED MESSAGE-----
On 7/18/2012 6:19 PM, Jacob Appelbaum wrote:
> 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.
Maybe I'm being dense, but under what circumstances does it make sense
for a GPG public key to be ... not public? I genuinely would like to
better understand your position. My specific questions on your example:
* If you want to hide your key from me, how do you expect me to reply
to the communication while maintaining the confidentiality? I don't
understand a use case in which this would make sense. Hiding it from
the public is one thing, but hiding it from the recipient?
* What do you mean by "may be used to ask you to disclose a specific
key", exactly? The only thing doing the "asking" is my trusted local
GPG instance, and in the case of --throw-keyids, it will actually be
asking me /more/ questions and causing significantly more risk of
information disclosure in the case of system compromise (but if my
system is already compromised, I've already lost, so I still don't
understand the threat profile here either).
* I won't argue about the third party, but that's already handled
automatically by Enigmail when you BCC, which is typically the only
way that third party key would get in the mix in a standard Enigmail
use case scenario.
Additional to all of this, the GPG key itself is never being disclosed
here, just its key ID. It's still giving a unique identifier from
which you can build a social graph, I'll grant you, but again, I'd
argue that it's a real stretch to say this information is anything
more than is already disclosed in the required SMTP headers.
Please, educate me!
Tim Wilde, Software Engineer, Team Cymru, Inc.
twilde@xxxxxxxxx | +1-847-378-3333 | http://www.team-cymru.org/
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
tor-talk mailing list