Qwerty Remailer Delays
It's not very clear how long the delays should be; depends on traffic to/from your remailer and to some extent to/from the other sites your remailer cooperates with and the machine it runs on. If the delay is near-zero, relative to the rest of your traffic, traffic-analysts can see mail going to your remailer, followed quickly by similar-sized mail going to another location, and guess that the two are related, especially if they're reading the mail itself. (For instance, if netcom is a bunch of machines on an Ethernet, and somebody breaks root on one of them, packet-sniffing the net may catch a non-trivial amount of your mail going in at least one direction. It's certainly easier than tapping all the phones if you don't have a warrant.) How much you need also depends on your threat model - do you expect monitoring by netcom users only, active monitoring by root, logfile examination without ongoing monitoring, etc....? If there are a bunch of other messages in between, especially if you're sending most of them to the same destination (e.g. instead of always choosing a random remailer to send through, you pick one remailer and send a batch of N messages to it; and maybe use a different remailer for the next batch) then it's harder to correlate incoming and outgoing messages. One strategy for batching is to accumulate N messages and send them at once, rather than delaying for N minutes. This may cause rather long delays, unless you either get lots of traffic or else give up and send the real message and some fake ones after rand{5..N} minutes. (If you use fixed N, it's easy to track when traffic is low.) Bill
It's not very clear how long the delays should be; depends on traffic to/from your remailer and to some extent to/from the other sites your remailer cooperates with and the machine it runs on.
If the delay is near-zero, relative to the rest of your traffic, traffic-analysts can see mail going to your remailer, followed quickly by similar-sized mail going to another location, and guess that the two are related, especially if they're reading the mail itself. (For instance, if netcom is a bunch of
I have an idea I don't think has been proposed before. There has been a lot of discussion of having "background noise" by having remailers mail random messages to various bit-buckets and other remailers on a constant basis. But why not do it this way. If a remailer recieves a message of size N, it holds that message for a short (< 15min) period of time, and then it sends out X (5 < rnd X <15) messages of size N, some going to remailers as noise messages, some going to bit buckets as dummy recipients, and of course one heading on it's origional route. One problem with this is that messages would multiply, ie. 'A' sends to remailer 'B' whichs sends 10 messages out, 5 to other remailers who in turn send out 10 messages a piece, 5 of which goes to other remailers who again multiply this. And you end up with one of those annoying commercials, where, he tells 5 friends, and they tell 5 friends until the network shuts down. So Remailers must establish some code (which would be send pgp encrypted) that would give a message a max possible life span of say 5-10 generations. (even that may be too much) Well it is just my $.02 (and Canadian cents at that!) Rob "Remeber, the day after tomorrow is the second day of the rest of your life." Unknown.
participants (2)
-
Rob P. Martin -
wcs＠anchor.ho.att.com