Tim Wilde: > 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? >
I regularly encrypt a key that isn't public because I want to keep a copy of the email accessibly to that key. > * 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). The RIP Act in the UK, specifically I think, Section Three. That's the current British tyranny where they may request your specific encryption key and if you cannot produce it, they jail you. > > * 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. > I think the subtle difference here will be lost on most users. I admit, I didn't know about this feature until you mentioned it. > 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! I think this is less a matter of education and more a concern about leaking information without user's consenting. It's such a subtle issue, I feel like a lot of information that is cryptographically assured or asserted - well, it leaks out. All the best, Jake _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
