Subject: Re: [openpgp] Reducing the meta-data leak

From: Ben McGinnes <[email-masked]>
Date: Sat, 2 Jan 2016 15:06:13 +1100

On 4/11/2015 1:37 am, Neal H. Walfield wrote:
> 
> 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.

While I don't doubt the good intentions, I fail to see how this has
any real value.  Specifically because of the significantly larger
amounts of meta-data which already leaks from every SMTP exchange
ever.  That's the real threat and that inevitably leads to this
question:

* In what scenario has someone gone to the effort of disguising all
  their SMTP traffic (remailers, tor, whatever), but not selected an
  alias on the OpenPGP key they're using?

Regards,
Ben

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 04 Jan 2016 19:43:35 -0500

>   alias on the OpenPGP key they're using?

fwiw, there is effort going into protecting some of the SMTP/RFC822
metadata (see the discussions in [email-masked]), which would make this
kind of work within OpenPGP more valuable than it currently is in the
full-metadata-wrapped OpenPGP e-mail use case.

It's worth thinking about this problem from the point of view of a
single message encrypted to a single recipient.  We already have the
mechanisms to deal with multi-recipient messages: A sender who wants to
craft a single message to N people without indicating the number of
people should probably re-build the message N times, with a single
PK-ESK on each.  If they really cares that an observer can't tell that
each recipient is getting the same message, they should presumably
choose a separate SK for each version, and pad each message to different
sizes as well.  We can do all of the above except padding in OpenPGP as
it stands, and padding can often be done in whatever format is being
wrapped by OpenPGP (e.g. a text/plain MIME part consisting of all
whitespace).  Incidentally, the single-pkesk-per-message approach
addresses the smartcard UI/UX concern, and mitigates the
multiple-secret-key UI/UX concern somewhat (the multiple-secret-key
UI/UX concern can be further mitigated by configuration recipient-side).

Implementation work or guidance on avoiding creation of multi-recipient
messages would be good.

With regards to the bloom filter proposal here, i think Tom's concerns
about its viability are worth heeding.  In a single-recipient message,
the bloom filter is effectively just a smaller hash of the key.  The
current PKESK itself already doesn't provide an unambiguous answer to
who a message is encrypted to, since it provides only 64 bits of the
fingerprint, and we know that there are pairs of keys that share their
lower 64 bits of fingerprint.

We could simply reduce the size of that further to get more ambiguity
(the distribution should already be uniform) but the ambiguity is
already on the edge of being a problem for UI (it's not clear whether a
UI should announce "this message claims to be for key XXXXX, which we
have, but cannot be decrypted with it" or "this message claims to be for
keyid XX, and while we have key XXXXX which can't decrypt it, the sender
might have meant some other key").  Yuck.

Removing the metadata of who a message is for seems likely to require
either:

 a) trial decryption on the recipient side (problematic for smartcard
    and multiple-secret-key setups, as Neal and Werner pointed out), or

 b) some sort of racheted shared state between sender and recipient
    (e.g. a briar- or axolotl-style esk, which might provide other nice
    features, like "deletable" ("forward-secret") messages)

While (b) is out of scope for us here until we get 4880bis sorted, if
someone wanted to experiment with that and report back, i'm sure it
would be interesting to several people on the list.

Or maybe there's a (c) option?

       --dkg

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 5 Jan 2016 12:23:49 +1100

On 5/01/2016 11:43 am, Daniel Kahn Gillmor wrote:
> metadata (see the discussions in [email-masked]), which would make
> this kind of work within OpenPGP more valuable than it currently is
> in the full-metadata-wrapped OpenPGP e-mail use case.

With a list name like that I'm just going to have to check it out.

> Or maybe there's a (c) option?

There is, but I can't recall if I've mentioned it on this list or not,
but I know it's been mentioned on gnupg-users because that's how I
found out about it:

http://www.confidantmail.org/

An attempt at side-stepping SMTP entirely and replacing the transport
method with one of the methods used by BitTorrent.  It relies on GPG
for the message encryption and everything is contained within the
encrypted zip.  The only addressing metadata is the key UID which is
of the format of:

any-damn-thing-you-like@somehost-including-tor-hidden-sites-and-i2p-it-doesn't-care

It even includes a clever means of achieving forward secrecy, but
arguably it could benefit from hiding the OpenPGP metadata a little
better.

Regards,
Ben

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 04 Jan 2016 22:15:38 -0500

> arguably it could benefit from hiding the OpenPGP metadata a little

This sounds like an effort to hide the SMTP metadata, but doesn't
involve hiding the metadata in the OpenPGP format itself.  While i think
this is a neat idea, i'm not convinced it's addressing the same problems
that (a) and (b) are addressing.

     --dkg

---

From: [email-masked]
Date: Tue, 05 Jan 2016 14:50:24 -0500

On 1/4/2016 at 7:43 PM, "Daniel Kahn Gillmor"  wrote:
Removing the metadata of who a message is for seems likely to require
either:

 a) trial decryption on the recipient side (problematic for smartcard
    and multiple-secret-key setups, as Neal and Werner pointed out),
or

 b) some sort of racheted shared state between sender and recipient
    (e.g. a briar- or axolotl-style esk, which might provide other
nice
    features, like "deletable" ("forward-secret") messages)

=====

Maybe a (c) option that combines  aspects of (a) and (b):

[1] Suggesting that users of multiple secret keys have 1 unique e-mail
address for key.
(e.g.  Hushmail allows for unlimited nym e-mail aliases which all go
to the same hushmail account under the primary [non-nym] e-mail
account.)
A user can generate multiple keypairs, assigning a different nym alias
to each of them).

[2] The users should not upload the keys to keyservers, but rather
exchange public keys with whomever they wish to communicate.

[3] They then use the --throw-keyid option, but the receiver knows
exactly which key it is, by seeing to which nym e-mail address it is
sent.

[4] No interceptor knows who the 'true' recipient is, except for
e-mail client, which could be set up to do this without tracking,
(i.e.   
(a) register for the e-mail client under a false name with a pre-paid
no-name credit card
(b) use an e-mail client that allows multiple nym aliases  )
-- just a possible avenue of exploration as to how it might be done
...
vedaal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 05 Jan 2016 14:54:46 -0500

> exchange public keys with whomever they wish to communicate.

this seems like it might be handwaving away a very difficult question...

> exactly which key it is, by seeing to which nym e-mail address it is

if the receiver can see it, then the metadata is present, right?  so
this proposal just moves the metadata out of the OpenPGP block and into
the surrounding RFC822 message.  I don't think that solves the problem.
or am i misunderstanding your proposal?

   --dkg