PGP key questions: fingerprints, subkeys, algorithms, expiry
Your OpenPGP key is really a bundle: a primary key, one or more subkeys, your names and email addresses, and signatures that tie them together. The questions below explain how to identify a key safely, which algorithm to pick, and how to keep a key usable for years.
Identifying keys
What is the difference between a key ID and a fingerprint?
The fingerprint is a hash of the public key. For the common version 4 keys it is a 160-bit SHA-1 hash, written as 40 hexadecimal digits, often in groups of four:
F5CB B616 339D 2765 9CF3 A6A0 DA9A A34B BCE5 6058
A key ID is just a piece of the fingerprint. The "long" key ID is the last 16 digits (DA9AA34BBCE56058 above); the "short" key ID is the last 8 (BCE56058). Key IDs are handy labels, but RFC 9580 warns that they are not guaranteed to be unique. Current GnuPG versions therefore show the full fingerprint by default; you can change this with --keyid-format.
In PGP 2.x it worked differently: the key ID of a version 3 RSA key was simply the lowest 64 bits of the RSA modulus, and the fingerprint was an MD5 hash. Both are deprecated.
Why are 8-digit (short) key IDs unsafe?
Because they are easy to fake. In 2014 the Evil32 project generated a key with a matching short ID for every key in the web of trust's "strong set", and reported that a colliding 32-bit ID takes about 4 seconds on a GPU. Keyservers accepted these keys, so a command like gpg --recv-keys BCE56058 could import an attacker's key. Always use the full fingerprint when you fetch, sign or trust a key, and compare all 40 digits with the owner. More on how lookups work: HKP and key IDs.
Two keys have the same name. How do I choose the right one?
Anyone can create a key with any name and email address, so names prove nothing. Use the fingerprint in commands, for example gpg -r F5CBB616339D27659CF3A6A0DA9AA34BBCE56058 -e file, and confirm the fingerprint with the person. Once you have checked a key, certify it with gpg --quick-lsign-key FINGERPRINT so GnuPG knows it is valid; see key signatures.
Structure and algorithms
Why does my key have a primary key and a subkey?
A new GnuPG key looks like this:
pub ed25519 2026-11-04 [SC] [expires: 2029-11-03]
F5CBB616339D27659CF3A6A0DA9AA34BBCE56058
uid [ultimate] Alice Example <alice@example.org>
sub cv25519 2026-11-04 [E]
The pub line is the primary key. Its letters mean S = sign and C = certify (sign other keys and your own user IDs and subkeys). The sub line is a subkey for E = encryption. A key may also have an authentication subkey (A), used for SSH. The fingerprint everyone checks belongs to the primary key; subkeys can be added, replaced or revoked later without changing it.
PGP 2.x keys had no subkeys: one RSA key did everything. Splitting the roles lets you keep the primary key offline or on a smartcard and use subkeys every day.
Should I choose Ed25519/Curve25519 or RSA?
For a new key, take the GnuPG default: Ed25519 for the primary key and Curve25519 (cv25519) for encryption. It has been the default since GnuPG 2.3.0 (2021), the keys and signatures are small and fast, and RFC 9580 requires every implementation to support Ed25519 and X25519.
Choose RSA only if someone you must work with uses very old software or a device without elliptic-curve support. Then use 3072 or 4096 bits: RFC 9580 forbids generating RSA keys below 3,072 bits. Larger RSA keys are slower and much bigger. For post-quantum options, see security questions.
What are version 4, 5 and 6 keys?
- Version 4 is the format defined in RFC 4880 (2007) and used by almost every key in use. GnuPG still creates version 4 keys by default.
- Version 6 is the new format in RFC 9580 (2024). It uses 256-bit SHA-256 fingerprints and salted signatures. RFC 9580 deprecates version 4 keys but says implementations should still accept them.
- Version 5 comes from LibrePGP, the specification the GnuPG developers follow. GnuPG uses it for some newer key types, such as X448 and its Kyber post-quantum keys.
Version 5 and version 6 keys are not interchangeable, and a program that supports one does not necessarily support the other, so for the widest compatibility a version 4 Ed25519 key is still the safe choice as of November 2026. Background: OpenPGP standards.
Expiry and maintenance
Should my key have an expiry date?
Yes. An expiry date is a safety net: if you lose the private key and the revocation certificate, the key still stops being used one day. It is not a deadline you must meet, because you can extend it whenever you like. GnuPG 2.4.3 and later give new keys a default lifetime of 3 years; versions from 2.1.17 up to that point used 2 years. Put a reminder in your calendar a month before the date.
How do I extend the expiry date?
gpg --quick-set-expire FINGERPRINT 2y
gpg --quick-set-expire FINGERPRINT 2y '*'
The first command extends the primary key, the second extends all valid subkeys. Then publish the updated public key again, for example with gpg --armor --export FINGERPRINT > mykey.asc, and upload or send it. Your contacts must refresh their copy, or they will keep seeing the old date.
My key still prefers SHA-1 or old ciphers. How do I fix that?
Old keys carry the algorithm preferences that were current when they were made. Update them to GnuPG's current default list and republish the key:
gpg --quick-update-pref FINGERPRINT
You can see a key's preferences with gpg --list-options show-pref -k FINGERPRINT.
Backups and multiple identities
How do I back up my key?
Export the private key (which also contains the public parts) to a file and store it offline, for example on two USB sticks kept in different places:
gpg --armor --export-secret-keys FINGERPRINT > secret-key-backup.asc
The file is still protected by your passphrase, but treat it as sensitive. Also copy the revocation certificate from ~/.gnupg/openpgp-revocs.d/, which GnuPG creates automatically for each new key. The GnuPG manual notes that the external tool paperkey makes better paper backups. Step by step: backup and revoke.
How do I add another email address to my key?
gpg --quick-add-uid FINGERPRINT 'Alice Example <alice@work.example>'
Each name and address is a separate user ID on the same key. GnuPG uses the key for any of them. If you no longer use an address, revoke that user ID with --quick-revoke-uid rather than deleting it, so the change reaches other people's copies. Republish the key after either change.
Should I have one key or several?
One key with several user IDs is simplest: people need to check only one fingerprint. Separate keys make sense when the roles must stay apart, for example a work key your employer manages, a key for signing software releases that lives on a dedicated machine, or a pseudonymous identity that must not be linked to your real name (user IDs on the same key are visible to everyone who has the key).
Should I put my public key in my email signature?
Put your fingerprint there, or a link to where your key is published, not the whole key block, which is long and adds nothing a fingerprint does not. Publishing the key itself is easier through keys.openpgp.org or a Web Key Directory on your own domain; see keys.openpgp.org and Web Key Directory.
Sources
- RFC 9580: OpenPGP (sections 3.3, 5.5 and 12.4), RFC Editor
- Evil32: short key ID collisions
- gpg configuration options (--keyid-format), GnuPG manual
- OpenPGP key management commands, GnuPG manual
- Operational gpg commands (--export-secret-keys), GnuPG manual
- gpg configuration files (openpgp-revocs.d), GnuPG manual
- GnuPG NEWS file (2.1.17, 2.3.0, 2.4.3 changes), GnuPG repository mirror
- GnuPG key generation source (default algorithms, expiry, key versions), GnuPG repository mirror
- gpg manual source (quick-set-expire, quick-add-uid, quick-update-pref), GnuPG repository mirror
- LibrePGP Message Format (draft-koch-librepgp), IETF Datatracker