Key Management

Key Management

GPG - the foundation of cryptographic identity

Key Management is the practice of generating, storing, rotating, and recovering cryptographic keys. Poor key management undermines even the strongest encryption.

Principles

• Backup everything: Keys without backups are time bombs
• Compartmentalize: Different keys for different purposes
• Rotate regularly: Limit blast radius of compromise
• Document thoroughly: Future-you needs to understand the system

Key Types

Key Type	Purpose	Storage
SSH keys	Server authentication	~/.ssh/ + hardware key
GPG keys	Encryption, signing	Keyring + Yubikey
API keys	Service authentication	Password manager
Backup keys	Data encryption	Offline, distributed
2FA seeds	Account recovery	Password manager + hardware key

SSH Key Management

Generation

# Modern Ed25519 (recommended)
ssh-keygen -t ed25519 -C "description" -f ~/.ssh/keyname

# RSA for legacy compatibility
ssh-keygen -t rsa -b 4096 -C "description" -f ~/.ssh/keyname_rsa

Organization

~/.ssh/
├── config              # Host configurations
├── id_ed25519          # Primary key
├── id_ed25519.pub
├── github_ed25519      # GitHub-specific
├── github_ed25519.pub
├── work_ed25519        # Work systems
├── work_ed25519.pub
└── authorized_keys     # Allowed incoming keys

SSH Config

# Primary identity
Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519

# GitHub
Host github.com
    IdentityFile ~/.ssh/github_ed25519

# Work servers
Host *.work.example.com
    IdentityFile ~/.ssh/work_ed25519
    User workuser

Hardware Key SSH

See Yubikey for FIDO2 SSH keys. Modern approach:

ssh-keygen -t ed25519-sk -O resident -O verify-required

GPG Key Management

Key Structure

Primary Key (Certify only, kept offline)
├── Signing Subkey (day-to-day signing)
├── Encryption Subkey (decryption)
└── Authentication Subkey (SSH via GPG)

Generation

# Generate primary key
gpg --full-generate-key --expert

# Add subkeys
gpg --edit-key YOUR_KEY_ID
gpg> addkey

# Export for backup (DO THIS BEFORE MOVING TO HARDWARE)
gpg --export-secret-keys --armor YOUR_KEY_ID > master-key-backup.asc
gpg --export-secret-subkeys --armor YOUR_KEY_ID > subkeys-backup.asc

Hardware Storage

Move subkeys to Yubikey:

gpg --edit-key YOUR_KEY_ID
gpg> key 1          # Select subkey
gpg> keytocard      # Move to appropriate slot
gpg> save

Key Server Publication

# Upload to keys.openpgp.org
gpg --send-keys --keyserver keys.openpgp.org YOUR_KEY_ID

# Verify via email (required)

API Key Management

Storage

Never:

• Hard-code in source
• Commit to git
• Store in plaintext

Instead:

• Environment variables
• Password manager
• Secret management systems (Vault, AWS Secrets Manager)

Rotation

• Rotate immediately if exposed
• Rotate periodically (quarterly minimum)
• Rotate when team members leave
• Document rotation in changelog

Environment Variables

# .env (gitignored)
API_KEY=secret_value

# Load in shell
source .env

# Or use dotenv in code

Backup Keys

Encryption Keys for Backups

# Generate a strong symmetric key
openssl rand -base64 32 > backup.key

# Use for backup encryption
tar -czf - /important | openssl enc -aes-256-cbc -pbkdf2 -pass file:backup.key > backup.enc

# Store backup.key separately from backups

Paper Backups

For critical keys (GPG master, backup encryption):

• Print as QR codes
• Use PGP to encrypt before printing
• Store in multiple physical locations
• Fire-resistant safe, safe deposit box, trusted person

# Generate QR code from key
gpg --export-secret-keys --armor KEY_ID | qrencode -o key-qr.png

Recovery Procedures

SSH Key Loss

1. Remove old public key from authorized_keys on all servers
2. Generate new keypair
3. Distribute new public key
4. Update any services using the old key

GPG Key Loss

If you have backup:

gpg --import master-key-backup.asc
gpg --import subkeys-backup.asc

If no backup:

• Generate revocation certificate (you should have done this at creation)
• Publish revocation
• Generate new key
• Update all contacts

Hardware Key Loss

See Yubikey for recovery procedures. Key points:

• Use backup hardware key (you registered two, right?)
• Revoke lost key from all services
• Register replacement key
• Update recovery procedures

2FA Seed Management

Storage

• Primary: Hardware key (FIDO2)
• Backup: TOTP seeds in encrypted password manager
• Emergency: Printed backup codes in secure location

Recovery

If you lose 2FA access:

1. Try backup hardware key
2. Try backup TOTP in password manager
3. Use pre-generated backup codes
4. Contact service support (last resort)

Rotation Schedule

Key Type	Rotation	Trigger Events
SSH (daily use)	Annually	Compromise, device loss
GPG subkeys	2 years	Expiration, compromise
API keys	Quarterly	Exposure, team changes
Backup encryption	Never (use new for new backups)	N/A
2FA seeds	As needed	Device change, suspected compromise

Audit Checklist

Regular key hygiene:

• [ ] SSH keys: Are all authorized keys still needed?
• [ ] GPG keys: Are subkeys approaching expiration?
• [ ] API keys: Any unused keys that should be revoked?
• [ ] 2FA: Backup codes stored securely?
• [ ] Passwords: Manager synced across devices?
• [ ] Backups: Can you actually restore from backup?

Related

• PGP - GPG usage
• Yubikey - Hardware key storage
• SSH - SSH configuration
• Threat Modeling - Security planning