-----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-----