Skip to content

Public-Private Key Pairs

Why This Matters

For executives: Public-private key pairs are the mathematical foundation that enables secure communication without sharing secrets. This is why PKI eliminates password management burden - each service/user has a key pair instead of passwords. Understanding key pairs helps you evaluate security architecture decisions and vendor claims.

For security leaders: Key pair management is where most PKI security failures happen. Private keys leaked, weak key generation, improper key storage - these cause breaches. Understanding key pairs, key sizes, and key protection helps you design secure PKI architecture and identify vulnerabilities before they're exploited.

For engineers: You generate, store, and use key pairs constantly in PKI work. Understanding how key pairs actually work (not just "run this command") helps you debug problems, implement secure key generation, and avoid common mistakes that create vulnerabilities.

Common scenario: You're implementing certificate-based authentication. You need to understand key pair generation (which algorithm? which key size?), private key storage (filesystem? HSM?), and key usage (when to rotate? how to protect?). These decisions directly impact security and operational success.

TL;DR: Public-private key pairs enable asymmetric cryptography—the foundation of PKI. The private key must remain secret while the public key is freely distributed. This mathematical relationship enables secure communication without pre-shared secrets: public keys encrypt and verify signatures, private keys decrypt and sign. Understanding key pairs is essential for grasping how PKI provides authentication, encryption, and digital signatures.

Overview

The breakthrough of asymmetric cryptography in the 1970s (Diffie-Hellman, RSA) revolutionized secure communications. Before asymmetric crypto, parties needed to exchange secret keys through secure channels—an impossible requirement for internet-scale communications. Asymmetric cryptography solved this: two mathematically related keys where knowing one doesn't reveal the other.

The elegance of public-private key pairs is their dual functionality: what one key encrypts, only the other can decrypt; what one key signs, the other can verify. This enables strangers to communicate securely and verify identities without ever meeting or establishing prior trust—the fundamental enabler of e-commerce, secure communications, and the modern internet.

Understanding key pairs is foundational to PKI: how certificates work, why private keys must be protected, how signatures provide authentication, and why key management is critical operational discipline.

Related Pages: Cryptographic Primitives, What Is Pki, Certificate Anatomy, Private Key Protection

Key Concepts

Mathematical Relationship

Public and private keys are mathematically related through one-way functions: computations easy in one direction but infeasible to reverse.

RSA Key Relationship

Key Generation Process: 1. Select two large prime numbers: p and q 2. Compute n = p × q (modulus, part of both keys) 3. Compute φ(n) = (p-1)(q-1) (Euler's totient) 4. Choose public exponent e (typically 65537) 5. Compute private exponent d where (e × d) ≡ 1 (mod φ(n))

Result:

  • Public key: (n, e)
  • Private key: (n, d, p, q)

Mathematical Relationship: 

For any message m:
  Encrypt: c = m^e mod n
  Decrypt: m = c^d mod n

Due to: (m^e)^d ≡ m (mod n)

Security Foundation:

  • Given n and e, computing d requires knowing factors p and q
  • Factoring large n is computationally infeasible (no known polynomial-time algorithm)
  • Best known algorithms (General Number Field Sieve) require exponential time

Example (Small Numbers for Illustration): 

p = 61, q = 53
n = 61 × 53 = 3233
φ(n) = 60 × 52 = 3120
e = 17
d = 2753 (computed: 17 × 2753 ≡ 1 mod 3120)

Public key: (3233, 17)
Private key: (3233, 2753)

Encrypt message m=123:
  c = 123^17 mod 3233 = 855

Decrypt ciphertext c=855:
  m = 855^2753 mod 3233 = 123

Note: Real RSA uses 2048+ bit numbers (600+ digits), making factorization infeasible.

ECDSA Key Relationship

Key Generation Process: 1. Choose elliptic curve (e.g., P-256) 2. Curve has base point G 3. Generate random private key d (scalar) 4. Compute public key Q = d × G (point multiplication)

Result:

  • Public key: Q (point on elliptic curve)
  • Private key: d (large random number)

Mathematical Relationship:

  • Public key is private key multiplied by base point
  • Point multiplication easy (compute Q from d)
  • Discrete logarithm hard (find d from Q)

Security Foundation:

  • Given Q and G, finding d such that Q = d × G is elliptic curve discrete logarithm problem (ECDLP)
  • No known efficient algorithm for ECDLP
  • 256-bit ECDSA provides security equivalent to 3072-bit RSA

Dual Functionality

Key pairs enable two complementary operations:

Encryption (Confidentiality)

Purpose: Ensure only intended recipient can read message

Process: 1. Sender obtains recipient's public key 2. Sender encrypts message with public key 3. Only recipient's private key can decrypt

Direction: Public key encrypts → Private key decrypts

Use Cases:

  • Email encryption (recipient's public key)
  • TLS key exchange (server's public key)
  • Secure file sharing
  • Key encapsulation

Important: Direct RSA encryption limited to small messages (< key size). In practice, hybrid encryption is used: RSA encrypts symmetric key, symmetric key encrypts data.

Example: 

Alice wants to send secret to Bob:
1. Alice obtains Bob's public key
2. Alice encrypts message: ciphertext = encrypt(message, Bob_public_key)
3. Alice sends ciphertext to Bob
4. Bob decrypts: message = decrypt(ciphertext, Bob_private_key)

Eve who intercepts ciphertext cannot decrypt without Bob's private key

Digital Signatures (Authentication)

Purpose: Prove message came from specific sender and wasn't modified

Process: 1. Signer hashes message 2. Signer encrypts hash with private key (signature) 3. Anyone with public key can verify signature

Direction: Private key signs → Public key verifies

Use Cases:

  • Certificate signatures (CA signs certificates)
  • Code signing (developer signs software)
  • Document signing (sign contracts, emails)
  • Firmware signing (manufacturer signs firmware)

Properties Provided:

  • Authentication: Only private key holder could create signature
  • Integrity: Any message modification invalidates signature
  • Non-repudiation: Signer can't deny signing (assuming private key protected)

Example: 

Alice wants to sign document for Bob:
1. Alice computes hash: h = hash(document)
2. Alice signs hash: signature = sign(h, Alice_private_key)
3. Alice sends document + signature to Bob
4. Bob verifies: valid = verify(signature, Alice_public_key, document)

If valid = true:
  - Bob knows Alice signed it (only she has private key)
  - Bob knows document unchanged (hash matches)

Why This Works: The Non-Intuitive Math

The "magic" of asymmetric cryptography is mathematical functions with special properties:

One-Way Functions:

  • Easy to compute in one direction: f(x) = y
  • Hard to reverse: Given y, find x
  • Examples: Modular exponentiation, elliptic curve point multiplication

Trapdoor Functions:

  • One-way functions with a secret "trapdoor"
  • With trapdoor (private key), easy to reverse
  • Without trapdoor, hard to reverse
  • RSA trapdoor: Knowing p and q (factors of n) enables computing d from e

Why Knowing Public Key Doesn't Help:

  • Public key: Result of applying one-way function to private key
  • Reversing one-way function is computationally infeasible
  • Example: Given Q = d × G on elliptic curve, finding d requires solving discrete log (no efficient algorithm)

Security Assumption: These mathematical problems remain hard. If efficient algorithms discovered (e.g., via quantum computing), asymmetric crypto breaks.

Decision Framework

Key generation location:

Generate on target system when:

  • High security requirements (private key never transmitted)
  • Server certificates, client authentication
  • Normal use case (default choice)

Generate on CA/central system when:

  • Centralized key escrow required (controversial, generally avoid)
  • Legacy systems that can't generate keys
  • Some HSM architectures

Never:

  • Generate on untrusted systems
  • Transmit private keys over unencrypted channels
  • Reuse key pairs across different certificates

Key storage:

Filesystem with proper permissions when:

  • Standard servers, workstations
  • No compliance requirements for HSM
  • Cost-sensitive deployments
  • Must: 0600 permissions, encrypted filesystem, access logging

HSM (Hardware Security Module) when:

  • CA private keys (always)
  • High-value signing operations
  • Compliance requires (FIPS 140-2, PCI-DSS)
  • High assurance required

TPM (Trusted Platform Module) when:

  • Device-specific keys
  • Boot process signing
  • Desktop/laptop key protection

Cloud KMS when:

  • Cloud-native architecture
  • Need key availability across regions
  • Centralized key management
  • Must: Verify cloud provider security model

Key rotation:

Rotate regularly when:

  • Compliance requires (annual rotation common)
  • Long-lived keys (multi-year certificates)
  • Precautionary (limit exposure window)

Don't rotate when:

  • Short-lived certificates (service mesh 24-hour certs don't need key rotation)
  • Automated renewal already happening
  • Operational complexity exceeds benefit

Certificate renewal: Always generate new key pair?

  • Consensus: Yes, generate new key pair on renewal
  • Limits exposure if previous key compromised
  • Exception: CA keys (rarely rotated due to operational complexity)

Red flags:

  • Private keys stored in Git, cloud storage, shared drives (insecure)
  • Same key pair used across multiple certificates (violates principle of least privilege)
  • Keys generated on CA then transmitted to end systems (compromises security model)
  • No access logging for private key operations (can't detect compromise)
  • Weak key generation (< 2048-bit RSA, deterministic RNG)

Practical Guidance

Key Pair Lifecycle

Generation

Where to Generate:

  • On-device: Generate keys where they'll be used (preferred)
  • Private key never transmitted
  • Reduces exposure window

  • Examples: Server generates key, submits CSR to CA

  • In HSM: Generate keys in Hardware Security Module

  • Keys never leave secure hardware
  • Highest security for CA keys

  • Examples: Root CA key generation ceremony

  • Centrally (Avoid): Generate keys on management server

  • Private keys transmitted to endpoints
  • Increases risk of exposure
  • Only acceptable if keys encrypted during transmission and short-lived

Generation Commands:

# RSA key pair
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048

# ECDSA key pair (P-256)
openssl genpkey -algorithm EC -out private.pem -pkeyopt ec_paramgen_curve:P-256

# Extract public key
openssl pkey -in private.pem -pubout -out public.pem

Distribution

Public Key Distribution (Freely shareable):

  • Embed in certificate (primary mechanism)
  • Publish to key servers (PGP)
  • Include in application packages
  • Distribute via secure website
  • Email (though verify fingerprint out-of-band)

Private Key Distribution (Avoid if possible):

  • Should never be transmitted in plaintext

  • If must transmit:

  • Encrypt with strong passphrase (AES-256)

  • Use secure channel (TLS, IPsec)
  • Temporary, one-time access
  • Destroy transmission copy after receipt
  • Better: Generate on destination, never transmit

Public Key Verification: Always verify public key authenticity: 

# Compute fingerprint
openssl x509 -in cert.pem -noout -fingerprint -sha256

# Compare with published fingerprint (out-of-band)
# Phone call, different website, printed material, etc.

Usage

Private Key Usage Restrictions:

  • Minimal exposure time (load for operation, clear from memory after)
  • Access controls (file permissions, HSM authorization)
  • Audit logging (log every private key operation)
  • Dedicated systems (don't use CA keys on multi-purpose servers)

Public Key Usage (Unrestricted):

  • Freely shareable
  • Can be cached
  • No access controls needed
  • Integrity verification recommended (via certificate)

Rotation

When to Rotate Key Pairs:

  • Scheduled rotation (e.g., annually)
  • After private key compromise or suspected exposure
  • After personnel changes (lost access control)
  • Before cryptographic algorithm deprecation
  • When certificate expires (generate new key with renewal)

Rotation Process: 1. Generate new key pair 2. Obtain new certificate for new public key 3. Deploy new certificate in parallel with old 4. Transition services to new key 5. Grace period (accept both old and new) 6. Revoke old certificate 7. Securely destroy old private key

Destruction

Secure Private Key Deletion:

# Multiple overwrite passes
shred -vfz -n 35 private.key

# Verify deletion
ls private.key  # Should not exist

HSM Key Destruction:

  • Use HSM-specific deletion commands
  • Verify key no longer listed
  • Some HSMs maintain key backups (be aware)

Certificate Revocation:

  • After key rotation, revoke old certificate
  • Prevents use of old key pair even if private key recovered

Key Pair Formats

Private Key Formats

PKCS#1 (RSA Only): 

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA...
-----END RSA PRIVATE KEY-----
- Original OpenSSL format - RSA-specific - Unencrypted by default

PKCS#8 (All Algorithms): 

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkq...
-----END PRIVATE KEY-----
- Modern standard format - Algorithm-agnostic (RSA, ECDSA, etc.) - Supports encryption

PKCS#8 Encrypted: 

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFLTBXBgkqhkiG...
-----END ENCRYPTED PRIVATE KEY-----
- PKCS#8 with password-based encryption - Recommended for file storage - AES-256 encryption typical

Conversion: 

# PKCS#1 to PKCS#8
openssl pkcs8 -topk8 -in pkcs1.pem -out pkcs8.pem

# Encrypt PKCS#8
openssl pkcs8 -topk8 -in unencrypted.pem -out encrypted.pem -v2 aes256

Public Key Formats

SubjectPublicKeyInfo (SPKI): 

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG...
-----END PUBLIC KEY-----
- Standard X.509 public key format - Algorithm identifier + public key - Used in certificates

SSH Format: 

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user@host
- Used for SSH authentication - Base64 encoded - Includes comment field

Conversion: 

# Extract from certificate
openssl x509 -in cert.pem -noout -pubkey > public.pem

# Convert to SSH format
ssh-keygen -i -m PKCS8 -f public.pem > authorized_keys

Key Size Selection

Current Recommendations (2024)

Use Case Algorithm Key Size Security Level Valid Through
TLS Server RSA 2048-bit 112-bit ~2030
TLS Server RSA 3072-bit 128-bit Beyond 2030
TLS Server ECDSA P-256 128-bit Beyond 2030
CA Root RSA 4096-bit ~140-bit 2040+
CA Intermediate RSA 3072-bit 128-bit Beyond 2030
Code Signing RSA 3072-4096 128-140-bit Beyond 2030
User Auth RSA 2048-bit 112-bit ~2030
User Auth ECDSA P-256 128-bit Beyond 2030

NIST Guidance1:

  • 2048-bit RSA or 256-bit ECDSA: Through 2030
  • 3072-bit RSA or 384-bit ECDSA: Beyond 2030
  • Consider certificate lifetime in key size selection

Performance vs. Security Tradeoff

RSA Key Size Impact:

  • 2048 → 3072 bit: ~3x slower signing
  • 2048 → 4096 bit: ~7x slower signing
  • Verification speed less affected (small exponent)

ECDSA Advantages:

  • P-256 ECDSA ≈ 3072-bit RSA security
  • Much faster key generation
  • Much faster signing
  • Smaller keys and signatures

Decision Factors:

  • Performance: ECDSA better for high-volume operations
  • Compatibility: RSA more widely supported (legacy systems)
  • Certificate size: ECDSA produces smaller certificates (mobile/IoT)
  • Lifetime: Longer lifetime = larger keys
  • Regulation: Some industries mandate specific algorithms/sizes

Multi-Key Scenarios

Key Usage Separation

Best Practice: Separate key pairs for different purposes

Rationale:

  • Limits compromise impact
  • Enables different rotation schedules
  • Allows purpose-specific protection levels
  • Simplifies key management policies

Example Separation: 

Organization key pairs:
├── TLS Encryption: RSA-2048 (90-day certificates)
├── Email Signing: RSA-3072 (2-year certificates)
├── Code Signing: RSA-4096 (3-year certificates)
└── Document Signing: RSA-4096 (long-term archival)

X.509 Key Usage Extension: Enforces key purpose separation: 

Key Usage: Digital Signature, Key Encipherment
Extended Key Usage: TLS Web Server Authentication

Prevents certificate/key misuse (e.g., TLS key for code signing).

Key Rollover

Scenario: Transitioning from old to new key pair without downtime

Dual Certificate Configuration: 

# Nginx example
ssl_certificate /etc/ssl/certs/server-new.crt;
ssl_certificate_key /etc/ssl/private/server-new.key;
ssl_certificate /etc/ssl/certs/server-old.crt;
ssl_certificate_key /etc/ssl/private/server-old.key;

Process:

  1. Generate new key pair
  2. Obtain new certificate
  3. Configure server to present both certificates
  4. Clients select compatible certificate
  5. After transition period, remove old key pair

Timeline: 

Week 0: Generate new key, obtain certificate
Week 1: Deploy new key alongside old (both active)
Week 2-4: Monitor, ensure all clients using new key
Week 5: Remove old key configuration
Week 6: Revoke old certificate

Common Pitfalls

  • Reusing key pairs across certificates: Using same key pair for multiple certificates
  • Why it happens: Convenience; avoiding key generation overhead
  • How to avoid: Generate new key pair for each certificate issuance

  • How to fix: Revoke certificates sharing keys; regenerate with unique keys per certificate

  • Transmitting private keys in plaintext: Sending private keys via email or unencrypted channels

  • Why it happens: Convenience; lack of understanding of risk
  • How to avoid: Never transmit private keys; generate on-device; if necessary, use strong encryption

  • How to fix: Immediately rotate exposed keys; revoke certificates; implement secure processes

  • Using same key for encryption and signing: Single key pair for multiple cryptographic purposes

  • Why it happens: Simplicity; not understanding separation of concerns
  • How to avoid: Separate keys for encryption vs. signing; enforce with Key Usage extensions

  • How to fix: Issue separate certificates with purpose-specific keys and Key Usage constraints

  • Not protecting private keys at rest: Storing private keys unencrypted on file systems

  • Why it happens: Configuration complexity; password management challenges
  • How to avoid: Always encrypt private keys at rest (PKCS#8, HSM); use strong passphrases

  • How to fix: Re-encrypt keys immediately; rotate if exposure possible; implement key protection policies

  • Inadequate private key access controls: World-readable or group-readable private key files

  • Why it happens: Misconfiguration; troubleshooting shortcuts becoming permanent
  • How to avoid: chmod 600 for private keys; dedicated service accounts; regular audits
  • How to fix: Fix permissions immediately; rotate keys; review access logs for unauthorized use

Security Considerations

Private Key Compromise Impact

Immediate Risks:

  • Attacker can impersonate key owner
  • Past encrypted traffic decryptable (without forward secrecy)
  • Attacker can sign content as legitimate key owner
  • Complete trust breakdown for affected certificates

Cascade Effects:

  • If CA key compromised: All subordinate certificates compromised
  • If code signing key compromised: Malware signed as legitimate software
  • If user key compromised: Access to all resources protected by that key

Response Requirements:

  1. Immediately revoke certificate
  2. Generate new key pair
  3. Obtain new certificate
  4. Deploy new certificate
  5. Investigate compromise scope
  6. Review and improve key protection
  7. Notify affected parties if required

Forward Secrecy

Problem: Compromised server private key allows decryption of all past captured TLS traffic (if RSA key exchange used)

Solution: Ephemeral Diffie-Hellman key exchange (DHE/ECDHE) - Session keys derived from ephemeral (temporary) keys - Ephemeral keys destroyed after session - Server private key not used for key exchange - Past sessions remain secure even if server key later compromised

TLS Configuration: 

# Prefer forward secrecy cipher suites
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

Trade-off: Slightly slower handshake (must compute DHE), but much better security.

Quantum Computing Threat

Current Algorithms Vulnerable:

  • RSA: Shor's algorithm can factor in polynomial time on quantum computer
  • ECDSA: Shor's algorithm solves discrete log on quantum computer
  • All current public-key cryptography breakable on large quantum computers

Timeline:

  • No large-scale quantum computers yet (2024)
  • Optimistic estimates: 2030s
  • Conservative: 2040s

"Harvest Now, Decrypt Later" Threat:

  • Adversaries capture encrypted traffic today
  • Store for future decryption when quantum computers available
  • High-value long-term secrets at risk

Post-Quantum Cryptography:

  • NIST standardizing quantum-resistant algorithms
  • Based on different mathematical problems (lattices, hash-based, etc.)
  • Hybrid approach: Classical + post-quantum
  • Transition period: 2025-2035 expected

Action Items:

  • Monitor NIST PQC standardization
  • Plan for algorithm agility
  • Consider data lifetime sensitivity
  • Begin hybrid implementations for long-term keys

Key Entropy

Critical Requirement: Private keys must be generated from cryptographically secure random numbers

Insufficient Entropy Examples:

  • Debian OpenSSL bug (2008): Only 2^15 possible keys due to PRNG flaw
  • Predictable seeds: Using timestamp or process ID as seed
  • Reused random values: ECDSA nonce reuse

Proper Entropy Sources: 

# Python example
import secrets

# Generate cryptographically secure random bytes
private_key_material = secrets.token_bytes(32)  # 256 bits

# Never use:
import random
bad_key = random.getrandbits(256)  # NOT cryptographically secure

Verification:

  • Use established libraries (OpenSSL, cryptography.io)
  • Never implement crypto primitives from scratch
  • Test with statistical randomness tests (NIST test suite)

Real-World Examples

Case Study: Debian OpenSSL Predictable Keys (2008)

Incident: Debian maintainer modified OpenSSL to eliminate compiler warning, inadvertently removed entropy source

Impact:

  • Only 2^15 possible RSA keys (32,768) instead of 2^2048
  • All keys generated on affected systems (2006-2008) were weak
  • Attackers could brute-force all possibilities in hours

Response:

  • Mass revocation of affected certificates
  • Key regeneration for all affected systems
  • Demonstrated importance of entropy in key generation

Key Takeaway: Cryptographic key generation requires proper entropy. Don't modify crypto code without expert review.

Case Study: RSA vs. ECDSA Adoption

Historical Context:

  • RSA patented until 2000, limiting adoption
  • ECDSA introduced later (1999), patent issues slower adoption
  • RSA became standard due to earlier patent expiration and tooling

Modern Transition:

  • Let's Encrypt supports both RSA and ECDSA
  • Major browsers support ECDSA
  • Mobile and IoT prefer ECDSA (smaller keys, better performance)
  • Gradual transition: ~20% of certificates ECDSA (2024), growing

Key Takeaway: Algorithm transitions take decades. Start early, support multiple algorithms during transition.

Case Study: HTTPS Certificate Pinning

Some organizations pin specific public keys or certificates in applications:

Concept: Application only accepts specific public keys Goal: Prevent CA compromise from affecting the application Risk: If pinned key rotated without app update, app breaks

Notable Incidents:

  • Banking apps unable to connect after certificate rotation
  • Mobile apps requiring updates to fix pinning

Key Takeaway: Key rotation must be planned carefully. Pinning trades flexibility for security. Consider pinning CA public key rather than leaf certificate.

Further Reading

Essential Resources

Advanced Topics

Lessons from Production

What We Learned at Vortex (Private Key Permissions)

Vortex discovered private keys readable by multiple users on production servers:

Problem: Certificate automation made keys world-readable

Certificate deployment automation used root, then chown to application user. But deployment script had bug: 

# Bad: Made private key world-readable
chmod 644 /etc/ssl/private/server.key

Any user on system could read private keys. Existed for 8 months before discovered during security audit.

Impact:

  • Potential unauthorized access using leaked keys
  • Compliance violation (PCI-DSS requires private key protection)
  • Required key rotation for all affected certificates (2,000+ certificates)
  • $150K in audit remediation costs

What we did:

  • Fixed deployment automation (chmod 600, proper chown)
  • Rotated all compromised keys
  • Implemented automated security scanning for private key permissions
  • Added pre-deployment validation

Key insight: Automation is great, but automated insecurity is worse than manual security. Every deployment script must be security-reviewed.

Warning signs you're heading for same mistake:

  • Deployment automation written by developers without security review
  • No automated checking of file permissions
  • Certificates "just work" without understanding how automation deployed them
  • Security team not involved in certificate deployment design

What We Learned at Nexus (Key Generation Entropy)

Nexus discovered certificates with weak keys generated by VM provisioning:

Problem: VM clone-and-provision had entropy issues

VMs cloned from template, immediately generated SSH and TLS keys. But just-booted VMs had insufficient entropy, causing weak key generation:

  • Some RSA keys had small factors (factorable)
  • Multiple VMs generated identical keys (same RNG state)

Discovered when penetration test successfully factored RSA keys.

What we did:

  • Modified provisioning to wait for entropy pool initialization
  • Implemented entropy source verification before key generation
  • Added post-generation key quality checks (test for small factors)
  • Scanned all existing keys, rotated weak ones (found 47 weak keys)

Key insight: Key generation requires sufficient entropy. Virtual machines, containers, and embedded systems often have entropy problems. Must verify entropy before generating keys.

Warning signs you're heading for same mistake:

  • Generating keys immediately after system boot
  • VM provisioning generates keys without entropy checks
  • No post-generation key quality validation
  • Using /dev/random without checking available entropy

What We Learned at Apex Capital (Key Escrow Debate)

Apex Capital's legal team requested key escrow "in case employees leave":

Problem: Key escrow undermines PKI security model

Legal team wanted private keys backed up centrally so certificates could be recovered if employees left. Security team explained this violated PKI security model: - Key escrow means central compromise = all keys compromised - Eliminates non-repudiation (anyone with escrow access could impersonate) - Creates attractive target for attackers - Against industry best practices

What we did:

  • Educated legal team on PKI security model
  • Proposed alternative: Revoke departed employee certificates, issue new ones
  • Implemented automated certificate reissuance workflow (15 minutes)
  • Documented that key escrow unacceptable for security architecture

Key insight: Key escrow is almost always bad idea. Private keys should never leave the system that generated them. If key access needed after employee departure, revoke old certificate and issue new one.

Warning signs you're heading for same mistake:

  • "We need to backup private keys in case..."
  • Key escrow being considered for "operational convenience"
  • Not understanding that revoking and reissuing is correct approach
  • Business requirements written without security team input

Business Impact

Cost of getting this wrong: Vortex's private key permissions problem cost $150K in audit remediation and emergency key rotation. Nexus's weak key generation went undetected for 18 months - penetration test found it before attackers did (could have been catastrophic breach). Apex Capital spent 6 weeks resolving key escrow debate that delayed critical system launch.

Value of getting this right: Proper key pair management:

  • Prevents breaches: Private keys properly protected, can't be stolen
  • Enables compliance: Demonstrates strong cryptographic key management
  • Operational efficiency: Automated key generation and rotation scales
  • Non-repudiation: Private key possession proves identity legally
  • Incident response: If key compromised, can revoke and rotate quickly

Strategic capabilities: Understanding key pairs enables:

  • Designing secure certificate automation (generate keys correctly)
  • Implementing HSM architecture (when needed vs. overkill)
  • Planning key rotation strategies (balance security and operations)
  • Evaluating PKI products (can they actually protect keys securely?)

Executive summary: Private key protection is foundation of PKI security. Weak key generation, poor key storage, or improper key handling creates vulnerabilities that undermine entire security architecture. Investment in understanding key pairs prevents expensive security incidents.

When to Bring in Expertise

You can probably handle this yourself if:

  • Standard key pair generation (OpenSSL, cloud tools)
  • Filesystem storage with proper permissions
  • Simple use cases (TLS certificates, SSH keys)
  • Following established patterns

Consider getting help if:

  • Implementing HSM architecture (complex, expensive mistakes possible)
  • Key generation at scale (entropy management, automation)
  • Compliance requirements (FIPS 140-2 key management)
  • Designing key rotation strategy

Definitely call us if:

  • Discovered weak keys in production (need rapid response)
  • Implementing key escrow (probably shouldn't, need alternatives)
  • Post-compromise key rotation (time-critical, high-stakes)
  • Regulatory audit findings on key management

We've handled key management incidents at Vortex (private key permissions remediation), Nexus (weak key detection and rotation), and Apex Capital (key escrow architecture decisions). We know both cryptographic requirements and operational reality.

References

Change History

Date Version Changes Reason
2025-11-09 1.0 Initial creation Foundational key pair documentation

Quality Checks:

  • [x] All claims cited from authoritative sources
  • [x] Cross-references validated
  • [x] Practical guidance included
  • [x] Examples are current and relevant
  • [x] Security considerations addressed

  1. NIST. "Recommendation for Key Management." NIST SP 800-57 Part 1 Rev. 5, May 2020. Nist - Detail ↩