From: Eric_Weaver@avtc.sel.sony.com (Eric Weaver)
Date: Fri, 10 Jun 94 13:47:38 PDT
To: ravage@bga.com
Subject: back to programming projects...
In-Reply-To: <199406102033.PAA04147@zoom.bga.com>
Message-ID: <9406102047.AA01923@sosfc.avtc.sel.sony.com>
MIME-Version: 1.0
Content-Type: text/plain


   From: Jim choate <ravage@bga.com>
   Date: Fri, 10 Jun 1994 15:33:44 -0500 (CDT)

   [Sez Weaver:]
   > How about the sender encrypting with the REMAILER'S public key, and
   > the remailer sending out encrypted with its own private key?  That way
   > no registry is necessary.  If a sender doesn't trust the remailer,
   > let the sender sub-encrypt the message inside the remail headers.
   >

   I am not worried about their trusting me, I *don't* trust them...

   If the sender wants to encrypt that is fine. I will encrypt ALL outgoing
   with the recievers public key. Assuming the original reciever wants to
   reply the original sender will need a key in order for me to encrypt to
   them.

Please excuse my density, but against what are you defending by this
measure?  What don't you trust them about?

   > 
   > I hope some header field can be defined to specify a maximum delay,
   > and perhaps use the random number as a proportion of that maximum.
   >

   All messages will recieve a time stamp for transmission that will be no
   more than 24hrs away. The time stamp will be random. Until the clock 
   matches the stamp it sits encrypted w/ the recipients keys in a cache.
   Submitters will have no say in how long the message waits. If you want
   encryption and security you have to give something up. Besides if a user
   don't like the way I run it they don't have to use it.

True.  Then again, if it's your goal to provide something useful
that'll be used, well, a fixed 12-hour-average delay places a pretty
tight upper bound on usefulness.

   >    3. We intend to support anonymous as well as explicit addressing.
   > 
   > Could you amplify on this?
   >

   Yes, a sender will be able to designate whether they wish their return 
   accdress to be hidden behind an anon system or else we leave it on there
   relying on the encryption for security.

Cool.  Will it employ "anon handles" like some of the personals
remailers use?

   On the issue of traffic analysis:

   It occurs to me that simply monitoring a remailers feeds and their traffic
   analysis will provide enough information to determine the difference between
   bogus (ie random generated) and real traffic. While it may be possible for
   a sysadmin to make their systems traffic appear confusing *if* they don't 
   factor in their feeds traffic when a spook looks at not only the target 
   system but the feed systems and the traffic analysis on them you could
   determine to some degree of precision the amount and possible the actual
   bogus packets v the real traffic. Just a thought...

If I understood this properly, maybe you could scale back the
"Potemkin" traffic to level out the load.