1993-01-22 - Re: random remailers

Header Data

From: “DrZaphod” <ncselxsi!drzaphod@ncselxsi.netcom.com>
To: CypherPunks@toad.com
Message Hash: 70083bcfecceaf5b88d37a6408cb59a12ebe3b8d77932c9c7b4385920a801e8b
Message ID: <73148.drzaphod@ncselxsi>
Reply To: N/A
UTC Datetime: 1993-01-22 04:47:20 UTC
Raw Date: Thu, 21 Jan 93 20:47:20 PST

Raw message

From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Thu, 21 Jan 93 20:47:20 PST
To: CypherPunks@toad.com
Subject: Re: random remailers
Message-ID: <73148.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message Thu, 21 Jan 93 12:47:35 PST,
  Eric Messick <parallax.com!eric@netcomsv.netcom.com> writes:

>The problem with this is that every site along the way has to know the
>final delivery address, at least of this subset of the address chain.
>Better to just send it directly, and add some load balancing traffic.
>
>-eric messick

     What about letting every remailer see the second to last system in the
remailing process, another remailer.  Other remailers would route the
message around for a specified # of times +/- a small random # [users
choice with a max. limit set by remailers].  The second to last
remailer would recognize the last remailer from it's public key
encrypted message [::Request-Remailing-To: FinalDestination] and send
it on down to the last remailer which would decrypt the final remailing
block using it's secret key and send the intended message to it's final
destination.  This would provide random remailing routes without
compromising the ending not originating location.  The first remailer
wouldn't know if it had just received a message from a person, or another
remailer.  TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized





Thread