Re: [openpgp] Reducing the meta-data leak

Tom Ritter <> Tue, 03 November 2015 12:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 39B261B32C7 for <>; Tue, 3 Nov 2015 04:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ASdBkhcQnu0i for <>; Tue, 3 Nov 2015 04:19:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9AF441B32C6 for <>; Tue, 3 Nov 2015 04:19:13 -0800 (PST)
Received: by qkcl124 with SMTP id l124so5278656qkc.3 for <>; Tue, 03 Nov 2015 04:19:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wYNi81g+ZfeDXyjP8b+gWmzuzBaZK1htTUebMdHp7Ek=; b=0XeJUaBsAcUeMVFpX3Ulq7fsnUoqL1blGC0gVf8Puj99I0fguAInXx5fa4ItIzSyZA qm+NYPgU1Zd2O6BnbnGPuXyVlX9t6MrEmHP7sOL4pJr7cpnLusx3nX/7R5fy9LGABLdd fhh/utdIevdDZqJKJzTXnXiN+UkO8PDQyaBGk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wYNi81g+ZfeDXyjP8b+gWmzuzBaZK1htTUebMdHp7Ek=; b=jDnLynZlcoHRR8fNIfR03YwtcthZkBTiKCQCTSZ5J++W3wR8fYgnWlny0JeTxgSTF2 UMNdK3L2axWvhWH25CLXlHq2KhANsi9rkjD8OHW2BeubT3PFLt39OoKPjr9ARUTYKK3N 5nka0FuXuKkw/+f2H04m0czFojU0f1HXRFYAmSWq9XXG3VcSyUa5kUkWNAKQVwPXJXW3 NTcN4vCZzvzEX8Ywn4f6VtL444tV0M6vIZhsjZc+GaSlk3NCZFBA+zn8H7KLaKa9Txln cmnG+/TiBqxdy5C5KtjDDfAlP9IPFzs+R8Q59jCk/vXEijy9HwlWxUgDCcVhxa5FZW9P fBfA==
X-Gm-Message-State: ALoCoQlcvkwacBQb7/djBCKLSouVFcRy8F+BKmfquYKZ7qGaOrUCOh0KiWds7o5ocmhRDVImX0QT
MIME-Version: 1.0
X-Received: by with SMTP id d20mr21443695qkj.57.1446553152727; Tue, 03 Nov 2015 04:19:12 -0800 (PST)
Received: by with HTTP; Tue, 3 Nov 2015 04:19:12 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Tue, 3 Nov 2015 06:19:12 -0600
Message-ID: <>
From: Tom Ritter <>
To: "Neal H. Walfield" <>
Content-Type: multipart/alternative; boundary=001a11411122d141290523a1e647
Archived-At: <>
Cc: IETF OpenPGP <>
Subject: Re: [openpgp] Reducing the meta-data leak
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Nov 2015 12:19:15 -0000

On Tuesday, 3 November 2015, Neal H. Walfield <> wrote:

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