(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 pool.sks-keyservers.net and therefore needs gossip peers. http://code.google.com/p/sks-keyserver/wiki/Peering 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.
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?
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.
“>/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?
Simon: you are correct; bug #594105 filed.
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.
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
engines…