2

From the thread Does OpenPGP key expiration add to security? , we know that the faster the keys expire, the greater our security. The minimum expiration for a GPG key seems to be 1 day. Thus, isn't it much more secure to generate a new GPG key (that expires in 1 day) once per day?

That means, we generate a new GPG key whenever we want to sign a document, and we only re-use the key for a maximum of 24 hours before generating a new one.

However, this practice does not seem to be widespread. I see many people using the same key for months, or even an entire year before generating a new one.

What may be the disadvantage of only using 1-day expiration GPG keys?

Community
  • 1
Pacerier
  • 3,253
  • 6
  • 34
  • 61
  • It's a pain in the ass? On top of having to generate a new key every time, you also have to convince the other party of the authenticity of the *new* key. You could use each day's key to sign the next, but then have you really gained anything? – Stephen Touset Feb 11 '14 at 05:42
  • @StephenTouset, Convincing the other party is as easy as uploading it to https://keyserver.pgp.com/vkd/GetWelcomeScreen.event right? I don't see how the once-a-day process is unmanageable, especially when it could be entirely automated. – Pacerier Feb 11 '14 at 05:45
  • How would that be convincing? Anyone can upload their key, and attach any name, photo, or email address to a keyserver. – Stephen Touset Feb 11 '14 at 06:19
  • 2
    Your premise "From the thread [...] we know that the faster the keys expire, the greater our security" is wrong. – Murmel Nov 05 '18 at 12:27

2 Answers2

5

What may be the disadvantage of only using 1-day expiration GPG keys?

Even a minimal check of a new GPG key in professional/sensitive/regulated environments should involve something akin to a phone call to the other party's known phone number, and checking the key's fingerprint against what they have for the fingerprint.

If I have a daily file process, then for every key I get (1 per day per client/vendor/process/etc.) this requires

  • obtaining your daily key
  • importing your daily key into my keyring
  • validating your daily key's fingerprint to reduce the chance that it's an imposter
  • having my automated process figure out your newest key (NOT something that anyone I'm aware of currently does)
  • avoiding key identifier collisions as my keyring grows
  • pruning my keyring regularly to get rid of thousands of expired keys over the years

Further, imagine I have as few as 100 automated file processes, and if they're all (business) daily, that's over 26,000 keys a year! The Birthday Paradox is going to start rearing its head for short keyid collisions, not even counting the time spent doing all the above maintenance... and debugging the inevitable issues.

Key management is enough of a pain already - a hundred new keys a day? I don't think so. I'd rather deal with 100 purely random passphrases a day for symmetric encryption than 100 new GPG keys a day - it's less overall effort.

On a human note, I don't even want to think of the friendly name and email address collisions, given how hard it is to get most companies to use a SHA-256 or better self-signature, or even good cipher and hash preferences.

Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
2

That is a bad idea from the very first moment. I guess you have never dealed with key management and its P.I.T.A. problems. The correct answer here is: it has so many disadvantages they are difficult to enumerate, being the most important "preventing users from working". I will only add a few points to the Anti-weakpasswords response:

  1. Your first paragraph is completely false. The security of a key does not increase as you shorter the time expiration date.
  2. That is a crazy thing not one security expert will encourage you to do. As your document database grows, your users will need to use more and more keys and they will spend their time in key management issues and not their real tasks.
  3. It is not extended because it is nonsense, that is the kind of security that makes an enterprise hating the security guy.
kiBytes
  • 3,450
  • 15
  • 26