[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgp-keyserver-folk
Subject:    [Pgp-keyserver-folk] SKS: A call for participation
From:       "Yaron M. Minsky" <yminsky () cs ! cornell ! edu>
Date:       2003-02-19 23:14:24
[Download RAW message or body]

I've posted to this list about SKS before, but that was at an earlier stage
of development.  SKS has progressed considerably, and I believe it is ready
for some broader use.  There is currently a network of 3 SKS keyservers
which have been running quite stable for about a month now.  

So what I'm looking for is a few adventurous souls who would be willing to
set up SKS servers.  At first I'm just looking for a few people - 3 would be
a dandy start and would double the size of the current network.  If things
go well, I'd like to get more servers up soon after that.

SKS has a lot to recommend it.  Here are a few of the key features:

- Full RFC2440 compliance

   SKS does the right thing with respect to RFC2440 and RFC2440bis.  That
   means no problems with multiple subkeys or photoids or anything.  And
   there's even an architecture of applying "key scrubbers" for eliminating
   bugs introduced by other keyservers.  Right now, that just includes
   duplicate-packet elimination, but other filters could be easily added.

- Reliable, efficient synchronization 

   This is the neatest feature of SKS.  SKS uses a highly efficient
   differencing algorithm that can find a small number of differences in a
   fraction of a second, and that scales linearly in the number of
   differences.  The synchronization algorithm doesn't depend on mail, and
   is fully reliable --- if there's connectivity, all keys will be
   distributed to all participating SKS servers with probability 1.

   The load on an SKS server is far lower than the load on a PKS server.
   Even though an SKS server will synchronize with a randomly-chosen partner
   every minute, the amount of communication between two servers is
   proportional to the number of differences.  That means that a given key
   update is only received once, as opposed to the multiple transmissions
   typical of PKS's email-based flooding algorithm.
   
- Legacy-friendly

   SKS works hand-in-hand with existing PKS keyservers.  SKS servers can
   (and already do) receive email updates from PKS servers.  Due to the SKS
   synchronization algorithm, once an update is distributed to any SKS host,
   it will get distributed to all.  And you can build an initial database
   out of any PKS keydump.  
   
   Connectivity goes the other way as well:  any key submitted to the
   web interface of an SKS server will be forwarded to a handful of PKS
   servers, to ensure that keys are as widely distributed as possible.

- Simple to administer, no central point of failure

   SKS's simple gossip-based replication is simple to administer.  You just
   choose a list of partners to gossip with, and you're off.  The SKS
   reconciliation algorithm is very robust, and doesn't depend on a
   centralized multicast architecture.  
   
   SKS is also easy to compile and set up.  I've run it on solaris and on
   Linux, and it's been built on Alpha as well (but I have less data on
   this.)  You should be able to use it anywhere you can compile ocaml and
   Berkeley DB.  Other than that, the distribution comes with everything you
   need (except for a keydump.)

You can get more info about sks here:

   http://sks.sourceforge.net
   
The latest version can be checked out of CVS, and you can also sign up for
the mailing list.  As I said before, I want to expand the network slowly, so
please contact me before setting up the server.

Thanks,
Yaron

-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916 (new key as of Dec 4th)
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916

[prev in list] [next in list] [prev in thread] [next in thread]