Re: Looking for code to run an encrypted mailing list
John Pettitt <jpp@software.net> wrote:
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.
At 09:24 PM 3/4/96 -0800, abostick@netcom.com (Alan Bostick) suggested having the mailing list handler decrypt the session key using its private key, and re-encrypt with the public keys of the list members, but not do the IDEA decryption and re-encryption N times of the message body. This has the further advantage that the cleartext message body is never sitting around on the server where it might end up in swap space or file system leftover blocks. On the other hand, it really only costs you one IDEA encryption if you want to use the multiple-recipients options to PGP. With the current PGP, this means you don't have to hack your own crypto code; the toolkits in PGP 3.0 will make that easier, though.
[I don't want all the list members to need to know every other list members public key]
The multiple-recipients PGP doesn't give away everyone's public keys, only their keyIDs. If you want to remain pseudonymous, just create a public key that you use only for subscribing to the list. (Hmmm - multiple recipient support probably makes stealth-PGP harder to implement...)
-----BEGIN PGP SIGNED MESSAGE----- In article <199603060542.VAA28896@ix9.ix.netcom.com>, Bill Stewart <stewarts@ix.netcom.com> wrote:
On the other hand, it really only costs you one IDEA encryption if you want to use the multiple-recipients options to PGP. With the current PGP, this means you don't have to hack your own crypto code; the toolkits in PGP 3.0 will make that easier, though.
True, and reasonable. Suppose, though, that the Cypherpunks list was encrypted in this way. There are about a thousand listmembers. Using one IDEA key and the multiple-recipients option would mean that the encrypted message would consist of a thousand RSA-encrypted session keys followed by the IDEA-encrypted cyphertext. If everyone used a 1024-bit-or-longer key pair, then each message would be a megabyte long! ( (m**P) mod n is going to be log2(n) bits long, right?) BTW, it was pointed out to me in private email that while vanilla RSA commutes, the PKCS-compliant RSA in PGP which pads the session key with random data does not, so that my nifty trick to never expose cleartext in the list processor wouldn't work. That's why I'm just a loudmouth blowhard and not a real cryptographer. ;-) - -- 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 iQB1AwUBMUB7v+VevBgtmhnpAQHKXwMAhcjT3R6hE8jtGBEY3uHZ7Y3cOycQEpXP dSQ2TsK27vYpCCjFBe3JauxLBBpM6yPqhPq8rSerNaQ7a8lhAWB4UwcUTwh9S7U3 PobslFhkFEwPd9jnZwY4g0ZZKb3iABIO =sLrM -----END PGP SIGNATURE-----
Hello, On Fri, 8 Mar 1996, Alan Bostick wrote:
Bill Stewart <stewarts@ix.netcom.com> wrote:
Suppose, though, that the Cypherpunks list was encrypted in this way. There are about a thousand listmembers. Using one IDEA key and the multiple-recipients option would mean that the encrypted message would consist of a thousand RSA-encrypted session keys followed by the IDEA-encrypted cyphertext. If everyone used a 1024-bit-or-longer key pair, then each message would be a megabyte long!
The way to do it is for the system (listserver) to have everyone's public key, and just encrypt every message for that person. If this isn't done already I could get around to writing the program to do this. ========================================================================== James Black (Comp Sci/Comp Eng sophomore) e-mail: black@eng.usf.edu http://www.eng.usf.edu/~black/index.html "An idea that is not dangerous is unworthy of being called an idea at all." Oscar Wilde **************************************************************************
participants (3)
-
abostick＠netcom.com -
Bill Stewart -
James Black (CS)