Remailer REORDER not DELAY

[Jeremiah A Blatz]

Excerpts from internet.cypherpunks: 12-Jun-94 Re: Remailer REORDER not
DE.. by Rick Busdiecker at lehman.c 
> I think that there's a reasonable compromise in here somewhere.  It
> might even address some other concerns that people could have about
> the costs of running remailers, e. g. storing a zillion messages for
> 24 hours.

[scheme to send out messages in pseud0-randon spurts deleted]

I belive the problem is that you can trace a message back to its source
by anazyzing when the messages are sent. Let's say you're watching
Angie's net connection because you think she is guilty of Thoughtcrime.
At 12:34, Andie sends an encrypted message to soda. Say that soda hasn't
received any messages for 5 hours before 10:14, then receives 4 between
10:15 and the time Angie's mailer connects to port 25 of soda's
remailer. You wait until soda spits out 4 messages, then the 5th is
Angie's. You do this through the entire remailer chani, and when Angie's
message gets to its destination, you can see it, and trace it back to
her.

This is bad.

Now, if soda had queued a few messages, then spit them out in random
order in random chuinks, traffic analysis would be much less effective.

For examples of how evil traffic analysis can be, just watch a few
episodes of Deep Space Nine. I shudder whenever Otto says "Quark, you
have sent 5 messages to the Romulan high command this week." or whatever.

Jer

darklord at cmu.edu | "it's not a matter of rights  / it's just a matter of war
finger me for my |  don't have a reason to fight / they never had one before"
   Geek Code and |                                    -Ministry, "Hero"
  PGP public key | http://www.cs.cmu.edu:8001/afs/andrew.cmu.edu/usr25/jbde/