From: Jim choate <ravage@bga.com>
Date: Tue, 14 Jun 94 12:17:17 PDT
To: cypherpunks@toad.com
Subject: crypto-remailer traffic...
Message-ID: <199406141917.OAA17426@zoom.bga.com>
MIME-Version: 1.0
Content-Type: text


Hi all,

Sorry, due to a crash I lost the sender and original message but I did 
build a reply and will now post it. Hope this isn't too confusing.

On the baud rate issue:

The original position was that 10ea. 10k packets over 24hrs was 10 baud.
This is incorrect. The actual baud rate is:

    100k bits (10 10k packets)/5,184,000 sec. (1 day) = .02 baud
  
While the original assumption of no other activiy makes this seem like
a low cost method it is flawed. My system is intended to support a full
range of resources (and quite a few developed in-house) and it will have
more than this. Assuming that it was fully active we are actually looking
at paying for x bandwidth but only getting 1/10 x of useable bandwidth.
This is not economical to me when in the context of a SLIP (personaly I
would hesitate on a T1 or T3) feed. How many organizations can support a 
outlay of this amount? I suspect none.

Now on the packet count front:

Seems to me that if we are looking at a moderate to fully bandwidth limited
feed then what we are actually seeing is a small number of packets interspersed
with lots of other packets of all type. The simple re-order of the packets
on the out-going side should be sufficient since Mallet will have to look
at every packet anyway. With the above example we are looking at quite a 
signal to noise ratio (ie encrypted packet v all packets). I calculate it to
be on the order of-

     10k bits (1 packet)/ 74,649,600 bits (14.4k @ 24hrs) = 1.34E-4

This is a pretty small ratio and would stop most attacks unless one were using
a lot of Cray-acres...

As to the 24hr delay:

I understand and respect that some folks want instant access, I just see the
security as more important. By expanding the delay packet over 24hrs and not
a shorter period increases the amount of sheer data Mallet has to dig through.
I also suspect that if the sender can influence the delay, or if it is short,
they are looking at a reduced data set to analyze. I am attempting to use the
amount of information going out to hide the crypto-mail packets in a sheer
tide of info. 

Now for something completely different --

I will be using RX/V (A Unix SVR? clone) and was wondering if anyone has
used this OS? The users manual states it uses some form of DES for crypt().
Since I got the manuals today it may be a couple of days before I can really
answer in depth questions...

Thanks for all the input, much appreciated!

Take care all!

=