1997-10-06 - Re: Risks of using usually-reliable information sources in your programs

Header Data

From: Andy Dustman <andy@CCMSD.chem.uga.edu>
To: Bill Stewart <stewarts@ix.netcom.com>
Message Hash: a4bdf2c622958547c610a40a26500846f92169880efcbe5aba19cc4028ea36c2
Message ID: <Pine.LNX.3.94.971006090219.11082Z-100000@neptune.chem.uga.edu>
Reply To: <3.0.3.32.19971005191732.00688c2c@popd.ix.netcom.com>
UTC Datetime: 1997-10-06 13:33:51 UTC
Raw Date: Mon, 6 Oct 1997 21:33:51 +0800

Raw message

From: Andy Dustman <andy@CCMSD.chem.uga.edu>
Date: Mon, 6 Oct 1997 21:33:51 +0800
To: Bill Stewart <stewarts@ix.netcom.com>
Subject: Re: Risks of using usually-reliable information sources in your  programs
In-Reply-To: <3.0.3.32.19971005191732.00688c2c@popd.ix.netcom.com>
Message-ID: <Pine.LNX.3.94.971006090219.11082Z-100000@neptune.chem.uga.edu>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

On Sun, 5 Oct 1997, Bill Stewart wrote:

> to pick the more reliable remailers based on "Raph"'s statistics,
> so adding records for very reliable bogus remailers is a win.

Incidentally, I think the patches I have for premail would probably
reduce the effects of an attack like this. It adds a
reliability-threshold and latency-threshold. Any remailer more reliable
than the reliability-threshold (recommended: 99.5%) is treated as if the 
uptime was 100%. Latencies lower than the latency threshold are treated
as zero. On a good day, this means there are several remailers which
will score exactly the same before the shuffling factor is added. The
four spook remailers listed would all score the same as squirrel and
bureau42, which have latencies exceeding 3 hrs:

recovery remailer@biglouie.fbi.gov        ############     0:01  99.99% @
payswell remailer@digicrime.com           ############     0:01  99.99% @
trustme  trustme@trustme.nsa.mil          ************     0:59  99.99% @
mulder   mulder@juno.com                  #*#*##*#*#*#     0:57  99.98% @
cracker  remailer@anon.efga.org           +*+*+***++*+    15:42  99.99% @
nym      config@nym.alias.net             **#**###****      :39  99.99%
jam      remailer@cypherpunks.ca          +*++*++++++*    22:24  99.98% @
redneck  config@anon.efga.org             ############      :37  99.98%
privacy  remailer@privacynb.ml.org            #*#*****     1:47  99.98% @
neva     remailer@neva.org                --+*-+**+**-  1:15:36  99.97% @
mix      mixmaster@remail.obscura.com     + -*********    40:27  99.83% @
winsock  winsock@rigel.cyberpass.net      -------..+-   9:45:21  99.79% %
squirrel mix@squirrel.owl.de              ------+--+-   3:04:59  99.74% @
bureau42 remailer@bureau42.ml.org         -----------   3:09:39  99.53% @
reno     middleman@cyberpass.net          +* *  + +++*    30:42  99.44% #
replay   remailer@replay.com              **** *   ***     4:01  99.00% #
hera     goddesshera@juno.com             ---- .------  5:18:04  97.77%
htuttle  h_tuttle@juno.com                ---- - ----+  3:02:37  97.49% #
arrid    arrid@juno.com                   -  -   -.--   9:23:33  81.91%
tea      tea@notatla.demon.co.uk            -          19:27:50   1.92%

@ = all score identically (not counting other bonuses from various config
    flags), 100% uptime, 0 latency
% = 100% uptime
# = 0 latency

See http://anon.efga.org/anon/premail.efga.patch. 

This is not why I came up with the patch. Originally I came up with the
reliability-threshold when I was running as a middleman and wanted to make
sure I was picking good remailers. I find that for chaining, chain lengths
of 1 and 2 tend to be somewhat slower on average than with standard
premail. However, longer chains tend to be significantly faster and even
more reliable. Check out http://anon.efga.org/anon/remailer-chains.html
and look at the distribution of remailers selected in chains, and compare
my random chain stats against Raph's. (I have a couple of remailers he
doesn't, AFAIK.)

> The security would be improved if Raph signed the weekly file,
> but that also requires people using the file to check it with PGP
> and not just grep out the relevant lines for their programs' use.

Agreed, but the danger from attack like this lies with automatic chaining
programs, where the user may not even be aware of what remailers are on
the list, or what remailers were chosen. A PGP-signed version would
improve things, particular if a special signing key is used, and that key
is stored in a separate keyring. This PGP-version may have to be available
separately from the regular remailer list to avoid confusing chaining
programs.

I'll see if I can whip up a PGP-signed version of the EFGA remailer list
by the end of the day.

Andy Dustman / Computational Center for Molecular Structure and Design / UGA
    To get my PGP public key, send me mail with subject "send file key".
For the ultimate anti-spam procmail recipe, send me mail with subject "spam"
"Encryption is too important to leave to the government."  -- Bruce Schneier
http://www.athens.net/~dustman   mailto:andy@CCMSD.chem.uga.edu       <}+++<


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQEPAwUBNDjmWxOPBZTHLz8dAQGjaAfPY9KOWVqyi6egyZqAxt+SOCCeWmfWTxvr
UUqWdT4NcdwH52jJnlflLsUZr6c2TtgGoYkXrltH+rzhTNWWGfTSuQgyshuNNRfP
Lk6W/y8bsaroFrFccME5vq4M+L9izQekosf+e1muu4X9tJKk5ksCS5bfOQaVLQum
ueouSvQOc3dmn4J64R5Wih6iMOrsYusqIj30Dz3SZFjOCbNb7VC66WdF/GafHItw
RJiRVZnOsT0igtqTe25ywO097fiGhwld4L2rOGjsLUag4vqbjaf+5NCGl3Dshq0C
fcmSPfYXGAvk3/ZxjSjQ2VE1OAEPvde4MiQrTj9PdvFflA==
=Xz3V
-----END PGP SIGNATURE-----






Thread