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.
You can also tell it comes from the remailer because it is encrypted to allow you to verify exactly this. I am not interested in hiding the path information, I *want* to certify where it came from - *not* who(!) is sending it or *what* is in it. I can see not knowing or being able to prove the pathway as a possible hole for interjecting bogus packets. Now, about this re-sending issue. If I rcv. a packet at 10am and it gets a random time-stamp there is no guarantee when it will be sent other than within 24hrs. It may or may not be sent in the 5 hr. gap in your example, no way to know really.
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.
The random order is what does it, not the # of packets sent out. the randomness in leaving the site is more important than how many.
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.
Excuse me?.....DS9?...
Jer
darklord@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/