Encrypted MLs

[Fred Lindberg]

On Tue, 28 Apr 1998 08:54:30 +0200, Werner Koch wrote:

>Yes, this might make some sense.  But to do stream processing, the
>message should be encrypted first and stored in a file - may be it
>is better that gpg handles this and outputs several complete messages -
>to different files or with a special delimiter to stdout.

i was thinking of:

PASSPHRASE=`cat passphrase`
gpg --skip_addresses_with_not_trusted_keys \
	--decrypt --verify --sign_with_key_ID:123 --reencrypt --keyfile
addresses.txt \
	--output_to storage.file --format crude_non_armored < orignal
encrypted(signed(message)) > storage.file
switch ($?)
  case 0: ok
  case 1: bad_encryption
  case 2: bad_signature
  case 3: passphrase_doesn_t_work
  ...
  case 99: unknown fatal error

make mail messages from storage.file.
erase storage.file
---------

PASSPHRASE is the passphrase for decryption = signature

addresses.txt has user addresses = userids (ezmlm could have a database
doing address -> userid translation
this _could_ be piped in using a fd other than stdin. ezmlm could also
have the keyID in this db.

The "action" options would be in order. --verify would possibly put the
userID into the environment. An error message could go to and be
captured from stderr. This all would allow handling messages in a
pipeline without ever externalizing the clear text.

It assumes that the private key and pass phrase is secret. The list
could have a mechanism that generates a new /dev/urandom-based pass
phrase for the key at random intervals (not while gpg is running). This
way, deletion of the passphrase file would make all communication to
the list unreadable.

An option might be to keep the sender signature intact (when anonymity
of sender is not important and it is important to recipients to know
that the list has not tampered with the message contents.

The mailing list program would be responsible for rebuilding messages
from the crude gpg 1x(encrypted-message), n x (pub-key encrypted
session key block).

>A problem is how to handle addresses which have not enough trust
>assigned; normally a user interaction is required.  

A moderator checks all subscriptions and signs keys. Another part of
the list assures that only subscriber keys that are signed by a
moderator are accepted. If there are userIDs in addresses.txt with keys
that haven't been signed by a moderator, those userIDs are ignored.

Moderator signatures would in turn be trusted only if signed by other
moderators, but that would be added on later. Alternatively: Anyone
with access to the list key and passphrase can read messages, knows
recipients, etc. Thus, one might require only that moderator keys are
signed by the list key. I don't know what's best here, but it seems
that one has to assume that the list-computer is secure for anything at
all to work.


-Sincerely, Fred

(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)