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
- [openpgp] mailing list: managing the subscriber l… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… Rick van Rein
- Re: [openpgp] mailing list: managing the subscrib… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… Rick van Rein
- Re: [openpgp] mailing list: managing the subscrib… Werner Koch
- Re: [openpgp] mailing list: managing the subscrib… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… Neal H. Walfield
- Re: [openpgp] mailing list: managing the subscrib… vedaal
- Re: [openpgp] mailing list: managing the subscrib… Phillip Hallam-Baker