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.