1995-02-02 - No Subject

Header Data

From: <remail@desert.xs4all.nl>
To: cypherpunks@toad.com
Message Hash: 9615feb093d35dfe62069930b9419d554c22c9d082e6b626685f61f776269fa7
Message ID: <199502020308.AA13869@xs1.xs4all.nl>
Reply To: N/A
UTC Datetime: 1995-02-02 03:08:30 UTC
Raw Date: Wed, 1 Feb 95 19:08:30 PST

Raw message

From: <remail@desert.xs4all.nl>
Date: Wed, 1 Feb 95 19:08:30 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <199502020308.AA13869@xs1.xs4all.nl>
MIME-Version: 1.0
Content-Type: text/plain


##
Subject: Re: Frothing remailers - an immodest proposal
In-reply-to: <199502010520.VAA04884@largo.remailer.net> (eric@remailer.net)

> Date: Tue, 31 Jan 1995 21:20:28 -0800
> From: eric@remailer.net (Eric Hughes)
> 
>    In article <9501312152.AA10208@toad.com>,  <kevin@elvis.wicat.com> wrote:
>    >It seems to me that the current remailer web suffers a fundamental flaw.
>    >It is simply too static.
> 
> Now, dynamic rerouting is good for better delivery, but is bad for the
> trust in silence. [...] The end users must be involved, either directly or
> through some (legal) agent, in the manipulation of these relationships.
> 
> Any solution which tries to do this independent of the end user is
> broken, by definition.
> 
> Eric

  Well, pgp support multiple recipients of messages.  Supose that the
remailers would choose at random only one of the addresses the user
(or their client program) requested in a header line like:

Request-ND-Remailing-To: RM1@a.b.c, RM2@c.d.e, RM3@e.f.g

and try to deliver.  If the mail fails right away, then it tries
another address.  Etc.

  The very paranoid user would avoid this feature, and stick with the
old fashioned system.  The paranoid would list two remailers, and
encrypt the folowing message to both of them, and probably add a few
more levels to the chain, just to be sure.  The compleatly trusting
would only have two levels of remailing, but which listed every
remailer as a posible recipient of the message they send to the first
in the chain.

  In this way we get better reliability, but still have user control
over selecting the remailers.  In fact, the user can select arbitrary
message reliability, and remailer trust parameters, and should be able
to come up with a set of nd-hops to meet the parameters.

  Hey Wei, Hal: What is the cost of this in terms of likelyhood that
the whole path of remailers actually selected is compromised?  Is this
about right?  If 50% of the remailers are run by the enemy, then with
only one remailer listed in each hop, the odds of the path being
compromised is (.5)^h (where h is number of hops).  The odds of
successfull delivery are .90^h (asuming every remailer is 90% up).  If
at each step there were two remailers, and the evil remailers always
selected other co-operating evil remailers, then the odds of the path
being compromized is larger at ((1-.5^2)==.75)^(h).  But the odds of
sucessfull delivery are much better, (1-((1-.90)^2)==.99)^(h).  To
keep the same chance of the path being compromised, the user would
need to have 'x' times more hops where x is such that (.75)^x == .5,
or about 2.4 times as many.

  Hmmm...

  Noyb





Thread