[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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