Schleuder: A GPG-enabled mailinglist with remailing-capabilities
schleuder.nadir.org
schleuder.nadir.org
I suppose if you know about that then it is ok.
The benefit of this approach over the alternative (making people encrypt and sign with a lot of keys) is that once received, the content does not give away the key names of the other mailing list members.
The other benefit is that membership management is a lot easier. Usually the first time you tell members to add or remove a key, things start falling apart quickly. Schleuder makes that easy.
0: http://oss-security.openwall.org/wiki/mailing-lists/distros
This doesn't present a problem, because you can construct anonymous group signature schemes.
Heh. In practice this is true, but only for sufficiently advanced values of "you". I certainly wouldn't feel comfortable attempting such a thing without consulting a real cryptographer.
On the other hand schleuder exists today and can be used by normal people (for example without having a custom private key per list, as you need afaik for [SELS]).
The other often overlooked fact about schleuder is that it's also a re-mailer. You can use it in a one-to-many setting, where the external party does only know the cryptographic key and email address of the list and a group of people can communicate with this person using schleuder as the proxy. This is a great alternative to shared mailboxes and a feature that is probably impossible with proxy encryption.
[SELS] https://slagell.info/Adam_J._Slagell/Past_Projects_files/khu...
(And, by the way, applaud the Schleuder project's recognition and support for that, since I believe that mailing lists should be easily usable by non-subscribers. This modern widespread phenomenon of lists insisting on subscription before you can post is deplorable, and raises the bar for people to report issues to FOSS projects and such.)
The traditional plain text mailing list handles non-subscribers simply via two mechanisms: the Cc: header, and the use of "Reply-All" by participants when they reply to the mailing list. So messages are going not just through the mailing list robot but directly between people, and that keeps non-subscribers in the loop for conversations that they started.
This direct reply mechanism can't work for the encrypted case, clearly. A direct reply requires that we have the key for that party. So it must be that the encrypted list manager goes out of its way to handle the non-subscribers. The message must be relayed with a "Reply-to" header set to the list, and the list must then remember that the conversation includes an outside party that must stay in the loop somehow. The robot must also have the public key of the non-subscriber.
So effectively, the non-subscriber must become an "effective subscriber" for the conversation that they started. The robot remembers that person in a membership-like list.
Or, perhaps a special header can be used as a cookie, storing the non-subscriber's pubkey. If all the conversation participants relay this header back to the robot reliably, it doesn't have to keep it anywhere. (And the robot can also sign that pubkey so it doesn't have to blindly trust that the members are relaying it correctly.)
It not only re-sends a message to list subscribers, but manipulates the headers and bodies. It can optionally add footers to bodies and alter Subject: lines.
It just won't decrypt messages with its own GPG key and then re-encrypt them for the recipients; it doesn't do "crypto remailing".
So correctly it should have been called resending.