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

Header Data

From: mcb@net.bio.net (Michael C. Berch)
To: cypherpunks@toad.com
Message Hash: f52838438b4a79c89e389d3397db17513e0105c67892d2a530d0c21bf3235c2b
Message ID: <9401250656.AA11078@net.bio.net>
Reply To: N/A
UTC Datetime: 1994-01-25 07:06:45 UTC
Raw Date: Mon, 24 Jan 94 23:06:45 PST

Raw message

From: mcb@net.bio.net (Michael C. Berch)
Date: Mon, 24 Jan 94 23:06:45 PST
To: cypherpunks@toad.com
Subject: Re: REMAIL: Cover traffic
Message-ID: <9401250656.AA11078@net.bio.net>
MIME-Version: 1.0
Content-Type: text/plain


Jim Miller writes:
> > only one to leave the network.  If the Opponent has the ability to
> > monitor all traffic into and out of all nodes of the network (as he
> > would have to do anyway to defeat remailers even without this cover
> > traffic) then he will easily be able to find the messages which are not
> > aimed at other remailers.
> 
> How about extending the "send bogus messages" idea all the way out to the  
> users of the remailer system?  Part of the price of using the remailer  
> system is that you will occasionally receive a bogus message.

I was thinking about digital mix and defeating traffic analysis and
realized that the perfect cover for private messages exchanged among
remailers -- at least on the Internet -- is to multiplex them into a
netnews feed.  

You would need a new transport protocol that basically handles an
encrypted news feed and turns it back into normal NNTP/RFC1036 on the
far end, while diverting private mail messages to the appropriate
remailing software.

If remailers were on large site servers that were set up as news hubs,
there would already be a large amount of traffic between any pair of
them; insert the private traffic and encrypt/slice/dice the result.
This is a low-cost solution since the news has to flow somehow anyway
and it is better than just sending around random garbage.

--
Michael C. Berch
mcb@net.bio.net / mcb@postmodern.com





Thread