Schleuder: A GPG-enabled mailinglist with remailing-capabilities(schleuder.nadir.org)
schleuder.nadir.org
Schleuder: A GPG-enabled mailinglist with remailing-capabilities
https://schleuder.nadir.org/
19 comments
In theory there are alternatives where you do not need to trust the server. The keyword is proxy re-encryption (e.g. [SELS]).
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...
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...
> 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.
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.
The other benefit is that users can send to the list without the (possibly huge) administrative burden of getting a full and complete list of public keys for all subscribers. A similar setup is used for e.g. the (linux-)distros lists[0] at openwall for discussing embargoed security issues.
0: http://oss-security.openwall.org/wiki/mailing-lists/distros
0: http://oss-security.openwall.org/wiki/mailing-lists/distros
> once received, the content does not give away the key names of the other mailing list members
This doesn't present a problem, because you can construct anonymous group signature schemes.
This doesn't present a problem, because you can construct anonymous group signature schemes.
> 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.
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.
Absolutely agreed, I was speaking as a matter of theory :)
I'm interested in how non-subscribers are handled.
(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.)
(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.)
Should just be a patch for GNU Mailman.
schleuder is not a replacement for GNU Mailman, it does not contain all the features of GNU Mailman, while adding certain other features (e.g. remailing) that are not part of GNU Mailman.
GNU Mailman most certainly does remailing; something that doesn't do remailing can't be called a mailing list manager!
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".
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".
Please have a look at https://schleuder.nadir.org/docs/#an-email-hub-for-groups about the context here of remailing.
So correctly it should have been called resending.
So correctly it should have been called resending.
Funny you mention it, there's this (now dormant?) project that did extend Mailman to handle PGP and S/MIME.
https://non-gnu.uvt.nl/mailman-pgp-smime/
https://non-gnu.uvt.nl/mailman-pgp-smime/
Alternative software that does the same: https://fbb-git.github.io/gpg-remailer/
Schleuder can do more than gpg-remailer, e.g. resending messages to non-subscribers https://schleuder.nadir.org/docs/#an-email-hub-for-groups or actions triggered by keywords https://schleuder.nadir.org/docs/#special-keywords. It also has a web-interface to manage lists: https://0xacab.org/schleuder/schleuder-web/
gpg-remailer explicitly does not want to be a mailinglist, so it differentiates in multiple features (no mgmt of subscriptions of a list over list commands) nor does it have features like remailing capabilities.
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.