6 ms·

Schleuder: A GPG-enabled mailinglist with remailing-capabilities

81 points by cvwright 9y ago

dijit 9y ago
Kinda cool but it depends on you trusting the central mailer since it does decryption and reencryption. 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.
- lgierth 9y ago
  > 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.
- dice 9y ago
  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 http://oss-security.openwall.org/wiki/mailing-lists/distros
- dsacco 9y ago
  > 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.
  - cvwright 9y ago
    > 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.
    - dsacco 9y ago
      Absolutely agreed, I was speaking as a matter of theory :)
- o- 9y ago
  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/khurana05a.pdf https://slagell.info/Adam_J._Slagell/Past_Projects_files/khu...
MarianaTrench 9y ago
This sounds great. I'm not sure how it'd work exactly though. They just have a list of everyone's public keys?
lgierth 9y ago
I've been using schleuder through various mailing lists over the past years, it's always been doing what it says on the tin :)
- noloblo 9y ago
  is there a list I can subscribe to how to find a schleuder or gpg enabled list ?
clishem 9y ago
Alternative software that does the same: https://fbb-git.github.io/gpg-remailer/ https://fbb-git.github.io/gpg-remailer/
- mirabubu 9y ago
  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.
- fupd 9y ago
  Schleuder can do more than gpg-remailer, e.g. resending messages to non-subscribers https://schleuder.nadir.org/docs/#an-email-hub-for-groups https://schleuder.nadir.org/docs/#an-email-hub-for-groups or actions triggered by keywords https://schleuder.nadir.org/docs/#special-keywords https://schleuder.nadir.org/docs/#special-keywords. It also has a web-interface to manage lists: https://0xacab.org/schleuder/schleuder-web/ https://0xacab.org/schleuder/schleuder-web/
kazinator 9y ago
Should just be a patch for GNU Mailman.
- cvwright 9y ago
  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/
- mirabubu 9y ago
  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.
  - kazinator 9y ago
    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".
    - mirabubu 9y ago
      Please have a look at https://schleuder.nadir.org/docs/#an-email-hub-for-groups https://schleuder.nadir.org/docs/#an-email-hub-for-groups about the context here of remailing. So correctly it should have been called resending.
kazinator 9y ago
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.)

81 points by cvwright 9y ago

Kinda cool but it depends on you trusting the central mailer since it does decryption and reencryption. 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.

lgierth 9y ago
> 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.
dice 9y ago
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 http://oss-security.openwall.org/wiki/mailing-lists/distros
dsacco 9y ago
> 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.
- cvwright 9y ago
  > 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.
  - dsacco 9y ago
    Absolutely agreed, I was speaking as a matter of theory :)
o- 9y ago
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/khurana05a.pdf https://slagell.info/Adam_J._Slagell/Past_Projects_files/khu...

MarianaTrench 9y ago

This sounds great. I'm not sure how it'd work exactly though. They just have a list of everyone's public keys?

lgierth 9y ago

I've been using schleuder through various mailing lists over the past years, it's always been doing what it says on the tin :)

noloblo 9y ago
is there a list I can subscribe to how to find a schleuder or gpg enabled list ?

clishem 9y ago

Alternative software that does the same: https://fbb-git.github.io/gpg-remailer/ https://fbb-git.github.io/gpg-remailer/

mirabubu 9y ago
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.
fupd 9y ago
Schleuder can do more than gpg-remailer, e.g. resending messages to non-subscribers https://schleuder.nadir.org/docs/#an-email-hub-for-groups https://schleuder.nadir.org/docs/#an-email-hub-for-groups or actions triggered by keywords https://schleuder.nadir.org/docs/#special-keywords https://schleuder.nadir.org/docs/#special-keywords. It also has a web-interface to manage lists: https://0xacab.org/schleuder/schleuder-web/ https://0xacab.org/schleuder/schleuder-web/

kazinator 9y ago

Should just be a patch for GNU Mailman.

cvwright 9y ago
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/
mirabubu 9y ago
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.
- kazinator 9y ago
  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".
  - mirabubu 9y ago
    Please have a look at https://schleuder.nadir.org/docs/#an-email-hub-for-groups https://schleuder.nadir.org/docs/#an-email-hub-for-groups about the context here of remailing. So correctly it should have been called resending.

kazinator 9y ago

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.)