57

I've created a new OpenPGP key to sign a software package in a source repository with an expiration date three years from now. It seemed like a good security measure, because if the key is compromised or stolen the damage will be limited.

But then I thought about the day when I will need to sign my new key. Signing the new key with the old key seems equivalent to keeping the old key, and thus adds nothing to security.

Does setting an expiration date improve key security? If so, what's the best expiration/key replacement policy?

  • You can also set expire times on a signature, which is a good idea if It for example is used to signal organisation membership or a role. With an end date the revocation of those signatures does not have to be provided endlessly. – eckes Mar 30 at 16:35
64

tl;dr: the expiry date is no reasonable mechanism to protect the primary key, and you should have a revocation certificate at hand.


The slightly longer version is, that the effect of the expiration date differs between primary and subkeys, and also what you aim to prevent.

Subkeys

For subkeys, the effect is rather simple: after a given time frame, the subkey will expire. This expiry date can only be changed using the primary key. If an attacker gets hold of your subkey (and only this), it will automatically be inactivated after the expiry date.

The expiry date of a subkey is a great tool to announce you switch your subkeys on a regular base, and that it's time for others to update your key after a given time.

Primary Keys

For primary keys, the situation is different. If you have access to the private key, you can change the expiry date as you wish. This means, if an attacker gets access to your private key, he can extend the validity period arbitrarily. Worst case, you lose access to the private key at the same time, then even you cannot revoke the public key any more (you do have a printed or otherwise offline and safely stored revocation certificate, do you?). An expiry date might help in the case you just lose control over the key (while no attacker has control over it). The key will automatically expire after a given time, so there wouldn't be an unusable key with your name on it sitting forever on the key servers.

Recovering Weak Unrevoked Keys

Even worse, expiry dates might provide a false sense of security. The key on the key servers expired, so why bother to revoke it? There is a large number of well-connected RSA 512 bit keys on the key server network, and probably a comparabily large number of weak DSA keys (because of the Debian RNG problems). With faster processors and possibly new knowledge on algorithm weaknesses, an attacker might in future be able to crack the expired, but non-revoked key and use it!

Keeping a Revocation Certificate Safe Instead

If you've got a revocation certificate and are sure you never might lose access to both your private key and revocation certificate at the same time (consider fire, (physical) theft, official institutions searching your house), there is absolutely no use in setting an expiry date apart from possible confusion and more work extending it.

  • 1
    Makes sense. This should be the selected answer. – Kshitiz Sharma Feb 18 '15 at 5:32
  • 1
    On the point of Recovering Weak Unrevoked Keys, don't forget that if someone is able to break an expired but not revoked key, it becomes almost trivial to create a signature trail leading up to a given key in the present which appears legitimate by simply backdating signatures. As PGP doesn't require the use of an external, trusted time source, that just means setting your own computer's time back appropriately. – a CVn Feb 24 '17 at 7:22
  • It's an interesting point about cracking an old expired non-revoked keys. Still I think that "absolutely no use in setting an expiry date" is too strong conclusion. Anyone who cares about security shouldn't trust signatures from or shouldn't encrypt for a 512 bit RSA key. So they're broken either way and should not be used. On the other hand I still have 4096 RSA key I've lost on the keyservers without expiration time which is uncrackable as of today but I have no means to revoke it. – raindev Nov 1 '17 at 20:08
  • 2
    To sum up my arguments above, it seems like expiration time would protect a key from loss (not from compromise obviously) if it's set to expire before becoming crackable (at which point a PGP client should report it as broken anyway). – raindev Nov 1 '17 at 20:08
  • @raindev How does it protect a key from loss? – nhooyr Aug 14 '18 at 17:04
7

Note that an expiration date on the master key doesn't really do anything for security, as anyone who compromised that could always just extend it anyway. See http://madduck.net/blog/2006.06.20:expiring-gpg/.

(Expiring subkeys, on the other hand, can be useful, and the option at key creation sets the date on all of the keys.)

0

Does setting an expiration date improves key security?

Yes. You've already said why, too:

It seemed like a good security measure, because if the key is compromised or stolen - the damage will be limited.

Assuming you are compromised and the key is stolen, clearly, your first action would be to revoke the key and issue a new one. However, not everyone will check for revoked keys; they'll continue blindly using it until it becomes invalid.

Likewise, if you're compromised, somebody can only pretend to be you for a fixed window.

If so, what's the best expiration\key replacement policy?

There really isn't one - the question is more "what is the best I can do given constraints X Y Z". For example, if you set the Window too small, you inconvenience users; however, too high and you open up the risk if compromised. It really comes down to a judgement call - how sensitive exactly is what you're protecting and how often/inconvenient is it to replace keys frequently?

  • 1
    By "policy" I actually meant the procedure to undertake when a key is naturally expired. – Adam Matan May 8 '12 at 12:39
  • 5
    This is plain wrong, if your key is stolen, the thief can pretend to be you forever, as he can prevent it from expiring. – remram Feb 27 '14 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.