Subject: [openpgp] Reducing the meta-data leak

From: "Neal H. Walfield" <[email-masked]>
Date: Tue, 03 Nov 2015 11:02:25 +0100

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?

Thanks,

:) Neal

---

From: Tom Ritter <[email-masked]>
Date: Tue, 3 Nov 2015 06:19:12 -0600

> it should reduce the metadata leak a fair amount, I think.  Thoughts?
I'm skeptical that we could come up with a set of parameters such that this
provides any real protection.  On the loosest end, you would need to make
it ambiguous enough such that if you tried 'all' the OpenPGP keys you would
get too many false positives for it to be useful. On the tightest end, you
would need to make it ambiguous enough that even if you *had* the list of
the most common conversation partners of a user it would _still_ have too
many false positives to be useful.

And even then, the bloom filter is chosen once and set in stone in the spec
for all users and use cases? It would clearly not fit some of the
situations we expect OpenPGP to be used in.  And I tend to lean towards
more complex protocol options, but even I think user-configurable bloom
filters in every OpenPGP message is going too far...

-tom

---

From: Derek Atkins <[email-masked]>
Date: Tue, 03 Nov 2015 09:30:48 -0500

> 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?

> :) Neal

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Neal H. Walfield" <[email-masked]>
Date: Tue, 03 Nov 2015 15:37:06 +0100

At Tue, 03 Nov 2015 09:30:48 -0500,
> completely understand what the use-case is where the above solution

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

---

From: Derek Atkins <[email-masked]>
Date: Wed, 04 Nov 2015 09:31:49 -0500

> particular, he wanted to get rid of the recipients / number of

I'm not at all sure how you would remove the number of recipients; you
still need N encrypted session key packets.  Therefore anyone reading
the message can count the ESKs.

> difficult to get at the list of recipients.

Is it really worth the overhead?

-derek