Cryptographic key

Kerckhoffs's principle (1883) is the design rule behind the concept: a cipher must remain secure even if everything except the key is public. Security is therefore measured in bits of key strength, the base-2 logarithm of the work an attacker needs. For symmetric keys that is simply the key length (AES-128 gives 128 bits, assuming no structural break); for asymmetric keys it is far lower than the length because of mathematical shortcuts. NIST SP 800-57 Part 1 Rev. 5 equates RSA-2048 with about 112 bits and RSA-3072 or ECC P-256 with about 128 bits, and treats 112 bits as the minimum for current use.

Keys come in distinct types with distinct handling rules: symmetric secret keys, private/public key pairs, key-encrypting keys (KEKs) that wrap data-encrypting keys (DEKs), MAC keys, and ephemeral session keys that exist only for one exchange. Good practice is one key, one purpose; reusing an RSA key for both signing and decryption, or the same AES key in two protocols, opens cross-protocol attacks. Derived keys are produced with a KDF such as HKDF (RFC 5869) or those in NIST SP 800-108, which is how TLS 1.3 turns one shared secret into separate traffic keys per direction.

Generation is the most underestimated step. Keys must come from a cryptographically secure random bit generator (NIST SP 800-90A DRBGs seeded from a true entropy source, exposed as getrandom() on Linux or BCryptGenRandom on Windows); SP 800-133 describes approved generation methods. History shows what happens otherwise: the 2008 Debian OpenSSL bug (CVE-2008-0166) reduced the seed to the process ID, leaving only about 32,768 possible keys per type and size, and the 2017 ROCA flaw (CVE-2017-15361) in an Infineon library produced RSA moduli that could be factored, forcing the revocation of Estonian ID-card certificates. Embedded devices that generate keys at first boot, before the entropy pool has filled, have repeatedly produced shared factors across RSA keys found on the internet.

A key is not a password. A password is low-entropy, human-chosen and must be stretched with a deliberately slow KDF (Argon2id, scrypt, PBKDF2) before it can serve as key material, and even then its effective strength is bounded by how guessable it is. Keys also differ from certificates: a certificate carries a public key and binds it to an identity, while the private key never leaves its owner. In practice keys live as PEM/DER files, entries in a PKCS#12 container, objects in an HSM or cloud KMS accessed via PKCS#11 or an API, or in a TPM or secure enclave where they are marked non-exportable. Where a key physically resides determines what a compromised host can steal: a file can be copied, a non-exportable HSM key can only be misused while access lasts.