Re: [openpgp] openpgp Digest, Vol 30, Issue 7

On 4 Nov 2015, at 05:00, "openpgp-request@ietf.org" <openpgp-request@ietf.org> wrote:

> Send openpgp mailing list submissions to
>    openpgp@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://www.ietf.org/mailman/listinfo/openpgp
> or, via email, send a message with subject or body 'help' to
>    openpgp-request@ietf.org
> 
> You can reach the person managing the list at
>    openpgp-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openpgp digest..."
> Today's Topics:
> 
>   1. Re: Reducing the meta-data leak (Derek Atkins)
>   2. Re: Reducing the meta-data leak (Neal H. Walfield)
> "Neal H. Walfield" <neal@walfield.org> writes:
> 
>> Hi,
>> 
>> At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly,
>> suggested that we should try and hide more meta-data.  For instance,
>> instead of listing the recipients, someone decrypting a message would
>> try each of their available secret keys in turn.  Werner pointed out
>> that these probes are a pain for people who use a passphrase protected
>> key and I mentioned that it is a pain for people who use a smartcard,
>> in paritcular, those who use more than one smartcard.
>> 
>> What about using a bloom filter for encoding the recipients?  This, of
>> course, doesn't eliminate the meta-data leak and it can lead to false
>> positives (= gratuitious passphrase prompts / smartcard prompts), but
>> it should reduce the metadata leak a fair amount, I think.  Thoughts?
> 
> There was an extension at one point where you use the string 0x00...00
> for the keyID and that forced you to test all your secret keys.  There
> are certainly times where that is warranted; there are other times where
> it is not.

Right. What struck me about the proposed approach was the difficulty of using it in the other problematic use-case DKG described during the meeting - where someone has sent you a 5Gb cipher text (or, worse, a stream) and you have to decrypt some or all of it before you can tell whether you're using the right key or not.

I suspect the answer is to recognise that not all metadata is equal, and that it may be appropriate to have different levels of protection (including zero) for different items of metadata.

For example: if "recipient" is sent in clear, it simplifies the task of identifying the right key to use, but it would then be up to the communicating parties to decide whether they should use other means to protect their identities... The remaining metadata (such as algorithm identifier and parameters) could potentially be protected by other means. 

R 

> 
> I wasn't at the meeting (in person or virtually) so I'm not sure I
> completely understand what the use-case is where the above solution
> doesn't work?
> 
>> Thanks,
>> 
>> :) Neal
> 
> -derek
> -- 
>       Derek Atkins                 617-623-3745
>       derek@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
> 
> 
> At Tue, 03 Nov 2015 09:30:48 -0500,
> Derek Atkins wrote:
>> "Neal H. Walfield" <neal@walfield.org> writes:
>>> At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly,
>>> suggested that we should try and hide more meta-data.  For instance,
>>> instead of listing the recipients, someone decrypting a message would
>>> try each of their available secret keys in turn.  Werner pointed out
>>> that these probes are a pain for people who use a passphrase protected
>>> key and I mentioned that it is a pain for people who use a smartcard,
>>> in paritcular, those who use more than one smartcard.
>>> 
>>> What about using a bloom filter for encoding the recipients?  This, of
>>> course, doesn't eliminate the meta-data leak and it can lead to false
>>> positives (= gratuitious passphrase prompts / smartcard prompts), but
>>> it should reduce the metadata leak a fair amount, I think.  Thoughts?
>> 
>> There was an extension at one point where you use the string 0x00...00
>> for the keyID and that forced you to test all your secret keys.  There
>> are certainly times where that is warranted; there are other times where
>> it is not.
>> 
>> I wasn't at the meeting (in person or virtually) so I'm not sure I
>> completely understand what the use-case is where the above solution
>> doesn't work?
> 
> Bryan Ford proposed getting rid of all unencrypted meta-data.  In
> particular, he wanted to get rid of the recipients / number of
> recipients.
> 
> There are some practical difficulties with this approach,
> which I mentioned above.
> 
> My proposal is a blue sky idea to avoid having to try to decrypt a
> message with every secret key while (hopefully) making it more
> difficult to get at the list of recipients.
> 
> Neal
> 
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp