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

[Tim Wilde <twilde@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Jake,

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!

Thanks,
Tim

- -- 
Tim Wilde, Software Engineer, Team Cymru, Inc.
twilde@xxxxxxxxx | +1-847-378-3333 | http://www.team-cymru.org/
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJQCcEUAAoJED1BdOFPDWdbd94QAI6gQk5olrEDWXOa8J4Hh1Q+
OsOvFXYyxnDgbrZ8GycjAh9JeA5+I6wJwyrw0azpXbULQpYFcAnhngyTzkyYzPCn
eR80Vohj72KwMNCoFyO8LpKlLmdtnLi3ZsfEq5aF2Ou+cVCGOsUUNxiDhBEUsI8P
lgSzGWIa6x2g1+Qz4ZwMvFf5w62oJITdVQbmDOTgvExzivvtuMC5HYFNHKsanEVD
HeQJve0RO1jAYJnlr20J6Bx6gD/vdBoxNb4OnEbv+u1y+An7WcHu9al7/OpesIw5
dFPkzLI++ZHPVK4be9NdNEQpRZZbxdc7+nWGcZvUQ3nGH6UY/4zpJDaZXShY4tmG
aL/iRWGBH9QfiZj65lFreBELIqBtaYHJjnj4hQccE4Ee30VaSYgXXwCIUKVpDeNG
NYOExSCEaiKyx34jb/Q3gLhykLe6cjOQ6RKYwOca56BFc6wJ67ge6Jq9+1olyZKJ
WUmLWs/J2n4EvnuG/hkh6T0ivRgvUIuX1XUc8VvZfgSpUp5Hv1znwCW2MV38U4t0
TSoWsMFgFjDZrxa+6/kwKMIup0nK5fqhAAAI9fFAy5UhAtd2PtsSEdmE4x37tH9l
yjH63PsqZ8zBMb6n/72ynuuXTDEvPKI9lzUqSTdEv+/IpAM1a4CLoYV2K8Y2pN0B
v+gjuVV5L4I0kB17Ze3x
=q6+s
-----END PGP SIGNATURE-----
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk