From: Jim Choate <ravage@ssz.com>
Date: Fri, 3 Oct 1997 11:12:35 +0800
To: cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Subject: Re: Remailers and ecash (fwd)
Message-ID: <199710030325.WAA29273@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text



Forwarded message:

> Date: Thu, 2 Oct 1997 11:33:00 -0400
> From: Anonymous <anon@anon.efga.org>
> Subject: Re: Remailers and ecash (fwd)

> Jim Choate:
> 
> >For the sender to chain from remailer to remailer to destination the
> >destination has to be in the header info somewhere. Now in the most secure
> >system each packet header will only contain the address of the next hop. When
> >the next site gets it the packet contents are de-crypted (otherwise reading
> >the chaining info is trivial) and the contents are uncovered to reveal another
> >packet with the next hop header and another encrypted block. And on and on
> >we go.
> >
> ><Question: Are there any remailer sets that impliment the encrypted nested
> >           packet system?>
> 
> Jim Choate has been amazingly clueless throughout this discussion, but
> this takes the cake.  Does he really not know about encrypted nested
> chaining?  My God!  Of course remailers work this way, Jim.  They've
> worked this way practically from the beginning.  All remailers work this
> way. 

No they don't, all remailers do not encrypt their outgoing as a matter of
course (do any currently do it as a matter of course? I would bet not if I
were a gambler). The remailer you used to send this didn't use encryption on
its outgoing or else I wouldn't be able to read it. The last time I looked
about a year ago the vast majority of remailers didn't encrypt their outgoing
traffic as a matter of course, it required the user to do it (I suspect this
is still true). Furthermore I specificaly used the word 'set' to mean a group
of remailers acting in concert such that this encryption happened
automaticaly - I know the answer already - No, there are no sets (ie a
cooperative network) of remailers (Mixmaster operaters included) implimenting
this unless the user goes to extreme and does it all themselves. As a matter
of fact there appears to be little to no cooperation between remailer
operators. There are no remailer key servers to manage the server and user
keys so the user must contact each remailer and obtain the key which is
itself open to traffic analysis, note that such first contacts by definition
have to be in the clear. Hope that Mallet starts their analysis AFTER you
get your keys or else. If this process can't occur automagicaly there is
little commercial utility for the system - it's too cumbersome.

> The mixmaster remailers are built around this idea, making each
> packet a constant size and adding dummy packets as new ones are stripped
> off, so outgoing messages look just like incoming ones.

First off, the size of the packets in no way effects the succes of a traffic
analysis, only a cryptanalysis of their contents. Traffic analysis looks at
four things: the incoming packet header, the outgoing packet header, and
the times of receipt and transmission.

The idea behind latency is that if it is chosen correctly and the packet
re-transmission falls outside the analysis window there is no way to
correlate the incoming and outgoing traffic. From the analysis engines
perspective the events are distinct and non-related. Simply re-ordering the
packets at re-transmission time does nothing if I set the window larger than
the time it takes to resend the original traffic and the cover traffic.
Setting the analysis window to infinity also causes the analysis overhead to
grow quickly though this means that re-ordering and latency are irrelevant.

A party implimenting traffic analysis is probably not going to look at the
contents until they have a clear understanding of the traffic flow between
the surveiled parties. At that point it is cheaper to look at the involved
parties and see if one of them has a weakness that can be exploited (ie
offer immunity to a herion addict) over doing actual expensive
cryptanalysis. If you can subvert a member you are in the classic
man-in-the-middle position.

When the Austin Cpunks looked at Mixmaster about 1.5 years ago for several
months it became clear that as implimented currently Mixmaster can't easily
support public remailer key servers or automated non-user-involved chaining
and processing (encryption & decryption). Shure the packets look the same,
but unless you as the sender go in and manage that material you are shit out
of luck. The remailers can't do it themselves without user intervention,
that's economicly not viable.

> ><speculation: an encrypted chain could be made stronger if the next
> >              hop header depended on which key was used to decode it.
> >              In other words, remailer A's key will produce one next hop
> >              address while remailer B's key will send it elsewhere. This
> >              is a subset of the different plaintext - same cyphertext
> >              problem - a hard problem as I understand it. Find two
> >              distinct texts that encrypt with different keys to the
> >              same cyphertext>
> 
> That won't help.  There would be no point in doing this.  I'd ask you
> to explain, but that would just prolong the agony.

It is actualy quite simple why you would want to do this. You could then in
effect send the same packet (identical in every bit) to a set of remailers.
Each remailer would then decode the packet and send it on. All but one would
go to bogus addresses and the one remailer with the right key would get to
resend to the next remailer(s). Plus none of the outgoing traffic would be
to the same server, further complicating analysis. This also gives the user
some control over how much cover traffic gets generated. However Mallet
doesn't know which packets are which and therefore must follow every packet.
This multiplies the number of hops in the traffic analysis that need to be
analyzed. As mentioned in one of my previous posts, in this situation the
complexity goes up by a power causing the required computing resources to
trace the traffic to quickly become excessive.

Sine this is so painful for you, I assume this is the end of this
discussion.


    ____________________________________________________________________
   |                                                                    |
   |    The financial policy of the welfare state requires that there   |
   |    be no way for the owners of wealth to protect themselves.       |
   |                                                                    |
   |                                       -Alan Greenspan-             |
   |                                                                    | 
   |            _____                             The Armadillo Group   |
   |         ,::////;::-.                           Austin, Tx. USA     |
   |        /:'///// ``::>/|/                     http:// www.ssz.com/  |
   |      .',  ||||    `/( e\                                           |
   |  -====~~mm-'`-```-mm --'-                         Jim Choate       |
   |                                                 ravage@ssz.com     |
   |                                                  512-451-7087      |
   |____________________________________________________________________|