From: Jim Choate <ravage@ssz.com>
Date: Sat, 8 Jun 1996 13:39:19 +0800
To: cypherpunks@toad.com
Subject: Remailer thoughts
Message-ID: <199606080031.TAA04969@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text/plain



Hi Adam,

Forwarded message:

> From: Adam Shostack <adam@homeport.org>
> Subject: Re: Remailer chain length?
> Date: Tue, 4 Jun 1996 22:57:10 -0500 (EST)
> 
> Jim Choate wrote:
> 
> | > I don't think multiple remailers at the same site help anything.
> | > 
> | 
> | I agree completely. If traffic analysis is going to be done on a single box
> | it isn't going to matter how many remailers are there.  The monitor will
> | simply grab them all. At this point it simply maps them thusly:
> 
> |       incoming message > remailer #1 > .... > remailer #n > outgoing
> | 
> | 
> | That this really maps to is obvious:
> | 
> | 
> |       incoming message > remailer #1-#n > outgoing
> 
> 	Analyzing the traffic through three remailers is more
> difficult than analyzing the traffic through one.  One remailer with
> three N messages per day is more secure than an equivilant remailer
> with N mesasges.


Not if they are on the same box, simply treat the box itself as the
remailer. The internal mechanics are for the most part irrelevant to this
issue. N messages go in, N messages with (number of remailers)(# of cover
traffic/real message) messages of cover. My contention is that it does not
matter how many remailers are on a single box. It is the number of
connections in and out of the box available. The above equation is clearly
linear and therefore not what I would consider computationaly challenging.

If I may introduce some terminology (unless their is an existing stnd.),

x       number of messages
y       message multiplier
N#()    remailer number #
R#()    number of remailers on machine #
C()     number of cover messages/original messages
E#      number of connections on machine #
T()     total traffic through remailer system
$i()    cost per message, incoming
$o()    cost per message, outgoing
C       fixed cost items of operation (eg rent)

Note: each of these represent a family of functions.

My contention:

T(R#(n)) is equivalent to T(R#(N1(x), N2(x)..., Nn(x))) 

Where,

T() = R#(n)(2N#(x) + C(yN#(x)))

The term 2N#(x) represents the number of valid messages the remailer
handles. x incoming & x outgoing, hence 2x.

The total income of such a remailer:

$(T(x))=$i(x)-$o(T(x)-x)-C

It is important to recognize the profit dependancy on the input/output
message ratio. If it gets too high, you got nothing to spend on yourself.

Your contention (if I may translate):

N1(3x) is more secure than N1(x), assuming identical remailer configuration.

Do you consider N#(ax) equivalent to aN#(x)? May I inquire into your
reasoning?

> [much good thought deleted.]
> 
> |         5. Automaticaly limits spamming unless a remailer allows cloning
> |            AND all recipients share a commen private key.
> 
> 	Or unless the remailer mails to a mail to news gateway.

This is a limitation of the mail-news gateway and not of the remailer
technology. What it points to is a serious shortcoming in mail-news gateway
software. The technology required for truely efficient newsgroup handling is
something sorely in need of work.

> |         6. It maps 1:1 onto the physical remailer model with the same limits
> |            on information at each stage. This allows one to directly apply
> |            the current history of precedence involving anonymity and
> |            physical remailers.
> 
> 	With physical remailers, you can open the inner envelopes and
> read the message, leaving the end user to wonder where the post office
> lost the message.  With 'real' remailers, the lost message can't be
> read, only not delivered.

If the encryption technology is secure. The point I am making here is that
the encryption envelope is 'secure' only so long as nobody is trying to
crack it. Sooner or later somebody is going to decrypt your message, if not
the entire encryption system. This is synonymous with the physical model. The
paper envelope is secure as long as somebody isn't breaking the law by
tampering with the mail.
 
> | This is the basic model that the Austin Cypherpunks are working on at the
> | currrent time. The big problem we have right now is determining if the body
> | is actualy encrypted. We have done some basic tests of encryption-spoofing
> | using pgp and it is looks to be a thorny problem. It simply is not trivial
> | to look at a block of characters and determine if they are actualy
> | encrypted. You can't rely on the wrapper around the data put there by the
> 
> 	I'm not sure I see why this matters?  If you check that the
> message is not obviously readable, why not assume that its well
> encrypted?  You're rarely required to contort yourself to ensure your
> customers are obeying the law (weaponsmiths, cryptographers, and banks
> excepted.)  

Ok. Let's for a moment assume that to send a message to
'president@whitehouse.gov' with 'Die Bill!' is a crime. Would it not be a
crime to foil a packet of encryption by inserting 'Die Bill!' messages in
clear text in the encryption block? To date, provided no attempt at actual
decryption is attempted, there is nothing in the standards that prevent this
other than digital signatures. And again, a specific program has to be
executed. A person might very well look at it as plaintext w/o ever running
digital signatures (or they just assume its always right). Would this also
be a crime?

                                                      Jim Choate

       "Reality is observer dependant"
                              \
                                \   \\/////
                                    |     | 
                                    (.) (.)
      ===========================oOO==(_)==OOo==========================             

         Tivoli an IBM company                  CyberTects: SSZ
         Customer Support Engineer              SOHO Consulting/VR/Robotics

         9442 Capitol of Texas Highway North    1647 Rutland
         Suite 500                              #244  
         Austin, TX 78759                       Austin, TX  78758

         Email: jchoate@tivoli.com              Email: ravage@ssz.com
         Phone: (512) 436-8893                  Phone: (512) 259-2994
         Fax:   (512) 345-2784                  Fax: n/a
         WWW:   www.tivoli.com                  WWW: www.ssz.com
         Modem: n/a                             Modem: (512) 836-7374
         Pager: n/a                             Pager: n/a
         Cellular: n/a                          Cellular: n/a

      ===================================================================