How to Create GPG Key Pairs: A 2026 Practical Guide

You’re probably here because something in your workflow stopped being optional.

A repository now requires signed commits. A release process needs artifact signing. A security review flagged unmanaged private keys sitting on laptops. Or your CI runners need a way to sign output without turning your pipeline into a secret-sprawl problem.

That’s when “create gpg key” stops being a basic developer task and turns into an operational decision. The command is easy. The hard part is choosing the right algorithm, setting expiration, keeping the master key offline, and making automation safe in containers and headless runners.

Why You Still Need to Create a GPG Key in 2026

The most common starting point is simple. A developer tries to push a commit, Git rejects it, and the platform expects a verified signature. That one moment usually leads to the larger question: how do we prove that code, packages, and deployment inputs came from the right person or system?

GnuPG has been around long enough to earn that role. GnuPG was released in 1999 by Werner Koch as a free implementation of PGP, which began in 1991 during the crypto wars to push back against restrictions on strong cryptography, according to the GnuPG key generation background. That history matters because GPG is not a trend tool. It’s infrastructure for trust.

Where teams actually use it

In practice, teams use GPG in a few places that directly affect production safety:

• Git commit signing helps prove authorship and makes policy enforcement possible in repositories that reject unsigned changes.
• Artifact signing gives operations teams a way to verify that a release bundle, package, or configuration file wasn’t modified after build.
• File encryption still matters when teams need to share sensitive exports, credentials bundles, or offline backups.
• Automation identity matters in CI/CD, where a pipeline may need to sign outputs or verify upstream signatures before promotion.

This is part of the same discipline as broader network security best practices. You’re reducing trust by assumption and replacing it with trust by verification.

Practical rule: If a system can promote code, publish artifacts, or approve a release, it needs a verifiable cryptographic identity.

GPG also remains useful because it spans individual and machine workflows. A laptop key can sign commits. A service key can sign release metadata. A secured offline master key can anchor both. That flexibility is why it still shows up in serious engineering environments instead of getting replaced by a single-purpose signing tool.

Choosing Your Key Type RSA vs Ed25519

A bad key choice usually does not fail on day one. It fails six months later when an old verification service rejects signatures, a CI runner cannot import the format you picked, or a security review asks why your production signing identity was built around convenience instead of long-term control.

Algorithm choice is an operations decision as much as a cryptography decision. Pick the key type based on where the key will live, which systems must verify it, and whether the identity belongs to a person, a build pipeline, or an offline root of trust.

What RSA still does well

RSA remains the conservative choice for enterprise environments with mixed tooling. Git hosting platforms, older GnuPG installations, compliance teams, hardware tokens, and internal verification scripts are more likely to accept RSA without surprises. GitHub’s guidance on generating a new GPG key still points many users toward RSA, especially when compatibility matters more than elegance.

Use RSA, usually at 4096 bits, when you need:

• Broad verifier support across old servers, legacy package tooling, and developer workstations
• Fewer exceptions in audits where reviewers are more comfortable with established algorithm choices
• A low-friction default for human users who will sign from multiple systems over several years

The trade-off is straightforward. RSA keys are larger, slower to use, and clumsier in automation. That overhead is manageable for a laptop key used a few times a day. It becomes more noticeable when dozens of ephemeral CI jobs import, access, and use signing material repeatedly.

Why Ed25519 fits modern pipelines

Ed25519 is usually the better operational fit for current Linux distributions, containerized build systems, and service identities that sign often. The keys are smaller, signing is faster, and the setup is cleaner when every runner starts from a blank state.

That matters in CI/CD. Short-lived runners benefit from smaller secret payloads and less overhead during import. Teams managing an offline master key with online signing subkeys also benefit, because Ed25519 subkeys are easier to handle in modern environments where you control both the signer and verifier.

Ed25519 is a strong choice when you want:

• Fast signing for high-frequency build and release jobs
• Smaller key material for secret injection into containers and ephemeral runners
• Modern defaults in environments you fully control

The catch is compatibility. Some older tooling, older smartcards, and stale enterprise images still create friction with ECC-based keys. If your release process crosses team boundaries or customer-managed verification systems, test that path before standardizing on Ed25519.

A practical decision table

Attribute	RSA (4096-bit)	Ed25519 (ECC)
Primary strength	Broad compatibility	Fast modern signing
Security position	Conservative enterprise default	Strong modern ECC option
Performance	Slower signing and verification	Faster signing and verification
Key size	Larger	Smaller
Best fit	Older or mixed environments	CI/CD and modern developer workflows
Main trade-off	More overhead	Less support in older systems

How I choose in production

For a personal key that must work everywhere, RSA is still the safer answer.

For enterprise signing architecture, I separate the decision by role. Keep the master certification key offline and optimize subkeys for their job. If the online subkeys will live in controlled runners, current developer machines, or isolated signing services, Ed25519 is usually the better day-to-day operator experience. If the key has to survive old images, third-party verifiers, or slow-moving enterprise change control, RSA reduces surprises.

Expiration belongs in this decision too. A modern algorithm does not fix poor lifecycle management. Shorter-lived online subkeys with planned rotation are easier to govern than one long-lived key that ends up copied into laptops, build agents, and containers.

Use RSA for compatibility across unknown or older systems. Use Ed25519 for speed and simpler operations in environments you control.

Generate Your GPG Key Interactively

Interactive generation is still the best path when you’re creating a personal key or your first enterprise identity. It forces you to make the choices consciously instead of inheriting defaults you haven’t reviewed.

Start with the full generator

Use this command:

gpg --full-generate-key

The full generator gives you more control than the quick path. If you want the most conservative setup for a high-trust identity, generate it on an air-gapped machine, choose RSA at 4096 bits, and protect it with a 20+ character passphrase built with a diceware-style method for roughly 128-bit entropy, as recommended in this detailed GPG keypair walkthrough.

That same source also notes that passphrase breaches account for 80% of key compromises, which is why passphrase quality matters even when the algorithm is strong.

What to choose at each prompt

The prompts vary a bit by version, but the decisions are straightforward.

1. Key type
   Choose RSA if you want maximum compatibility. Choose ECC only if you know the environments that must support it.

2. Key size
   If you picked RSA, use 4096 bits. Don’t create a long-lived production key with a weaker size just to save a little time.

3. Expiration
   Set an expiration date. A year or two is practical for most team workflows because it forces review and rotation.

4. Name and email Use the identity you want attached to signatures. Keep comments blank unless you have a strong reason to include one.

5. Passphrase
   This should be memorable to you and miserable for an attacker. Diceware-style passphrases work well because they avoid the usual “complex but reused” trap.

A useful checkpoint comes right after generation:

• gpg --list-secret-keys
• gpg --list-keys --fingerprint

The first confirms the secret key exists. The second gives you the fingerprint you’ll use for verification and later configuration.

Generate enough randomness

GPG may pause while collecting randomness. That’s normal. On a desktop, just continue normal input. On quiet systems, especially VMs, that pause can feel endless.

Don’t interrupt key generation because it feels slow. Randomness collection is part of the security model, not wasted time.

A visual walkthrough helps if you’re doing this for the first time:

What you just created

You now have two things:

• a public key, which others can use to verify your signatures or encrypt data for you
• a private key, which stays under your control and should never be casually copied between systems

That second part is where many otherwise careful teams fail. They generate a solid key, then scatter the private material across laptops, build agents, and backup folders. Creation is easy. Containment is the actual job.

Mastering Subkeys and Secure Backups

Most guides stop too early. They show how to generate a key, then leave you with a single private key that does everything. That’s fine for basic personal use. It’s weak for enterprise work.

A better pattern is offline master key, online subkeys. The master key exists mainly to certify identity. Daily work happens with subkeys for signing, encryption, and authentication.

Why this model is worth the effort

Using gpg --expert --edit-key to create separate signing, encryption, and authentication subkeys lets you keep the master key offline. That practice is vital for enterprise security and is overlooked by over 80% of beginner tutorials, according to this secure GPG key guide.

That separation changes your failure mode. If a laptop is compromised, you can revoke and replace the affected subkey without burning down your whole identity.

Build the subkey layout

After generating your primary key, open it for editing:

gpg --expert --edit-key <keyid>

Inside the editor, use addkey to create purpose-specific subkeys. A practical layout looks like this:

• Signing subkey for Git commits, release signatures, and artifact signing
• Encryption subkey for protected file exchange and encrypted storage workflows
• Authentication subkey if you also use GPG-backed authentication workflows

Keep expiration shorter on subkeys than you would on an unmanaged all-in-one key. Shorter life makes rotation easier and compromise less painful.

Back up the right things

This is the part that matters most after creation.

Create a revocation certificate:

gpg --output revoke.asc --gen-revoke <keyid>

Export the master private key for offline backup:

gpg --armor --export-secret-keys <keyid> > master-private.asc

Then store both offline. Not in cloud storage. Not in a shared team folder. Not on the same laptop where you do daily signing. Use encrypted removable media and a physically controlled location.

A revocation certificate is emergency infrastructure. If you wait until after compromise, you waited too long.

What works and what doesn’t

What works:

• Master key kept offline
• Subkeys copied to daily-use systems
• Revocation certificate created immediately
• Documented rotation and recovery steps

What doesn’t:

• One key used everywhere
• Private key exports left on local disks
• No revocation plan
• Subkeys with unclear purpose

If you’re running production systems, the point isn’t elegance. It’s reducing blast radius. Subkeys do that well.

Automating GPG Key Generation for CI CD

A release pipeline is the wrong place to stop for an interactive prompt. In production, that usually happens at the worst time. A tag is ready, artifacts are built, and the signing step hangs because GPG wants a TTY, a passphrase, or entropy the runner does not have. Batch generation avoids that class of failure and gives security teams something they can review and enforce.

Use batch generation for repeatability

For CI/CD, define key parameters in a file and generate keys non-interactively. That turns key creation into code. You can review it, version it, and keep every runner on the same policy for algorithm choice, usage flags, and expiration.

A basic batch file looks like this:

cat > keygen.asc <<'EOF'
Key-Type: ECC
Key-Curve: Curve25519
Key-Usage: sign,auth
Subkey-Type: ECC
Subkey-Curve: Curve25519
Subkey-Usage: encrypt
Name-Real: CI Signing Key
Name-Email: [email protected]
Expire-Date: 1y
Passphrase: ${GPG_PASSPHRASE}
%commit
EOF

Then run:

gpg --batch --gen-key keygen.asc

Use this approach carefully. Pipelines should rarely mint long-lived production identities on demand. The safer pattern is to generate keys in a controlled process, keep the primary identity offline, and distribute only the subkey material a runner needs. Batch generation still matters there because it gives you a consistent, auditable way to build test keys, short-lived environment keys, or tightly scoped signing keys for isolated workflows.

Keep the GnuPG home ephemeral

Container runners create a specific problem. Key material can survive in cached layers, mounted workspaces, or reused volumes long after the job finishes. I have seen teams clean up artifacts and still leave a full secret keyring behind in a shared runner path.

Set a temporary GNUPGHOME for any job that does not need persistence:

export GNUPGHOME="$(mktemp -d)"
chmod 700 "$GNUPGHOME"

After the job finishes, remove it explicitly:

rm -rf "$GNUPGHOME"

That is simple, and it closes one of the easiest ways to leak signing keys in containerized CI.

Passphrases belong in the secret store

Treat the passphrase like any other production secret. Do not place it in a repository, a Dockerfile, or a copied pipeline example that turns into long-term configuration.

Good patterns include runtime injection from the CI platform, short-lived retrieval from a secrets backend, and job-scoped exposure only for the signing step. Weak patterns include plaintext variables in source control and shared pipeline templates that expose the same passphrase across unrelated projects.

Teams that are tightening release controls usually need this discipline everywhere, not just around GPG. That is the same mindset behind broader scalable CI/CD practices.

Solve Common Failures

Most pipeline failures around GPG come from the runtime, not from the cryptography.

• Low entropy
  Headless workers and fresh containers can block during first-time key generation. Seed the runner properly with host entropy sources, or configure tools such as rng-tools where your platform allows it.

• No agent available
  Minimal images often start without the GPG agent. If signing fails, launch it explicitly with gpgconf --launch gpg-agent.

• TTY and pinentry problems
  CI jobs do not have an interactive terminal. Use batch-safe options and make sure the passphrase delivery method matches the runner environment.

• Persistent key leftovers
  Use a temporary GNUPGHOME and delete it at the end of the job.

• Wrong key usage
  A pipeline that signs releases should use a signing-capable key or subkey, not a general key generated without purpose flags.

• Rotation ignored
  Set expiration when you create the key and schedule renewal before the next release train depends on it.

For teams tuning throughput and reliability across the delivery path, CI/CD pipeline optimization patterns are useful context. Signing, verification, and secret handling work best when they are designed into the pipeline from the start, not added after the first failed release.

Common GPG Operations and Troubleshooting

Once the key exists, daily use is simple. Most frustration comes from a small set of commands and a few recurring errors.

Commands you’ll actually use

Here are the basics:

• Export your public key gpg --armor --export <keyid> > public.asc

• Import someone else’s public key gpg --import colleague.asc

• Sign a file gpg --sign file.txt

• Verify a signature gpg --verify file.txt.sig

• List secret keys gpg --list-secret-keys

• Show fingerprints gpg --list-keys --fingerprint

Those cover most day-to-day work for commit signing, release verification, and secure file exchange.

Fix the usual breakages fast

When GPG says secret key not available, check whether the key is present in the current keyring and whether you’re running under the expected user account. This error often shows up when a shell, CI step, or container points at the wrong GNUPGHOME.

If signing hangs or prompts fail in automation, the agent is usually the culprit. Start it explicitly if needed, and confirm the environment can access the passphrase source you intended.

If you forget the passphrase, recovery is not something you should count on. In practice, that means you either still have a decrypted working environment, an offline backup, or you revoke and replace the key.

Treat lost passphrases like lost credentials with stronger consequences. Plan replacement before you need it.

A quick operating habit that saves time

Keep a small runbook for your team with:

• the key fingerprint
• where the revocation certificate is stored
• who can access offline backups
• how to rotate subkeys
• how CI imports the signing material

That prevents “tribal knowledge” from becoming a production dependency. If your team is already standardizing incident response and debugging, these software troubleshooting habits fit naturally alongside key management.

A GPG setup is only useful if people can operate it under pressure. The strongest key in the world won’t help if nobody knows how to export the public key, verify a signature, or revoke a compromised subkey.

---

If you’re building safer release workflows, GoReplay helps teams validate changes against real production traffic before deployment, which pairs well with signed commits, signed artifacts, and tighter CI/CD controls.