From: snow <snow@smoke.suba.com>
Date: Tue, 1 Oct 1996 08:49:49 +0800
To: stewarts@ix.netcom.com (Bill Stewart)
Subject: Re: Making Remailers Widespread [REMAILERS]
In-Reply-To: <199609290623.XAA25604@dfw-ix3.ix.netcom.com>
Message-ID: <199609301757.MAA00328@smoke.suba.com>
MIME-Version: 1.0
Content-Type: text


Mr. Stewart said:
> I agree, it's a problem; the return address seems to reduce abuse.
> But one-way remailers can be used to simulate many of the uses of two-way,
> especially with message-pool return methods (e.g. alt.anonymous.messages.)
> Doing two-way remailers well is hard - most of the methods around are ok
> for passive attacks, but may not resist subpoenas, rubber-hose, or crackers.
> It's especially hard if you want the remailer to be a no-brainer to install
> and operate, rather than one that requires expert support.
> Snow's one-shot reply block method is interesting, whether you do a public-key
> or secret-key approach (if you do public key, you obviously use the public
> half for the part that stays at the remailer.)  It has the real advantage that
> compromising the remailer doesn't give you the reply information for past or
> current messages, so you can only compromise one message at a time,
> which is a big win over the one-key-per-remailer reply blocks.
> I think I like it.
> On the other hand, there are a host of potential problems:
> - Chaining is probably more difficult, at least return-chaining.

     Each reply refers to the remailer before it. 

     The originating web site hands the originator a key and a pseudo-random
ID. The originator can check check back on a regular basis to see if a reply
came back in. That way there is no "final trail" and the reciepent can 
view the page thru something like www.anonymizer.com. 


> - Individual True Believer remailer operators would usually resist
> cooperating with authorities to decrypt the reply block, but ad-hoc
> remailer operators who are just running a remailer because they haven't
> turned off the default feature that came with their Web Server
> will probably reveal the key, especially for Politically Incorrect material
> (definition depends on their individual politics, of course.)

     Set a time limit on replies (say 5 days) and after the 5 days, the 
reply is deleted by the server. That way the casual user would have 
to hack the code to _keep_ the addresses on hand, and the censors would 
have to get back thru the entire chain in 5 days, and they don't know the
entire chain to begin with. If you can get the web server spread out 
internationally, that ain't gonna happen. 

> - A web form interface, filled out from a web anonymizer, doesn't
> give you a useful return address, so spammers can still abuse it.

     If you inert the *this is an anonymous email* automaticaly, this 
won't matter as much. Commercial spammers will have to put a 
commercial access point (phone, fax, email address) in their message
and people who are just harassing others will get deleted pretty quick.

     Spam itself will be cut back as you only allow <x> number of 
addresses per message, and set it up so that you enter the addresses
on a seperate page from the message. That way to hit 2 or 3 hundered 
email addresses you have to enter the message 100 times. Ok, so cut and
paste 100 times, but if the spammer has a brain (I know, but there 
may be one or two) they are going get the spam out. 


     How about this (It is a little complicated, so it may not work)


     Alice wants to send email to Bob, so she hit's sameers anonmymizer
site to go to a random remailer web site. 

     At this site she enters Bobs email address on one page, and on the
next enters her message. This message could even be encrypted, assuming that
Bob knows what to do with it. Hit send.

     The webremailer software hands Alice a temporary (10 day expire time) 
ID and key/passphrase.

     The webremailer selects the next mailer in the chain, encrypts the 
message, writes the public key and encrypted message to disk (with 
date stamp), and forwards the email (encrypted message + key) to the next 
remailer. 
 
     The second (and each succeeding remailer in the chain) simply re-writes
the headers and writes a keyid/previous-remailer pair file (with date stamp)
to file. (maybe even keep a single database file with this info in it, 
a single file might not get written to disk as often (maybe) and with constant
would be marginally harder to "recover" old addresses from than multiple hard
files (or would it?) and then sends the mail on.

    If we can use the "puts" feature, we really don't need much in the way of
headers right?

    Anyway the last remailer in the chain writes a simple web page with the 
keyid of the keypair, and simply sends the key and an address to the receipent
so that 1) the final "message" is still not the email, only a notice that 
email is waiting, for instance http://www.encodex.com/anonmail/id0x4556/
 
    The reciepient then goes to the site (or doesn't if they don't want
email) they can use www.anonymizer.com if they wish, and they enter their key
when prompted. The encrypted file is then decrypted and sent to them.

    At this point, the encryption is more to prevent the "prying eyes" than 
TLA level snooping, so it has to be good, but it doesn't have to be 2000 bit
RSA type stuff. That can be done at the message level. 

    Return messages would include the keyid of the sent message, and would 
retrace the same hops. At the original end, a simple web page is written
and a "you have a reply to your anonymous message at http://www.encodex.com
/anonmail/id0x99a4/ 

    Holes?

Petro, Christopher C.
petro@suba.com <prefered for any non-list stuff>
snow@smoke.suba.com