OpenPGP subkeys explained — separate keys for signing, encryption, and authentication

A modern OpenPGP "key" is actually a small bundle: one primary key plus one or more subkeys. The primary signs and certifies. Subkeys do the day-to-day work of encryption and signing. Splitting them this way is one of the few unambiguously-good operational practices in PGP.

Why subkeys exist

The primary key carries your identity. Its fingerprint is what others verify, what you publish, what people sign at key-signing parties, what links to your user ID. Rotating the primary means losing all that accumulated trust — every signature on it, every published reference, every business card.

You also want to use a key on devices where it might be exposed: encrypting messages on your laptop, signing emails on your phone. If those daily-use keys are the primary, a single compromised device burns the entire identity.

Subkeys solve both problems. The primary stays cold (offline, air-gapped, or only used to certify). Subkeys go on the daily devices. If a subkey is compromised, you revoke just that subkey, the primary signs a new replacement, and your identity continues with no loss of accumulated trust.

The three subkey roles

• Sign (S) — produces signatures on messages, files, commits, package releases. The most-used subkey for many people.
• Encrypt (E) — receives encrypted messages. When someone encrypts to you, their tool picks your encryption subkey from the public key bundle.
• Authenticate (A) — used as an SSH key (via gpg-agent), for client TLS auth, or other "prove identity to a server" workflows. Optional.

Each role can have multiple subkeys (e.g. one current + one for backup) and each can have a different algorithm (RSA-4096 for sign, Curve25519 for encrypt, etc.). Subkeys can also have their own expiry dates, independent of the primary.

Default behavior

When you generate a key with most modern tools — GPG, OpenPGP.js, this app — you automatically get a primary + an encryption subkey + (depending on the tool) a signing subkey. The Encrypt and Sign tools here use the primary for signing because the bundle ships a single signing-capable subkey by default; full split-role generation is more common from the command line.

For a casual user, the default is fine. For long-term operational hygiene, you want the four-subkey setup: cold primary (Certify only), online sign subkey, online encrypt subkey, optional authenticate subkey.

Practical workflow with GPG

Set up once with the offline-primary pattern:

gpg --quick-generate-key "Alice <[email protected]>" ed25519 cert never
gpg --edit-key [email protected]
  > addkey   # add a sign subkey
  > addkey   # add an encrypt subkey
  > addkey   # add an auth subkey
  > save

Then export the primary private key to a USB stick, store it offline, and remove it from your daily keyring with gpg --delete-secret-keys (the subkeys stay; this is the gpg-specific "stub" pattern). Day-to-day sign/encrypt operations now run from subkeys only — the primary is only needed when you add or revoke another subkey, which should be rare.

Rotating a subkey

• Plug in the offline primary.
• gpg --edit-key [email protected], run addkey to mint a fresh subkey of the appropriate role.
• Optionally revkey the old subkey to rotate it out (or just let it expire).
• gpg --send-keys to publish the updated public key. Recipients will pick up the new subkey on next refresh.

Their existing encrypted-to-old-subkey messages still decrypt with the old subkey, which you keep around for archive access. New messages will use the new subkey automatically.