1995-01-26 - “Subway” remailers

Header Data

From: xpat@vm1.spcs.umn.edu
To: cypherpunks@toad.com
Message Hash: 27eb9356870011745ab99e9b1593725b6488d1e56fa56e072ee18b2603df4d0e
Message ID: <9501262213.AA23510@toad.com>
Reply To: N/A
UTC Datetime: 1995-01-26 22:13:45 UTC
Raw Date: Thu, 26 Jan 95 14:13:45 PST

Raw message

From: xpat@vm1.spcs.umn.edu
Date: Thu, 26 Jan 95 14:13:45 PST
To: cypherpunks@toad.com
Subject: "Subway" remailers
Message-ID: <9501262213.AA23510@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Need ideas/comments:

I have been modeling remailer scenarios using IBM VM/ESA virtual
machines. After fwaffing a bit, looking at the traffic analysis
concern, and taking note of some of the probability work posted
recently, I thought I might throw this idea out for a sanity check:

"Subway" remailers.

"Subway" remailers would exchange identical sized "containers", much
like a subway at semi-regular pulses or intervals. It would require
a ring of remailers large enough (yeah, I know) to make traffic analysis
of entrance and exit points difficult and/or expensive.

Each container would contain either fixed or variable slots for
multiple messages. Containers could be full, partially full, or
even empty. (there would probably have to be a max message size)

Subway remailers would be able to carry a message to a designated
"last" remailer or to deliver blindly to a "last" remailer of
random choosing.

Messages may or may not change containers at the various
stations/remailers. It could be randomized.

Possible header scripts:

X-Subway-Script: Ride 2; Latent: 03:30; Ride 3; Deliver;

or many other possibilities.

The whole container would be encrypted to the next remailer,
giving the next remailer the same access to exchange passengers
or to make them wait in a latent state.

The quirkier matters on this are how to handle PGP so that
nothing is compromised and for how the remailers to identify
each other as "friendly and operational" so the subway system
does not have a traffic jam.

Crypto comments please.

------------------------------------------------------------------
P M Dierking |





Thread