On Wed, Jul 22, 2015 at 1:30 AM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net>
wrote:
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.
I was playing with a similar approach, it translates fine into any DH
system in any group (and you want to do DH in a group...).
This is another consequence of the DH key multiplication capability I will
be presenting an application of in CFRG later today. DH is actually a much
more interesting cipher system than RSA as far as 'exotic' approaches go.
If we have a Right private key R and a Left private key L, we can derive a
Joint key J as follows:
J = R+L
e^J = e^R . e^L
Further, if we perform the computations in a finite group it can be shown
that knowledge of e^R and e^L does not provide any information about J
unless knowledge of e^R discloses R (in which case DH is broken in that
group anyway).
The thing is that this is only a way to avoid the need to store the private
key for the mailing list on the system. Everything else is completely
unchanged. The end users can use their regular DH key.
This is a very very useful property and one that the folk doing PERC should
probably be looking at.
It isn't one that has any impact on OpenPGP (or S/MIME) because it can be
implemented regardless of the base spec. The only constraint being that the
mailing list members use a DH based key.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp