GnuPG is still the tool I reach for when the question is “can I certify, sign, encrypt, and authenticate without giving a vendor the private material.” The onboarding is famously unkind. That is not a reason to skip it. It is a reason to treat the primary secret as a rare, offline object, and to do the daily work with subkeys.
This is the expert path. If you want a smaller modern default, age for files and SSH keys for login will take you a long way. OpenPGP earns its beard when you need a web of certification, mail, git signatures, and a key you can keep in a drawer.
Basics · What a key is doing here
A public key is something you can publish. A private key is something that must stay under your control. Certification says “this identity belongs with this key.” Signing says “this file or message is from me.” Encryption is for confidentiality. Authentication is for logging in (for example SSH via gpg-agent). You can split those jobs across subkeys so the most dangerous secret — the one that can mint the others — does not live on the laptop you take on a train.
A certification-only primary, then three jobs
The arrangement I use, and documented at length in GnuPG Keys Management, is:
- one primary key whose only capability is certify,
- three subkeys: sign, encrypt, authenticate,
- the primary secret stored on encrypted removable media and then deleted from the daily computer,
- optional offload of the subkeys to an OpenPGP smartcard.
GnuPG’s current defaults prefer ECC (Ed25519 / Cv25519). That is a reasonable intermediate choice: fast, small, well supported. I still generate a large RSA certification key when I want the conservative, widely-understood primary. Do not paste a passphrase into a batch template. pinentry exists for a reason.
gpg --list-secret-keys --fingerprint --with-keygripUse the full fingerprint, never a short key ID. Short IDs were a collision hazard. A keygrip is a different identifier, used by gpg-agent for one secret component. Mixing them up is how people delete the wrong thing.
Export, then prove the export, then delete
An export command is not a backup. Exports made after a key was moved to a card, or after the primary secret was already removed, can contain stubs. Before you delete anything, restore into a throwaway home in RAM:
umask 077
TEST_GNUPGHOME="$(mktemp -d /dev/shm/gnupg-test.XXXXXX)"
gpg --homedir "$TEST_GNUPGHOME" --import ./primary.private-key.sec
gpg --homedir "$TEST_GNUPGHOME" --list-secret-keys --fingerprintYou want sec (not sec#) and real ssb lines for the subkeys. gpg --list-packets will show gnu-dummy or gnu-divert-to-card if you exported a stub. Only then:
gpg --delete-secret-keys "${FINGERPRINT}!"
gpg --list-secret-keys "$FINGERPRINT"The quoted ! selects the primary only. Without it you can take the subkeys with you. After a correct deletion the daily keyring shows sec#. If the subkeys later live on a YubiKey, expect ssb> instead of ssb.
Store, on the encrypted volume: the full secret export, a subkeys-only export, the public key, ownertrust, and revocation certificates for the usual reasons (none, compromised, superseded, no longer used). Generate those certificates while you still have the primary. Importing a secret into a new home does not recreate openpgp-revocs.d for you. Check the home you think you are using:
gpgconf --list-dirs homedirUsing the offline primary
Certification — adding a uid, signing someone else’s key, making a new subkey — means mounting the encrypted volume and, preferably, working from a clean GNUPGHOME, not from the daily agent. Then unmount. The laptop that signs git commits should not be able to mint a new identity.
Keep the encrypted volume out of the bag you take every day if you can. Two-person knowledge of where it lives is more useful than a third copy in “the cloud folder.”
Intermediate · If you are not ready for an offline primary
Then do not pretend. Generate Ed25519/Cv25519 keys with an expiration, put a revocation certificate somewhere you will find after a disk death, and back up ~/.gnupg onto encrypted media you have actually restored. age (age-keygen, age -r) is a cleaner tool for file encryption if you do not need the OpenPGP web of trust. SSH keys are a cleaner tool for login. You can graduate to an offline certification key later. You cannot un-leak a primary that sat in a laptop bag for three years.
What this is not
It is not a tutorial for encrypting a joke on a mailing list. It is not an argument that everyone must use RSA-8192. It is the shape of a key whose most dangerous part you can keep in a drawer, whose daily parts you can replace, and whose recovery you have watched work in /dev/shm before you needed it.
The full command walkthrough — templates, subkey capabilities, card offload — lives in the guide linked above. This essay is the reason that guide is so fussy. The fuss is the practice.
