Encryption Key Generator

Choosing a key length

AES (FIPS 197) accepts keys of exactly 128, 192 or 256 bits (16, 24 or 32 bytes). All three are considered secure against brute force today. 256-bit is the usual default and is what most libraries, cloud key services and “AES-256” requirements expect; it also keeps a large margin against future attacks, including Grover's algorithm on a quantum computer, which would roughly halve the effective strength. 128-bit is fine where speed matters or a protocol specifies it. 192-bit is rarely used, and Chrome's Web Crypto doesn't accept it.

Keys, IVs and salts

• Key: the secret. Anyone who has it can decrypt.
• IV (initialization vector) or nonce: a per-message value that makes encrypting the same text twice give different results. It isn't secret and is stored next to the ciphertext. For AES-GCM use 12 bytes (96 bits, as NIST SP 800-38D recommends) and never reuse an IV with the same key: reuse in GCM leaks the authentication key and the XOR of the messages. CBC needs a 16-byte IV that is unpredictable; CTR needs a unique one.
• Salt: random bytes for deriving a key from a password with PBKDF2, scrypt or Argon2, so identical passwords give different keys. Store it with the result.

Hex vs Base64 output

The bytes are the same; only the text encoding differs. Hex uses 2 characters per byte (a 256-bit key is 64 characters) and is common in config files and command-line tools such as openssl enc -K. Base64 (RFC 4648) uses 4 characters per 3 bytes (44 characters with padding for 32 bytes) and is what most APIs and environment variables expect. Base64url swaps +/ for -_ and drops the padding, so it is safe in URLs and JSON Web Tokens. Copy as JWK gives a JSON Web Key (RFC 7517) with kty: "oct" that crypto.subtle.importKey("jwk", …) accepts directly. To convert other data, use the Base64 encoder.

How the keys are generated (Web Crypto)

Every byte comes from crypto.getRandomValues, the Web Crypto API's cryptographically secure random number generator, which browsers seed from the operating system (for example getrandom on Linux or BCryptGenRandom on Windows). It is the same source browsers use for TLS. Math.random is never used: it is predictable and not meant for secrets. The optional test imports the key with crypto.subtle.importKey and runs AES-GCM in the browser's own crypto implementation. The key exists only in the page's memory; it is not saved, logged or sent anywhere, and it is gone when you close the tab.

Storing keys safely

Put keys in a secrets manager or key management service (AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault) or at least an environment variable outside the code repository. Never commit keys to Git, paste them into chat or tickets, or reuse one key across environments. Plan for rotation: record which key encrypted what so you can re-encrypt. If a key may have leaked, generate a new one and re-encrypt; there is no way to “un-leak” a key. For human passwords, use a password generator; to fingerprint data rather than encrypt it, use a hash generator.