Re: Looking for code to run an encrypted mailing list

[abostick@netcom.com (Alan Bostick)]

-----BEGIN PGP SIGNED MESSAGE-----

In article <2.2.32.19960304053309.00bd5ec8@mail.software.net>,
John Pettitt <jpp@software.net> wrote:

> I'd like to run an encrypted mailing list  - the model I'm linking of is this ..
> 
> Poster cryptes mail with pgp using list exploder key. List exploder decrypts
> mail and recrypts with keys for all current list members and then sends the
> mail.
> 
> [I don't want all the list members to need to know every other list members
> public key]

Is this the right way to go about doing this?

If the mailing list has N members, then, for each message posted to the
list, the list processor must decrypt the message and then reencrypt it
N times.  If it is using PGP, that means:

(1) decrypting the incoming message's IDEA session key with the list
processor's RSA private key;

(2) decrypting the incoming message using the IDEA session key;

foreach $listmember (@mailinglist)
{
(3) generate an IDEA session key for message to listmember;

(4) encrypt the message with that IDEA session key;

(5) encrypt the session key with listmember's RSA public key;

(6) send the encrypted message and encrypted IDEA session key to listmember;
}

PGP does each encryption seamlessly . . . but in a large list, that's 
a lot of encryptions to do.  

It seem's to me that it would be more efficient simply to:

(1) decrypt the incoming message's IDEA session key using the list
processor's RSA private key;

foreach $listmember (@mailinglist)
{
(2) encrypt that same IDEA session key with listmember's RSA public key;

(3) send listmember the encrypted message and the encrypted IDEA session
key;
}

This saves one IDEA decryption and N IDEA encryptions of the message. 
It also saves the need to generate N random session keys, demanding 128N
bits of randomness from randseed.bin .

It means, however, that the list processing software couldn't use PGP, but
has to implement RSA public-key cryptography independently and
compatibly with PGP, so that listmembers could use PGP to encrypt and
decrypt list messages.

(That is, unless the API for PGP 3.0 will be sufficiently robust to
allow fancy session key management like this.)

According to Schneier, RSA is about 100 times slower than IDEA. (He says
it's 100 times slower than DES in software, and DES are about the same
speed.) The faster method still requires N RSA encryptions of the
128-byte session key.  Processing time is cut in half for a message of 
about 13kbytes' length; longer messages save more, shorter ones less.

And it occurs to me that, since RSA encryptions are commutative, the
list processor could encrypt the session key with the recipient's public
key *before* it decrypted it with its private key, so that the session
key is never available in cleartext to the list processor operator.

(Do pseudopunks write pseudocode? ;-) )

- -- 
   Alan Bostick             | "If I am to be held in contempt of court,
Seeking opportunity to      | your honor, it can only be because the court
develop multimedia content. | has acted contemptibly!"
Finger abostick@netcom.com for more info and PGP public key

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBMTvdZuVevBgtmhnpAQEEowMAuo9Z3t8lmE9SH0pSoTXeIIxjwqG/uWWQ
kSgichHXmun8X+q+wjRu7iGTaDF1WabvOXUIPOftjZgo7xN5MN5awbEgGmrCidXd
ClUQWX/qvH0h+IxcoSURsJOX8MFLMRlP
=0Cwo
-----END PGP SIGNATURE-----