REMAIL: Cover traffic
Several people have suggested that the remailers could send bogus messages amongst themselves in order to allow more "confusion and diffusion" of the other messages passing through the remailer network. The remailers could then batch up incoming messages fairly frequently and still have many messages in a batch. The problem with this that I see is that, looking at the remailer network as a whole, you still may have one message in and one message out a short while later. The fact that it was temporarily mixed up with a bunch of other messages doesn't help much if this message is the only one to leave the network. If the Opponent has the ability to monitor all traffic into and out of all nodes of the network (as he would have to do anyway to defeat remailers even without this cover traffic) then he will easily be able to find the messages which are not aimed at other remailers. For cover traffic to be useful, it would have to be indistinguishable from real traffic as it enters and leaves the network. So messages aimed at known "bit bucket" addresses, or at a few cooperating individuals who accept and discard incoming addresses (the same thing, really) will not help. Hal
Hal Finney on sending noise messages:
The fact that it was temporarily mixed up with a bunch of other messages doesn't help much if this message is the only one to leave the network.
This is still a big win, since it expands the traffic analyst's task from determining what goes in and out of a single remailer to what goes in and out of the entire network. The per-remailer traffic, for now and in the forseeable future, is too small to effectively mix traffic at that level; but traffic across the entire network may soon be sufficient for that. We get a reasonable digital mix with over an order of magnitude less real traffic by using noise messages. My biggest current concern as an individual, or potential business remailer user, is not some super-duper netwide traffic analysis by giga-bureaucracies that have much bigger fish to worry about than myself; it is rather is the _manual_ tracking of message via hacking of remailer sites or collusion by remailers, who seem to all log their messages. If I was to send out a message I really wanted hidden right now, I would generate quite a bit of noise to go along with it, so that the easy _manual_ tracking of messages that can practically occur now would be foiled.
Message aimed at known "bit bucket" addresses, or at a few cooperating individuals who accept and discard incoming addresses (the same thing, really) will not help.
Sure they will. Every bit bucket address adds another node that the opponent must monitor; most opponents will quickly be overwhelmed by the task of sniffing out just a few bit-bucket PCs on private "Little Garden" style networks. Most folks who make serious use of remailers (with nested-encryption scripts, etc.) can also easily set themselves up as bit-bucket addresses. Realistic-looking accounts can be set up at many sites and used as nothing but bit buckets. (Remailer users can of course use real addresses at bit buckets right now, but this is rather rude!) Noise messages and bit-bucket addresses may not be theoretically interesting, but the provide major practical improvements. I challenge cypherpunks to come up with designs for actual software to distinguish quantized noise messages from real messages that can realistically be implemented on the Internet, not just scenarios that an extremely strong organization could theoretically implement, by expending vastly much more effort than remailer users and operators. Nick Szabo szabo@netcom.com
participants (2)
-
Hal -
szabo@netcom.com