Hi,
Jacob Appelbaum wrote (21 Jun 2012 06:03:13 GMT) :
> On 06/20/2012 06:24 PM, intrigeri wrote:
>> Wouldn't any of the following tricks work?
>>
>> - set 0.0.0.0 as proxy IP
>> - set a port number that is larger than the max. legal TCP port
>> number
> I'm not sure, I bet it would work.
Ah, some possibility of *really* failing closed on the horizon.
Sounds much better than the initial "There is no way to fail closed" :)
>>> However, I think that it is absolutely imperative to use that option
>>> with gpg and thunderbird. Otherwise, we leak a cryptographic
>>> identity, directly, not indirectly. :(
>>
>> I'm not sure what exactly you mean by leaking a cryptographic
>> identity, but perhaps it's because the last time I have read your
>> threat model was months ago.
>>
>> I see two major problems with the default GnuPG behaviour:
>>
>> 1. if an encrypted message is Bcc'd to several recipients,
>> every recipient gets to know which other public OpenPGP
>> keys the message was encrypted to.
> This.
>> 2. whoever can snoop along the email routing path can link recipient
>> email addresses with OpenPGP public key IDs.
> This.
>> 3. < insert here what I'm missing :) >
> Also the mail servers who receive the message.
I consider the email route to go from the sender's MUA to every
recipient's MUA, so this is part of "whoever can snoop along the email
routing path".
>> To clarify, which one is the cryptographic identity leak that makes it
>> absolutely necessary to switch to the --throw-keyids mode?
> All three above - especially if the mail servers in question do not
> use TLS or STARTTLS, or if the user is using 0.2.2.x Tor without the
> Isolated Streams work.
Well... I think I now can see what you're trying to achieve by
enabling --throw-keyids, but doing this has a huge cost.
Strategically speaking,
I'm not convinced we practically do all of this at the same time:
1. encourage widespread use of OpenPGP for email encryption
2. encourage widespread use of contextual identities
3. a) hide the "an unpublished OpenPGP public key X exists and presumably
belongs to the email address A" information
b) hide the other recipients to a recipient of a Bcc's email
Given we want to keep #1,
I tend to prefer throwing away #3 to get #2,
than throwing away #2 to get #3 the contrary.
Unless I've misunderstood, it looks like we disagree on that point.
A compromise could be to *not* use --throw-keyids by default, but
opportunistically enable it *only* when sending encrypted email to
a bunch of Bcc'd recipients. This way, #3.b is covered, and at the
same time #2 is not too much harmed. What do you think?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
