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