1994-06-14 - Re: Remailer REORDER not DELAY

Header Data

From: Jim choate <ravage@bga.com>
To: darklord+@CMU.EDU (Jeremiah A Blatz)
Message Hash: ce126fc0de7904eb8dff59f9e8bd56ebe035a9f378c865bfb3e6039a416cf31b
Message ID: <199406141856.NAA16253@zoom.bga.com>
Reply To: <QhzS1SG00iV0I3ap9f@andrew.cmu.edu>
UTC Datetime: 1994-06-14 18:57:39 UTC
Raw Date: Tue, 14 Jun 94 11:57:39 PDT

Raw message

From: Jim choate <ravage@bga.com>
Date: Tue, 14 Jun 94 11:57:39 PDT
To: darklord+@CMU.EDU (Jeremiah A Blatz)
Subject: Re: Remailer REORDER not DELAY
In-Reply-To: <QhzS1SG00iV0I3ap9f@andrew.cmu.edu>
Message-ID: <199406141856.NAA16253@zoom.bga.com>
MIME-Version: 1.0
Content-Type: text


> 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/
> 





Thread