My Web pages are best viewed with style sheets enabled.

Unrated

PGP: Public Key Servers

Copyright © 2002-2012, 2014, 2016 by David E. Ross

A public key server is a computer program that maintains a collection of public PGP keys. Someone with a new public key can add that key to a server's collection. Anyone seeking someone else's public key can search the collection. Keys already in a server's collection can also be updated. Such updates can reflect the addition of key signatures by other PGP users or the addition of a new user ID (i.e., a new E-mail address for the key's owner). Also an update can reflect the owner having revoked the key. However, once a key has been added to a key server, consider it not removable.

There are several different Internet protocols (communication interfaces) used by key servers. Servers that use the HTTP, LDAP, and E-mail protocols permit searches for individual keys; thus, I call these single-key protocols (although they may be used to find a set of keys that share a common characteristic). The FTP protocol described at The FTP Based Key Server System provides access to very lengthy keyrings (over 20 MB) and is not suitable for processing individual keys.

Searching for Keys

You want the key of someone, and you know her E-mail address. Or you want to check the status of your own key. Or you already have someone else's key, but you want to see if anyone else new has signed that key. Or …

You can use any single-key protocol to search a key server for the key. I have had no experience with using the E-mail protocol, and so I refer you to the comp.security.pgp FAQ. You search a selected HTTP or LDAP key server for a key you identify by specifying either a part of the user ID (e.g., rossde for my keys) or the complete key ID (e.g., 0xE3EFE1A7, where the 0x (zero-eks, not oh-eks) — mandatory for key ID specifications — at the beginning indicates the ID is a string of hexadecimal bytes). The server returns all keys that satisfy that request. The LDAP protocol actually allows you to specify more than one characteristic; for example, you could request all keys that contain rossde in the user ID and that are not revoked. (I have not tried the LDAPS protocol because every server that supports it also supports the LDAP protocol, which I do use.)

The easiest way to use these protocols is to setup server information in PGP's Options. In the table in the middle of this page, I indicate which protocols each server uses. Then, you use PGP's Servers menu to perform the search. Note that a domain server contains keys only for one E-mail domain (e.g., only for earthlink.net). (A domain key server is usually only semi-public. It is used by a company just for the keys of its own employees. The public might be allowed to download a key from a domain server, but often only a system administrator can upload keys to it.) A search through PGP's Search menu returns a list of keys in a display very similar to the standard PGPkeys window. You can examine signatures and properties in that list. Then, just mark one or more keys and then use a pull-down menu to import them into your keyring. Yes, searching for a PGP key actually means downloading that key.

Often, key servers that support the HTTP protocol also provide Web pages for use in searching for a key. Using the HTTP protocol, these allow you to input a single identification (part of the user ID or the entire key ID). Usually, they also allow you to specify short or verbose. The former returns a listing of the keys that satisfy the request, one line per key. The latter shows all the signatures on each key. Sometimes, a Web page uses the terms index and verbose. One server even has the descriptive terms Simple index and Key & who has signed it. Some Web sites do not give any option.

Note that, with a Web page, downloading requires one extra step after a successful search. Keys are listed with a link (often at the key ID). Select the link to download and see the key. Then copy the resulting Web page and paste it into the PGPkeys window to add it to your keyring. Extraneous information on the Web page may be included in the copy; PGP will automatically paste only the key itself.

Warning: Just because you obtained a public key from a server does not mean that the key is authentic, that the actual owner is really who he or she claims to be. If you have a message that is so sensitive that it must be encrypted, then you must also verify the authenticity of the key and its owner. Once you have done that, you then sign the key to mark it as verified. (You may then wish to distribute the signed key to let others know of your verification. This is the following subject.)

Uploading a Key

You have just generated a key pair and want to distribute your new public key. More important, you just revoked your key and want as many people as possible to know. Public key servers are generally used for very broad public distribution of new and modified keys.

If you add another user ID (e.g., a new E-mail address) to your key, which you previously uploaded to a key server, you must now upload the key again. If you sign a key because you indeed know the owner of that key, then that key might also be uploaded to a key server; however, in this case, courtesy requires that you ask the key owner first (especially if the key has never been uploaded before).

If you have setup the Servers portion of PGP's Options, you can upload directly from PGP. After connecting to the Internet, select one or more keys to upload. Then select Send To in the Servers menu. Remember, Domain refers to a server that only has keys for the E-mail domain that matches the server's domain; to upload to such a server, it must first be setup in your list of servers.

If you are using a Web page, select one or more keys and then copy them (from the Edit menu or from a pull-down menu). Paste the result in the input area on the Web page. Finally, select the appropriate button or link on the Web page to upload the pasted keys.

Public Key Servers

The following table contains these columns:

• Server: This is the name of the server. If you are setting up a server in the PGP Options, this is the name you use.
• Web: An X is a link to the Web page interface for uploading and searching for a key. If these functions are on separate pages, the link is to the "parent" of those pages. If there is no X, I could not find a Web page for these functions.
• Lang: This indicates the language that the Web site uses:
  • Croat: Croatian
  • Engl: English
  • Germ: German
  • Hung: Hungarian
  • Japn: Japanese
  • Span: Spanish
  If I could not access a Web page, I indicate ?.
• Ports: When you setup a new entry in the list of servers, each protocol has a port number by which PGP connects to the server. The port is blank for a protocol not supported by the server. If all ports are blank, the server can be used only via a Web page.
• Alias: Some servers have more than one domain name. Use only one of the names, either the primary or an alias. Whatever you get from one will be the same as for the others.
• Tested: This is the date on which I last tested the information for this server. Key servers are operated free to the users (often by volunteers). Lists of servers quickly become obsolete as operators lose interest or are diverted to productive (i.e., money-making) activities and allow servers to die. I tested the servers on the list in the following manner:
  • I check the domain, doing a DNS lookup to make sure the domain is currently valid.
  • I try a Web page interface to search for a key. If the request fails, I try twice more with some other specification. If there is no response at all or if I cannot get a successful request after three tries, I assume the server has no functioning Web interface.
  • I try each of the known protocols for a key. If a request fails, I assume that protocol is not functional.
  • If a server fails for the Web interface and for all protocols, it is not listed.
  Note: When searching for a key, I search for my own keys (the oldest of which was generated in 1997). If that fails, I reject the server as not synchronizing. Often, such non-synchronizing servers are specialized (e.g., handling keys for only one organization).

  Once a server is unlisted below, it can be added only if someone brings it to my attention. I will not try it again later on my own initiative. Running into a brick wall once per server is enough.

The initial information in this table was obtained from Brian M. Carlson's PGP and GnuPG Web site, which no longer exists. I solicit additional inputs and corrections via E-mail.

Note: Some (or all) of the servers listed below might not handle keys with subkeys or photos. Not using either, I have not tested for their use.

Those servers whose domain names are in bold are in the list of servers I entered into my PGP options. I tested the synchronization of these using new, updated, and revoked keys late in August 2010; they synchronized with other servers in less than 90 minutes. All the other servers in this list are also known to synchronize with others.

After a key server has been tested above and entered into the list below, subsequent testing only involves checking to make sure the server responds.

Servers to Avoid

Because they fail to synchronize with other servers (at least within 48 hours), I strongly recommend against using the following key servers (listed with their aliases and the date tested). Nevertheless, if you revoke a key, check these to see if they contain your key. If any of these servers do contain the key you are revoking, safety requires that you specifically upload the revocation to that server.

• dir2.es.net
  6 Jan 06
• fleming.veridis.com
  (search.keyserver.net, www.keyserver.net)
  4 Sep 04
• keyserver.pgp.com
  (certserver.pgp.com)
  7 Jan 06
• kies.mcbone.net
  (keyserver.topnet.de, keyserver.freenet.de)
  30 Aug 10
• nicpgp2.nic.ad.jp
  (pgp.nic.ad.jp)
  30 Aug 10
• dtype.org
  (pgp.dtype.org)
  7 Sep 04
• pks.mtholyoke.edu
  30 Aug 10
• wwwkeys.cz.pgp.net
  (pks.ms.mff.cuni.cz, wwwkeys.gpg.cz)
  4 Jan 11

Also, there is a bug in older versions of the SKS key server code that impairs synchronization from other, non-SKS servers but not synchronization to others. Among the servers affected are cryptonomicon.mit.edu (pgp.mit.edu, pgpkeys.mit.edu, www.us.pgp.net), pks.gpg.cz (sks.ms.mff.cuni.cz), and the.earth.li (wwwkeys.uk.pgp.net), all of which have been removed from the above list of servers. It has not yet been determined if the problem relates to which version of the SKS server software is used or is a result of whether the server is or is not a member of the SKS pool.

When you urgently need to revoke your public key because either your private key or passphrase has been compromised, a server that is slow to synchronize can be as catastrophic as a server that does not synchronize at all.

Note: If any of the servers listed here as non-synchronizing or dead are now functioning and synchronizing, please let me know.

Server Networks and Round-Robins

At one time, key servers were closely grouped into networks. Synchronization among servers within a network occurred more frequently than with servers in other networks. Today, however, well-functioning servers synchronize with all other known servers quite often and quite quickly; and the concept of networks is no longer significant.

Round-robins are pseudo-servers, one of which is wwwkeys.pgp.net (alias www.uk.pgp.net). A round-robin reroutes requests to other servers, randomly or cyclically choosing one from a list. However, some of the servers on the list may be inactive. Thus, a round-robin might often be unresponsive and should be avoided. The list of servers above excludes round-robins but does include known individual, active servers that participate in round-robins.

Remove a Key From a Key Server?

Several times a month, I see messages on the PGP newsgroups asking "How can I remove my key from a key server?" In general, you should assume that you cannot. While some public key servers do allow keys to be deleted, this is very problematical.

• To prevent a third-party attack (e.g., denial-of-service by eliminating a valid key), you must positively identify yourself as the owner of the key by signing the deletion request using your private key and passphrase — corresponding to the public key you want deleted. Usually, however, those who want to delete their public keys have either lost their private keys or forgotten their passphases.
• If you delete your public key from only some key servers, they will reappear when those servers synchronize with other servers. There is no standardized message servers can send to each other that a deletion request was processed by one server. Synchronization merely involves comparing databases and adding keys to a database that are in another and updating keys in a database that have more recent updates in another. Some servers synchronize only with a select group of other servers, some never synchronize, and some synchronize with all known servers. (No one really knows all the servers. My list above is not totally comprehensive.) Thus, unless you know all the servers containing your key, unless they all accept deletion requests, and unless you send those requests simultaneously to all servers before any synchronization can occur (which can be three minutes or less, even between servers in different networks), your deleted key will not remain deleted.
• The best action in lieu of deletion is to revoke your key-pair and upload the revoked public key to key servers. A revoked key cannot be used for encryption. However, it does remain on the key servers, which is not a bad situation.
  • While you might notify those you know who have your old key that it is revoked, what do you do about those who have your old key that you don't know? Occasional synchronization of personal keyrings against key servers will uncover revoked keys. But how often is occasional? That is, how long is long enough for a revoked key to remain on a key server to let others know about the revocation?
  • While a revoked public key can no longer be used for encryption, it can still be used to verify old PGP signatures made before the revocation.

But what can you do if you lose your private key or forget your passphrase? This is not clean, but can provide a warning to those who synchronize with key servers.

• Of course, you must generate a new key-pair. If your software does not automatically self-sign your public key, do so manually. Do not yet upload the public key to a key server.
• Add a user ID to your new key: "Key revoked -- do not use". Make this your primary user ID (name). Self-sign it.
• If you have lost both your public and private keys, you will have to download your old public key from a key server.
• Sign your old public key with your new key. Upload your old public key to whatever key servers you previously uploaded it.
• Remove the "Key revoked … " user ID from your new key.
• Now you may upload your new public key to key servers. However, you might want to make a revocation certificate first, to avoid any repetition of the problem.

For more discussion about deleting keys from key servers, see Tom McCune's page for Pretty Good Privacy.

Last updated 26 November 2016

Main PGP page

David Ross home

My PGP keys