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
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp