🔑 Managing GPG Keys and Encrypting Files on Linux

I avoided GPG for years. Every time I needed to encrypt a backup or verify a signed release, I would copy-paste some command from a wiki, watch it fail with a cryptic keyring error, and quietly give up. The mental model never clicked. What finally fixed that was sitting down for an afternoon, generating a real key, breaking my own keyring on a throwaway VM, and treating an AI assistant like a fast junior engineer who could draft the commands while I checked every flag before pressing enter. This post is the guide I wish I had: accurate commands, the reasoning behind them, and a hard rule I will repeat more than once. Never hand the AI your private key.

Generating a Key Pair the Right Way

Modern GPG makes key generation interactive and sane. Use the full flow so you control the algorithm and expiry:

gpg --full-generate-key

Choose ECC (sign and encrypt) if your version offers it, or RSA and RSA with a 4096-bit length if you want maximum compatibility. Set an expiry of one or two years rather than “key does not expire” — you can always extend it, and an expiry date limits the blast radius if you lose control of the key. GPG will ask for your real name, email, and a passphrase. Pick a strong passphrase; it is the only thing protecting the private key on disk.

When it finishes, confirm the key exists:

gpg --list-keys
gpg --list-secret-keys --keyid-format=long

The --keyid-format=long flag prints the long key ID, which you will use to reference the key in later commands. The fingerprint shown is what other people verify out of band before trusting you.

Pro Tip: An AI assistant is excellent at explaining what each prompt in --full-generate-key means, but generate the key yourself on the target machine. There is never a reason to paste a private key or passphrase into a chat window.

Encrypting and Decrypting Files

To encrypt a file for a specific recipient, you reference their public key by email or key ID:

gpg --encrypt --recipient alice@example.com report.tar

This produces report.tar.gpg, readable only by Alice’s private key. To encrypt for yourself and a colleague at once, repeat the flag:

gpg --encrypt --recipient alice@example.com --recipient me@example.com report.tar

Add --armor to get ASCII-armored output (.asc) that survives email and copy-paste:

gpg --encrypt --armor --recipient alice@example.com report.tar

Decryption is symmetric in spelling but not in keys — only the holder of the matching private key can read it:

gpg --decrypt report.tar.gpg > report.tar

GPG will prompt for your passphrase through the agent. If you script this on a server, resist the urge to embed the passphrase in plaintext. If you are wiring encryption into an incident workflow, a tool like the Incident Response dashboard can capture the context while the actual key operations stay on a trusted host.

Symmetric Encryption Without Keys

Sometimes you just need a password-protected file and no key pair at all. Symmetric mode uses a passphrase as the shared secret:

gpg -c secret-notes.txt

The -c (or --symmetric) flag prompts for a passphrase twice and writes secret-notes.txt.gpg. Anyone with the passphrase can decrypt it with gpg --decrypt. This is handy for one-off transfers, but it shifts the entire security burden onto how you share the passphrase. Use a real secrets channel, not the same email as the file.

Signing and Verifying

Encryption hides contents; signing proves origin and integrity. For a detached signature — a separate file that sits alongside the original — use:

gpg --detach-sign --armor release.tar.gz

That writes release.tar.gz.asc. Anyone with your public key verifies it without altering the original artifact:

gpg --verify release.tar.gz.asc release.tar.gz

To bundle the signature and data together, use --sign, or --clearsign for human-readable text where the signature wraps the original content inline. Detached signatures are the standard for software releases because the artifact stays byte-for-byte identical. When you ask an AI to help audit a release pipeline, this is the kind of mechanical check it drafts well — but treat its output like a code review draft from a junior engineer and confirm the signer’s fingerprint yourself.

Exporting, Importing, and Sharing Keys

To share your public key, export it in armored form:

gpg --export --armor me@example.com > mypubkey.asc

Hand that file to anyone who needs to encrypt to you or verify your signatures. To import a key someone sent you:

gpg --import theirpubkey.asc

Exporting the private key is a deliberate, dangerous act reserved for backups and trusted migrations:

gpg --export-secret-keys --armor me@example.com > private-backup.asc

Store that output on encrypted, offline media. This file plus the passphrase is your full identity.

Pro Tip: This exported secret key is exactly the thing you must never paste into an AI tool, a pastebin, or a CI log. The AI is a fast assistant for drafting gpg commands and explaining errors; it is not a vault, and it should never see production credentials or private keys.

Managing Trust, Expiry, and Edits

Day-to-day key administration happens inside the interactive editor:

gpg --edit-key alice@example.com

At the gpg> prompt, trust lets you set how much you vouch for a key, expire updates the expiration date on your own key (extend it before it lapses rather than rebuilding from scratch), and adduid adds a new identity. Run save to commit changes or quit to discard. The trust model is what makes the web of trust work, so set it deliberately rather than blindly marking everything ultimate.

If you want a curated set of starting prompts for explaining these flows or generating safe runbooks, the prompt library and the prompt packs are built for exactly this kind of Linux administration task. You can iterate on them interactively in the prompt workspace before committing anything to a real host.

Revocation and Backup Discipline

Generate a revocation certificate the day you create the key, not the day you need it. Modern GPG produces one automatically under ~/.gnupg/openpgp-revocs.d/, but you can also create one explicitly:

gpg --output revoke.asc --gen-revoke me@example.com

If your key is ever compromised or lost, importing this certificate and pushing it tells the world to stop trusting the key. Store it separately from the key itself — a revocation cert on the same disk as the key it revokes helps no one after a drive failure.

A complete backup is three things on encrypted offline media: the exported secret key, the exported public key, and the revocation certificate. Test the restore on a clean machine at least once. A backup you have never restored is a hypothesis, not a safety net.

For ongoing visibility into key expiry and certificate health across a fleet, wire reminders into your monitoring and alerts setup so an expired signing key never surprises a release.

Conclusion

GPG stops being intimidating once you have generated a key, signed a file, and recovered from a deliberately broken keyring on a VM you do not care about. The commands above cover the full lifecycle: generation, encryption, signing, sharing, trust, expiry, revocation, and backup. Lean on an AI assistant the way you would lean on a sharp junior engineer — let it draft commands and explain errors fast, then verify every flag and fingerprint yourself. Keep the human in the loop, keep the private key off the network, and GPG becomes one of the most reliable tools in your Linux toolkit. For more in this vein, browse the rest of the Linux admins category.