Re: [openpgp] mailing list: managing the subscriber list

vedaal@nym.hush.com Wed, 13 January 2016 23:01 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 66C161A8833 for <openpgp@ietfa.amsl.com>; Wed, 13 Jan 2016 15:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.091
X-Spam-Level:
X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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=ham
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 crsPt-1im4TF for <openpgp@ietfa.amsl.com>; Wed, 13 Jan 2016 15:01:13 -0800 (PST)
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) (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 56E081A8831 for <openpgp@ietf.org>; Wed, 13 Jan 2016 15:01:13 -0800 (PST)
Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 9EF49E0259 for <openpgp@ietf.org>; Wed, 13 Jan 2016 23:01:12 +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=6XgkaSE+VKQzfQGnlSejhcr4Q+hjY5HTssHT8EGBD+U=; b=w9rExdlDjXNv3NKxoH+A+HKZWzcsSa0dxAkFDJVVejLMId40zCqnmkxc8IGC2Kb+Vdro9C/Bm3wiacbaNExUZWwmCIObxytRqZS6sbJEbXT0taJYjbZtQCW5f0vDKePGbN1oIbBjk3AU8mzx3AdhR5v2jtiZ3eU/i/wUDAvri1qHOC7RrEXiOwhCn3xnOMVD8FmGG8SDnMLxzaLh3Ck2k+B4YH0wm+3eLmzRqvHCXaS7cF5ZucHO1hYMBiQN7nRBnP/f8UePhGAoGV7KbqsLn8dTQxLsE3cm7RkwViShCos86iFDq4GfUCLrk0DSJGQGnRJ4j2G4avhDEpsjrbGtQg==
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 smtp3.hushmail.com (Postfix) with ESMTPS; Wed, 13 Jan 2016 23:01:12 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id 4F73920106; Wed, 13 Jan 2016 23:01:12 +0000 (UTC)
MIME-Version: 1.0
Date: Wed, 13 Jan 2016 18:01:12 -0500
To: "Neal H. Walfield" <neal@walfield.org>, Rick van Rein <rick@openfortress.nl>
From: vedaal@nym.hush.com
In-Reply-To: <87pox54hvh.wl-neal@walfield.org>
References: <87ziwd3yrn.wl-neal@walfield.org> <56938B98.7000707@openfortress.nl> <87r3hn4tw2.wl-neal@walfield.org> <56943997.1000001@openfortress.nl> <87pox54hvh.wl-neal@walfield.org>
Content-Type: multipart/alternative; boundary="=_f59a8a78ca9cb5ee3f53458f5000c456"
Message-Id: <20160113230112.4F73920106@smtp.hushmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/JLX3n2clT-mFuyMVY9fSf0wab5U>
Cc: openpgp@ietf.org, Matthew Green <matthewdgreen@gmail.com>
Subject: Re: [openpgp] mailing list: managing the subscriber list
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: Wed, 13 Jan 2016 23:01:15 -0000


On 1/13/2016 at 10:30 AM, "Neal H. Walfield"  wrote:...

I want to protect the subscriber list from passive observers, but the
message contents from active attackers (i.e., the same assurances that
OpenPGP can provide).

...

Again, a driving concern is backwards compatibility and, if I
understand your suggestion correctly, you are suggesting a
non-backwards compatible change.  Perhaps this extension is useful to
consider for 4880bis.
...

If I did, then I misstated my position.  I consider the system running
the mailing list software to be a potentially active adversary.
...

For the purposes of this exercise, I want to trust the mail server as
much as a normal OpenPGP user trusts an SMTP server.  Namely, an
OpenPGP user reveals the list of recipients to the SMTP server and
relies on the server to forward the encrypted message.

I realize that there are other approaches that reveal less meta-data,
but insofar as they exist today, they are not widely adopted.  I don't
want to say that those fights are not worth fighting, but I am looking
for a short-term solution that provides similar security guarantees
that OpenPGP provides for normal encrypted email.

> > The problem with reencryption algorithms is that a subscriber
can't
> > reuse her own secret key.  Instead, she gets a new secret key
(sent
> > via email, which she has to import) for each mailing list
> > subscription.

=====

What you want to accomplish, can be done, (at the expense of backward
compatibility), by allowing split-shared keys:

[1] You, (or the owner of any list using this),  has one
signing/certifiying master key with 'n' encryption subkeys, with the
ID name of the mailing list.

[2] For Encryption, the message is simultaneously encrypted to each of
the n encryption subkeys.

[3] For Decryption, only one share of any subkey, is needed.

[4] Each subscriber of the list is sent one share of one subkey,
encrypted to the subscriber's own keypair.

[5] If, for whatever reason, you distrust a particular subscriber of
'leaking' a share, you can revoke that subkey, and send a signed
notice to all subscribers, and generate a new subkey, signed by your
master key.

[6] No meta-data of the recipient, is leaked in any of the encrypted
messages.
[7] For further secrecy, 

(a) each recipient generates a 'throw-away' web-based e-mail.

(b) then generates a keypair with a with a bogus ID, and sends that
public key to the list for a share to be sent encrypted to this
'throw-away' e-mail address.

(c) the recipient then discards the throw-away e-mail address, and
generates a new one

(d) then asks to be subscribed to the new one, stating that he/she
already has a shared portion of the decryption key
 to this it, and that no share needs to be sent, just the messages
encrypted to the n subkeys.

(e) If all the recipients are instructed to wait after they have
received their 'share', and send their subscription requests to their
new e-mail addresses, all at some pre-arranged time, (e.g. a day
later), then their identity of the individual e-mail, is difficult to
trace to the specific subscriber.

[8] The determination of the 'n' of the 'n' subkeys, is a
cryptographic issue to which I don't know the answer.

I imagine that there is some minimum size of a 'share' below which it
is feasible to brute force the share, but since there is no limit to
the subkeys one can generate, it seems do-able to decide on a share of
'safe' size and proceed, (although the encrypted message can get
*really* bulky and long, if there are many many subscribers.)

[9] It can be made 'backward' compatible, for new subscribers, if 'n'
is large enough to simply just send a pre-existing  share as
subscribers are added.
just a possible suggestion ...
vedaal