GPG-encrypted mailing list and other approaches to safe communication

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.