GPG Best Practices Are Broken – Here’s What Actually Works

Too many options, not enough relevance

GPG gives you everything: master keys, subkeys, signatures, trust levels, revocation certificates, UID management, keyservers, smartcards, expirations, etc.

That’s powerful. But in practice? Most people just want to:

• Encrypt something and decrypt it later
• Share secrets securely with a small group
• Sign commits or messages reliably
• Maintain access across multiple machines

Instead, they end up managing a miniature PKI — often with no real threat model, and a massive cognitive load.

The real problem I faced

I had:

• The private key on my primary workstation (as per best practice)
• Subkeys copied to a secondary laptop
• I had deleted the main key from the laptop — again, best practice

One day I needed to decrypt passwords using password-store on the laptop. But the subkey had expired.

And guess what? I couldn’t renew it — because the main key wasn’t there. No way to extend it. No access to secrets. Dead end.

This was not a compromise. No intrusion, no suspicion. Just self-inflicted entropy.

I didn’t need expiration. I needed continuity.

We treat cryptographic keys like they're radioactive. But your house key lasts 10 years with continuous use.

Expiration ≠ Security

In organizations, keys rotate for a reason: machines change, people leave, risk must be contained.

But if you're managing your own infrastructure, with your own physical access, expiration does not increase your safety. It increases your friction.

If someone compromises your device, the key's expiry date is irrelevant. You have a bigger problem.

If you're working across multiple devices, expiring a subkey on one of them creates instant friction — not increased protection.

What actually works

After enough failure, here’s what I recommend — and use:

• One GPG identity per person, shared across all your devices
• Same signing key for everything — makes the trust chain traceable
• Create a subkey per device for encryption/decryption
• Do not expire subkeys unless you actually rotate devices often
• Only use expiration where key exposure is likely (e.g., shared devices, cloud boxes)
• Trust your own threat model more than the default paranoia

GPG is not the problem — the culture around it is. It was designed for a world of desktop-only email paranoia. That world is gone.

What we need now are tools that map to how we actually live and work: Multiple machines. Portable setups. Automated workflows. No self-sabotage.

Signing commits vs. decrypting secrets

Let’s separate two very different use cases: signing vs decrypting.

• Signing is about authorship. It’s your identity.
• Decrypting is about access. It’s local and practical.

So I use:

• The same signing subkey across all my machines — because no one cares where the commit came from, only who signed it.
• One encryption subkey per device — so I can add or revoke access per machine without affecting everything else.

This way:

• I sign commits and messages consistently, regardless of where I am
• I control which laptop, VM, or server can decrypt secrets — and I can rotate or revoke per device, not per person

It’s simple: identity stays the same, access adapts to hardware.

This gives real control, real ownership — and eliminates needless entropy.

Final thoughts

I still use GPG daily — for password-store, for SSH auth, for sharing encrypted data and signing git commits. But I use it my way, not the old way.

Don’t let best practices block you from accessing your own infrastructure.

Use what fits your rhythm, not someone else’s fear.

— Nuno