Remailer Reliability

[Samuel Pigg]

>>>>> On Fri, 3 Sep 1993 19:30:10 GMT, bill at 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 at 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 at cfraix.cfr.usf.edu
samp at renoir.cftnet.com        <or>       b44729 at achilles.ctd.anl.gov
PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C