Re: Remailer Reliability

If you want reliability, you can take a page from the fault tolerance
business.  Replicate the remailers.  (There are many papers on this topic.
See, for example, ISIS from Cornell and Manetho from Rice.)

Example:

I send to r1 and r2.

Each of r1 and r2 sends to r3 and r4.

r3 and r4 each take the first message to arrive and drop the second.

at the end of the chain, you have rm and rn.

rm and rn each get the message (drop the second) and then decide between
them who gets to post it.  The one who gets to, does and tells the other
that it's all done -- at which time the other drops its copy.

Death detection is by time-out (but only rn and rm need to delay operation
until the time-out -- to prevent multiple postings from a split-brain
network.)

Expensive (4x the message traffic) -- but fault tolerant.

 - Carl

In article <9309031826.AA09137@ellisun.sw.stratus.com>,
Carl Ellison <cme@ellisun.sw.stratus.com> wrote:
: If you want reliability, you can take a page from the fault tolerance
: business.  Replicate the remailers.

If you're going to do that, why not go for extra security at the
same time? Instead of transmitting the same message to all of the
remailers, transmit different pieces to each and then reconstruct
the original from whatever pieces you get. Done right, this could
also be used to make traffic analysis harder.

>>>>> On Fri, 3 Sep 1993 19:30:10 GMT, bill@twwells.com (T. William Wells) said:

	bill> If you're going to do that, why not go for extra security at the
	bill> same time? Instead of transmitting the same message to all of the
	bill> remailers, transmit different pieces to each and then reconstruct
	bill> the original from whatever pieces you get. Done right, this could
	bill> also be used to make traffic analysis harder.


By breaking a message into pieces and sending them via different paths
to the same destination ("path forking"), this can only make traffic
analysis easier, because all the pieces lead to the same destination,
and you can follow any of them to get to the anonymous recipient.

But there *is* a way this could be useful: implementing a "kill message"
remailer command for pieces that have been forked off from the
original message. This way, a message could split itself into pieces
(or duplicate itself with a different header) and the attacker would
have to determine which one to try to follow to the recipient (or
follow them all), as only one will arrive there and the rest would die
after a number of remailer hops.

I really think that non-deterministic "smart messages" are the way to
go here. A simple command language for the remailers would allow
the header construction software already being worked on by
ebrandt@jarthur.Claremont.EDU (CRM) and others to use tricks
like this to defend against attacks. 
	The defense complexity would be a function of the users'
header construction software and needs. People who need "minimal"
anonymity would have simpler anonymous address blocks, as compared to
those who require "serious" anonymity, and the remailers themselves
would have a lighter load (not having to implement very serious
security for *all* messages-- just those that need it).
	"Smart messaging" would also have the added benefit of
not requiring the remailers to be constantly rewritten as new schemes
are conceived for foiling remailer attack (well, for the most part.)

Sam Pigg                                  dt1acaa@cfraix.cfr.usf.edu
samp@renoir.cftnet.com        <or>       b44729@achilles.ctd.anl.gov
PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C

> the header construction software already being worked on by
> ebrandt@jarthur.Claremont.EDU (CRM) and others to use tricks

Urk?

   Eli

Samuel Pigg wrote:
>go here. A simple command language for the remailers would allow
>the header construction software already being worked on by
>ebrandt@jarthur.Claremont.EDU (CRM) and others to use tricks
>like this to defend against attacks. 

??

Header construction software for unix and pc's has existed for months
and is available at soda.berkeley.edu

Granted, I'm waiting to validate three of the remailers so the scripts
are a bit out of date, especially the dos batch files...

--
Karl L. Barrus: klbarrus@owlnet.rice.edu         
keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5  3D F3 93 7E 81 B5 CC 32 

"One man's mnemonic is another man's cryptography" 
  - my compilers prof discussing file naming in public directories

>>>>> On Sun, 5 Sep 1993 11:14:48 -0500 (CDT), Karl Lui Barrus <klbarrus@owlnet.rice.edu> said:

	Karl> Samuel Pigg wrote:
>go here. A simple command language for the remailers would allow
>the header construction software already being worked on by
>ebrandt@jarthur.Claremont.EDU (CRM) and others to use tricks
>like this to defend against attacks. 

	Karl> ??

	Karl> Header construction software for unix and pc's has
	Karl> existed for months and is available at soda.berkeley.edu

	Karl> Granted, I'm waiting to validate three of the remailers
	Karl> so the scripts are a bit out of date, especially the dos
	Karl> batch files...

Ok.. I'll rewrite it:

>go here. A simple command language for the remailers would allow
>the header construction software already around to use tricks
>like this to defend against attacks. 

The point is that header contruction software would be able to use the
remailer command language in the header contruction to custom tailer
some of the defense against statistical and traffic based remailer
attacks.

Sam Pigg                                  dt1acaa@cfraix.cfr.usf.edu
samp@renoir.cftnet.com        <or>       b44729@achilles.ctd.anl.gov
PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C