From: don@cs.byu.edu
To: cypherpunks@toad.com
Message Hash: 033ae9d17b094aff83e899ce7d70bff810a119d3e066535007e3d2b85efbe67c
Message ID: <199509071832.MAA00480@wero.byu.edu>
Reply To: N/A
UTC Datetime: 1995-09-08 02:58:18 UTC
Raw Date: Thu, 7 Sep 95 19:58:18 PDT
From: don@cs.byu.edu
Date: Thu, 7 Sep 95 19:58:18 PDT
To: cypherpunks@toad.com
Subject: Announce: Web of Trust Ring
Message-ID: <199509071832.MAA00480@wero.byu.edu>
MIME-Version: 1.0
Content-Type: text/plain
-----BEGIN PGP SIGNED MESSAGE-----
WEB OF TRUST KEYRING GENERATION PROJECT
I have completed my project to make a condensed version of the keyserver
PGP keyrings, containing only the "web of trust" inter-related keys. My
methods were rather crude, and unfortunately only extracted those people
who have signed someone (already on the list) else's key. That means that
people who are well connected on the web of trust are included, while
those people who only receive signatures from well-connected people are
not included.
The keyfile is approximately 1 megabyte, as opposed to 5-6 in the
keyservers. Building it required 12 successive passes to the MIT keyring,
each requiring 4-6 hours on my poor 386. I also made a subsequent pass
using the UNIMI keyring. To seed the list I used warlord@mit.edu (Uh
Derek? Hello??) and those keynumbers that cpunks mailed me. (Unfortunately
some people sent only their key blocks, which I didn't use. Also, my
server "lost" mail _twice_ due to "disk crash" while I was collecting key
numbers.) I assume that requiring 13 passes means that the longest
possible chain with a single connection (not necessarily a trust
connection) to one of the seed keys is 12 keys.
All included keys are exactly as they are on keyservers. The keyring
can be trivially validated as much as possibly simply by validating
one of the well-connected keys, like the ones that come with PGP. Warning:
not responsible for assigning trust levels for all those people. That's
your job. Have fun.
Why did I do this:
1) Because I wanted to.
2) Because I really had nothing better to do with my CPU time.
3)
wait, wait, ok for reals:
1) Because I want a web of trust keyring for myself, and that big old
5+ meg clunker keyfile is tooooo slow to use.
2) Because I feel that a DNS-style keyserver would not suit many
web-of-trust activities that I wanted the keyring for, IE: pgp aware
tools like news and mail readers for on-the-fly validation.
3) Because I feel that a system like this would encourage strengthening
the web-of-trust, ie, trusting the KEYS. The current system has a
lot of disjointed keys (uh, 4 meg worth I guess, eh?) which I found
myself trusting simply because they were on the Keyservers. While
this facilitates creation of a stable nym(*), real or not, I found
myself even trying to justify to others trusting a key simply because
it was on a keyserver.
* = I agree with Bill Steward that we are a bit obsessed on True Names(tm)
bit. I understand when Someone(tm) like Derek Atkins wants to see a
True Name ID card(tm), but I'm sympathetic to having Nym signing, with
the problem to overcome being simply the man-in-the-middle thwarting.
Updates:
Currently I am not really planning to do much in the way of updates to
this, unless people actually are interested in updates. To be frank,
this keyring is what I'm dropping into my own PGP, other than that it's
not too exciting.
If you get a copy, please tell me what you think of the project. The
location is ftp to bert.cs.byu.edu, pub/donring.pgp. Unfortunately I
don't know if you can tack that together as a ftp:// address. If you do,
try ~ftp/pub/donring.pgp for good measure.
I have suggested in the past that keyserver software could be modified to
update the web of trust (using a keyfile such as mine for a base) instead
of accepting just any key. I am not capable of making such modifications
to the keyserver program, nor do I know of a keyserver operator who is
willing to run such a system. A "for real" web of trust keyserver would
want to fully expand my keyring by adding what I left out - those keys who
are signed by included keys, but are not themselves included because they
were not a seed and have not signed an included key. Having coded that, an
update system that checks for a relation to a already-included key would
be trivial.
A second issue is that "The Web" of trust depends on the keys used to seed
it. It's very possible that many of unimi's (for example) key file (500k
bigger than MIT) keys do not have signatures connecting them to the people
who came out with PGP, but have a robust web of trust none the less.
Unless the project can obtain a seed which connects to that web, none of
it is included. However, as I stated, that is a fact which will
_encourage_ people to seek each other out for key signing.
I suppose I could also make a list of the keyring generation script, if
anyone actually wanted to ftp it. It would take between 15 and 35 hours to
run on a 386 Linux box such as mine, mere hours on a big, fast box. There
is really no need for it except to regenerate the keyring, for paranoia
purposes or other reasons.
Don
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBME6dqsLa+QKZS485AQFiBwL/boAb6BOdvcVHVyV+rGRmMTNk8iibcXvX
kdngbRLrBEc2r4pJkuNpDvT2M/GmmGEGYxiAXKV9LDmWa7RLnCicjidP1RJVcu+3
xtVeO9PF+4ZecgEUJl4j6JdPEE52guOr
=nm0W
-----END PGP SIGNATURE-----
<don@cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY
PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39)
June 7&14, 1995: 1st amendment repealed. Death threats ALWAYS pgp signed
* This user insured by the Smith, Wesson, & Zimmermann insurance company *
Return to September 1995
Return to “don@cs.byu.edu”