Managing Encryption Keys for Post-Quantum Network Connections

Post-quantum cryptography is changing how organizations establish secure network connections. Existing encryption systems rely on mathematical problems that are difficult for conventional computers to solve but may become vulnerable to sufficiently powerful quantum computers.

This creates a long-term concern for organizations that handle information requiring protection for many years. An attacker could collect encrypted network traffic today and attempt to decrypt it in the future when quantum computing capabilities improve. This approach is commonly called harvest now, decrypt later.

The transition to post-quantum cryptography introduces new key types, algorithms, and compatibility requirements. However, adopting a post-quantum algorithm is only one part of the work. Organizations must also decide how keys are generated, protected, rotated, monitored, and retired.

For network connections, ML-KEM is an important part of this transition. It is standardized in NIST FIPS 203 and provides a mechanism for two parties to establish a shared secret over a public channel. That secret can then be used by symmetric encryption algorithms to protect communication.

This article explains how to manage encryption keys for post-quantum network connections, how hybrid TLS key exchange works, and what development and infrastructure teams should consider during migration.

Understand the Different Keys Used in Post-Quantum TLS

One common mistake during a post-quantum migration is treating every cryptographic key as if it serves the same purpose.

TLS uses different cryptographic mechanisms for key establishment, authentication, and data protection.

ML-KEM does not directly encrypt application traffic. It establishes a shared secret that TLS uses as part of its key schedule.

Similarly, enabling post-quantum key exchange does not automatically make certificate authentication post-quantum. A connection can use a hybrid post-quantum key exchange while still relying on conventional certificate signatures.

These differences should be reflected in the organization's cryptographic inventory and key-management policies.

Understand ML-KEM Key Generation and Lifecycle

ML-KEM is a key-encapsulation mechanism standardized by NIST in FIPS 203.

It provides three parameter sets:

• ML-KEM-512.

• ML-KEM-768.

• ML-KEM-1024.

They offer different security and performance characteristics. The appropriate parameter set depends on the protocol profile, security requirements, and supported implementation.

ML-KEM uses two types of keys:

1. Encapsulation key: The public key that another party uses to generate a shared secret and an encapsulation.

2. Decapsulation key: The private key used by the recipient to recover the shared secret.

The process can be represented as follows:

Recipient:
    Generate ML-KEM key pair
        |
        +---- Public encapsulation key
        |
        +---- Private decapsulation key

Sender:
    Receive public encapsulation key
        |
    Run ML-KEM.Encaps()
        |
        +---- Encapsulation
        |
        +---- Shared secret

Recipient:
    Receive encapsulation
        |
    Run ML-KEM.Decaps()
        |
        +---- Same shared secret

The private decapsulation key must remain protected. The public encapsulation key can be distributed through the protocol.

In TLS, the handshake implementation manages the relevant ephemeral key material. Application developers should generally use a maintained TLS library rather than manually generating ML-KEM keys and implementing the handshake themselves.

A separate ML-KEM key-management process may be necessary for other use cases, such as a custom secure communication protocol or long-term encrypted data exchange.

The distinction matters because TLS handshake keys and long-lived encryption keys have different lifecycles.

Use Hybrid Key Exchange During Migration

Replacing every traditional cryptographic mechanism at once can introduce compatibility and security risks.

Hybrid key exchange provides a transition strategy by combining a traditional key agreement algorithm with a post-quantum mechanism.

TLS 1.3 now has standardized hybrid groups defined in RFC 10024:

The two components contribute to the resulting shared secret.

The purpose is to provide security against both traditional and quantum-capable attackers, assuming the hybrid construction and its component algorithms are implemented correctly.

For many deployments, X25519MLKEM768 is a practical starting point because it combines a widely deployed elliptic-curve mechanism with ML-KEM-768.

Organizations with specific cryptographic compliance requirements may need to evaluate the P-256 or P-384 combinations instead.

Hybrid key exchange should not be confused with certificate migration. The key exchange protects the establishment of session secrets, while certificates authenticate the communicating parties.

Configure Post-Quantum Key Exchange in TLS

The TLS implementation must support the selected hybrid group on both sides of the connection.

For example, OpenSSL 3.5 and later include support for hybrid groups such as X25519MLKEM768, depending on the build and provider configuration.

First, check which TLS groups the installed OpenSSL version supports:

openssl list -tls1_3 -tls-groups

A server can configure its supported TLS groups through its OpenSSL application or TLS library configuration.

An example using the OpenSSL command-line tool is:

openssl s_server \
  -accept 4433 \
  -cert server.crt \
  -key server.key \
  -tls1_3 \
  -groups X25519MLKEM768

A client can test the connection using:

openssl s_client \
  -connect localhost:4433 \
  -tls1_3 \
  -groups X25519MLKEM768

These commands assume that the installed OpenSSL build supports the requested group and that the certificate and private key are valid.

They are useful for a controlled compatibility test. They are not a complete production TLS configuration.

For production systems, configure the preferred hybrid group alongside approved compatibility groups where the TLS implementation and organizational policy allow it. Monitor the negotiated group so that the team can identify whether clients actually use the intended key exchange.

Also verify that load balancers, reverse proxies, API gateways, service meshes, and other TLS termination points support the same algorithms. Updating only the application server may leave the externally visible connection using traditional key exchange.

Protect Long-Term Private Keys

ML-KEM private keys and certificate signing keys should not be managed identically.

A certificate signing key may remain active for an extended period and is used to authenticate identities. An ephemeral ML-KEM decapsulation key used during a TLS handshake has a much shorter operational lifecycle.

For long-term keys, use an established key-management system such as a Hardware Security Module or an appropriately configured Key Management Service.

Important controls include:

• Restrict access to private key operations.

• Separate key administrators from application administrators.

• Use strong authentication for key-management operations.

• Maintain an audit trail for key generation and usage.

• Define rotation and retirement procedures.

• Establish a response process for suspected compromise.

Where a cryptographic module supports the required post-quantum algorithms, verify that its implementation and compliance status meet the organization's requirements.

Do not assume that an existing HSM supports ML-KEM merely because it supports RSA and elliptic-curve algorithms.

Also avoid storing private key material in application configuration files, container images, source repositories, or ordinary environment variables.

Separate Session Key Management From KMS Operations

A common architectural question is whether ML-KEM session keys should be stored in a central KMS.

For ordinary TLS connections, the answer is generally no.

The TLS implementation generates and processes ephemeral key material during the handshake. It derives traffic secrets and uses them to protect the connection. These session secrets should remain within the TLS implementation's protected memory and should not be exported to a central KMS for routine storage.

A KMS is more appropriate for managing long-lived keys used for tasks such as:

• Encrypting stored application data.

• Protecting database encryption keys.

• Wrapping data-encryption keys.

• Managing long-term cryptographic secrets.

• Controlling access to key material used by separate services.

This separation prevents unnecessary exposure of ephemeral session secrets and avoids introducing a central dependency into every TLS handshake.

For example, an application may use hybrid TLS to establish a secure connection to a database service while using a KMS-managed key to encrypt sensitive records stored in the database.

Both mechanisms contribute to security, but they solve different problems.

Plan Key Rotation and Algorithm Replacement

Post-quantum migration should include cryptographic agility: the ability to replace algorithms and key configurations without redesigning the entire application.

A practical key-management policy should define:

1. Which algorithms are approved for each use case.

2. Which components generate and store the keys.

3. How key ownership and access are assigned.

4. When keys are rotated or retired.

5. How compromised keys are revoked or replaced.

6. How clients and servers transition between algorithm versions.

For TLS, ephemeral key material is normally regenerated as part of new handshakes. Session resumption and ticket lifetimes also need review because they influence how long previously established session state can be reused.

For long-term signing keys, rotation requires a different process involving certificates, trust stores, certificate authorities, and dependent services.

Do not use a single rotation interval for every cryptographic key. The appropriate lifetime depends on the key's purpose, exposure, algorithm, and security policy.

Monitor Compatibility and Performance

Hybrid key exchange introduces larger handshake messages than many traditional key exchanges.

This can affect network infrastructure that assumes smaller TLS ClientHello messages.

Potential problems include:

• Firewalls dropping fragmented handshake traffic.

• Older proxies rejecting unfamiliar supported groups.

• TLS inspection devices failing to parse new key-share formats.

• Increased handshake processing time.

• Client libraries not supporting the selected hybrid group.

The larger ClientHello can be particularly relevant when a client sends a hybrid key share during its initial handshake.

Test the connection across the actual network path rather than relying only on a direct local TLS test.

A useful validation checklist includes:

For large services, compare the results with the existing TLS configuration under representative traffic.

Common Key-Management Mistakes

Conclusion

Managing encryption keys for post-quantum network connections requires a clear distinction between ephemeral handshake material, long-term private keys, certificate signing keys, and symmetric session keys.

ML-KEM provides a standardized mechanism for establishing shared secrets, while hybrid TLS key exchange combines post-quantum protection with established classical algorithms during the migration period.

For application and infrastructure teams, the priority should be to use maintained cryptographic implementations, protect long-term private keys, keep ephemeral session secrets within the TLS implementation, and verify compatibility across every network component.

A well-planned migration also needs cryptographic agility. Algorithms will continue to evolve, so key-management policies and network architectures should make future changes possible without requiring a complete application redesign.