From: Hal <hfinney@shell.portal.com>
To: cypherpunks@toad.com
Message Hash: f20848c58439bc17e3ef1405dd7019672e630144fe5e273b8b86be2ad3edd4a3
Message ID: <199510181642.JAA18712@jobe.shell.portal.com>
Reply To: <v02120d02acaa97afa587@DialupEudora>
UTC Datetime: 1995-10-18 16:43:43 UTC
Raw Date: Wed, 18 Oct 95 09:43:43 PDT
From: Hal <hfinney@shell.portal.com>
Date: Wed, 18 Oct 95 09:43:43 PDT
To: cypherpunks@toad.com
Subject: Re: Anonymity: A Modest Proposal
In-Reply-To: <v02120d02acaa97afa587@DialupEudora>
Message-ID: <199510181642.JAA18712@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain
tbyfield@panix.com (t byfield) writes:
> Well, when some folks want to circumvent this kind of last-link
>accountability (even if they are the _only_ link), they simply forge their
>headers--so why not incorporate that tactic into the remailer net?
I think a remailer which forged headers would get people even angrier
than one which was up front about what it was doing. Forging headers is
really considered antisocial by a lot of people on the net. If you could
do it safely, you wouldn't need remailers. Since you need them, it's not
safe, hence the message will probably get traced back to the remailer.
This is prima facie evidence to get an account yanked at a lot of places.
> Also, maybe apropos...It seems to me that there should be a way,
>within the remailer net, to synthesize forged-path strings with the "Human
>ID through insecure channel" remarks you made a few days ago.
The "human ID" thing requires a shared secret at both ends, which isn't
generally practical between a customer and a remailer. Also, it was
specific to the needs of human minds; if you have a computer and a shared
secret you do a lot better to use DES or IDEA (and let the shared secret
be the key), and even without a shared secret you can use public key
techniques for identification and authentication. So I don't think the
human ID approach would be relevant here.
Hal
Return to October 1995
Return to “tbyfield@panix.com (t byfield)”