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
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
Return to January 1993
Return to ““DrZaphod” <ncselxsi!drzaphod@ncselxsi.netcom.com>”
1993-01-22 (Thu, 21 Jan 93 20:47:20 PST) - Re: random remailers - “DrZaphod” <ncselxsi!drzaphod@ncselxsi.netcom.com>