Re: [openpgp] Reducing the meta-data leak

vedaal@nym.hush.com Tue, 05 January 2016 19:50 UTC

Return-Path: <vedaal@nym.hush.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4759C1B2D51 for <openpgp@ietfa.amsl.com>; Tue, 5 Jan 2016 11:50:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.076
X-Spam-Level:
X-Spam-Status: No, score=-0.076 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKOBPviyRFWk for <openpgp@ietfa.amsl.com>; Tue, 5 Jan 2016 11:50:26 -0800 (PST)
Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219001B2D4E for <openpgp@ietf.org>; Tue, 5 Jan 2016 11:50:26 -0800 (PST)
Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 6F73F2020F for <openpgp@ietf.org>; Tue, 5 Jan 2016 19:50:25 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=e+ytzcYiNs7XkVZLljGbSct0NLL9VPV1sQcyE9bMw/U=; b=Nqd03qSnFZCi+dVFe5JFJPurh7SquUpq8LVlus5e5yu/UJSpFdrr7PiSiaswRDBEr1pziprziezgWXJHyExslb6aZrBz5Zl6NAfM/dgOWdl7GYezpJSuFB22lwTGXONgYqZKmFDtZMe2RwZ7jTO2gRTof8UYf8Xku55ZD9WW65oq09RVX5iyoxesgNMSs5mGct55oz6EmSG9Pycwv47VUdTg0JyI76MZh/0g6KhZjZakzxKJV9G+ZzLajo7BDWfcqgWTl2zWYUBw1yp/GrTkSLZa4mgxaOYzx+4Fr3hRBdB7aQtC2LlykFMwaQcUex/kUklHsie8UDPvFRw1/4gmKQ==
Received: from smtp.hushmail.com (w1.hushmail.com [65.39.178.83]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Tue, 5 Jan 2016 19:50:24 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id D3CC2200D0; Tue, 5 Jan 2016 19:50:24 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 05 Jan 2016 14:50:24 -0500
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Ben McGinnes <ben@adversary.org>, "Neal H. Walfield" <neal@walfield.org>, Derek Atkins <derek@ihtfp.com>
From: vedaal@nym.hush.com
In-Reply-To: <87d1tgzwi0.fsf@alice.fifthhorseman.net>
References: <87io5j764u.wl-neal@walfield.org> <sjm7flz9muf.fsf@securerf.ihtfp.org> <87h9l36tf1.wl-neal@walfield.org> <56874CB5.7060806@adversary.org> <87d1tgzwi0.fsf@alice.fifthhorseman.net>
Content-Type: multipart/alternative; boundary="=_79a28b169609dbce07cd0ef4b867a6c1"
Message-Id: <20160105195024.D3CC2200D0@smtp.hushmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/V1UJYf_NPBqkLAYLGY5ZCDP1Bac>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] Reducing the meta-data leak
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 19:50:27 -0000


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)

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

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