What is the best way to communicate privately on a mailing-list?

Requiring each member of the list to have the public key of each other member, and encrypt their messages with those, is cumbersome to the point of being useless.

On the other hand, using only one private key of which every member knows the password is unsafe and, ultimately, extremely problematic when one member leaves the ML - you have to change the list's private key, thereby making all previously encrypted messages unreadable.

I've seen there are some implementations of secure ML's, but in my case I have to use a hosted one (i.e. I cannot choose the ML software).

Any ideas?

  • What is your threat model? How valuable are past and current messages to you and to your adversaries? (BTW, para 3 still needs fixing, no need to know the password). Jan 5, 2013 at 16:31
  • Para 3 refers to the case where all members of the list know the password (and have a copy) of the list's private key, and use that keypair to encrypt/decrypt messages.
    – asymmetric
    Jan 5, 2013 at 16:34
  • That's too dangerous. How would you securely deliver the keypair to all members of the list? Jan 5, 2013 at 16:37
  • That's exactly my point.
    – asymmetric
    Jan 5, 2013 at 16:39
  • let us continue this discussion in chat Jan 5, 2013 at 16:40

2 Answers 2


When a secret is known by more than two or three people, it is no longer a secret, merely discreet. Any recipient of the mailing-list, by definition, can read all messages, hence he is trusted (in the sense of: he has the power to betray you). This limits your options.

With GnuPG, in your case, you can do any of the following:

  1. Have each recipient own a key pair, as is normal with GnuPG. Each message is encrypted with all users as recipients (the OpenPGP format supports that; size overhead will be a few hundred bytes per recipient, hence tolerable as long as there are less than a few hundred recipients). The mailing-list maintainer regularly sends the list of recipients over the mailing-list itself, so that every user can know the public keys of all recipients.

    This method is what maps best on what GnuPG inherently knows how to do. However, it has some drawbacks: size overhead (depending on the number of recipients), complex task for senders (not all GnuPG interfaces make it easy to send an email to dozens of recipients), publication of the list of recipients (every member of the list learns who else is a member).

  2. Do a relay. There again, each recipient owns a key pair. However, messages are sent with a single recipient (e.g. the mailing-list maintainer) who then forwards the message to all recipients. This makes it much easier for the end users, since they just send the messages to the mailing-list maintainer; and each relayed message can be encrypted for a single recipient at a time. This solves the issues of the previous method.

    However, it adds a few additional issues: extra latency (each message must wait for the maintainer to process it), increased vulnerability to censorship (the maintainer can block any message), more complex signatures (if the sender signs his message, the maintainer must wrap the signed message within the encryption for everybody else; this is allowed by the file format but some implementation might have some trouble processing that). Also, the maintainer himself has a lot of work or must use some automated tools which may or may not be available to him.

  3. Use a common password. Instead of using asymmetric key pairs, use symmetric encryption with a password that all recipients know. This is decentralized: to add a subscriber, it suffices to give him the password, and every subscriber can do that. The mailing-list itself can be replaced by any medium, even decentralized systems which will support a no-single-point-of-failure mode (for instance, Usenet). This scheme most closely resembles what was used by resistance networks during WWII (see Radio Londres for instance).

    The main problem with a common password is what I said at the beginning of this answer: a common password cannot be that secret.

Mixed strategies are possible. For instance, split your subscribers into cells, where the members of each cell know each other (and may share a common password or at least know each other's public keys), and know the public key of two or three people in "adjacent" cells. Messages are then relayed from cell to cell, with nobody knowing the full extent of the network. Such networks have historically proved robust with regards to infiltration and total collapse. See also this novel for an illustration. This might be a bit extreme in your case -- it really depends on your security model. Maybe your situation is not of the life threatening persuasion.


see also https://git.codecoop.org/schleuder/schleuder3/ this is a encrypted remailing list e.g. used by https://www.digitale-gesellschaft.ch/

  • Link only answers are as useful as the link is alive. Can you include the relevant details from the link in your answer? The OP is not looking for products to use but to understand a secure process.
    – schroeder
    Oct 16, 2016 at 7:15
  • Project moved to 0xacab.org/schleuder/schleuder Apr 11, 2018 at 11:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .