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
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
participants (5)
-
b44729＠achilles.ctd.anl.gov -
bill＠twwells.com -
cme＠ellisun.sw.stratus.com -
Eli Brandt -
Karl Lui Barrus