Strategies for offline PGP key storage

Posted Oct 3, 2017 13:28 UTC (Tue) by merge (subscriber, #65339)
In reply to: Strategies for offline PGP key storage by ms
Parent article: Strategies for offline PGP key storage

That's nice, making use of letsencrypt that way!

So, why use key cards? Creating known-good keys that in turn *can* get compromised until they expire seems more cheap, more safe, and more easy to use, especially when you're at it anyways, regularly finding a place to unlock your most secured files for a very short period of time.

to post comments

Strategies for offline PGP key storage

Posted Oct 5, 2017 6:48 UTC (Thu) by madhatter (subscriber, #4665) [Link] (2 responses)

Because you're probably not the only person that uses your public key. If you're only using gpg to secure your files on your hardware, your point is valid. But if others use your key to correspond with you, and you change it every 80 days, they have a big key validity problem every 80 days.

If instead you have one highly-secure long-lived key that's on a HSM, and you use it to sign your ephemeral encryption keys, then any correspondent who has the public part of your long-lived signing key can get your current public key off any old keyserver and immediately know whether to trust it or not.

Strategies for offline PGP key storage

Posted Oct 5, 2017 7:00 UTC (Thu) by merge (subscriber, #65339) [Link] (1 responses)

That's true. But for example Debian encourages to use signing subkeys, see https://wiki.debian.org/Subkeys (although not explicitely short-term keys). But in the end I guess you'd only have to wait until your new signing subkey has landed in all keyrings and let your current one expire, which is solved by overlapping the key validity intervals by a few weeks and always using the oldest.

Strategies for offline PGP key storage

Posted Oct 5, 2017 12:53 UTC (Thu) by anarcat (subscriber, #66354) [Link]

One of the problem I've encountered with having multiple signing keys is that not all programs using GPG make it easy to choose which key to use for signing. Last month, for example, I added that signing key and that key took well... about a month to propagate through Debian's infrastructure. That gave me time to notice that:

1. gpg chooses the latest signing subkey (I would have expected it would sign with all available signing subkeys)
2. notmuch-emacs and mutt do not allow you to choose which subkey to use to sign outgoing messages
3. debsign *does* allow you to choose the signing subkey, but that's about the only thing

I had to go back to inline signing to send email... And I had to specify the signing key with a bang ("!") at the end, which was weird and unusual (I would have expected the keygrip to work here for example).

So in short, it's a pain in the back to rotate signing keys, I wouldn't recommend having a workflow based on doing that on a regular basis, unless you control key propagation.