-----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. twi...@cymru.com | +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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk