Post-Quantum Cryptography in 2026: How ML-KEM, ML-DSA and Quantum-Safe TLS Are Securing the Future Internet

November 5, 2026

Post-Quantum Cryptography in 2026: How ML-KEM, ML-DSA and Quantum-Safe TLS Are Securing the Future Internet

Introduction

The rapid advancement of quantum computing is creating one of the most significant challenges in modern cybersecurity: protecting digital communications against future quantum-enabled attacks.

For decades, internet security has relied heavily on public-key cryptographic algorithms such as RSA, Elliptic Curve Cryptography (ECC), and Diffie–Hellman key exchange. These algorithms secure online banking, enterprise applications, cloud infrastructure, authentication systems, and confidential communications.

However, sufficiently powerful quantum computers could undermine the mathematical assumptions on which many of these algorithms depend.

This challenge has accelerated the development of Post-Quantum Cryptography (PQC), a new generation of cryptographic techniques designed to resist attacks by both classical and quantum computers.

In August 2024, the National Institute of Standards and Technology (NIST) finalized three important post-quantum cryptography standards:

FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM).
FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA).
FIPS 205: Stateless Hash-Based Digital Signature Algorithm (SLH-DSA).

An important development occurred on October 27, 2026, when NIST published the final NISTIR 8547, Transition to Post-Quantum Cryptography Standards. This report establishes a comprehensive transition framework for replacing quantum-vulnerable public-key cryptography.

Meanwhile, modern cryptographic libraries such as OpenSSL 3.5 and later provide practical implementations of post-quantum algorithms and hybrid TLS 1.3 key exchange.

This tutorial explains the underlying concepts, standards, architectures, practical implementations, and security considerations involved in building quantum-resistant software systems.

1. What Is Post-Quantum Cryptography?

Post-Quantum Cryptography refers to cryptographic algorithms designed to withstand known attacks using both conventional computers and sufficiently powerful quantum computers.

Unlike quantum cryptography, which may require specialized quantum communication hardware, PQC algorithms run on ordinary computers and servers.

They can therefore be integrated into existing operating systems, applications, network infrastructure, and security protocols.

1.1 Why Classical Public-Key Cryptography Is Vulnerable

Traditional public-key cryptography depends on computational problems that are believed to be difficult for classical computers.

For example:

RSA: Relies on the difficulty of factoring sufficiently large integers.

Elliptic Curve Cryptography: Relies on the elliptic-curve discrete logarithm problem.

Finite-Field Diffie–Hellman: Relies on the discrete logarithm problem over finite fields.

These mathematical problems are computationally expensive for conventional computers at appropriate security parameters.

However, Shor’s quantum algorithm provides polynomial-time algorithms for integer factorization and discrete logarithms on a sufficiently capable quantum computer.

Consequently, public-key systems based on these problems could become vulnerable.

1.2 What About Symmetric Encryption?

Symmetric cryptography, including AES, is affected differently.

Grover’s algorithm offers a theoretical quadratic speedup for certain brute-force search problems.

It does not generally break AES in the same way that Shor’s algorithm threatens RSA and ECC.

AES-256 remains an important choice for systems requiring long-term security, although quantum attack costs depend on implementation assumptions and computational resources.

Modern hash functions also remain useful, subject to appropriate security parameters and application-specific analysis.

1.3 What Makes PQC Different?

PQC algorithms rely on mathematical structures for which no comparably devastating, practical quantum attacks are currently known.

Major approaches include:

Lattice-based cryptography.
Hash-based digital signatures.
Code-based cryptography.
Multivariate cryptography and other research approaches.

No algorithm should be considered unconditionally quantum-proof. Cryptographic security depends on evolving research, implementation quality, and appropriate parameter selection.

2. Understanding the Quantum Threat

2.1 Shor’s Algorithm

Shor’s algorithm is particularly relevant because it threatens widely deployed asymmetric cryptography.

Consider a simplified example involving RSA.

In RSA, a public modulus is generated from the product of two large prime numbers:

[
n = p \times q
]

The security of RSA depends partly on the difficulty of recovering the factors (p) and (q) from (n).

Large classical computers cannot efficiently factor properly chosen RSA moduli using currently known classical algorithms.

A sufficiently capable fault-tolerant quantum computer running Shor’s algorithm could change that security assumption.

2.2 Harvest Now, Decrypt Later

An immediate concern is the Harvest Now, Decrypt Later (HNDL) attack.

An adversary may record encrypted communication today and preserve it for future analysis.

The attack involves three stages:

Collect encrypted communication protected using quantum-vulnerable key establishment.
Store the captured ciphertext and relevant handshake information.
Use a sufficiently powerful quantum computer in the future to recover the necessary secrets and decrypt previously captured data.

This threat is especially relevant to information that must remain confidential for many years.

Examples include medical records, government communications, proprietary research, financial information, and sensitive corporate data.

PQC migration is therefore not only about protecting future communications. It is also about reducing the long-term confidentiality risks affecting information transmitted today.

3. NIST Post-Quantum Cryptography Standards

NIST’s finalized standards provide a foundation for modern PQC deployment.

Standard	Algorithm	Purpose
FIPS 203	ML-KEM	Key establishment
FIPS 204	ML-DSA	Digital signatures
FIPS 205	SLH-DSA	Hash-based digital signatures

Although these standards were finalized in August 2024, their deployment and integration continue to be important developments in 2026.

The October 2026 migration guidance further clarifies the need for organizations to identify and replace quantum-vulnerable algorithms.

4. ML-KEM: Module-Lattice-Based Key Encapsulation

ML-KEM is a post-quantum key-encapsulation mechanism standardized in FIPS 203.

It is based on the CRYSTALS-Kyber family and uses mathematical problems associated with module lattices.

The underlying security assumptions are connected to the Module Learning with Errors (Module-LWE) problem.

4.1 What Is a Key-Encapsulation Mechanism?

A Key-Encapsulation Mechanism (KEM) allows two parties to establish a shared secret using public-key cryptography.

A KEM does not directly encrypt arbitrary application data.

Instead, it establishes a secret that can be used with symmetric encryption algorithms or incorporated into a secure key schedule.

ML-KEM provides three fundamental operations:

Key Generation

(public_key, private_key) = KeyGen()

Encapsulation

(ciphertext, shared_secret_A) =
    Encapsulate(public_key)

Decapsulation

shared_secret_B =
    Decapsulate(private_key, ciphertext)

When the procedure succeeds:

shared_secret_A == shared_secret_B

Both parties then possess the same secret value.

The exchanged ciphertext is not the encrypted application message. It is the KEM encapsulation output.

4.2 ML-KEM Security Parameter Sets

Parameter set	NIST security category	Public key size	Ciphertext size	Shared secret
ML-KEM-512	1	800 bytes	768 bytes	32 bytes
ML-KEM-768	3	1,184 bytes	1,088 bytes	32 bytes
ML-KEM-1024	5	1,568 bytes	1,568 bytes	32 bytes

The higher parameter sets provide stronger security targets but generally increase key sizes, message sizes, and computational costs.

ML-KEM-768 offers a useful balance for many applications and is a central building block in hybrid TLS key exchange.

These NIST security categories describe standardized security-strength targets; they should not be interpreted as exact predictions of the resources needed for every possible attack.

5. Practical 1: Generate ML-KEM Keys Using OpenSSL

This experiment demonstrates a complete ML-KEM workflow using OpenSSL.

5.1 Requirements

Install OpenSSL 3.5 or later with ML-KEM support.

The experiment can be performed on Windows, Linux, or macOS.

Verify the installed version:

openssl version

Check that ML-KEM is available:

openssl list -kem-algorithms

OpenSSL 3.5 introduced native ML-KEM functionality.

If the command does not list ML-KEM algorithms, verify that the correct OpenSSL executable and cryptographic provider are being used.

5.2 Generate an ML-KEM-768 Private Key

openssl genpkey -algorithm ML-KEM-768 -out mlkem_private.pem

This creates a private key suitable for ML-KEM decapsulation.

The corresponding public key can be extracted from it.

5.3 Extract the Public Key

openssl pkey -in mlkem_private.pem -pubout -out mlkem_public.pem

The public key may be distributed to a party that needs to establish a shared secret.

The private key must remain protected.

5.4 Encapsulate a Shared Secret

openssl pkeyutl -encap -pubin -inkey mlkem_public.pem -out ciphertext.bin -secret sender_secret.bin

This operation produces two outputs:

ciphertext.bin — the encapsulated KEM ciphertext.
sender_secret.bin — the shared secret generated by encapsulation.

5.5 Decapsulate the Shared Secret

openssl pkeyutl -decap -inkey mlkem_private.pem -in ciphertext.bin -secret receiver_secret.bin

The holder of the private key decapsulates the ciphertext and obtains the corresponding shared secret.

5.6 Verify Both Secrets

On Linux or macOS:

cmp sender_secret.bin receiver_secret.bin

If the files are identical, cmp exits successfully without displaying differences.

On Windows, use:

fc /b sender_secret.bin receiver_secret.bin

The result should indicate that no differences were found.

The two parties have successfully established matching secret values.

Security note: The generated .pem private key and shared-secret files are sensitive. Keep this exercise inside a disposable laboratory directory, protect file permissions, and never publish these files in a source-code repository.

6. ML-DSA: Module-Lattice-Based Digital Signature Algorithm

ML-DSA is standardized in FIPS 204 and is derived from the CRYSTALS-Dilithium digital signature family.

Its purpose is different from ML-KEM.

ML-KEM establishes shared secrets.

ML-DSA creates and verifies digital signatures.

Digital signatures provide two essential security properties:

Authenticity: Assurance that a message was signed using the corresponding private key.

Integrity: Evidence that the signed information has not been modified after signing.

In properly designed systems, digital signatures also contribute to non-repudiation, although legal and operational non-repudiation additionally depends on key management, identity binding, and evidentiary controls.

6.1 How ML-DSA Works

The signing process involves three operations.

Step 1: Generate Keys

(public_key, private_key) = KeyGen()

Step 2: Sign a Message

signature = Sign(private_key, message)

Step 3: Verify the Signature

valid = Verify(public_key, message, signature)

If the message is modified after signing, verification should fail.

6.2 ML-DSA Parameter Sets

Algorithm	NIST security category	Public key	Signature
ML-DSA-44	2	1,312 bytes	2,420 bytes
ML-DSA-65	3	1,952 bytes	3,309 bytes
ML-DSA-87	5	2,592 bytes	4,627 bytes

ML-DSA signatures are larger than many classical elliptic-curve signatures.

Consequently, migrating to ML-DSA may affect protocol message sizes, certificate chains, storage requirements, and network performance.

7. Practical 2: Create and Verify ML-DSA Digital Signatures

This experiment uses OpenSSL 3.5 or later.

7.1 Generate an ML-DSA-65 Private Key

openssl genpkey -algorithm ML-DSA-65 -out mldsa_private.pem

7.2 Extract the Public Key

openssl pkey -in mldsa_private.pem -pubout -out mldsa_public.pem

7.3 Create a Message

Create a text file called message.txt containing:

Post-Quantum Cryptography protects future digital communications.

7.4 Sign the Message

openssl pkeyutl -sign -in message.txt -inkey mldsa_private.pem -out signature.bin

The command generates an ML-DSA signature.

7.5 Verify the Signature

openssl pkeyutl -verify -in message.txt -pubin -inkey mldsa_public.pem -sigfile signature.bin

Expected output:

Signature Verified Successfully

7.6 Test Signature Integrity

Modify the message to:

Post-Quantum Cryptography has no security challenges.

Run the verification command again.

The signature verification should fail because the message is no longer identical to the original signed content.

This experiment demonstrates how digital signatures detect unauthorized changes.

7.7 Where Is ML-DSA Useful?

ML-DSA is relevant to:

Software update signing.
Secure document signing.
Firmware authentication.
Digital identity systems.
Code-signing infrastructure.
Post-quantum certificate systems.
Enterprise application authentication.

Its suitability in a particular application depends on protocol compatibility, certificate support, key-management requirements, and the availability of interoperable implementations.

8. What Is Quantum-Safe TLS?

Transport Layer Security (TLS) protects communication between applications, browsers, APIs, and servers.

TLS 1.3 typically uses public-key key establishment, authentication mechanisms, and symmetric cryptography.

For example, an HTTPS connection may use:

Client
  |
  | TLS handshake
  v
Server
  |
  | Key establishment
  v
Shared application traffic keys
  |
  | Authenticated symmetric encryption
  v
Secure application communication

Traditional TLS 1.3 connections commonly rely on elliptic-curve Diffie–Hellman key exchange.

A sufficiently powerful future quantum computer threatens the long-term confidentiality of traffic captured from such connections.

Quantum-resistant TLS addresses this concern by incorporating post-quantum key-establishment mechanisms.

8.1 Hybrid TLS Key Exchange

Hybrid key exchange combines a classical algorithm with a post-quantum algorithm.

An important example is:

X25519MLKEM768

This combines:

X25519 elliptic-curve key agreement.
ML-KEM-768 post-quantum key encapsulation.

The resulting key schedule incorporates contributions from both mechanisms through a specified hybrid construction.

The objective is to preserve security when at least one underlying component continues to provide the required protection, subject to the assumptions of the construction and its implementation.

8.2 Why Hybrid Cryptography?

Hybrid systems are important during cryptographic migration because post-quantum algorithms are relatively new compared with long-established classical algorithms.

They enable a transition strategy that can retain classical security properties while introducing protection against known quantum attacks.

However, hybrid implementations have trade-offs:

Larger handshake messages.
Increased network bandwidth.
Possible compatibility issues.
Changes in latency under some network conditions.
More complicated protocol testing.

8.3 Quantum-Resistant Key Exchange Is Not the Same as Fully Quantum-Safe TLS

A TLS connection may use X25519MLKEM768 for key establishment while continuing to authenticate its server through a traditional RSA or ECDSA certificate.

Such a connection has quantum-resistant hybrid key exchange, but its authentication is not fully post-quantum.

Achieving comprehensive post-quantum protection also requires suitable authentication algorithms, certificate infrastructure, validated implementations, and secure operational procedures.

This distinction is essential when evaluating the quantum readiness of HTTPS services.

9. Practical 3: Test Hybrid Post-Quantum TLS 1.3 Using OpenSSL

This experiment demonstrates hybrid TLS key exchange in a local environment.

It requires OpenSSL 3.5 or later.

Step 1: Verify Supported TLS Groups

Run:

openssl list -tls1_3 -tls-groups

Check whether X25519MLKEM768 is listed.

Step 2: Generate a Test Server Certificate

For laboratory testing, create a self-signed certificate:

openssl req -x509 -newkey rsa:3072 -noenc -keyout server.key -out server.crt -days 1 -subj "/CN=localhost"

The certificate is valid only for testing and is not trusted by public browsers.

It uses classical RSA authentication to keep the laboratory simple.

The experiment therefore tests hybrid post-quantum key exchange, not fully post-quantum authentication.

Step 3: Start a TLS Server

Open a terminal and run:

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

This starts a local TLS 1.3 server.

Keep the terminal running while testing the client.

Step 4: Connect with an OpenSSL Client

Open another terminal:

openssl s_client -connect localhost:8443 -servername localhost -tls1_3 -groups X25519MLKEM768 -brief -CAfile server.crt -verify_hostname localhost

The client requests the hybrid group.

Because the server and client both support it, a successful handshake should negotiate X25519MLKEM768.

Look for output indicating:

Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

The exact cipher suite and printed fields may vary with the OpenSSL build and configuration. The selected TLS group is the key information to verify.

Step 5: Interpret the Result

A successful connection demonstrates that the client and server can negotiate a TLS 1.3 hybrid key exchange.

The confidentiality of the handshake’s established session keys incorporates both the X25519 and ML-KEM contributions.

It does not demonstrate that the certificate signature or the entire authentication chain is post-quantum.

This distinction is important when reporting experimental results.

10. Practical 4: Automating ML-KEM Experiments with Python

Python can automate cryptographic testing by invoking OpenSSL through the subprocess module.

This example generates an ML-KEM-768 key pair, encapsulates a secret, decapsulates it, and verifies that both values match.

Create a file named mlkem_demo.py.

import subprocess
import tempfile
import hmac

from pathlib import Path


def run_command(args):
    subprocess.run(
        args,
        check=True,
        capture_output=True,
        text=True
    )


def main():

    with tempfile.TemporaryDirectory() as temp:

        folder = Path(temp)

        private_key = folder / "private.pem"
        public_key = folder / "public.pem"

        ciphertext = folder / "ciphertext.bin"
        sender_secret = folder / "sender.bin"
        receiver_secret = folder / "receiver.bin"

        # Step 1: Generate ML-KEM private key

        run_command([
            "openssl", "genpkey",
            "-algorithm", "ML-KEM-768",
            "-out", str(private_key)
        ])

        # Step 2: Extract public key

        run_command([
            "openssl", "pkey",
            "-in", str(private_key),
            "-pubout",
            "-out", str(public_key)
        ])

        # Step 3: Encapsulate secret

        run_command([
            "openssl", "pkeyutl",
            "-encap",
            "-pubin",
            "-inkey", str(public_key),
            "-out", str(ciphertext),
            "-secret", str(sender_secret)
        ])

        # Step 4: Decapsulate secret

        run_command([
            "openssl", "pkeyutl",
            "-decap",
            "-inkey", str(private_key),
            "-in", str(ciphertext),
            "-secret", str(receiver_secret)
        ])

        # Step 5: Compare secret values

        secret_a = sender_secret.read_bytes()
        secret_b = receiver_secret.read_bytes()

        matched = hmac.compare_digest(
            secret_a,
            secret_b
        )

        print("ML-KEM-768 Experiment")
        print("---------------------")
        print("Secret Size:", len(secret_a), "bytes")
        print("Ciphertext Size:",
              ciphertext.stat().st_size, "bytes")
        print("Secrets Match:", matched)

        assert matched, "KEM verification failed"


if __name__ == "__main__":
    main()

Execution

python mlkem_demo.py

Expected output:

ML-KEM-768 Experiment
---------------------
Secret Size: 32 bytes
Ciphertext Size: 1088 bytes
Secrets Match: True

Explanation

The program performs the complete ML-KEM lifecycle through OpenSSL.

The subprocess.run() method invokes system commands.

The temporary directory reduces the risk of accidentally retaining experimental key material.

The hmac.compare_digest() method compares the resulting secret values without using an ordinary early-exit string comparison.

This program is appropriate for educational experimentation.

It is not a complete secure communication protocol and should not be used as a substitute for established TLS or authenticated encryption implementations.

11. Traditional Cryptography vs Post-Quantum Cryptography

Feature	Traditional public-key cryptography	Post-quantum cryptography
Examples	RSA, ECDH, ECDSA	ML-KEM, ML-DSA, SLH-DSA
Mathematical foundations	Factoring, discrete logarithms	Lattices, hash-based constructions
Threat from Shor’s algorithm	Significant for applicable schemes	No equivalent known efficient attack
Public-key size	Often relatively compact for ECC	May be substantially larger
Signature size	Often compact for ECC	Frequently larger
Maturity	Decades of operational deployment	Newer standardized algorithms
Migration requirements	Established infrastructure	Software, protocol and operational updates
Quantum resilience	Vulnerable in major asymmetric schemes	Designed to resist currently known quantum attacks

Post-quantum cryptography does not eliminate symmetric encryption.

For example, modern systems may combine ML-KEM-based key establishment with AES-256-GCM authenticated encryption.

12. Enterprise Architecture for Post-Quantum Security

A post-quantum-ready enterprise application may combine quantum-resistant key establishment, authentication, security monitoring, and cryptographic lifecycle management.

An illustrative architecture is:

                  CLIENT
                    |
                    v
             TLS 1.3 HANDSHAKE
                    |
             HYBRID KEY EXCHANGE
                    |
             X25519 + ML-KEM
                    |
                    v
             AUTHENTICATION
                    |
       Classical / PQ Migration Path
                    |
                    v
          SYMMETRIC SESSION KEYS
                    |
                    v
              AES-256-GCM
                    |
                    v
              APPLICATION
                    |
          +---------+---------+
          |                   |
     DATABASE             CLOUD API
          |                   |
      ENCRYPTION          KEY MANAGEMENT

This architecture distinguishes key establishment from certificate authentication.

Both components must be included in a complete migration plan.

12.1 Cryptographic Inventory

Organizations should identify where existing cryptographic algorithms are used.

Relevant locations include:

TLS endpoints.
API gateways.
SSH services.
VPNs.
Certificate authorities.
Software signing systems.
Cloud key management services.
Authentication applications.
Database encryption infrastructure.
Embedded and IoT devices.

12.2 Crypto-Agility

Crypto-agility is the ability to replace or update cryptographic algorithms without redesigning an entire application.

It is essential because algorithms, implementation guidance, and industry standards may evolve.

Applications should avoid unnecessarily hardcoding a single cryptographic algorithm throughout their codebases.

12.3 Secure Key Management

Post-quantum keys require secure generation, storage, rotation, distribution, and destruction.

Organizations should use mature cryptographic libraries and appropriate key-management infrastructure rather than creating their own cryptographic primitives.

13. The 2026 NIST Post-Quantum Migration Roadmap

NIST’s final IR 8547 was published on October 27, 2026.

The report provides guidance for transitioning from quantum-vulnerable public-key cryptographic standards to post-quantum alternatives.

It identifies affected cryptographic standards and supports migration planning for federal organizations and other technology stakeholders.

13.1 Important Migration Milestones

The United States federal transition framework includes several significant targets:

Target year	Migration objective
2030	Prioritized key-establishment migration for specified federal high-value assets and high-impact systems
2031	Corresponding digital-signature migration for those specified systems
2035	Broad federal post-quantum migration target

These are U.S. federal policy milestones, not universal deadlines imposed on all businesses or countries.

Organizations operating elsewhere must also consider their own national regulations, contractual obligations, and security requirements.

13.2 Practical Migration Strategy

A structured migration program may follow these stages.

Phase 1: Discovery

Identify cryptographic assets and quantum-vulnerable implementations.

Phase 2: Risk Assessment

Prioritize systems based on data sensitivity, confidentiality lifetime, and exposure.

Phase 3: Compatibility Testing

Evaluate post-quantum algorithms, hybrid configurations, application libraries, and protocol support.

Phase 4: Pilot Deployment

Introduce supported PQC components in a controlled environment.

Phase 5: Performance Evaluation

Measure handshake latency, CPU consumption, certificate sizes, network overhead, and interoperability.

Phase 6: Production Rollout

Deploy compatible implementations with appropriate monitoring, rollback procedures, and key-management controls.

Phase 7: Continuous Review

Track updated cryptographic standards, vulnerabilities, interoperability guidance, and implementation requirements.

14. Performance Challenges of Post-Quantum Cryptography

The introduction of post-quantum algorithms brings engineering challenges beyond mathematical security.

14.1 Larger Keys and Signatures

Post-quantum public keys, ciphertexts, and signatures may be larger than their classical alternatives.

This can increase transmission sizes and storage requirements.

14.2 TLS Handshake Overhead

Larger key shares and certificate chains can increase TLS handshake traffic.

Under certain network conditions, larger messages may affect connection-establishment latency.

14.3 Embedded-System Constraints

IoT devices may have limited memory, bandwidth, CPU resources, and energy capacity.

Algorithm selection and implementation efficiency are important in such environments.

14.4 Compatibility

Not all clients, servers, load balancers, hardware security modules, and certificate-management systems support the same post-quantum algorithms.

Upgrading one component does not guarantee end-to-end compatibility.

14.5 Implementation Security

Cryptographic implementations may be vulnerable to timing attacks, cache attacks, fault injection, or other side-channel techniques.

Standards compliance alone does not guarantee that every implementation is secure.

15. Benchmarking Post-Quantum Algorithms

Developers and researchers can evaluate post-quantum implementations using a consistent experimental methodology.

Useful measurements include:

Key-generation latency.
Encapsulation latency.
Decapsulation latency.
Signing latency.
Signature verification latency.
Public-key size.
Ciphertext or signature size.
CPU utilization.
Memory consumption.
TLS handshake time and transferred bytes.

15.1 Benchmarking with OpenSSL

OpenSSL provides a benchmarking utility:

openssl speed -help

Algorithm availability and supported benchmark options depend on the OpenSSL version and provider configuration.

Where supported, ML-KEM and ML-DSA implementations can be benchmarked using the OpenSSL speed framework.

For rigorous research, the methodology should report the exact library version, build configuration, processor, operating system, number of repetitions, and statistical measures.

15.2 Suggested Experiment

Compare:

Configuration A: Classical X25519-based TLS 1.3 key exchange.

Configuration B: Hybrid X25519MLKEM768 TLS 1.3 key exchange.

Collect handshake time, CPU utilization, and bytes transferred.

Repeat tests under multiple network conditions, including low latency and simulated high latency.

Present average, median, standard deviation, and percentile results rather than relying on a single execution.

No performance improvement or degradation should be claimed without measurement.

16. Applications of Post-Quantum Cryptography

16.1 Cloud Computing

PQC can help protect communication between cloud clients, applications, and infrastructure components.

Hybrid TLS deployments are particularly relevant to cloud-facing APIs and services.

16.2 Banking and Financial Systems

Financial institutions handle information requiring strong confidentiality, authentication, and long-term integrity.

PQC migration planning can help reduce exposure to future quantum threats.

16.3 Healthcare Systems

Medical records may require confidentiality for long periods.

Quantum-resistant communication and carefully managed digital signatures may become important components of healthcare infrastructure.

16.4 Software Supply Chains

Post-quantum signatures can support future software signing and verification mechanisms.

Migration must address signing tools, distribution formats, verification systems, and trust infrastructure.

16.5 Internet of Things

IoT devices require efficient cryptographic mechanisms for secure communication and firmware authentication.

Implementations must account for device limitations and lifecycle constraints.

16.6 Government and Defense

Systems handling long-lived sensitive information are strong candidates for early cryptographic inventory, risk analysis, and carefully planned migration.

17. Challenges and Limitations

Post-quantum cryptography is an important advancement, but several challenges remain.

Newer security assumptions: Post-quantum schemes have received extensive scrutiny, but their standardized deployments are newer than many classical systems.

Larger data structures: Keys, ciphertexts, and signatures may require additional storage and bandwidth.

Incomplete ecosystem migration: Many legacy systems do not yet support new algorithms.

Operational complexity: Organizations must maintain cryptographic inventories, manage certificates and keys, and coordinate upgrades.

Authentication migration: Hybrid key exchange does not automatically provide post-quantum authentication.

Side-channel risks: Correct algorithms can still be undermined by insecure implementations.

Quantum computing uncertainty: The arrival date of a cryptanalytically relevant quantum computer remains uncertain.

For these reasons, organizations should approach PQC through risk-based engineering and carefully validated deployment strategies.

18. Future Research Directions

Post-quantum cryptography offers significant research opportunities.

18.1 Lightweight PQC for IoT

Design and evaluate efficient cryptographic implementations suitable for constrained devices.

18.2 Hybrid Cryptographic Protocol Optimization

Investigate ways to reduce latency, communication overhead, and resource consumption in hybrid key-exchange protocols.

18.3 Post-Quantum Cloud Security

Study cryptographic integration within distributed cloud systems, container platforms, and service-to-service communication.

18.4 Side-Channel-Resistant Implementations

Evaluate implementations against timing, cache, and fault-based attacks.

18.5 Crypto-Agile Software Architecture

Develop mechanisms that enable applications to transition between cryptographic algorithms without major redesign.

18.6 Post-Quantum Authentication Infrastructure

Investigate interoperability, scalability, and operational trade-offs when deploying post-quantum signatures in certificate and identity infrastructures.

19. Frequently Asked Questions

Q1. What is post-quantum cryptography?

Post-quantum cryptography refers to algorithms designed to resist attacks from both classical and sufficiently powerful quantum computers.

Q2. Is ML-KEM an encryption algorithm?

ML-KEM is a key-encapsulation mechanism. It establishes shared secrets that can be used to derive keys for symmetric encryption.

Q3. What is the difference between ML-KEM and ML-DSA?

ML-KEM supports shared-secret establishment, while ML-DSA is used to generate and verify digital signatures.

Q4. Does ML-KEM replace AES?

No. ML-KEM and AES serve different purposes. ML-KEM establishes secrets, while AES provides symmetric encryption.

Q5. What is X25519MLKEM768?

It is a hybrid key-exchange group combining classical X25519 key agreement and post-quantum ML-KEM-768.

Q6. Is TLS 1.3 already quantum-safe?

Not automatically. TLS 1.3 may use classical key establishment and classical signatures. Quantum-resistant configurations require suitable algorithm support.

Q7. Can OpenSSL implement ML-KEM and ML-DSA?

Yes. OpenSSL 3.5 introduced native support for ML-KEM, ML-DSA, and relevant post-quantum TLS capabilities.

Q8. Is RSA immediately insecure?

RSA remains widely deployed, and no generally available quantum computer has been demonstrated that can practically break properly configured modern RSA at cryptographically relevant sizes. Nevertheless, long-term risks justify migration planning.

Q9. Does post-quantum cryptography require quantum hardware?

No. PQC runs on conventional computing infrastructure.

Q10. Which ML-KEM variant should developers select?

The appropriate parameter set depends on security requirements, protocol compatibility, implementation support, and performance constraints. ML-KEM-768 is a significant option in modern hybrid TLS deployments.

Q11. Can post-quantum cryptography eliminate all cybersecurity threats?

No. PQC addresses particular cryptographic threats. It does not eliminate malware, credential theft, software vulnerabilities, access-control failures, or insecure implementation practices.

Q12. Why should organizations begin migration before powerful quantum computers arrive?

Sensitive encrypted information may already be collected and retained for future decryption. Cryptographic migration also requires substantial planning, testing, deployment, and infrastructure coordination.

20. Conclusion

Post-quantum cryptography represents a major transition in digital security.

The standardization of ML-KEM, ML-DSA, and SLH-DSA has provided a foundation for replacing vulnerable public-key cryptographic mechanisms.

The publication of NISTIR 8547 in October 2026 reinforces the importance of structured migration planning.

At the implementation level, OpenSSL provides practical tools for experimenting with post-quantum key encapsulation, digital signatures, and hybrid TLS key exchange.

ML-KEM supports quantum-resistant key establishment. ML-DSA provides quantum-resistant digital signatures. Hybrid TLS combines classical and post-quantum key-establishment technologies to support a gradual transition.

However, a secure migration requires more than replacing algorithms.

Organizations must also evaluate authentication, certificates, software compatibility, performance, operational security, and cryptographic lifecycle management.

For programmers and cybersecurity professionals, learning these technologies is an important step toward designing systems capable of protecting sensitive information against the next generation of cryptographic threats.

References

National Institute of Standards and Technology. (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://doi.org/10.6028/NIST.FIPS.203
National Institute of Standards and Technology. (2024). FIPS 204: Module-Lattice-Based Digital Signature Standard. https://doi.org/10.6028/NIST.FIPS.204
National Institute of Standards and Technology. (2024). FIPS 205: Stateless Hash-Based Digital Signature Standard. https://doi.org/10.6028/NIST.FIPS.205
Moody, D., Perlner, R., Robinson, A., Regenscheid, A., & Cooper, D. (2026). Transition to Post-Quantum Cryptography Standards. NISTIR 8547. https://doi.org/10.6028/NIST.IR.8547
OpenSSL Project. OpenSSL 3.5: pkeyutl Documentation. https://docs.openssl.org/3.5/man1/openssl-pkeyutl/
OpenSSL Project. EVP_PKEY-ML-KEM Documentation. https://docs.openssl.org/3.5/man7/EVP_PKEY-ML-KEM/
OpenSSL Project. EVP_PKEY-ML-DSA Documentation. https://docs.openssl.org/3.5/man7/EVP_PKEY-ML-DSA/
OpenSSL Project. SSL Configuration and TLS Groups. https://docs.openssl.org/3.5/man3/SSL_CONF_cmd/
NIST Computer Security Resource Center. Post-Quantum Cryptography Project. https://csrc.nist.gov/projects/post-quantum-cryptography