1998-01-19 - On the LAM–Local Area Mixes

Header Data

From: Tim May <tcmay@got.net>
To: cypherpunks@Algebra.COM
Message Hash: d52100bd6bb1c3893bb25472e6320f707a0bcac8f47fd3b34b5b30149ab8f655
Message ID: <v03102800b0e941b7b909@[207.167.93.63]>
Reply To: <19980119013252.18949@ulf.mali.sub.org>
UTC Datetime: 1998-01-19 19:22:42 UTC
Raw Date: Tue, 20 Jan 1998 03:22:42 +0800

Raw message

From: Tim May <tcmay@got.net>
Date: Tue, 20 Jan 1998 03:22:42 +0800
To: cypherpunks@Algebra.COM
Subject: On the LAM--Local Area Mixes
In-Reply-To: <19980119013252.18949@ulf.mali.sub.org>
Message-ID: <v03102800b0e941b7b909@[207.167.93.63]>
MIME-Version: 1.0
Content-Type: text/plain




SUMMARY

This post is about "lumping" of mix nodes to get a lot more mixing
bandwidth while also protecting against court-ordered seizures and
subpoenas. The idea is to have a dozen or more fairly cheap mix machines in
several apartments or offices connected with high-speed links, running
protocols not feasible over more expensive T1 and T3 sorts of links between
physically distant locations. Think of these concentrations as Local Areas
Mixes, or LAMs.


BACKGROUND

Early in the history of Cypherpunks, one of our schemes was to drastically
increase the number of nodes in the mix network by having many machines at
one physical site talking to each other at high speed over local networks.
A message would enter the physical site, bounce around to N machines, and
exit, perhaps going to other machines and sites, and back again, etc. (The
image was of perhaps 20 or 30 cheap PCs linked with Ethernet in a set of
apartments in Berkeley--obtaining search warrants or court orders to allow
monitoring of all 20 or 30 machines, scattered across several physical
addresses, would be "problematic.")

(This is still not a bad idea....lots of additional mixing entropy can be
gained this way, plus increased resistance against compromise of a single
remailer. Plus lots of headaches for any Scientologists or Christian
Crusaders or B'nai Brithers trying to shut down speech they don't like.)

Obviously, a list of machine names and public keys would have to be kept
current (modulo the frequency with which machines go down).  (BTW, how do
Mixmaster users actually decide which remaielers are reliable enough to
use? Or have the delays they wish? Do they use R. Levien's regular report,
or hit his URL?)


REMAILER MATH MODEL IS STILL LACKING

I don't believe anyone has publically analyzed "remailer math" in the
detail we would've expected by now. That is, analyzed the security (against
traceability) of having N nodes for M users communicating with remailers
having some operational model (number of messages in mix, "latency" (!),
etc.). We have commented for at least several years that this would make a
nice thesis for someone. I would've expected that this would by now be a
respectable research topic for "Crypto" papers.

(Much of the "analysis" of remailers has been of the seat-of-the-pants
type, with K mesages in a mix and  X bounces allgegedly leading to K ^ X
messages to be followed. But this analysis neglects correlation analysis of
sent/received messages, the pitiful number of messages flowing in the
overall network at any given time, and a bunch of other more subtle
effects. If Alice and Bob are using a remailer network to communicate, and
if an adversary has access to the packets flowing through the remailer
network--a big if--then statisical and probabalistic analysis can perhaps
reduce the entropies greatly. A better model is needed.)

Eric Hughes has expressed similar concerns, and presented a few tantalizing
details of how traceability can be extracted from mix networks using
Bayesian types of correlation analyses. (Alice and Bob being identified as
communicants through the patterns of sent and received packets, regardless
of the mixing between them.)

My reason for mentioning this here is that I think a more detailed analysis
of mix networks and the entropy and decorrelation seen would show the
advantages of having drastically more nodes, with various PipeNet and
BlackNet sorts of protocols running.


MAKING THE BEST USE OF BANDWIDTH

One of the motivations for the idea of having a lot of small machines at
some site is this: to reduce the network bandwidths needed for PipeNet
sorts of approaches.

Imagine this scenario. Concrete numbers are picked for easier visualization.

A set of offices in Berkeley has 20 low-cost machines running in 5 offices,
the offices being owned or leased by several organizations or individuals,
all legally separated. The 20 machines are all running either fixed
bandwidth (a la PipeNet) connections, or connections which never physically
leave the building and which can be inspected for taps. Additional
shielding of the cables might be a nice touch....optical fibers an even
nicer touch, as the tapping methods I know of require physical access to
the fiber, to do a tunnelling tap, or an actual break-and-splice. Ideally,
all or some of the boxes should be TEMPEST-protected, and/or
tamper-resistant.

I believe a sub-$500 cheap PC--with a 150 MHz Pentium--could be "hardened"
with $200 worth of additional copper or mu metal sheeting, placement inside
larger metal boxes, whatever. Or 10 such machines could cheaply be placed
in a locked Faraday cage, with a good lock on the door and video cameras
and such used for surveillance against black bag jobs. (*) In other words,
this network of mixes could be made very secure against nearly all
attackers. "All attackers" is a dangerous description, but I think the
costs of attacking the network undetectably could be made to cost a
prohibitive amount....

(* Though I tend to dislike PR stunts, imagine a "WebCam" aimed
continuously at this physical site, this Faraday cage, with a clock inside
ticking away, and maybe even a mechanical clock with clearly moving parts,
all so that an attacker could not easily spoof the image by replacing the
camera scene. This could generate interesting PR, as people "check the
security" of the site, and also get some education.)


MORE SUCH SUB-NETWORKS IN OTHER COUNTRIES

Now imagine the same sort of network of low-cost machines running in, say,
Amsterdam. With a fairly low bandwith connection to the Berkeley network.
(That is, not a leased line, just _regular_ usage of a normal link. For
example, a 100K packet attempted to be sent every 30 seconds or so, round
the clock. Exact details are not import...the idea being that external
watchers cannot detect patterns in the packet usage, a la PipeNet.)

There is, of course, no reason packets cannot also be bounced out to other
mixes, as selected by the user. And the sites in Berkeley and Amsterdam,
and elsewhere, may of course add their own bounces (as we all know, this is
always acceptable (*), and does not require the original sender to be
involved).  (* modulo reliability issues--if additional links are added,
they must not degrade overall realiability)

The original sender, Alice, of course will have complete say over the basic
routing, as it is she who selects the routing and constructs the chain of
encryptions. The idea of conglomerating mix nodes into physically close
spaces is not to take away any of her freedom to choose, but only to solve
the bandwidth and surveillance problems, by allowing her to bounce her
message amongst 20 machines in one site, bounce it to some remailers she
chooses, bounce it around to some sites she likes, and so on.


CHALLENGES FOR ATTACKERS

An attacker seeking to shut down the remailer sites will have a formidable
challenge:

-- court orders applicable to one apartment or office presumably will not
apply to other offices or addresses.

(Drug dealers often have stored drugs in one apartment while dealing them
from another, using a "rat line" to move the drugs between apartments. Last
I heard, search warrants cannot cover whatever sites raiders decide to
pick....this may've changed with the recent Supreme Court. In any case, a
"cyberspace rat line" can include wires snaking all throughout a large
building, making any search warrant focussed on a specific address or
person not applicable to sites in other parts of the building. Or in other
buildings completely (but still connected with high-bandwidth lines).

-- the machines in various locations should not have their locations noted.
(For example, the "Medusa mix" should not be identified, at least not in
general, as being upstairs in the Citizens for a Constitutional Process
offices. There is no "need to know" such things, and this makes
"propagation of search warrants" all the more problematic. )

-- the routing topology of the site may be an interesting area to look at.
Ideally, a "Linda"-like broadcast topology (all machines see all packets,
like messages in a bottle thrown into the "sea") could have certain
advantages, analogous completely to a message pool or Blacknet topology.

(This would make propagation of subpoenas vastly more difficult.)

-- again, in a physically close space, such high-bandwith methods are
easier to implement than in a physically spread out space (where bandwidth
costs a lot more).


RICO?

On the other hand, while ordinary subpoenas might be difficult to spread
across all of the machines, the clustering of many machines in one region
might be seen as a "conspiracy" to do something the Authorities don't like,
and thus be a RICO (Racketeer-Influenced and Corrupt Organizations, of
course) violation. It might be the Mother of all Steve Jackson Games Raids,
but one could imagine Unhappy Authorities seizing _all_ machines. (There
are aspects of the ECPA which may mitigate against this, though. A la the
Alcor case in Riverside, CA, 10 years ago.)


NEW TOPOLOGIES AND BETTER USE OF BANDWIDTH

Purists will point out that there is nothing that a network of N machines
in some physically close location cannot do that those same N machines
scattered in multiple legal and national jurisdictions cannot do just as
well.

Well, except for a few things:

A. Bandwidth. Local machines can be connected with PipeNet sorts of
connections, with vast amounts of cheap bandwidth.

B. Security against Tampering or Surveillance. While it may be possible for
NSA packet sniffers at major routing points to sniff mix traffic (recall
the work of Shimomura on sniffers, and the increasing concentration of
packets at the half dozen biggest network routing nodes, like MAE West),
local LANs are resistant to such sniffings. And to physical taps.  (These
dangers will be lessened if we ever get to where all machine to machine
traffic is routinely encrypted, a la SWAN, but we're not there yet by any
strech.)

C. New Topologies. Message pools, Linda-like "seas," and PipeNet are all
more feasible on such LAMs. As with the brain, which as multiple levels of
organization, an overall mix network consisting of subnetworks and
clusterings probably offers a richer set of behaviors than just one overall
loosely-couple set of mix nodes.

(I haven't mentioned this, but a LAM could be used for some very
high-bandwith mixing, like audio telephony and even video....modulo the
Alice-Bob correlation attacks I mentioned earlier.)


Anyway, I ought to stop for now. There are a lot more things to mention,
and issues to resolve.

But I think we need to once again consider such strategies. Having some
very high bandwidth "local mix networks" opens up some interesting
possibilities. Running PipeNet and BlackNet sorts of systems locally, for
example. Making issuance and serving of subpoenas very problematic, for
another example.

Your thoughts are welcome.

--Tim May



The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."








Thread