Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
1  
Private keys are not known by anyone except their owners! –  Deer Hunter Jan 5 '13 at 16:20
    
Sorry, I meant public key, Will edit that. –  asymmetric Jan 5 '13 at 16:27
    
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). –  Deer Hunter Jan 5 '13 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 '13 at 16:34
    
That's too dangerous. How would you securely deliver the keypair to all members of the list? –  Deer Hunter Jan 5 '13 at 16:37

1 Answer 1

up vote 7 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.