On Mon 2015-07-20 12:02:42 +0200, Neal H. Walfield wrote:
There are two possibilities here.
First, the mailing list software reencrypts the message. This means
that the plaintext is handled on the server and that either the
private key material is directly on the server or it is on a smartcard
permanently attached to the server. In the former case, the key
material can be stolen and in the later case, an attacker can send out
fake messages until the break-in is discovered. This implies absolute
trust in the provider. These issues limit the applicability of this
solution.
I think the goal of an attacker in most scenarios isn't key recovery,
but cleartext recovery. an attack on the remailer service doesn't need
access to the key even if it's on a smartcard, they just want to
compromise the server enough to read the messages after the server
decrypts and before it encrypts.
The other possibility is that each poster encrypts to all recipients.
This works, but has horrible management issues. In particular, the
posters need to synchronize the list of subscribers and keys. This is
not easy. There is another management problem as well, which is less
obvious. The mailing list participants might want the list of
recipients to be hidden. In GnuPG, this is done using the
--hidden-recipient option. In this case, the public-key encrypted
session key packets don't contain the recipients' keyids. Making sure
all posters remember to use this option is hard. This is also not
scalable: the recipients will need to decrypt (on average) half of the
public-key encrypted session key packets before they find the packet
for them.
This approach is clunky, and i agree that your approach is superior to
it for key management. however, both of these approaches also leak the
size of the subscriber list (as well as historical join and leave dates)
in the public keyring. if they're re-using their normal
encryption-capable subkeys (or if they have User IDs attached) then
anyone who has access to the list's OpenPGP certificate is going to know
who all of the subscribers are.
There is a third approach, though, which is that used by PSELS:
http://sels.ncsa.illinois.edu/about.html
http://www.ncsa.illinois.edu/People/hkhurana/ICICS.pdf
I haven't seen anyone re-tread this idea to use more modern crypto, but
i think it might work.
The idea is (roughly, from memory) that you're using some sort of
discrete-log-based encryption key (e.g. el gamal, encryption-capable
ECC), and the list has a public key. All correspondence to the list is
encrypted to the list's public key.
The (human, offline) mailing list manager knows a secret key for the
list, and when a new subscriber joins, the manager issues the new
subscriber a personalized secret key that has a specific randomized
offset from the list's secret key, and tells the list server the
subscriber's address, public key, and their offset from the list's key.
The (automated) mailing list server doesn't know the list's secret
material, but it knows the offset between all subscribers' public keys
and the encryption key, and modifies the message so that the subscriber
can decrypt it.
unsubscribe happens by removing the address and the offset from the
mailing list server. End users send encrypted mail exactly as they
currently do, and the automated server never sees the cleartext.
one chokepoint in this system is certainly the mailing list manager, who
has access to the secret key material; but this is no different from
your proposal, where whoever has access to the list's primary key has
the same powers.
In the PSELS approach, if any subscriber can collude with the list
server, i think they can jointly reassemble the list's secret key, which
is an additional risk, i think. though any subscriber on their own
already has the content of all the messages, so i'm not sure how
important the risk is.
Of course, none of this avoids the problem of a large "private" list
actually having the security of the weakest link in the group :/
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp