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