License Key Generation: Algorithms, Security, and Best Practices

Every software licensing system starts with key generation. A poorly designed key format creates security vulnerabilities, support headaches, and piracy exposure. A well-designed format is compact, tamper-proof, and carries embedded metadata that your validation layer can decode in microseconds. This guide covers the algorithms, formats, and operational practices behind production-grade license key generation.

What Makes a Good License Key?

A license key must satisfy competing requirements:

• Uniqueness — No two customers should ever receive the same key
• Tamper resistance — Modifying any character should invalidate the key
• Compact format — Short enough for humans to copy-paste or read aloud
• Embedded metadata — Encode plan tier, expiry date, and feature flags directly in the key
• Offline verifiable — Clients should be able to validate without calling your server
• Non-guessable — Sequential or predictable keys are trivially brute-forced

Key Generation Algorithms

1. Random Hex/Base32 Keys (Basic)

The simplest approach: generate random bytes and encode them as hex or Base32. Used by most indie developers.

// Basic random key generation
import { randomBytes } from 'crypto'

const generateKey = () => {
  const bytes = randomBytes(20) // 160 bits of entropy
  const hex = bytes.toString('hex').toUpperCase()
  // Format as XXXXX-XXXXX-XXXXX-XXXXX
  return hex.match(/.{5}/g).join('-')
}

Pros: Simple, high entropy. Cons: No embedded metadata, requires server-side validation for every check, no tamper detection.

2. HMAC-Signed Keys (Intermediate)

Embed metadata in the key and sign it with HMAC-SHA256. The signature proves the key was issued by your server.

// HMAC-signed key with embedded metadata
const payload = JSON.stringify({
  plan: 'professional',
  exp: '2027-01-01',
  seats: 10
})

const signature = createHmac('sha256', SECRET)
  .update(payload)
  .digest('base64url')
  .slice(0, 16)

const key = btoa(payload) + '.' + signature

Pros: Metadata embedded, tamper-proof. Cons: Symmetric key — if your HMAC secret leaks, attackers can forge unlimited keys. Every client that validates offline needs the secret.

3. Ed25519-Signed Keys (Production Grade)

Use asymmetric cryptography: sign with your private key, verify with your public key. Clients only need the public key, which can be safely embedded in your application.

// Ed25519 asymmetric key signing
import { sign, verify } from '@noble/ed25519'

// Server-side: generate signed license
const payload = new TextEncoder().encode(JSON.stringify({
  id: 'lic_a8f3k2m',
  plan: 'business',
  domains: ['app.example.com'],
  exp: 1735689600
}))

const signature = await sign(payload, privateKey)
const licenseKey = btoa(payload) + '.' + btoa(signature)

// Client-side: verify without server call
const isValid = await verify(signature, payload, publicKey)
// No secret exposure risk — public key is safe to ship

This is the approach used by Traffic Orchestrator. Ed25519 signatures are 64 bytes, fast to compute (under 1ms), and cryptographically secure against forgery.

Key Format Design

Your key format affects customer experience, support costs, and technical integration:

Format	Example	Use Case
Segmented hex	A8F3K-2M9XP-Q7BN4-R5DW8	Desktop apps, manual entry
JWT-style	eyJhbG...payload.signature	API integrations, SDKs
UUID-based	a8f3k2m9-xpq7-bn4r-5dw8-j6ht9c3f2y1a	SaaS platforms, database-friendly
Short codes	PRO-A8F3K2M9	Promotional codes, trials

Entropy Requirements

The minimum entropy depends on your threat model:

• 128 bits — Minimum for production use. Brute-forcing would take billions of years
• 160 bits — Recommended. Provides a comfortable security margin
• 256 bits — Maximum practical entropy. Used when keys also serve as API credentials

Never use sequential IDs, timestamps alone, or deterministic seeds as license keys. An attacker who can predict the next key can generate unlimited valid licenses.

Common Mistakes

1. Shipping the Signing Secret

If you use HMAC (symmetric) signing and embed the secret in your application binary, attackers will extract it and forge keys. Use asymmetric cryptography (Ed25519) so clients only need the public key.

2. No Revocation Mechanism

Signed keys are valid forever unless you build revocation into your validation flow. Always check a revocation list — either server-side or via periodic sync.

3. Leaking Key Metadata

If your key format encodes the plan tier in plaintext (e.g., PRO-XXXXX), customers may attempt to modify the prefix. Sign the entire payload including metadata.

4. Insufficient Key Length

Keys with fewer than 80 bits of entropy can be brute-forced. Always use at least 128 bits from a cryptographically secure random source.

Operational Best Practices

• Rotate signing keys periodically — Maintain a key ID in your license format so old licenses remain valid during rotation
• Log all key generation events — Audit trails prevent unauthorized key creation
• Rate-limit key generation APIs — Prevent automated key farming
• Hash keys before storage — Store SHA-256 hashes in your database, not raw keys
• Support key migration — Allow customers to transfer keys when changing domains or hardware