[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Torbirdy and gpg --throw-keyids
> 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?
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,
tor-talk mailing list