Why you should use GPG over other identity verification alternatives

Introduction: Trust in the Digital Age

In an era where digital trust is both critical and fragile, verifying the identity of someone who signs code, emails, or documents is paramount. Whether you’re pushing commits to an open-source project, sending secure communications, or distributing software, your reputation and the security of others depend on the authenticity of your cryptographic identity.

Amid various modern alternatives like SSH signatures, Sigstore, or GitHub verification badges, GPG (GNU Privacy Guard) remains a gold standard. It’s time-tested, decentralized, cryptographically robust, and under your control. In this article, you’ll learn why GPG is still the right choice, how to set it up properly, and how to publish your key securely using a Web Key Directory (WKD).

Why GPG still matters

1. Decentralization without compromise

Unlike centralized services like GitHub or GitLab that act as identity gatekeepers, GPG operates on a Web of Trust model. You can self-host your identity, share it on your own domain, and never depend on a third party to vouch for you.

2. Granular trust control

You decide who you trust. You can inspect and sign others’ keys, or let them sign yours. This model is more robust than blindly trusting a cloud provider that could be compromised or co-opted.

3. Separation of duties via subkeys

GPG allows you to use a secure master key (stored offline) and dedicated subkeys for everyday actions like signing Git commits. This minimizes risk while preserving security.

4. Ubiquity across the open-source ecosystem

GPG is widely supported in Linux distributions, Git, email clients, and package managers. It’s also the cornerstone of software distribution security for projects like Debian and Arch Linux.

Understanding GPG Key Architecture: Master vs Subkeys

The master key

• Used to certify (sign) other keys and UIDs.
• Should be kept offline (e.g., air-gapped USB device).
• Acts as your long-term identity root.

Subkeys

• Used for specific tasks:
• Signing subkey: for signing Git commits, emails, and files.
• Encryption subkey: for receiving encrypted messages.
• Authentication subkey: for SSH login or VPN access.
• Can be kept on daily-use machines or smartcards (e.g., YubiKey).

This model ensures that even if a subkey is compromised, your core identity remains secure.

Step-by-step: creating a master key and signing subkey

Generate your master key

Use --full-generate-key to set up a secure root key:

gpg --full-generate-key

Choose the following options when prompted:

• Key type: RSA and RSA
• Key size: 4096
• Expiry: 1y (can be extended later)
• Name and email: Your real identity
• Passphrase: Choose a strong one!

List your key

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

Take note of your key ID. (The part after the rsa4096/ or ed25519/ and before the date)

Add a signing subkey

gpg --edit-key YOUR_KEY_ID

Inside the GPG prompt:

addkey
Choose: RSA (sign only), size 4096, expiry 1y
save

Export and back up your keys

Export your public key:

gpg --armor --export [email protected] > publickey.asc

Export and back up your private key (store safely!):

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

Publishing your GPGkey via WKD (Web Key Directory)

The Web Key Directory allows your domain to serve your public key in a standardized way. Tools like gpg --locate-keys can then automatically find your key at https://yourdomain.com/.well-known/openpgpkey/.

1. Create your WKD directory structure

On your web server (e.g. Nginx):

mkdir -p /var/www/yourdomain.com/.well-known/openpgpkey/yourdomain.com/hu

2. Generate WKD hash

gpg --with-wkd-hash --list-keys [email protected]

This gives you a hex-based filename, something like:

hu/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

3. Export public key in WKD format

gpg --export --armor [email protected] > openpgpkey.asc

Then copy it:

cp openpgpkey.asc /var/www/yourdomain.com/.well-known/openpgpkey/yourdomain.com/hu/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

4. Serve WKD directory (testing purposes only)

You can serve this directory locally using Python 3 for testing:

cd /var/www/yourdomain.com
python3 -m http.server 8080

Then test with:

gpg --auto-key-locate wkd --locate-keys [email protected]

⚠️ Note: This method is for testing only. For production, use a proper web server like Nginx or Apache that can serve .well-known/ paths correctly and over HTTPS.

Using Your GPG Subkey to Sign Git Commits

Once your GPG subkey is set up and available on your system, you can use it to sign Git commits. This gives your code contributions a cryptographic signature of authenticity.

To sign a commit:

git commit -S -m "Your commit message"

If Git is configured to use your GPG subkey, this command will prompt for your passphrase (unless cached) and produce a signed commit.

ℹ️ Setting up Git to use your GPG subkey (via user.signingkey and commit.gpgsign) is outside the scope of this article, but many tutorials and Git documentation cover it in detail.

You can verify a commit was signed with:

git log --show-signature

Conclusion: Control, credibility, and cryptographic hygiene

GPG is a battle-tested, decentralized way to assert identity across borders and platforms. While GitHub’s verification is convenient, and Sigstore is promising, GPG remains the only solution that gives you full control over your cryptographic reputation.

By separating your master key from your subkeys and hosting your public key via WKD, you build a resilient, verifiable, and portable trust system — one that’s independent of any single platform.

So don’t just sign your commits. Own your entire identity.

---

Need help building a WKD or integrating GPG into your DevSecOps workflows? Contact ushy to get enterprise-grade cryptographic hygiene built into your pipelines.