Goal
Master public key distribution methods: exporting and importing keys, using keyservers safely, and understanding the Web of Trust model for decentralized identity verification.
Prerequisites: Week 3b (Encryption & Signatures)
This is Part 3 of 4 - Covers key distribution, keyservers, and web of trust.
1. Public Key Distribution and Import
Export Your Public Key
# Export in ASCII armor (shareable format)
gpg --armor --export [email protected] > alice-public-key.asc
# View the exported key
cat alice-public-key.asc
Output:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGcYexamplePublicKeyDataHere...
=ABCD
-----END PGP PUBLIC KEY BLOCK-----
Where to Publish Your Public Key
Options:
- Personal website -
https://example.com/pgp-key.asc - Keyserver (see next section)
- GitHub - Add to profile README
- Email signature - Include fingerprint
- Business card - QR code of fingerprint
- Social media bio - Link to key
Example website publication:
<!-- On your About page -->
<h2>GPG Public Key</h2>
<p>Fingerprint: <code>ABCD 1234 ABCD 1234 ABCD 1234 ABCD 1234</code></p>
<p><a href="/alice-public-key.asc">Download Public Key</a></p>
Import Someone’s Public Key
# Import from file
gpg --import bobs-public-key.asc
# Output:
gpg: key XYZ789: public key "Bob Cypherpunk <[email protected]>" imported
gpg: Total number processed: 1
gpg: imported: 1
Verify Imported Key Fingerprint
CRITICAL: Always verify fingerprints!
# Check Bob's key fingerprint
gpg --fingerprint [email protected]
# Output:
pub rsa4096 2025-09-01 [SC]
XYZ7 89AB XYZ7 89AB XYZ7 89AB XYZ7 89AB XYZ7 89AB
uid [ unknown] Bob Cypherpunk <[email protected]>
Verification process:
- Get Bob’s fingerprint through trusted channel (in person, phone call, his website)
- Compare with imported key fingerprint
- If match: Trust the key
- If mismatch: DELETE the key immediately (potential MITM attack)
Example secure verification:
# You're on phone with Bob
You: "I imported your key. Can you read your fingerprint?"
Bob: "X Y Z 7 8 9 A B..."
You: [Compares with gpg --fingerprint output]
You: "Confirmed! I'll sign your key now."
2. The Keyserver Ecosystem
What Are Keyservers?
Public keyservers store GPG public keys for discovery and distribution.
Popular keyservers:
keys.openpgp.org(modern, privacy-focused)keyserver.ubuntu.com(Ubuntu default)pgp.mit.edu(classic, legacy)
How they work:
Alice uploads public key → Keyserver → Bob searches for Alice → Downloads key
Uploading Your Key to Keyserver
# Upload to keys.openpgp.org
gpg --keyserver keys.openpgp.org --send-keys ABCD1234
# Upload to Ubuntu keyserver
gpg --keyserver keyserver.ubuntu.com --send-keys ABCD1234
What gets uploaded:
- Public key
- User IDs (name, email)
- Signatures on your key
What stays private:
- Private key (never leaves your system)
- Passphrase
Searching for Keys
# Search by email
gpg --keyserver keys.openpgp.org --search-keys [email protected]
# Search by name
gpg --keyserver keys.openpgp.org --search-keys "Alice Cypherpunk"
# Search by key ID
gpg --keyserver keys.openpgp.org --search-keys ABCD1234
Refreshing Keys from Keyserver
# Update all keys in your keyring
gpg --keyserver keys.openpgp.org --refresh-keys
# Update specific key
gpg --keyserver keys.openpgp.org --refresh-keys [email protected]
Why refresh:
- Gets updated expiration dates
- Downloads new signatures (web of trust)
- Gets revocation certificates (if key compromised)
Pros and Cons of Keyservers
Pros:
- Easy public key distribution
- No need for manual key exchange
- Automatically propagate updates
- Standard part of GPG ecosystem
Cons:
- No identity verification - Anyone can upload key with any name/email
- Spam problem - Keys can be polluted with fake signatures
- Privacy leak - Your email and social graph become public
- Can’t delete keys - Once uploaded, permanent (by design)
- Certificate flooding attacks - Attackers add millions of signatures, making key unusable
Modern best practice:
- Use
keys.openpgp.org(has email verification, prevents abuse) - Publish key on personal website too
- Always verify fingerprints out-of-band
- Consider not using keyservers for privacy-sensitive identities
Alternative: Web Key Directory (WKD)
Modern, privacy-preserving key distribution:
# Keys hosted on your own domain
# Example: https://example.com/.well-known/openpgpkey/
Advantages:
- You control your keys
- No third-party keyserver
- Domain-verified (key at [email protected] hosted on example.com)
- Privacy-respecting
Implementation beyond this course, but worth knowing about.
3. Web of Trust: Decentralized Identity Verification
The Problem: How to Trust Public Keys
Scenario:
- You download Bob’s public key from keyserver
- Key says “Bob Smith [email protected]”
- How do you know this is the REAL Bob?
Without verification:
- Could be attacker’s key pretending to be Bob
- Man-in-the-middle attack
- You encrypt to fake Bob → Attacker reads message
The Web of Trust Solution
Concept: Trust through relationships, not central authority.
You trust Alice → Alice met Bob in person and signed his key
→ You can trust Bob's key (transitively through Alice)
Key signing:
- Alice verifies Bob’s identity in person
- Alice signs Bob’s key with her private key
- Alice’s signature says “I verified this key belongs to Bob”
- Anyone who trusts Alice can now trust Bob
Signing Someone’s Key
Prerequisites:
- Met person in person OR verified via multiple channels
- Verified government ID (if high-trust scenario)
- Verified key fingerprint
Process:
# 1. Import their key
gpg --import bobs-key.asc
# 2. Verify fingerprint (in person or phone)
gpg --fingerprint [email protected]
# 3. Sign their key
gpg --sign-key [email protected]
# Prompts:
# - Confirm you've verified identity
# - Enter your passphrase
# - Sign at different trust levels
# 4. Export signed key back to them
gpg --armor --export [email protected] > bobs-key-signed-by-alice.asc
# 5. Bob imports your signature
# (Bob's key now has your signature, strengthening web of trust)
Trust Levels
When editing trust:
gpg --edit-key [email protected]
> trust
Trust levels:
- Unknown - No opinion
- None - Don’t trust this person to verify others
- Marginal - Somewhat trust (need 3 marginal signatures to trust a key)
- Full - Fully trust (1 full signature enough to trust a key)
- Ultimate - Your own key
Example web of trust:
You (ultimate trust)
↓ (you fully trust)
Alice
↓ (Alice signed)
Bob
↓ (Bob signed)
Carol ← You can trust Carol (through Alice → Bob → Carol)
Key Signing Parties
In-person events where people verify identities and sign keys.
How it works:
- Everyone brings government ID and key fingerprint printouts
- Form a circle, verify each person’s ID and fingerprint
- Everyone goes home and signs all keys they verified
- Upload signed keys to keyserver
- Web of trust grows stronger
Remote alternative:
- Video call with ID verification
- Voice verification of fingerprints
- Lower trust level, but better than nothing
Web of Trust vs TOFU (Trust On First Use)
Web of Trust:
- Distributed trust model
- Requires social interaction (key signing)
- Strong security if done right
- Complex for beginners
TOFU (like SSH):
- Trust first key you see
- Warn if key changes
- Simpler, but vulnerable to initial MITM
Modern GPG supports both models.
Up Next
Week 3d covers key management (rotation, revocation, backup), email encryption setup, and modern alternatives like age.
Key Takeaways
- Export/import keys using ASCII armor for portability
- Keyservers enable discovery but have privacy trade-offs
- keys.openpgp.org is the modern, privacy-focused choice
- Always verify fingerprints through a separate trusted channel
- Web of Trust builds decentralized identity verification through key signing
- Trust levels determine how signatures propagate trust transitively
- Key signing parties strengthen the web of trust through in-person verification