"Subway" remailers

[xpat@vm1.spcs.umn.edu]

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 |