1994-01-26 - Re: REMAIL: Cover traffic

Header Data

From: jim@bilbo.suite.com (Jim Miller)
To: cypherpunks@toad.com
Message Hash: 5622d15255067dc0eb9d4d8a8f05b40fd23a5178b3dc23809661862027cbf582
Message ID: <9401260539.AA08270@bilbo.suite.com>
Reply To: N/A
UTC Datetime: 1994-01-26 05:46:55 UTC
Raw Date: Tue, 25 Jan 94 21:46:55 PST

Raw message

From: jim@bilbo.suite.com (Jim Miller)
Date: Tue, 25 Jan 94 21:46:55 PST
To: cypherpunks@toad.com
Subject: Re: REMAIL: Cover traffic
Message-ID: <9401260539.AA08270@bilbo.suite.com>
MIME-Version: 1.0
Content-Type: text/plain



There's a subtle difference between the "send bogus messages thru random  
set of remailers back to yourself" protocol versus the "round-robin send  
bogus message to remailer peers" protocol.  I don't know if it matters,  
but it's worth pointing out.

In a simple round-robin protocol, bogus messages won't be contained within  
nested digital envelopes.  When a remailer receives a bogus message from  
one of its peers, it will unwrap the outermost digital envelope, and,  
walla, a bogus message.

You could modify the round-robin protocol to create more complex,  
multi-hop bogus messages (first hop is the next remailer peer, all other  
hops randomly chosen), but then your basically back to the first protocol.

Is it important that your remailer peers know when you send them bogus  
messages?  I suppose it depends on how many of your remailer peers are  
really operated by the Bad Guys.  <shrug>


Jim_Miller@suite.com






Thread