Remailer traffic analysis foiling

Remailer hackers,

I've been thinking about the problem of traffic analysis of anonymous 
remailers and I have a question to pose to those of you whose thoughts on 
this topic are "more frequent or fully-formed".  

Would there be any advantage to giving remailers a MIRV capability?  

The idea goes like this:

The message arrives, the PGP wrapper is removed, the message is scanned 
for some specific token imbedded in the text (ala Matt Ghio's Cutmarks 
function).  That token is a divider between two outbound messages.  
These messages are sent along their respective ways.  The result is 
something like a 10K message coming in, and a 7K and a 3K message leaving.
If one of these goes to the bit bucket, it is like having added padding 
stripped off.  Alternately they each could be part of the real message, 
previously split and then sent via different paths to reduce chances of 
complete message interception.

I guess the issues involved are:

1)  How difficult would this be to code?  [Yeah, yeah "Cypherpunks write 
    code"(TM), but some of us write genetic code, not computer code :-)]

2)  What is the credible threat of traffic analysis?
	a)  Does multiplication of messages and their routing schemes create 
            problems of scale for these alleged eavesdropers?
        b)  Do you assume that if it's not a compromised server, that 
	    what goes on inside the machine is hidden? 

Now before the Zippos start flicking, I've followed the the latency vs. 
reordering argument, and accept that latency *may* acheive reordering, but 
not necessarily.  In this system though, different latencies after the 
split would seem to acheive something because without reliable size in/out 
information it would be harder to correlate message in with messages out.

Comments (incendiary or or otherwise) requested.
 
C. J. Leonard                     (    /      "DNA is groovy"
                                   \ /                - Watson & Crick
<cjl@welchlink.welch.jhu.edu>      / \     <--  major groove
                                  (    \
Finger for public key               \   )
Strong-arm for secret key             /    <--  minor groove
Thumb-screws for pass-phrase        /   )

On Wed, 3 Aug 1994, cjl wrote:

> Remailer hackers,
> 
> Would there be any advantage to giving remailers a MIRV capability?  
> 
> [deleted]

> I guess the issues involved are:
> 
[ deleted] 

> 2)  What is the credible threat of traffic analysis?
> 	a)  Does multiplication of messages and their routing schemes create 
>             problems of scale for these alleged eavesdropers?
>         b)  Do you assume that if it's not a compromised server, that 
> 	    what goes on inside the machine is hidden? 
> 

for total anon post/mail
How workable is setting up remailers with psudo-cooperation
so that when it recieves an anon mail it waits 20 or so min
and then randomly sends copies of it to 5 other remailers of which
the original reciever randomly decides which 1 of the 6 will post 
and the rest simply discard. 
  a 5 fold increase in traffic will make it harder to analize if
80% is just noise

Duct tape is like the force.  It has a light side, and a dark side, and
it holds the universe together ...
		-- Carl Zwanzig

On Wed, 3 Aug 1994, Jidan wrote:

> 
> for total anon post/mail
> How workable is setting up remailers with psudo-cooperation
> so that when it recieves an anon mail it waits 20 or so min
> and then randomly sends copies of it to 5 other remailers of which
> the original reciever randomly decides which 1 of the 6 will post 
> and the rest simply discard. 
>   a 5 fold increase in traffic will make it harder to analize if
> 80% is just noise

I think that sending many copies of the same message sounds like a good
way of making sure that it ends up being monitored by some 
alleged surveillance net.  Sending dummy messages is another matter. 

A fivefold increase in traffic may or may not have an impact on analysis, 
depending on your assumptions about the adversary's capabilities.  Anyway,
you still have a message of fixed size going in one end, coming out the 
other, and landing in someone's mailbox.  The superfluous messages may in 
fact be easy to identify if they are addressed to bit.bucket@dev.null.  

C. J. Leonard                     (    /      "DNA is groovy"
                                   \ /                - Watson & Crick
<cjl@welchlink.welch.jhu.edu>      / \     <--  major groove
                                  (    \
Finger for public key               \   )
Strong-arm for secret key             /    <--  minor groove
Thumb-screws for pass-phrase        /   )

Since it was posted twice I guess I can reply twice :-)

On Wed, 3 Aug 1994, Jidan wrote:
> for total anon post/mail
> How workable is setting up remailers with psudo-cooperation
> so that when it recieves an anon mail it waits 20 or so min
> and then randomly sends copies of it to 5 other remailers of which
> the original reciever randomly decides which 1 of the 6 will post 
> and the rest simply discard. 
>   a 5 fold increase in traffic will make it harder to analize if
> 80% is just noise

This scheme wouldn't be workable in the currently fragile and ephemeral 
net of remailers.  They would have to spend a lot of time talking to each 
other and making sure that they all had up-to-date lists of valid 
remailers.  That's too much of a burden to put on the net.philanthropists
that are currently operating mailing lists.

Any validation of a chained remailer pathway is up to the user (not 
exactly *caveat emptor* cause you ain't paying for anything, but you get 
the idea)

 
C. J. Leonard                     (    /      "DNA is groovy"
                                   \ /                - Watson & Crick
<cjl@welchlink.welch.jhu.edu>      / \     <--  major groove
                                  (    \
Finger for public key               \   )
Strong-arm for secret key             /    <--  minor groove
Thumb-screws for pass-phrase        /   )