Key Generation Best Practices

Key generation is the first and most critical step in the cryptographic key lifecycle. A key generated with insufficient entropy, a weak algorithm, or in an insecure environment is permanently compromised — no amount of subsequent protection can fix a weak key. The only remedy is to generate a new key and re-encrypt or re-sign everything. Secure key generation requires: a strong random source, an appropriate algorithm and key size, generation in a protected environment, and immediate documentation of the key’s metadata and lifecycle policy.

Why it matters

• Entropy is everything — a 256-bit key generated from a predictable source (timestamp, PID, sequential counter) may have only 32 bits of actual entropy. An attacker can brute-force 2³² possibilities in seconds.
• Algorithm choice is permanent — once data is encrypted with RSA-2048, you can’t upgrade to RSA-4096 without re-encrypting. Choose the right algorithm and size at generation time.
• Environment matters — a key generated on a compromised system is compromised from birth. Generate in HSMs for high-value keys, or on freshly-booted secure systems at minimum.
• Compliance evidence — auditors ask: “How was this key generated? What random source? What algorithm? Who authorized it?” Without documentation, you can’t prove secure generation.
• No second chances — unlike passwords (which can be changed), a compromised key means re-issuing certificates, re-encrypting data, or re-signing code. The blast radius of weak generation is enormous.

How it works

1. Select algorithm and size — based on security requirements, compliance, and performance needs
2. Select random source — hardware TRNG (HSM), OS CSPRNG (/dev/urandom), or dedicated entropy source
3. Select generation environment — HSM (highest security), secure workstation (medium), or application runtime (lowest)
4. Generate — invoke the key generation function with proper parameters
5. Validate — verify key properties (correct algorithm, correct size, passes basic sanity checks)
6. Protect immediately — store in HSM, encrypt at rest, or set proper file permissions. Never leave a key unprotected even momentarily.
7. Document — record: algorithm, size, generation date, environment, purpose, owner, rotation schedule

Recommended algorithms and sizes (2026):

Purpose              | Algorithm    | Minimum Size  | Recommended
TLS certificates     | ECDSA        | P-256         | P-256 (or Ed25519 for SSH)
TLS certificates     | RSA          | 2048-bit      | 3072-bit or 4096-bit
Data encryption      | AES          | 128-bit       | 256-bit
SSH keys             | Ed25519      | 256-bit       | Ed25519 (fixed size)
Code signing         | ECDSA        | P-256         | P-384 for long-lived
CA signing keys      | ECDSA/RSA    | P-384/4096    | P-384 or RSA-4096

In real systems

OpenSSL key generation:

# ECDSA P-256 (recommended for TLS)
openssl ecparam -genkey -name prime256v1 -out server.key

# RSA 4096 (when RSA is required)
openssl genrsa -out server.key 4096

# Ed25519 (SSH keys)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

# Verify key properties
openssl ec -in server.key -text -noout | head -5
# Shows: ASN1 OID: prime256v1, NIST CURVE: P-256

HSM key generation (PKCS#11):

# Generate key inside HSM — key never exists outside
pkcs11-tool --module /usr/lib/libCryptoki2_64.so \
  --login --pin 1234 \
  --keypairgen --key-type EC:prime256v1 \
  --label "ca-signing-key-2026" \
  --id 01
# Key is generated and stored inside HSM
# Only a reference (handle) is returned — not the key material

AWS KMS (cloud-managed generation):

# Key generated inside AWS HSM — never extractable
aws kms create-key \
  --key-spec ECC_NIST_P256 \
  --key-usage SIGN_VERIFY \
  --description "Production code signing key" \
  --tags Key=Environment,Value=production

Checking entropy source (Linux):

# Verify entropy pool is sufficient
cat /proc/sys/kernel/random/entropy_avail
# Should be > 256 for key generation

# /dev/urandom is safe for key generation (uses CSPRNG)
# /dev/random blocks when entropy is low (unnecessary on modern kernels)
# Both use the same CSPRNG in Linux 5.6+ — /dev/urandom is preferred

Where it breaks

Weak entropy in VMs/containers — a freshly-booted VM or container may have very low entropy (no hardware interrupts, no disk I/O, no user input). Keys generated in the first seconds after boot may use predictable random values. Mitigations: use virtio-rng (pass host entropy to VM), install haveged or rng-tools, or wait for entropy pool to fill before generating keys.

Application-level PRNG used for keys — a developer uses Math.random() (JavaScript), random.random() (Python), or java.util.Random for key generation. These are NOT cryptographically secure — they’re predictable given enough output. Always use: crypto.randomBytes() (Node.js), secrets.token_bytes() (Python), SecureRandom (Java), or OS-level /dev/urandom.

Key generated on wrong system then transferred — a developer generates a TLS private key on their laptop, then SCPs it to the production server. The key now exists on the laptop (in shell history, in temp files, potentially in backups). Generate keys on the system that will use them — or in an HSM. Never generate elsewhere and transfer.

Operational insight

The single most impactful key generation practice: generate in an HSM and never extract. This eliminates entire categories of risk — the key can’t be stolen from disk, can’t be leaked in logs, can’t be accidentally committed to Git, can’t be copied to unauthorized systems. For keys that can’t be in an HSM (application-level encryption, SSH keys on developer machines), the next best practice: generate on the target system using OS CSPRNG, immediately set restrictive permissions (chmod 600), and never copy the key anywhere. Every copy of a key is an additional attack surface.

Related topics

• Key Lifecycle Management
• Key Rotation Strategies
• What are Hardware Security Modules
• NIST SP 800-57 Key Management
• Elliptic Curve Cryptography