Improving the resilience of the Web of Trust

(this is a post in two parts)

At the BoF of GPG Key Management: Best Practices, dkg had two immediate recommendations for improving WoT resilience:

  • Regularly refresh your local keyring from the key servers;
  • If you have spare space and transit, provide a key server to take part in the pool.

Regular Refreshes

This is important because unless keys are refreshed, changed expirations and (more importantly) revocations on keys are never made known to you. Making regular refreshes is easy, though I was surprised to hear people had experienced difficulty with it – it’s a simple entry to cron, like:

0 0 * * 1  /usr/bin/gpg --refresh-keys

to run at midnight on a Sunday, or any other convenient time. Append > /dev/null to make it silent unless there are errors.

Provide a key server

This is nearly as trivial a refreshing the keyring, but it does take some disk space (on my machine, 4G for the decompressed dump from another server, 7.4G for the database itself and a few hundred MB for other stuff. Supposedly the dump can go after a full database build, but as I’m not constrained I haven’t bothered).

The sks package in Lenny and Squeeze manages the database and answers to clients. However, take care to follow README.Debian carefully, since if the permissions on /var/lib/sks or /var/log/sks aren’t set right it will silently fail and much head-scratching will ensue. Building the database for the first time takes some hours even on a reasonably quick machine, and takes a lot of CPU time, so it’s probably best done overnight.

Once sks is running, it needs to catch up from the date of the key dump to now (which is why a recent dump is always a good start). To do that, it should be listed in the and therefore needs gossip peers. is an excellent guide, though the version of sks in Lenny does not support multiple listening addresses for either the recon or hkp processes.

When a small enough delta between the server and its peers is reached, it’s included in the DNS pool for use by other clients.


  1. Stephane says:

    Is there today a risk of collapse of the Web of Trust?

    Is the ‘provide a key server’ recommendation for internal use or is it a call to set up new public servers? Currently, the last link shows there are 60 available servers in IPv4 and 19 of these 60 are IPv6-compliant too. Is it not enough?

    1. Jon says:

      Is there today a risk of collapse of the Web of Trust?

      No, I don’t think that collapse is imminent. But the resources required to provide more keyservers are small for each contributor, and will help to distribute the network around the world to protect against interference, DDoS, splits and so on.

  2. Simon says:

    “>/dev/null” doesn’t help much, nor does “–quiet”, seems “requesting key” message is written to stderr in either case despite it being neither and error, nor especially essential. Bug report time?

    1. Jon says:

      Simon: you are correct; bug #594105 filed.

  3. How much traffic can I expect if I install a key server?

    1. Jon says:

      How much traffic can I expect if I install a key server?

      Well, I haven’t been measuring it specifically, but the average traffic to that box over the past 24 hours has been about 6kbps in and 10kbps out. Over the past four hours, that has been 11.4MB inbound and 26MB outbound.

      That box is also serving HTTP and other data, so the figures for just key exchanges should be much less.

  4. mirabilos says:

    I have two problems with gpg and SKS…

    First, if keys have a preferred-keyserver notation
    set, they are downloaded one by one. With 120 keys from the same server, that makes 121 connections to
    that server instead of one… and SKS doesn’t like that
    and aborts the refresh process sometime.

    Second, SKS bitches if it doesn’t have any peers. But
    it may have none both in the initial setup and in a
    scenario where you want a sort-of “private” keyserver,
    public to use but forbidden to sync or for any search

Comments are closed.