From: jthomas@coconut.mitre.org (Joe Thomas)
Date: Fri, 16 Apr 93 09:27:24 PDT
To: cypherpunks@toad.com
Subject: Proposal for anon chaining
Message-ID: <9304161626.AA02630@coconut>
MIME-Version: 1.0
Content-Type: text/plain


KINNEY WILLIAM H <kinney@spot.colorado.edu> writes:

> Recent traffic on anonymous remailers/servers:
> 

> >From:  Eli   <ebrandt@jarthur.claremont.edu>
> >> From: Hal <74076.1041@CompuServe.COM>
> >> This method of posting does not allow you to receive replies.  I  
have set
> >> "nicknames" for these two accounts as "Untraceable account"  
which will appear
> > >in the "From" line on the postings.  Hopefully that will offer a  
clue that
> > >the normal reply mechanism doesn't work.  Maybe the nickname  
should say so
> >> more explicitly?
> >
> >
> >The security provided by this technique could be provided without
> >the IMHO serious disadvantage of having no return address.  Eric's
> >hybrid approach, where a pseudonym server hands mail to an  
remailer
> >chain, is secure (barring sophisticated traffic analysis) if you
> >trust the last remailer in the chain.  Julf, have you thought  
about
> >whether you want to do something like this?
> 

> > Hal
> 

> Here's an idea I haven't seen suggested before, which would remove  
the need
> for a pseudonym server:
> 

> [Description of chain-encrypted header info, separated from message  
text]
> 

> This seems to me to be a very robust pseudonymous mail system which 

> could be implemented by relatively minor changes to the existing  
Cypherpunk 

> remailer structure. It has the additional advantage of being  
decentralized 

> and maintenance-free.  It could be used for pseudonyms on net news,  
e-mail, 

> wherever, and could presumably be integrated in some way into  
Julf's 

> anon server.
> 

Yes, this would seem to be the way to do this, and this type of  
nested-encrypted routing information is what I was referring to as an  
"SASE" in my front-end/back-end anonymous posting design.  There are  
some drawbacks, however.

Traffic analysis by watching a remailer's feed, and seeing messages  
come in and go back out is much easier, since the message _text_ is  
unchanged from one remailer to the next.  In fact, however, such  
traffic analysis is not difficult with the present system, since  
message lengths can be used to correlate messages going in and out,  
and the remailers aren't getting enough traffic to do much internal  
"mixing" to avoid obvious FIFO behavior.  The obvious solutions are a  
remailing protocol that supports padding out messages to a few  
"standard" lengths, and increasing the remailer traffic, perhaps with  
dummy messages.

But this doesn't help in the above case, when routing information is  
separate from message text, and not known to the sender (except for  
the first hop).  One possible solution relies on the fact that each  
remailer must know the next hop a message will take.  When the  
remailer is forwarding mail with separately encrypted header  
information, it will append some random bits to the message, then  
encrypt it with the next remailer's public key.  (Note that if the  
appending of random bits is skipped, the system provides no security  
against traffic analysis, since the adversary can simply try  
encrypting incoming messages with various remailers' public keys,  
then watch to see if that message comes back out).

I've got some more ambitious ideas for this (encrypted return  
addresses as a MIME content-type?), but I think the version outlined  
above could be implemented pretty easily, although I admit I haven't  
really read through the remailer scripts.  I'll take a crack at it as  
soon as I get my Linux box (a couple weeks) if people think it's a  
good idea.

Joe