1995-01-10 - Re: Data Haven problems

Header Data

From: pstemari@erinet.com (Paul J. Ste. Marie)
To: nesta@nesta.pr.mcs.net (Nesta Stubbs)
Message Hash: bdf49696e1c65b2379d5d36e0a647b9231175d46bc40001c72b1d1b24913d2be
Message ID: <9501100322.AB12220@eri.erinet.com>
Reply To: N/A
UTC Datetime: 1995-01-10 03:30:14 UTC
Raw Date: Mon, 9 Jan 95 19:30:14 PST

Raw message

From: pstemari@erinet.com (Paul J. Ste. Marie)
Date: Mon, 9 Jan 95 19:30:14 PST
To: nesta@nesta.pr.mcs.net (Nesta Stubbs)
Subject: Re: Data Haven problems
Message-ID: <9501100322.AB12220@eri.erinet.com>
MIME-Version: 1.0
Content-Type: text/plain


At 07:25 PM 1/9/95, dfloyd@io.com wrote:
> ... Of course, the DH will be hidden by a good remailer (anon.penet.fi), but
>it is trivial to use traffic analysis to find where the DH lies.  Just
>monitor traffic from/to the remailer and do a series of store/retrives.
>Then for confirmation, forge a mail from the dh site to the remailer with
>the password (obtained from sniffing) to yourself. ...

Hmm, hmm.  Using c'punk remailers with encrypted send blocks fixes one 
problem, especially if the c'punk mailers do some sort of file splitting and 
reassembly along the lines of what happens to IP packets that are too large 
for a given link.  What would also help would be a mechanism for randomly 
varying the encrypted send-to block.  The password replay attacks can be 
fixed by encrypting the transmitted password along with a timestamp/sequence 
number.

One problem that remains would be a trail left by the increased traffic 
to/from a DH vs a normal user.  That could only be fixed by a multitude of 
DH sites.

    --Paul J. Ste. Marie
      pstemari@well.sf.ca.us, pstemari@erinet.com






Thread