Encryption algorithms receive significant attention in cybersecurity discussions, but the keys that control those algorithms are what actually determine whether encryption protects your data. The strongest algorithm provides no security if the key is compromised, predictable, or poorly managed.

Understanding what makes keys secure, how different key types serve different purposes, and why key management is the critical vulnerability in most systems is essential for anyone responsible for protecting sensitive information. This guide covers the fundamentals of encryption keys, compares the major algorithms in use today, and addresses the emerging challenge of post-quantum cryptography.

What is an Encryption Key?

An encryption key is the secret parameter that controls an encryption algorithm's behaviour. The same algorithm applied with different keys produces completely different ciphertext, even from identical plaintext. The key is the sole element that must remain secret. Compromise of the key means compromise of all data encrypted with it.

Modern encryption keys are sequences of random bits. A 256-bit key is a random string of 256 zeros and ones, providing 2^256 possible key values. This is a number so large it exceeds the estimated number of atoms in the observable universe. This vast key space is what makes brute-force attacks impractical with current computing technology.

Symmetric and Asymmetric Keys: Two Approaches to Encryption

Encryption systems use two fundamentally different approaches to key management, each suited to different purposes.

Symmetric Keys

Symmetric encryption uses a single shared key for both encryption and decryption. Both the sender and recipient must possess the same secret key. This approach is fast and computationally efficient, making it the standard for bulk data protection: encrypting databases, file systems, network traffic, and stored data.

The dominant symmetric algorithm is AES (Advanced Encryption Standard), adopted by NIST in 2001 and now the global standard. AES supports key lengths of 128, 192, and 256 bits. AES-128 provides approximately 128 bits of security, meaning an attacker would need roughly 2^128 operations to break it through brute force. AES-256 provides even greater margins, and current recommendations specify 128 bits for general use and 256 bits for highly sensitive data. For a deeper look at symmetric encryption, see our guide to AES and modern data protection.

The primary weakness of symmetric encryption is key distribution. Both parties need identical secret keys before they can communicate securely. Exchanging those keys without interception requires a separate secure channel, which is why organisations use hybrid cryptosystems combining symmetric and asymmetric encryption.

Asymmetric Keys

Asymmetric encryption uses a mathematically linked pair of keys: a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. This eliminates the key distribution problem, because the public key can be shared with anyone without compromising security.

Asymmetric encryption is computationally expensive compared to symmetric encryption, so it is typically used for short operations: exchanging symmetric session keys, creating digital signatures, and authenticating identities. The most widely used asymmetric algorithms are RSA and elliptic curve cryptography (ECC).

Asymmetric keys require substantially longer lengths for equivalent security. RSA-2048 provides roughly 112 bits of security, less than AES-128 despite having a much longer key. This difference exists because asymmetric security relies on mathematical problem complexity (factoring large numbers for RSA, solving discrete logarithms for ECC), not just key space size. Current recommendations specify minimum 2048-bit RSA keys, with 3072 or 4096 bits for long-term security.

In practice, Public Key Infrastructure (PKI) manages asymmetric keys through digital certificates that bind public keys to verified identities. The certificate lifecycle, from issuance through renewal and revocation, is how organisations maintain trust in their asymmetric key infrastructure.

Encryption Key Algorithm Comparison

The following table compares the major encryption algorithms in use today, including the post-quantum standards that will replace current asymmetric algorithms over the coming years.

Note: AES-256 remains quantum-safe because Grover's algorithm only halves its effective key strength (to 128 bits), which is still computationally infeasible to attack. The threat from quantum computing falls on asymmetric algorithms (RSA, ECC), not symmetric ones.

Key Generation: Where Security Begins

Keys must be generated using cryptographically strong random number generators. Predictable keys, even slightly predictable ones, undermine security entirely. If an attacker can narrow the possible key values from 2^256 to 2^40 through prediction, brute force becomes feasible.

Common key generation failures include using system time as a random seed, relying on weak random number generators, generating keys on systems with insufficient entropy (newly booted virtual machines are a frequent culprit), and deriving keys from predictable passwords without proper key derivation functions.

Proper key generation uses hardware random number generators (HRNGs) or well-seeded cryptographic random number generators (CSPRNGs). For keys derived from passwords, key derivation functions like PBKDF2, bcrypt, or Argon2 stretch weak passwords into strong keys by adding computational cost that makes brute-force attacks against the password impractical.

Key Storage and Protection

How encryption keys are stored and protected is as important as how they are generated. Common storage failures include hardcoding keys in source code (visible to anyone with repository access), storing keys in configuration files without protection, keeping keys on the same systems as encrypted data (one compromise exposes both), and leaving keys in memory longer than necessary.

Hardware Security Modules (HSMs) provide the gold standard for key protection. HSMs are dedicated hardware devices designed to generate, store, and use cryptographic keys without ever exposing the key material. Even administrators cannot extract keys from a properly configured HSM; they can only use the keys for authorised operations. HSMs are standard practice in government, defence, and financial services PKI deployments, and are increasingly required by regulatory frameworks.

For organisations not using HSMs, key management services from cloud providers (AWS KMS, Azure Key Vault, Google Cloud KMS) offer similar protection with operational simplicity. The key remains in the provider's secure infrastructure; your applications request cryptographic operations rather than accessing keys directly. Our partnership with Cryptomathic extends this further with CrystalKey 360, which centralises key lifecycle management across applications, HSMs, cloud environments, and key stores.

Key Rotation and Lifecycle Management

Keys should not last forever. Regular key rotation limits the damage from undetected compromise: if a key was stolen six months ago, data encrypted with a new key remains protected. Rotation also limits the volume of data encrypted under any single key, reducing that key's value to attackers.

Key lifecycle management encompasses generation, distribution, storage, use, rotation, and eventual destruction. Each stage presents security challenges. Distribution must use secure channels. Storage must prevent unauthorised access. Use must be logged and monitored. Rotation must not disrupt operations. Destruction must be complete and verifiable.

For asymmetric keys, this lifecycle is managed through PKI: the infrastructure of certificates, certificate authorities, and revocation mechanisms that bind keys to identities and manage their validity. Certificate lifecycle management automates this process at scale, ensuring certificates (and the keys they contain) are renewed before expiry, revoked when compromised, and governed consistently across the entire estate.

Encryption Key Security Checklist

The following checklist summarises the key management practices that organisations should have in place. Gaps in any of these areas represent direct risk to the effectiveness of your encryption.

Hardware random number generation: all cryptographic keys are generated using hardware RNG or properly seeded CSPRNGs, never from predictable sources.

HSM storage for CA and signing keys: all Certificate Authority private keys and code signing keys are stored in hardware security modules, not in software keystores.

Automated key rotation: key rotation is automated with defined intervals, not dependent on manual processes or calendar reminders.

Separation of duties: no single individual can generate, access, and use a key without oversight. Key ceremonies for root CA keys follow multi-person control procedures.

Audit logging: all key operations (generation, use, rotation, destruction) are logged with immutable audit trails that support forensic investigation and compliance reporting.

Complete cryptographic inventory: the organisation maintains a cryptographic bill of materials that maps where keys and certificates exist across the infrastructure.

Key destruction verification: decommissioned keys are destroyed through verified processes, not simply deleted from file systems where recovery may be possible.

Incident response for key compromise: documented procedures exist for responding to suspected or confirmed key compromise, including immediate revocation, re-keying, and notification.

The Gap Between Strong Algorithms and Weak Operations

The vast theoretical security margin of modern encryption algorithms creates a dangerous illusion. Organisations assume their data is protected because they use AES-256 or RSA-2048, while operational practices undermine that protection entirely.

Security audits frequently reveal keys stored in plain text, shared across multiple systems, never rotated, or accessible to far more people than necessary. These operational failures, not algorithm weaknesses, cause real-world encryption breaches.

The shift to shorter digital certificate lifetimes (down to 47 days for public TLS certificates by 2029) and the growing adoption of zero trust security strategies are both increasing the operational demands on key management. Organisations that cannot manage keys effectively at current volumes will face significantly greater challenges as certificate frequency and key rotation requirements intensify.

Post-Quantum Encryption: How Quantum Computing Threatens Current Keys

The most significant emerging threat to encryption key security comes from quantum computing. Current asymmetric algorithms (RSA and ECC) derive their security from mathematical problems that classical computers cannot solve efficiently: factoring large numbers (RSA) and solving discrete logarithms on elliptic curves (ECC). A sufficiently powerful quantum computer running Shor's algorithm could break both in hours.

This does not mean all encryption becomes insecure. Symmetric algorithms like AES are far less affected. Grover's algorithm provides a quadratic speedup for brute-force attacks on symmetric keys, effectively halving the key strength. AES-256 would offer 128 bits of post-quantum security, which remains computationally infeasible to attack. The threat is concentrated on asymmetric cryptography: the key exchange, digital signatures, and identity verification that PKI depends on.

NIST Post-Quantum Standards

NIST published three post-quantum cryptography standards in 2024 (FIPS 203, 204, and 205):

ML-KEM (CRYSTALS-Kyber, FIPS 203) replaces RSA and ECDH for key encapsulation (secure key exchange). ML-KEM keys are approximately 1,184 bytes for the ML-KEM-768 parameter set, compared to 256 bytes for a typical RSA-2048 public key. This increase in key and ciphertext sizes has implications for network protocols, certificate sizes, and bandwidth.

ML-DSA (CRYSTALS-Dilithium, FIPS 204) replaces RSA and ECDSA for digital signatures. ML-DSA-65 public keys are approximately 1,952 bytes, and signatures are approximately 3,293 bytes, significantly larger than their RSA or ECC equivalents.

SLH-DSA (SPHINCS+, FIPS 205) provides a hash-based backup signature scheme. It uses a fundamentally different mathematical approach from ML-DSA, providing diversity in case lattice-based assumptions are later found to be vulnerable.

What This Means for Key Management

The transition to post-quantum algorithms will require organisations to update their key management infrastructure. HSMs must support the new algorithms and the larger key sizes. Certificate management systems must handle larger certificates without performance degradation. Network infrastructure must accommodate increased bandwidth from larger key exchanges.

NIST has set a 2030 deadline for deprecating RSA and ECC, with full prohibition by 2035. Organisations should be assessing their cryptographic estate now, building crypto agility into their architecture, and developing phased migration roadmaps. For a comprehensive overview of PQC transition planning, see our guide to preparing your PKI for quantum computing.

The harvest now, decrypt later threat makes this particularly urgent for organisations handling data with long-term sensitivity. Adversaries intercepting encrypted data today may be able to decrypt it once quantum capability becomes available, which means organisations handling classified, medical, financial, or intellectual property data should treat PQC readiness as a current priority, not a future one.

How Unsung Supports Encryption Key Security

Unsung specialises in the infrastructure that makes key management work: the PKI that manages asymmetric keys, the HSM deployments that protect critical key material, and the operational practices that ensure keys remain secure throughout their lifecycle.

Our services include:

PKI health checks that assess your current key management practices against security best practices, identifying gaps that could undermine your encryption.

Certificate lifecycle management to automate the issuance, renewal, and revocation of the certificates that carry your asymmetric keys.

Hardware security module design, deployment, and integration to protect your most critical cryptographic material.

Cryptographic bill of materials to map your full cryptographic estate and identify where vulnerable algorithms or weak key management practices exist.

PKI consultancy for organisations planning post-quantum migration, key management modernisation, or cryptographic infrastructure redesign.

Our consultants hold SC and DV security clearance and work across government, defence, financial services, and healthcare. Get in touch to discuss your encryption key management requirements.

Frequently Asked Questions

What is the difference between symmetric and asymmetric encryption keys?

Symmetric encryption uses a single shared key for both encryption and decryption. It is fast and efficient, used for bulk data protection. Asymmetric encryption uses a mathematically linked pair of keys (public and private). It is slower but solves the key distribution problem. In practice, PKI combines both: asymmetric keys securely exchange a symmetric session key, which then encrypts the actual data.

How long should an encryption key be?

For symmetric encryption, 128 bits (AES-128) is considered secure for general use, and 256 bits (AES-256) for highly sensitive data. For asymmetric encryption, minimum 2048-bit RSA keys are recommended, with 3072 or 4096 bits for long-term security. ECC P-256 provides equivalent security to RSA-3072 with much shorter keys. Post-quantum algorithms require significantly larger keys: ML-KEM-768 keys are approximately 1,184 bytes.

What is an HSM and why does it matter for key security?

A hardware security module is a dedicated physical device designed to generate, store, and use cryptographic keys without ever exposing the key material. HSMs ensure that private keys cannot be extracted, even by administrators. They are essential for protecting CA private keys, meeting regulatory requirements, and providing the highest level of assurance for cryptographic operations.

Will quantum computing break all encryption?

No. Quantum computing threatens asymmetric algorithms (RSA, ECC) that rely on mathematical problems quantum computers can solve efficiently. Symmetric algorithms like AES are far less affected. AES-256 retains 128 bits of security against quantum attacks, which remains computationally infeasible. The PKI framework (certificates, CAs, trust hierarchies) will remain; only the underlying asymmetric algorithms will change.

What is key rotation and how often should it happen?

Key rotation is the practice of replacing encryption keys at regular intervals. It limits the damage from undetected compromise and reduces the volume of data protected by any single key. Rotation frequency depends on the key's sensitivity and use case. CA root keys may rotate on 10-to-20-year cycles with strict ceremony controls. TLS certificate keys rotate with certificate renewal (annually or more frequently). Session keys rotate per connection.

What is a cryptographic bill of materials (CBOM)?

A CBOM is a comprehensive inventory of all cryptographic assets across your organisation: keys, certificates, algorithms, protocols, and their dependencies on business services. It provides the visibility needed to assess risk, plan migrations (including PQC), and demonstrate compliance. Without a CBOM, any key management or PQC planning is built on assumptions rather than evidence.

What is crypto agility?

Crypto agility is the organisational capability to transition between cryptographic algorithms quickly and with minimal disruption. As post-quantum standards mature, organisations will need to replace the algorithms their keys and certificates currently use. Systems designed with crypto agility can make this transition through configuration changes rather than application rewrites.

How does key management relate to zero trust?

Zero trust architectures rely on cryptographic proof of identity for every access request. The keys embedded in digital certificates provide this proof. If keys are compromised, poorly managed, or expired, zero trust controls fail. Effective key management, including automated rotation, HSM protection, and certificate lifecycle management, is a prerequisite for zero trust.