remailer multiple paths?
Is there any value to the idea of breaking up a message and sending the parts of it by different "remailer paths" to the ultimate recipient? Shouldn't this reduce the risk of remailer compromise as much or more than simply nesting remailers? You'd need a good way of breaking up the message; if you were encrypting already, it'd probably do well enough to put byte x into message (x mod n) where you're sending n messages. (You could even slice it at the bit level, but that's a little harder to do in a trivial script...) Or would you? is breaking up the message at all good enough, or is it necessary that "nothing of value" can be produced from the pieces? Haven't thought this through, but perhaps others here have. (The concept could even be used with an anonymous pool, sort of a "collect the whole set!" type of reading mechanism...) It could be argued that the various binary.pictures groups are already run this way :-) _Mark_ <eichin@paycheck.cygnus.com> ... just me at home ...
From: "Mark W. Eichin" <eichin@paycheck.cygnus.com> You'd need a good way of breaking up the message; if you were encrypting already, it'd probably do well enough to put byte x into message (x mod n) where you're sending n messages. (You could even slice it at the bit level, but that's a little harder to do in a trivial script...)
It would be easy enough to split the message by XOR into as many pieces as you wish. This would be much more secure than an every-nth-byte division, though it would increase total traffic correspondingly. Taking into account the non-ideality of the remailer net, using m-of-n secret sharing would be more reliable. It's not clear to me that this buys you much, though. Encrypting the message end-to-end will suffice to keep it private. What remailers do for you is impede traffic analysis. Sending your message in n pieces gives a traffic watcher n chances. Eli ebrandt@jarthur.claremont.edu
participants (2)
-
Eli Brandt -
Mark W. Eichin