Best practice for periodic key change?

Andreas Heinlein aheinlein at gmx.com
Fri May 6 08:22:45 CEST 2011


Am 05.05.2011 22:10, schrieb Doug Barton:
> On 05/04/2011 23:52, Andreas Heinlein wrote:
>> We have a OpenPGP key which we use for signing our software releases.
>> That key should be changed yearly and carry an expiration date to
>> enforce this change.
>
> What are you trying to accomplish by doing it this way? I've yet to
> see a good rationale for setting expiration dates on keys, but perhaps
> you can be the first. :)
>
>
Well, there are several reasons.

The first is that there is always the chance that the key is cracked
brute-force. Remember that the x-zillion years which are often cited are
only an average. One might always be lucky and find the right one within
the first 0.0001% of keyspace, taking only a few days or weeks. Chance
is very low, but then almost every week someone wins the lottery... ;-)

More likely your key gets compromised some other way, e.g. it is stolen
from your computer by a trojan, a malicious website or whatever. A good
passphrase mitigates this risk somewhat, but most people choose
passphrases which are weaker and easier to brute-force than the actual key.

Here comes the third point; even if you notice your key was compromised,
you need to revoke it *and* make sure the revocation reaches all users
of your key. Like Werner said, many people never refresh their keys, so
expiring is indeed a way to force them to do that. ( I admit that, in
our case, even this will not help, since gpg will happily verify a
signature made by an expired key. It will tell you that it's expired,
but verify anyway. The 'hard' way would be to just refuse to do anything
with an expired key or even delete it automatically, but that's another
discussion).

Much depends on the use case you're using GPG for, there's another
discussion currently on this topic. Werner's approach still doesn't
satisfy me, as it doesn't protect you from someone else using your
(compromised) key as long as you don't notice it.

Andreas



More information about the Gnupg-users mailing list