What are Cryptographic Keys?

What is a cryptographic key?

A cryptographic key is a value used with a cryptographic algorithm or protocol to perform a security function. Depending on the design, the function may include encrypting or decrypting information, generating or verifying an authenticator, creating or verifying a digital signature, or establishing other keying material. Cryptographic keys are therefore operational inputs to cryptographic mechanisms, not merely labels for those mechanisms.21

NIST compares a cryptographic key to the combination of a safe: if an adversary learns the combination, even a strong safe does not protect its contents. The analogy highlights why an organization can select a strong algorithm and still lose confidentiality or authenticity if it mishandles the key. NIST states that effective cryptography depends directly on key strength, the associated cryptographic mechanisms and protocols, and protection of key information. []1

Key types and related cryptographic objects

The two broad key arrangements are symmetric and asymmetric. In a symmetric arrangement, entities use an already established shared symmetric key to protect files or messages or to distribute other keys. In an asymmetric arrangement, a public key is paired with a corresponding private key. Asymmetric mechanisms can also establish a symmetric key through key agreement or key transport, after which symmetric cryptography can protect application data. []3

A public key is intended to be distributed more broadly than its corresponding private key, but that does not make every public-key-related object a key. A certificate binds information, including a public key, to a subject through a certification authority’s process. RFC 5280 describes certification as a certification authority issuing a certificate for a user’s public key and returning or publishing that certificate. The certificate is therefore an assurance and distribution object around a public key, not the private key itself.43

A hash digest is also different from a key. FIPS 180-4 defines secure hash algorithms as producing condensed representations of messages and describes their use with other cryptographic algorithms, digital signatures, keyed-hash message authentication codes, and random-number generation. The digest is the output of hashing; it is not automatically a secret cryptographic key. []5

Generation, entropy, and use

Key generation should produce keying material with the properties required by the intended cryptographic mechanism and security objective. The cited NIST material identifies random bit generation, RBG seeds, shared secrets, passwords, and other public or secret information as distinct subjects in keying-material generation and distribution. This distinction matters because a key generated from predictable or inadequately protected inputs can undermine an otherwise strong algorithm.1

Entropy is relevant to the unpredictability of generated secret values. TLS 1.3 notes an implementation risk in which public output could help an attacker determine the internal state of a cryptographically secure random number generator and predict keying material; it describes using separate generators for public and private values as an additional security measure. This is implementation-specific guidance, not a universal design rule for every system, but it illustrates why random-generation design and isolation require review. []6

Keys should be used only for their intended purpose and within the assumptions of the relevant algorithm and protocol. Key length is the length of a key in bits, also called key size. Security decisions must consider the application, environment, technology, cryptographic mechanism, and expected security life of the protected information; FIPS 197 states that AES use depends on several such factors and must be combined with an approved or recommended mode of operation. []72

The cryptographic key lifecycle

Key management is the handling of cryptographic keys and related key information throughout the entire lifecycle. NIST identifies generation, storage, establishment, entry and output, use, and destruction as lifecycle activities. Its key-management-system definition additionally includes distribution, backup, archive, recovery, revocation, and associated metadata. A lifecycle view prevents teams from treating key creation as the end of the security problem.1

A practical lifecycle begins with planning and generation, followed by registration and assignment of ownership. During operation, the key is stored, accessed, used, monitored, and potentially distributed or established with another entity. Continuity planning may require protected backup and authorized recovery. When a key is changed, archived, deregistered, revoked, or destroyed, the organization must preserve the records and controls needed to understand its status and prevent unintended use. NIST SP 800-57 Part 1 Rev. 5 explicitly lists operational, postoperational, and destroyed phases and includes key change, archive, recovery, deregistration, destruction, and revocation functions. []1

Storage, access, distribution, and separation of duties

Secret keying material requires protection against unauthorized disclosure. NIST describes key-management systems as systems for managing keys and metadata, including generation, distribution, storage, backup, archive, recovery, use, revocation, and destruction. An automated system may oversee, automate, and secure the process, but automation does not remove the need for defined responsibilities, authorization, accountability, and audit.31

Access should be granted to authorized entities for defined purposes, with ownership and responsibility recorded. NIST defines a key owner as an entity authorized to use a key or key pair whose identifier is associated with it. A key-management practices statement describes organizational structure, responsible roles, and rules for lifecycle functions. These concepts support separation of duties: the people or systems that generate, approve, administer, use, audit, recover, or revoke keys need not all be the same. []14

Distribution and establishment must preserve the required security properties. Shared symmetric keys may be established manually or through asymmetric key-establishment methods. In TLS 1.3, the client and server negotiation determines shared keys, and an ephemeral Diffie–Hellman share can participate in key establishment. The exact distribution mechanism is protocol- and environment-dependent; the evidence does not support one universal delivery method.36

Backup and recovery require a balance between availability and confidentiality. RFC 5280 describes optional backup of user private keys used for encryption and recovery after loss of a password or key-chain file. It also warns that certification authorities should maintain secure backup for signing keys because loss can prevent certificate revocation-list production or normal key rollover, while insecure backup can become a compromise path.4

Rotation, recovery, revocation, and destruction

Key change is a lifecycle function, but the cited evidence does not prescribe a single rotation interval for every key. NIST discusses cryptoperiods—the appropriate lengths of time that keys are used—and includes changing keys, key update, and rekeying in its guidance. A defensible change decision therefore considers the key’s purpose, exposure, amount and sensitivity of protected data, compromise indications, operational dependencies, and the expected security life of that data.

Rotation should also be distinguished from revocation. Changing or rekeying introduces replacement keying material for continued operation. Revocation is a status action that signals that a key or certificate should no longer be trusted or used, potentially before its planned end. In PKI, certificates may expire naturally, but events during their lifetime can invalidate the binding between a subject and public key; timely and available revocation information affects relying-party assurance.

Recovery is not the same as creating a replacement. NIST defines key recovery as mechanisms and processes that allow authorized entities to retrieve or reconstruct a key from backups or archives. Recovery may be necessary for continuity or access to data encrypted under an older key, whereas compromise recovery may require generating new keys and updating dependent systems.

Destruction is the deliberate end of a key’s usable lifecycle. It should account for active copies, backups, archives, replicas, caches, and dependent metadata according to the organization’s retention and recovery requirements. NIST lists key destruction as a postoperational lifecycle function and identifies eventual destruction as part of general key-management guidance. The cited passages do not specify a universal technical erasure procedure, so implementation details must be selected for the storage technologies and applicable requirements.

Why lifecycle controls matter as much as algorithm strength

A strong algorithm cannot compensate for exposed, misused, unavailable, or poorly governed keys. NIST states that poor key management may compromise strong algorithms and that effective cryptographic protection depends on key strength, cryptographic mechanisms and protocols, and protection of key information. This is why key inventories, ownership, access control, monitoring, backup, recovery, revocation, and destruction belong in the same security conversation as algorithm and key-size selection.

Algorithms and key lengths may need to change because of algorithm breaks or more powerful computing techniques. NIST SP 800-131A Rev. 2 recommends planning for transitions and cryptographic agility. NIST SP 800-57 Part 1 also advises selecting algorithms and key sizes expected to remain secure for the entire security life of the protected data, which is especially important near transition dates.

Agility is not achieved by swapping an algorithm name in configuration alone. A transition can affect key generation, key sizes, certificates, protocols, inventories, stored ciphertext, validation, rollover, recovery, and destruction. The cited evidence establishes the need to plan for transitions, but it does not provide a universal migration schedule for every organization or application.

Conclusion

Cryptographic keys are the values that enable cryptographic algorithms and protocols to protect information, authenticate entities, or establish protected communications. Symmetric keys and asymmetric key pairs support different arrangements, while passwords, certificates, hashes, and algorithm identifiers are related but distinct objects. The central operational lesson is that cryptography is only as dependable as its key lifecycle: generate appropriate and unpredictable material, control access and distribution, maintain secure backup and recovery, change keys according to context, revoke compromised or invalid material, plan for algorithm transitions, and destroy keys when their lifecycle ends.