[cks-devl] Re: SKS: The synchronizing keyserver (fwd)

[Yaron M. Minsky]

I'm actually very interested in figuring out how to do interoperability 
with different keyservers.  There are some issues that arise when 
synchronizing between databases that make different decisions about 
which keys to discard, however, that still need working through.

It's worth noting, by the way, that the algorithm for synchronizing the 
databases is not entirely trivial to implement.  It relies on some 
algorithms for interpolation and factoring of rational functions over a 
finite field.  I rolled my own implementation for SKS which you are, of 
course, welcome to crib.  But my implementation is written in OCaml and 
might be a bit of a pain to translate to C.

Another possibility is that it should be possible to use the 
reconciliation part of my code directly with your keyserver.  SKS is 
divided into a key-database daemon (sks_db) and a reconciliation daemon 
(sks_recon).  The reconciliation daemon is pretty simple to interface 
with and should be usable with different keyservers.

y

V. Alex Brennen wrote:
> I've taken a quick initial look at the code, and right
> now, I'm planning to support interoperability with this
> in cks.
>
>         - VAB
> ---------- Forwarded message ----------
> Date: Thu, 26 Sep 2002 23:18:50 -0400
> From: Yaron M. Minsky <address@hidden>
> To: keyserver-list <address@hidden>
> Subject: SKS: The synchronizing keyserver
>
> I'd like to announce the release of a new keyserver, SKS.  I've been 
> quietly working on SKS for the last few months, and it's now in a stage 
> where I think it's together enough to get some feedback on.
>
> You might wonder why we need a new keyserver at all.  After all, the 
> existing keyservers do a pretty good job, and there are some actively 
> developed keyservers (namely CKS) that are getting better all the time. 
>   But SKS is meant to address one big weakness shared by all of the 
> existing PGP keyservers -- replication.  Current keyservers rely on a 
> not-terribly-reliable flooding-based approach.   Keys often fail to get 
> distributed everywhere, and the only current way to repair these 
> differences is to periodically exchange full database dumps.
>
> SKS takes a very different approach to replication.  Instead of using 
> the kind of flooding approach adopted by PKS, SKS works by directly 
> comparing the databases and discovering and repairing whatever 
> differences are found.  SKS uses some newly developed algorithms for 
> making the comparison between databases extremely efficient.  In 
> particular, the cost of reconciling a pair of keyservers is proportional 
> to the number of keys that differ between them, rather than the size of 
> the overall database.  That means reconcilation is cheap enough to be 
> done often. By having hosts periodically reconcile with other randomly 
> selected hosts, updates are quickly "gossiped" throughout the system. 
> The resulting system is simple to administer, and the replication is 
> extremely robust.
>
> You can also try querying one of the two publicly-reachable SKS servers. 
>   The web pages for querying those servers are at:
>
>    http://sks.dnsalias.net/
>          -and-
>    http://sks.dnsalias.net/other_sks.html
>
> (yes, the web pages are hosted on the same server, but the actual sks 
> servers that the querying is done on are in different places.)
>
> You can get more information about SKS, including some links to papers 
> describing the reconciliation protocols at:
>
>      http://sks.sourceforge.net
>
> and you can download the first release from:
>
>      http://sourceforge.net/projects/sks
>
> Any key succesfully submitted to one keyserver should appear on the 
> other within about a minute.
>
> I'd love to get some feedback from the community.  And eventually, I'd 
> like to find a few brave souls who would be willing to run a few copies 
> of SKS to build a kind of proto-SKS network.   SKS is still new and is 
> not ready for production.  But I'm very committed to getting it there.
>
> Yaron