Generating and Managing GPG Keys: Best Practices

OpenPGP remains a foundational standard for end-to-end encrypted messaging, decentralized identity verification, and digital artifact signing. Implemented predominantly through GNU Privacy Guard (GnuPG or GPG), the security of an OpenPGP workflow does not rest solely on the mathematical resilience of its underlying algorithms, but on the operational security (OpSec) deployed during key generation, storage, and maintenance. Misconfigurations, poor key separation, and failure to anticipate endpoint compromise often undermine the cryptographic guarantees GPG aims to provide. Establishing an auditable, defensive key management lifecycle is critical for high-risk individuals, journalists, and security practitioners.

Cryptographic Primitive Selection: RSA vs. Modern ECC

Historically, OpenPGP implementations relied extensively on the RSA (Rivest-Shamir-Adleman) cryptosystem. While an RSA key with a modulus of 4096 bits remains computationally robust against brute-force attacks by classical computers, it carries significant operational disadvantages: large key sizes, slow key generation and decryption speeds, and a higher vulnerability to implementation-specific timing side-channel attacks.

Modern implementations favor Elliptic Curve Cryptography (ECC), specifically Curve25519 primitives formalized in OpenPGP under RFC 9580 (and previously RFC 4880bis drafts):

Ed25519 (Edwards-curve Digital Signature Algorithm): Utilized for digital signatures and identity certification. It provides approximately 128 bits of symmetric security with exceptionally compact 32-byte public keys and deterministic signature generation, mitigating risks associated with compromised random number generators.
X25519 (Montgomery curve): Utilized for Elliptic Curve Diffie-Hellman (ECDH) key exchange, handling message encryption.

Unless backward compatibility with legacy hardware tokens or deprecated software suites is strictly required, practitioners should generate native Ed25519/X25519 keypairs. If RSA must be retained for institutional compliance, use a key size of exactly 4096 bits. RSA-2048 should be considered legacy and deprecated for long-term identities.

Architectural Separation: Primary Keys vs. Operational Subkeys

A fatal architectural mistake is utilizing a single keypair for all cryptographic operations across multiple machines. OpenPGP resolves this via the subkey mechanism. A robust key topology isolates responsibilities across distinct keys bound cryptographically to a master identity.

A complete OpenPGP identity architecture consists of four distinct capabilities:

Certify [C]: The Primary (Master) Key. Its sole responsibility is identity management: creating subkeys, issuing identity revocations, updating expiration dates, and cross-signing other entities' public keys in the Web of Trust.
Sign [S]: Operational subkey used strictly for signing documents, git commits, software releases, and plain emails.
Encrypt [E]: Operational subkey used exclusively for asymmetric decryption of transport or storage payloads.
Authenticate [A]: Operational subkey repurposed for non-OpenPGP protocols, primarily serving as an SSH authentication key via the gpg-agent SSH daemon.

Defensive Principle: The Certify master key should never reside on an internet-connected, daily-driver workstation. It must be generated in an isolated environment, backed up to cold storage, and stripped from the daily operating environment. Only the operational subkeys ([S], [E], [A]) are deployed on host endpoints. If an endpoint is compromised, only the subkeys are exposed; the identity itself remains intact and can issue immediate subkey revocations.

Hardened Key Generation Protocol

Generating keys on a multi-tenant, network-attached, or compromised operating system invalidates all forward guarantees. The generation phase must be conducted in an air-gapped, pristine environment—such as a dedicated machine booted into a stateless live Linux distribution (e.g., Tails or an air-gapped Debian live image without networking enabled).

Step 1: GPG Daemon Hardening

Before initializing the key, verify that your ~/.gnupg/gpg.conf enforces modern cipher preferences, hashes, and compression algorithms. Recommended configuration defaults include:

personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed
default-preference-list SHA512 SHA384 SHA256 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed
cert-digest-algo SHA512
s2k-digest-algo SHA512
s2k-cipher-algo AES256
charset utf-8
no-comments
no-emit-version
no-greeting
keyid-format 0xlong
with-fingerprint
list-options show-uid-validity
verify-options show-uid-validity

Step 2: Generating the Master Key

Initialize GPG using the expert menu to specify curve parameters directly:

gpg --expert --full-generate-key

When prompted, select (11) ECC (set your own capabilities). Toggle capabilities so that the key holds only the Certify capability. Next, select (1) Curve 25519. Assign a reasonable expiration date (e.g., 2 years) and attach a single, canonical User ID (Name and Email).

Step 3: Appending Operational Subkeys

Once the primary key is generated, edit the key to append the Signing, Encryption, and Authentication subkeys:

gpg --expert --edit-key <PRIMARY_KEY_FP>
gpg> addkey

Repeat the addkey workflow three times:

Select (10) ECC (sign only) using Curve 25519 for the [S] subkey.
Select (12) ECC (encrypt only) using Curve 25519 for the [E] subkey.
Select (11) ECC (set your own capabilities), clear all flags, enable Authenticate, and assign Curve 25519 for the [A] subkey.

Commit the changes via save. Ensure all subkeys have defined expiration intervals aligned with your key rotation policy.

Hardware Security Tokens and Storage Isolation

Even isolated subkeys remain vulnerable to memory dumps or persistence malware if stored on workstation storage drives. The industry standard defense is transferring subkeys onto an OpenPGP-compliant Hardware Security Module (HSM) or smartcard, such as a YubiKey or Nitrokey.

Hardware tokens provide cryptographic boundaries: private keys are transferred onto the smartcard's secure element, after which they can never be extracted into host memory. Cryptographic signing, decryption, and challenge-response authentication occur directly on the chip.

Moving Subkeys to Hardware

Within the GPG interactive shell, use the keytocard command:

gpg --edit-key <PRIMARY_KEY_FP>
gpg> key 1
gpg> keytocard
# Assign to the Signature slot
gpg> key 1
gpg> key 2
gpg> keytocard
# Assign to the Encryption slot
gpg> key 2
gpg> key 3
gpg> keytocard
# Assign to the Authentication slot
gpg> save

The keytocard operation is destructive; it moves rather than copies the local secret key data to the hardware token, leaving behind a key stub (indicated by an arrow sec# or ssb> in gpg -K). Ensure a full offline encrypted backup is completed prior to executing this step.

Lifecycle Management: Expiration, Rotation, and Revocation

A key management plan must anticipate loss, theft, and migration. Relying on an indefinite key validity is a severe operational anti-pattern.

Pre-generating Revocation Certificates

A revocation certificate allows you to permanently invalidate your key on keyservers and verification clients if the primary secret key or revocation material is lost or compromised. Modern GnuPG automatically generates a revocation certificate under ~/.gnupg/openpgp-revocs.d/, but creating a documented, explicit backup certificate is mandatory:

gpg --output primary-revocation.asc --gen-revoke <PRIMARY_KEY_FP>

Store this revocation certificate on paper (e.g., printed as text and as a high-density QR code via qrencode) or write-once media (optical CD-R), isolated completely from network exposure.

The Practice of Key Expiration

Setting an expiration date is not an emergency cutoff switch; it is a mechanism for enforcing key health checks. If an individual drops off the grid or dies, an expired key signals to the ecosystem that communications should halt.

Before a key expires, the holder boots their secure, air-gapped system holding the master certify key and extends the validity period:

gpg --edit-key <PRIMARY_KEY_FP>
gpg> expire
# Select new expiration (e.g., 1y)
gpg> key 1
gpg> expire
# Extend subkey validity
gpg> save

Extending key expiration does not change the key fingerprints or alter the underlying cryptographic relationships. The updated public key is simply re-exported and redistributed.

Distribution, Public Key Hygiene, and the Web of Trust

Publishing and retrieving public keys historically relied on the SKS keyserver network using the HKP (HTTP Keyserver Protocol). This network suffered structural vulnerabilities, primarily keyserver poisoning via unauthenticated signature injection (an attacker could attach millions of invalid signatures to an identity, causing memory exhaustion and denial-of-service in client software).

Modern public key distribution must utilize cryptographically bound or validated distribution architectures:

Web Key Directory (WKD): A protocol whereby domains host verified public keys via a strict HTTPS path (/.well-known/openpgpkey/...). GPG can query this directory automatically via the target's email domain, ensuring authentication matches the transport layer security of the provider.
Validating Keyservers: Services such as keys.openpgp.org enforce cryptographic identity challenges (sending an encrypted verification link to the UID email address) and strip non-essential third-party signatures to avoid poisoning.
Cryptographic Attestation Platforms: Protocols such as Keyoxide bind public keys to decentralized platforms, DNS records, and social endpoints using OpenPGP notations and cryptographic claims.

Public keys should never be imported blindly. When establishing out-of-band trust, verify the full 40-character hexadecimal fingerprint—never trust short 8-character or long 16-character Key IDs, which are trivial to collide using hash collision attacks (such as spoofing the lowest 32 bits via GPU brute-forcing).

Defensive Posture as Operational Discipline

Cryptographic systems degrade when operational friction drives users toward shortcuts. Isolating the primary master key, operating entirely via hardware-secured subkeys, enforcing strict expiration deadlines, and transitioning away from vulnerable public keyserver infrastructure transforms GnuPG from an unwieldy legacy tool into an enterprise-grade communications bastion. Security lies not in the algorithm alone, but in the discipline of key lifecycle management.