[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Risks of using usually-reliable information sources in your programs
-----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 [email protected] ############ 0:01 99.99% @
payswell [email protected] ############ 0:01 99.99% @
trustme [email protected] ************ 0:59 99.99% @
mulder [email protected] #*#*##*#*#*# 0:57 99.98% @
cracker [email protected] +*+*+***++*+ 15:42 99.99% @
nym [email protected] **#**###**** :39 99.99%
jam [email protected] +*++*++++++* 22:24 99.98% @
redneck [email protected] ############ :37 99.98%
privacy [email protected] #*#***** 1:47 99.98% @
neva [email protected] --+*-+**+**- 1:15:36 99.97% @
mix [email protected] + -********* 40:27 99.83% @
winsock [email protected] -------..+- 9:45:21 99.79% %
squirrel [email protected] ------+--+- 3:04:59 99.74% @
bureau42 [email protected] ----------- 3:09:39 99.53% @
reno [email protected] +* * + +++* 30:42 99.44% #
replay [email protected] **** * *** 4:01 99.00% #
hera [email protected] ---- .------ 5:18:04 97.77%
htuttle [email protected] ---- - ----+ 3:02:37 97.49% #
arrid [email protected] - - -.-- 9:23:33 81.91%
tea [email protected] - 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:[email protected] <}+++<
-----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-----