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

[Jacob Appelbaum]

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