1994-08-03 - Re: Remailer traffic analysis foiling

Header Data

From: sidney@taurus.apple.com (Sidney Markowitz)
To: cypherpunks@toad.com
Message Hash: 28aec0cf689bc68615de3d9ac72de866d28d038d6b6eb99205a16d0746824c0f
Message ID: <9408032242.AA06825@toad.com>
Reply To: N/A
UTC Datetime: 1994-08-03 22:43:20 UTC
Raw Date: Wed, 3 Aug 94 15:43:20 PDT

Raw message

From: sidney@taurus.apple.com (Sidney Markowitz)
Date: Wed, 3 Aug 94 15:43:20 PDT
To: cypherpunks@toad.com
Subject: Re: Remailer traffic analysis foiling
Message-ID: <9408032242.AA06825@toad.com>
MIME-Version: 1.0
Content-Type: text/plain

I was under the impression that remailers already allowed for multiple
messages with separate destinations to be batched in one message with
appropriate embedded demarcation headings.

How about if a remailer reordered incoming messages, batched groups of
messages, and sent the batches to different remailers for chaining? That
would achieve the effects on traffic analysis without multiplying traffic.

If you want to keep chaining strictly under the senders' control, the
batching could be done with messages that are marked by the sender as being
destined for chaining through the same remailer. But I don't like that as

Jonathan Rochkind suggested that the remailers could signal their
availability via posts to a special alt newsgroup. I think it would be
easier and more reliable if instead the remailers contacted each other
directly in some way to check for availabity. Perhaps they could listen on
some port, perhaps a finger daemon, anything that would let one remailer
ask another for some sort of status check. Automated chaining between
mailers that confirm availabilty before passing on messages would be more
reliable than a user choosing the entire chaining path before mailing off
the message. And it would allow the chained messages to be reordered and

 -- sidney <sidney@apple.com>