Remailer REORDER not DELAY

Jim choate <ravage@bga.com> writes:

> 2. messages will be cached and re-transmitted after a random delay. I intend
>    to generate a random number between 0 and 24. When the appropriate hour
>    arrives all messages with that time stamp will be sent encrypted.
>    I would suggest getting a random number between 0 and 1440. This will

I waited for a good reply to this and didn't see one.  Smart people have 
commented on this before and no one in this round seems to be remembering.

Delay--time--isn't what matters.  It's confusion about which message is
which that matters.  So if I get 10 messages in one minute, I can scramble
the order and send them out the next minute, and I've done my job--at
least the order-scrambling part.  (You also need to pad or packetize
messages.)

So use serial numbers, not times!  Send a message for every one you get, 
keep a fixed number of messages queued, and add dummies if necessary
to keep things moving.

> On the issue of traffic analysis:
>
> It occurs to me that simply monitoring a remailers feeds and their traffic
> analysis will provide enough information to determine the difference between
> bogus (ie random generated) and real traffic...

Why not have the dummy message forwarded in a long enough chain and back to 
you?  Then you could swallow it or turn it into another dummy, depending on
whether you need to hurry your queue right now.

I don't think the amount of dummy traffic is a big problem.  You only need
enough to keep your queue flowing.  Plus, if the remailers only generate
dummies when necessary, the total dummy traffic is self-regulating, since
multi-hop dummies are x-lax for every remailer they pass through.

I like thinking about the traffic pattern with get-one-send-one remailers:
A user sends a message, and it seems to bounce from remailer to remailer
to remailer...to a final recipient--but no, it was all a shell game!

-fnerd




- - - - - - - - - - - - - - -
the snack that eats like a food
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
sRjLQs4iVVM=
=9wqs
-----END PGP SIGNATURE-----

> 
> Jim choate <ravage@bga.com> writes:
> 
> > 2. messages will be cached and re-transmitted after a random delay. I intend
> >    to generate a random number between 0 and 24. When the appropriate hour
> >    arrives all messages with that time stamp will be sent encrypted.
> >    I would suggest getting a random number between 0 and 1440. This will
> 
> I waited for a good reply to this and didn't see one.  Smart people have 
> commented on this before and no one in this round seems to be remembering.
> 
> Delay--time--isn't what matters.  It's confusion about which message is
> which that matters.  So if I get 10 messages in one minute, I can scramble
> the order and send them out the next minute, and I've done my job--at
> least the order-scrambling part.  (You also need to pad or packetize
> messages.)
> 
> So use serial numbers, not times!  Send a message for every one you get, 
> keep a fixed number of messages queued, and add dummies if necessary
> to keep things moving.
>
Wrongo...the random time stamp does randomly re-order then. As to bogus
messages, not on my system you won't....

I have a system which runs of a SLIP feed and bandwidth is sacrosanct.
If you would like to pay for an additional line to handle the added 
load then fine but my pocket book won't support it. And when one makes
the consideration of the future where there will be many small systems
with minimal bandwidth and monetary resources then I realy doubt they 
will be interested in any system which slows down or otherwise wastes
a precious and critical resource.

I also oppose the implied synchronicity of your methods as well. I am 
looking at a resonably secure asynchronouse method of making the 
traffic analysis difficult (the real reason for all this mumbo jumbo
in the first place). Why should I provide a potential monitor with the
information that a certain amount of information going out will be 
bogus? This also relates to my comments concerning the use of the other
'feed' systems around me.

> > On the issue of traffic analysis:
> >
> > It occurs to me that simply monitoring a remailers feeds and their traffic
> > analysis will provide enough information to determine the difference between
> > bogus (ie random generated) and real traffic...
> 
> Why not have the dummy message forwarded in a long enough chain and back to 
> you?  Then you could swallow it or turn it into another dummy, depending on
> whether you need to hurry your queue right now.
> 
> I don't think the amount of dummy traffic is a big problem.  You only need
> enough to keep your queue flowing.  Plus, if the remailers only generate
> dummies when necessary, the total dummy traffic is self-regulating, since
> multi-hop dummies are x-lax for every remailer they pass through.
> 
> I like thinking about the traffic pattern with get-one-send-one remailers:
> A user sends a message, and it seems to bounce from remailer to remailer
> to remailer...to a final recipient--but no, it was all a shell game!
>
You obviously don't pay all the costs for your feed or else you are very 
rich...


> -fnerd
> 
> 
> 
> 
> - - - - - - - - - - - - - - -
> the snack that eats like a food
> -----BEGIN PGP SIGNATURE-----
> Version: 2.3a
> 
> aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
> ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
> 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
> sRjLQs4iVVM=
> =9wqs
> -----END PGP SIGNATURE-----
>

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.

How about something like this:
   
 - The remailer is configured by its maintener with a maximum
   desireable time delay and a maximum desireable message queue size.
   People who do not like the values selected are free to shop
   elsewhere :-)
 - When a message arrives, it is assigned a latest output time based
   on the time that it is received, the remailers maximum desireable
   time delay and a random factor.
 - When the remailer's message queue size is greater its maximum
   desireable size, the message due to be sent next is sent regardless
   of its latest output time.
 - When a message's latest output time arrives, it is sent regardless
   of the remailers message queue size.

You might even want to have some other remailer configuration
parameters, like:
 - a maximum number of messages sent out during some arbitrary time
   interval (message/minute, e. g.)
 - a minimum interval between messages being sent.
These two examples might force the queue size to be considerably
larger than its maximum desired size during usage peaks.

None of this addresses a situation where a single message is received
during an arbitrarily long time period, although none of the other
proposals addresses that situation.  Although I can imagine how Mallet
might abuse this if he coudl control the remailer's net connection,
personally, I don't think that it's a problem that merits much
consideration.  In the absense of a suitably powerful Mallet or other
serious networking problems, it's likely that such a situation is just
an indication that the remailer isn't very popular.

BTW, what possible benefit is there to knowing that a particular
message was sent by a particular remailer?  As a recipient, should I
`trust' a remailer more than I trust, say, a digitial signature from
the sender?  Could someone describe a situation where this would
provide useful information?  In other words, why *not* simply encode
with the recepient's public key and restrict the usage of the
remailer's private to decoding incoming messages?

			Rick

Excerpts from internet.cypherpunks: 12-Jun-94 Re: Remailer REORDER not
DE.. by Rick Busdiecker@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@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/

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

Date: Tue, 14 Jun 1994 12:52:46 -0400 (EDT)
    From: Jeremiah A Blatz <darklord+@cmu.edu>
    
    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.

If the messages are been randomly ordered, you do not know this.
Angie's message could be the first message sent out after it is
received.  I was attempting to address the possibility of
unnecessarily long delays and message queue build up during a period
of high use.  During a low usage period, the scheme that I outlined
should act like the one that Jim choate outlined.

If there are long enough delays between messages, none of the proposed
schemes interferes with traffic monitoring.

			Rick