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.