[Howto] Using sks key server pool for managing GPG signatures

920839987_135ba34fffGPG/PGP needs key servers to work properly. However, some of the servers announced on the web only react slowly – or not at all. The solution is to access a pool of servers which maintains itself.

GPG/PGP works within a web of trust: you trust people you know by signing their keys. If you meet someone you don’t know, you can check if someone you trusted signed the key of the unknown person.

To look up such signatures you however need the infrastructure of such a web of trust: key servers, which store and deliver keys and signatures.

However, many key servers are really slow or do not work properly although they are still listed in programs like KDE’s kgpg. The solution is to use a round robin based pool of servers like the sks key servers. The advantage of such a pool is that even if one server does not respond, next time you query the pool another server will respond most likely. Also, the pool checks itself if the servers are working and removes them from the pool if not. One new child of the family of pool servers is by the way a server provided by the Fedora Project.

The sks pool can be used just like any other key server, for example on the command line:

$ gpg --keyserver keys.fedoraproject.org --recv-keys 449FA3AB
gpg: requesting key 449FA3AB from hkp server keys.fedoraproject.org
gpg: key 449FA3AB: public key "Linus Torvalds <torvalds@transmeta.com>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:  12  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:  12  signed: 123  trust: 6-, 0q, 0n, 0m, 6f, 0u
gpg: depth: 2  valid: 122  signed: 177  trust: 119-, 0q, 0n, 0m, 3f, 0u
gpg: depth: 3  valid:  63  signed: 113  trust: 63-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2014-05-10
gpg: Total number processed: 1
gpg:               imported: 1

You can also add the key server to GUI programs like kgpg, or add it as default server to your ~/.gnupg/gpg.conf:

$ grep keyserver .gnupg/gpg.conf
keyserver  hkp://pool.sks-keyservers.net

[Howto] Changing the expiry date of GPG keys

920839987_135ba34fff
GnuPG keys can have an expiry date. When the key expires, it cannot be used to encrypt data anymore, and thus is a good way to enforce security measures. However, what most people does not seem to know is that this expiry date can be changed quite easily.

Setting an expiry date for a GPG key is usually a good thing: it makes sure that even if you forget the password and do not have a revocation certificate the key will not be valid at some point in the future. Additionally it might force users to replace keys ever so often to enforce specific security measures. Last but not least it forces the key owner to think about his or her own GPG infrastructure and if changes are needed.

Still, there might be times where it makes sense to change the expiry date – if only because you realized that your GPG keys are all fine.

First, you need to know the key ID, in this example ABCDEF12:

$ gpg --list-keys liquidat@example.com
pub   2048R/ABCDEF12 2012-09-10 [expires: 2032-09-10]
uid                  liquidat <liquidat@example.com>
sub   2048R/BCDEF123 2012-09-10 [expires: 2032-09-10]]

With that ID at hand you can now edit the key:

gpg --edit-key ABCDEF12
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2013-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

gpg>

As you see this key is going to expire in fall 2013. The gpg> indicates a prompt, so you are basically at a gpg specific shell. So, let’s actually change the expiry date:

gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Fri May  6 15:45:42 2016 CEST
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "liquidat <liquidat@example.com>"
2048-bit RSA key, ID ABCDEF12, created 2012-09-10

The passphrase is usually queried by standard means, so on a desktop systems a pop up windows should come up asking you for the passphrase.

Afterwards, list the key again to check the new expiry date:

gpg> list
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

gpg>

As you see, the expiry date has only changed for the first key, but not for the pub key. The edit procedure is always for one key only. Thus, change the focus from the first key, called “key 0”, to the sub key, “key 1”. A star sign * will indicate the focus on the subkey:

gpg> key 1
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub*  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

gpg> expire

Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Fri May  6 15:45:42 2016 CEST
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "liquidat <liquidat@example.com>"
2048-bit RSA key, ID BCDEF123, created 2012-09-10

gpg> list
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2016-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

As you see, you are done, both dates are changed now. The changes finally need to be saved:

gpg> save

And, last but not least, don’t forget to upload the updated public key to the key servers:

$ gpg --keyserver pgp.mit.edu --send-keys ABCDEF12
gpg: sending key ABCDEF12 to hkp server pgp.mit.edu