Encryption Key Generator

Produces cryptographically strong random hex strings suitable for symmetric encryption keys, API tokens, or session secrets. Bytes are sourced from the browser's Web Crypto API (window.crypto.getRandomValues), which calls into the operating system's CSPRNG.

Common lengths: 16 bytes (128-bit), 32 bytes (256-bit AES key). All generation happens locally; the value never leaves the page.

The Web Crypto API's getRandomValues provides cryptographically secure pseudorandom output by calling the operating system's entropy source: /dev/urandom on Linux and macOS, BCryptGenRandom on Windows. These sources combine hardware entropy (cycle counter jitter, network packet timing, disk activity, hardware RNG instructions on modern CPUs like Intel's RDRAND) with cryptographic mixing (typically a stream cipher seeded from the entropy pool) to produce output that is computationally indistinguishable from true randomness. The contrast with Math.random is consequential: Math.random uses a non-cryptographic PRNG (xorshift128+ in V8) whose output is predictable from observed values and must never be used for security purposes.

A worked example: generating a 32-byte (256-bit) AES key produces 64 hexadecimal characters such as 'a8f3c1d4e5b9870fa2c4d6e8f1a3c5d7e9b1c3d5e7f9a1b3c5d7e9f1a3b5c7d9'. This is suitable as an AES-256 symmetric key, an HMAC-SHA256 signing key for JWT, or a session token. Shorter outputs (16 bytes / 128 bits) match AES-128 and are still considered strong against currently feasible attacks, though 256-bit is preferred for keys that need to remain secure for decades against possible future quantum attacks (which would reduce effective key strength by half via Grover's algorithm).

Limitations are mostly about correct usage rather than the generator itself. The output is suitable for symmetric encryption keys, MAC keys, session secrets, and similar one-shot random values. It is not suitable for password storage; passwords need slow, salted hashing functions (Argon2id, scrypt, bcrypt) that are deliberately slow to make brute-force attacks expensive. Using a random hex string as a 'password hash' provides no protection against an attacker who steals the database; the right approach is to hash the user's password through a memory-hard KDF and store that. Asymmetric keys (RSA, ECDSA) require keypair generation with specific mathematical properties (large primes, points on a specific curve) and cannot be produced by random hex; the Web Crypto API's generateKey function handles those properly.

Key rotation is a separate concern. Generated keys should be stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password CLI) rather than in source control or environment files, and should be rotated periodically (industry guidance varies from quarterly to annually depending on threat model). Hex encoding is more verbose than base64 but avoids URL-safety concerns and the +/= characters that need escaping in some contexts; URL-safe base64 (with - and _ replacing + and /) is the right choice for tokens that must travel in URLs.