Hands-On Quantum-Safe PKI: A Practical Post-Quantum Cryptography Implementation Guide
Update (April 2026): The CNSA 2.0 section of this article originally listed both ML-DSA-65/87 and ML-KEM-768/1024 as approved. That's incorrect — CNSA 2.0 requires ML-DSA-87 and ML-KEM-1024 exclusively per draft-jenkins-cnsa2-pkix-profile §4. FIPS 204/203 standardize additional parameter sets but CNSA 2.0 only adopts Category 5. Is your Public Key Infrastructure quantum-ready? Remember way back when we built the PQC CNSA 2.0 Implementation guide in October 2025? So long ago! Due to popular request, we've expanded the lab to now include THREE distinct learning paths: NIST FIPS standards, NSA CNSA 2.0 compliance, AND alternative post-quantum algorithms for those wanting diversity or international compliance options.. The GitHub lab guide walks you through building quantum-resistant certificate authorities using OpenSSL with hands-on exercises. Why learn and implement post-quantum cryptography (PQC) now? While quantum computing is a fascinating area of science, all technological advancements can be misused. Nefarious people and nation-states are extracting encrypted data to decrypt at a later date when quantum computers become available, a practice you better know by now called "harvest now, decrypt later." Close your post-quantum cryptographic knowledge gap so you can get secured sooner and reduce the impact(s) that may not surface until after it's too late. Ignorance is not bliss when it comes to cryptography and regulatory fines, so let's get started. The GitHub lab provides step-by-step instructions to create: Quantum-resistant Root CA using ML-DSA-87 (FIPS and CNSA 2.0) Algorithm flexibility based on your compliance needs Quantum-safe server and client certificates OCSP and CRL revocation for quantum-resistant certificates TLS 1.3 key exchange testing with ML-KEM and hybrid modes Alternative algorithm exploration (FrodoKEM, BIKE, HQC) for TLS/KEM usage Access the Complete Lab Guide on GitHub → At A Glance: OpenSSL Quantum-Resistant CA Learning Paths Select the path that aligns with your requirements: FIPS 203/204/205 CNSA 2.0 Alt. Algorithms Target Audience Commercial organizations Government contractors, classified systems Researchers, international compliance, defense-in-depth Compliance Standard NIST FIPS standards NSA CNSA 2.0 Non-NIST algorithms, international standards Algorithm Coverage ML-DSA, ML-KEM, SLH-DSA, Hybrid ML-DSA-87, ML-KEM-/1024 FrodoKEM, BIKE, HQC Use Case General quantum-resistant infrastructure National security systems Algorithm diversity, conservative security 📚 Learning Path 1: NIST FIPS 203/204/205 For commercial organizations implementing quantum-resistant cryptography using NIST standards. This path uses OpenSSL 3.5.x's native post-quantum cryptography support—no external quantum library providers required. So nice, so easy. Modules Module Description 00 - Introduction Overview of FIPS 203/204/205, prerequisites, and lab objectives 01 - Environment Setup Verifying OpenSSL with PQC support 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-65 04 - Certificates Issuing end-entity certificates for servers and users 05 - Revocation Implementing OCSP and CRL certificate revocation 06 - Hybrid Methods IETF hybrid PQC methods (X25519MLKEM768, composite signatures) Algorithms Covered ML-DSA-44/65/87 (FIPS 204) - Lattice-based signatures ML-KEM-512/768/1024 (FIPS 203) - Lattice-based key encapsulation X25519MLKEM768 - Hybrid TLS 1.3 key exchange 📚 Learning Path 2: NSA CNSA 2.0 For government contractors and organizations requiring CNSA 2.0 compliance. This path uses OpenSSL 3.2+ with Open Quantum Safe (OQS) providers for strict CNSA 2.0 algorithm compliance. Modules Module Description 01 - Introduction Overview of CNSA 2.0 requirements and compliance deadlines 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-87 04 - Certificates Issuing CNSA 2.0 compliant certificates 05 - Revocation Implementing OCSP and CRL certificate revocation CNSA 2.0 Approved Algorithms Algorithm Type Approved Algorithms NIST Designation Digital Signatures ML-DSA-87 FIPS 204 Key Establishment ML-KEM-1024 FIPS 203 Hash Functions SHA-384, SHA-512 FIPS 180-4 Note: CNSA 2.0 requires ML-DSA-87 and ML-KEM-1024 exclusively — no other parameter sets are approved. ML-DSA-44, ML-DSA-65, ML-KEM-512, ML-KEM-768, SLH-DSA, and Falcon are NOT part of CNSA 2.0, even though several are FIPS-approved. See draft-jenkins-cnsa2-pkix-profile §4. 📚 Learning Path 3: Alternative PQC Algorithms (NEW!) For researchers, organizations requiring algorithm diversity, and those interested in international PQC implementations. This path explores post-quantum algorithms outside the primary NIST standards, providing options for defense-in-depth strategies and understanding of the broader PQC landscape. Perfect for organizations wanting to hedge against potential future vulnerabilities in current adopted standards. Modules Module Description 00 - Introduction Overview of non-NIST algorithms, international standards, use cases 01 - Environment Setup OpenSSL and modifying OQS provider configuration 02 - FrodoKEM Conservative unstructured lattice KEM (European recommended: BSI, ANSSI) 03 - BIKE and HQC Code-based KEMs (HQC is NIST-selected backup to ML-KEM) 04 - International PQC EU, South Korean, and Chinese algorithm standards 05 - Performance Analysis Comparing algorithms, latency impacts, use cases, nerd stats Algorithms Covered Algorithm Type Mathematical Basis Key Characteristic FrodoKEM KEM Unstructured lattice (LWE) Conservative security, European endorsed (BSI, ANSSI) BIKE KEM Code-based (QC-MDPC) NIST Round 4 candidate, smaller keys than HQC HQC KEM Code-based (Quasi-cyclic) NIST-selected backup to ML-KEM (standard expected 2027) Why Alternative Algorithms Matter Algorithm Diversity: If a vulnerability is found in lattice-based cryptography (ML-KEM), code-based alternatives provide a backup International Compliance: European agencies (BSI, ANSSI) specifically recommend FrodoKEM for conservative security Future-Proofing: HQC will become a FIPS standard in 2027 as NIST's official backup to ML-KEM Research & Testing: Understand the broader PQC landscape for informed decision-making What This Lab Guide Achieves Complete PKI Hierarchy Implementation The lab walks through building an internal PKI infrastructure from scratch, including: Root Certificate Authority: Using ML-DSA-87 providing the highest quantum-ready NIST security level Intermediate Certificate Authority: Intermediate Certificate Authority: ML-DSA-65 in the FIPS path, ML-DSA-87 in the CNSA 2.0 path for hierarchy-wide compliance. End-Entity Certificates: Server and user certificates with comprehensive Subject Alternative Names (SANs) for real-world applications Revocation Infrastructure: Both Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) implementation TLS 1.3 Key Exchange Testing: Hands-on testing with ML-KEM, hybrid modes, and alternative algorithms Security Best Practices: Restrictive Unix file permissions, secure key storage, and backup procedures throughout Key Takeaways After completing one or more of the labs, you will: Understand ML-DSA Cryptography: Gain hands-on experience with both ML-DSA-65 (Level 3 security) and ML-DSA-87 (Level 5 security) algorithms Explore Algorithm Diversity: Understand when and why to use alternative algorithms like FrodoKEM, BIKE, and HQC Configure Modern PKI Features: Implement SANs with DNS, IP, email, and URI entries, plus both CRL and OCSP revocation mechanisms Test TLS 1.3 Key Exchange: Hands-on experience with ML-KEM and hybrid key exchange in real TLS sessions Troubleshoot Effectively: Learn to diagnose and resolve common issues with opensl and oqsproviders for PQC compatibility Prepare for Migration: Start the practical steps needed to transition existing PKI infrastructure to quantum-resistant algorithms Access the Complete Lab Guide on GitHub → About This Guide We built the first guide for NSA Suite B in the distant past (2017) to learn ECC and modern cipher requirements. It was well received enough to built a new guide for CNSA 2.0 but it's quite specific for US federal audiences. That lead us to build a NIST FIPS PQC guide which should apply to more practical use cases. And now we've added alternative algorithms because things are only going to get a bit more complicated moving forward. In the spirit of Learn Python the Hard Way, it focuses on manual repetition, hands-on interactions and real-world scenarios. It provides the practical experiences needed to implement quantum-resistant PKI in production environments. By building it on GitHub, other PKI fans can help where we may have missed something; or simply to expand on it with additional modules or forks. Have at it! Frequently Asked Questions (FAQs) Q: What is CNSA 2.0? A: CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA's updated cryptographic standard requiring quantum-resistant algorithms. Q: When do I need to implement quantum-resistant cryptography? A: The NSA and NIST mandate CNSA 2.0 and FIPS 203/204/205 implementation by 2030. Organizations should begin now due to "harvest now, decrypt later" attacks where adversaries collect encrypted data today for future quantum decryption. Q: What is ML-DSA (Dilithium)? A: ML-DSA (Module-Lattice Digital Signature Algorithm), formerly known as Dilithium, is a NIST-standardized quantum-resistant digital signature algorithm specified in FIPS 204. Q: What is ML-KEM (Kyber)? A: ML-KEM... ships in three parameter sets — ML-KEM-512 (~AES-128), ML-KEM-768 (~AES-192), and ML-KEM-1024 (~AES-256). ML-KEM-768 is the common enterprise default; CNSA 2.0 requires ML-KEM-1024. Q: What are the alternative algorithms and why should I care? A: FrodoKEM, BIKE, and HQC are non-NIST-primary algorithms that provide algorithm diversity. If a vulnerability is discovered in lattice-based cryptography (which ML-KEM and ML-DSA use), code-based alternatives like HQC could provide a backup. HQC is actually NIST's selected backup to ML-KEM and will become a FIPS standard in 2027. Q: What's the difference between BIKE and HQC? A: Both are code-based KEMs. BIKE has smaller key sizes but wasn't selected by NIST. HQC has larger keys and was selected as NIST's official backup to ML-KEM. Q: Why do European agencies recommend FrodoKEM? A: FrodoKEM uses unstructured lattices (standard LWE) rather than the structured lattices used in ML-KEM. This provides more conservative security assumptions at the cost of larger key sizes. Germany's BSI and France's ANSSI specifically recommend FrodoKEM for high-security applications. Q: Is this guide suitable for production use? A: NOPE. While the guide teaches production-ready techniques and compliance requirements, always use Hardware Security Modules (HSMs) and air-gapped systems for production Root CAs (cold storage too). The lab is great for internal environments or test harnesses where you may need to test against new quantum-resistant signatures. ALWAYS rely on trusted public PKI infrastructure for production cryptography. 🤓 Happy PKI'ing! Reference Links NIST Post-Quantum Cryptography Standards - Official NIST PQC project page FIPS 203: ML-KEM Standard - Module-Lattice Key Encapsulation Mechanism FIPS 204: ML-DSA Standard - Module-Lattice Digital Signature Algorithm FIPS 205: SLH-DSA Standard - Stateless Hash-Based Digital Signature Algorithm NSA CNSA 2.0 Algorithm Requirements - NSA's official CNSA 2.0 announcement Open Quantum Safe Project - Home of the OQS provider for alternative algorithms OQS Provider for OpenSSL 3 - GitHub repository for OQS provider HQC Specification - Official HQC algorithm documentation BIKE Specification - Official BIKE algorithm documentation OpenSSL 3.5 Documentation - Comprehensive OpenSSL documentationPost-Quantum Cryptography: Building Resilience Against Tomorrow’s Threats
Modern cryptographic systems such as RSA, ECC (Elliptic Curve Cryptography), and DH (Diffie-Hellman) rely heavily on the mathematical difficulty of certain problems, like factoring large integers or computing discrete logarithms. However, with the rise of quantum computing, algorithms like Shor's and Grover's threaten to break these systems, rendering them insecure. Quantum computers are not yet at the scale required to break these encryption methods in practice, but their rapid development has pushed the cryptographic community to act now. This is where Post-Quantum Cryptography (PQC) comes in — a new wave of algorithms designed to remain secure against both classical and quantum attacks. Figure 1: Cryptography evolution Why PQC Matters Quantum computers exploit quantum mechanics principles like superposition and entanglement to perform calculations that would take classical computers millennia2. This threatens: Public-key cryptography: Algorithms like RSA rely on factoring large primes or solving discrete logarithms-problems quantum computers could crack using Shor’s algorithm. Long-term data security: Attackers may already be harvesting encrypted data to decrypt later ("harvest now, decrypt later") once quantum computers mature. How PQC Works The National Institute of Standards and Technology (NIST) has led a multi-year standardization effort. Here are the main algorithm families and notable examples. Lattice-Based Cryptography. Lattice problems are believed to be hard for quantum computers. Most of the leading candidates come from this category. CRYSTALS-Kyber (Key Encapsulation Mechanism) CRYSTALS-Dilithium (Digital Signatures) Uses complex geometric structures (lattices) where finding the shortest vector is computationally hard, even for quantum computers Example: ML-KEM (formerly Kyber) establishes encryption keys using lattices but requires more data transfer (2,272 bytes vs. 64 bytes for elliptic curves) The below figure shows an illustration of how Lattice-based cryptography works. Imagine solving a maze with two maps-one public (twisted paths) and one private (shortest route). Only the private map holder can navigate efficiently Code-Based Cryptography Based on the difficulty of decoding random linear codes. Classic McEliece: Resistant to quantum attacks for decades. Pros: Very well-studied and conservative. Cons: Very large public key sizes. Relies on error-correcting codes. The Classic McEliece scheme hides messages by adding intentional errors only the recipient can fix. How it works: Key generation: Create a parity-check matrix (public key) and a secret decoder (private key). Encryption: Encode a message with random errors. Decryption: Use the private key to correct errors and recover the message Figure3: Code-Based Cryptography Illustration Multivariate & Hash-Based Quadratic Equations Multivariate These are based on solving systems of multivariate quadratic equations over finite fields and relies on solving systems of multivariate equations, a problem believed to be quantum-resistant. Hash-Based Use hash functions to construct secure digital signatures. SPHINCS+: Stateless and hash-based, good for long-term digital signature security. Challenges and Adoption Integration: PQC must work within existing TLS, VPN, and hardware stacks. Key sizes: PQC algorithms often require larger keys. For example, Classic McEliece public keys can exceed 1MB. Hybrid Schemes: Combining classical and post-quantum methods for gradual adoption. Performance: Lattice-based methods are fast but increase bandwidth usage. Standardization: NIST has finalized three PQC standards (e.g., ML-KEM) and is testing others. Organizations must start migrating now, as transitions can take decades. Adopting PQC with BIG-IP As of F5 BIG-IP 17.5, the BIG-IP now supports the widely implemented MLKEM cipher group for client-side TLS negotiations as well as Server side TLS negotiation. Other cipher groups and capabilities will become available in subsequent releases. Cipher walkthrough Let's take the supported cipher in v17.5.0 (Hybrid X25519_Kyber768) as an example and walk through it. X25519: A classical elliptic-curve Diffie-Hellman (ECDH) algorithm Kyber768: A post-quantum Key Encapsulation Mechanism (KEM) The goal is to securely establish a shared secret key between the two parties using both classical and quantum-resistant cryptography. Key Exchange X25519 Exchange: Alice and Bob exchange X25519 public keys. Each computes a shared secret using their own private key + the other’s public key: Kyber768 Exchange: Alice uses Bob’s Kyber768 public key to encapsulate a secret: Produces a ciphertext and a shared secret Bob uses his Kyber768 private key to decapsulate the ciphertext and recover the same shared secret: Both parties now have: A classical shared secret A post-quantum shared secret They combine them using a KDF (Key Derivation Function): Why the hybrid approach is being followed: If quantum computers are not practical yet, X25519 provides strong classical security. If a quantum computer arrives, Kyber768 keeps communications secure. Helps organizations migrate gradually from classical to post-quantum systems. Implementation guide F5 introduced new enhancements in 17.5.1 New Features in BIG-IP Version 17.5.1 BIG-IP now supports the X25519MLKEM768 hybrid key exchange in TLS 1.3 on the client side and server side. This mechanism combines the widely used X25519 elliptic curve key exchange with MLKEM768 They provide enhanced protection by ensuring the confidentiality of communications even in future quantum threats. This enhancement strengthens the application’s cryptographic flexibility and positions it for secure communication in classical and post-quantum environments. This change does not affect existing configurations but provides an additional option for enhanced security where supported. Implementation KB provided by F5 K000149577: Enabling Post-Quantum Cryptography in F5 BIG-IP TMOS NGINX Support for PQC We are pleased to announce support for Post Quantum Cryptography (PQC) starting NGINX Plus R33. NGINX provides PQC support using the Open Quantum Safe provider library for OpenSSL 3.x (oqs-provider). This library is available from the Open Quantum Safe (OQS) project. The oqs-provider library adds support for all post-quantum algorithms supported by the OQS project into network protocols like TLS in OpenSSL-3 reliant applications. All ciphers/algorithms provided by oqs-provider are supported by NGINX. To configure NGINX with PQC support using oqs-provider, follow these steps: Install the necessary dependencies sudo apt update sudo apt install -y build-essential git cmake ninja-build libssl-dev pkg-config Download and install liboqs git clone --branch main https://github.com/open-quantum-safe/liboqs.git cd liboqs mkdir build && cd build cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DOQS_DIST_BUILD=ON .. ninja sudo ninja install Download and install oqs-provider git clone --branch main https://github.com/open-quantum-safe/oqs-provider.git cd oqs-provider mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DOPENSSL_ROOT_DIR=/usr/local/ssl .. make -j$(nproc) sudo make install Download and install OpenSSL with oqs-provider support git clone https://github.com/openssl/openssl.git cd openssl ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl linux-x86_64 make -j$(nproc) sudo make install_sw Configure OpenSSL for oqs-provider /usr/local/ssl/openssl.cnf: openssl_conf = openssl_init [openssl_init] providers = provider_sect [provider_sect] default = default_sect oqsprovider = oqsprovider_sect [default_sect] activate = 1 [oqsprovider_sect] activate = 1 Generate post quantum certificates export OPENSSL_CONF=/usr/local/ssl/openssl.cnf # Generate CA key and certificate /usr/local/ssl/bin/openssl req -x509 -new -newkey dilithium3 -keyout ca.key -out ca.crt -nodes -subj "/CN=Post-Quantum CA" -days 365 # Generate server key and certificate signing request (CSR) /usr/local/ssl/bin/openssl req -new -newkey dilithium3 -keyout server.key -out server.csr -nodes -subj "/CN=your.domain.com" # Sign the server certificate with the CA /usr/local/ssl/bin/openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365 Download and install NGINX Plus Configure NGINX to use the post quantum certificates server { listen 0.0.0.0:443 ssl; ssl_certificate /path/to/server.crt; ssl_certificate_key /path/to/server.key; ssl_protocols TLSv1.3; ssl_ecdh_curve kyber768; location / { return 200 "$ssl_curve $ssl_curves"; } } Conclusion By adopting PQC, we can future-proof encryption against quantum threats while balancing security and practicality. While technical hurdles remain, collaborative efforts between researchers, engineers, and policymakers are accelerating the transition. Related Content K000149577: Enabling Post-Quantum Cryptography in F5 BIG-IP TMOS F5 NGINX Plus R33 Release Now Available | DevCentral New Features in BIG-IP Version 17.5.1 The State of Post-Quantum Cryptography (PQC) on the Web
Even More Hands-On Quantum-Safe PKI: Building Enterprise PQC Certificate Authorities with EJBCA Community Edition
Your PQC CAs just graduated from the command line to the corner office. Back in December and again in January we published Hands-On Quantum-Safe PKI, a step-by-step lab for building quantum-resistant certificate authorities from scratch using OpenSSL. You learned ML-DSA algorithms, built a Root CA, chained an Intermediate CA, issued end-entity certificates, and stood up revocation infrastructure, all by hand, one command at a time. Billions of you went through it. Six of you even enjoyed it. But here's the thing about building a CA with OpenSSL: it works beautifully for learning and it works beautifully for testing. It does not work beautifully at 2 AM when someone asks you to revoke a certificate and your "management interface" is vim index.txt . Calgon, take me away! The lab has expanded. The Post-Quantum Cryptography Step-by-Step Lab now includes a complete EJBCA Community Edition deployment track, nine modules that take you from bare metal to enterprise-managed, quantum-resistant Certificate Authorities running inside a real PKI management platform. Same SassyCorp identity. Same ML-DSA-87 Root CA and ML-DSA-65 Intermediate CA. Now with a database, an application server, audit logs, and a web UI that doesn't require you to memorize openssl ca flags. But if you want to we won't stop you and we love you for that. 🔥🔥🔥 Access the Complete Lab on GitHub 🔥🔥🔥; The new lab walks through deploying Keyfactor's EJBCA Community Edition v9.3 on Ubuntu with WildFly 35, MariaDB, and OpenJDK 21. You configure a 3-port TLS architecture, HTTP on 8080, public HTTPS on 8442, and mutual TLS admin access on 8443 where your browser has to prove it's worth it is before EJBCA lets you touch anything. It's PKI with actual access control, which is a refreshing change from chmod 600 being your entire security model. The Evolution: Why This Matters Think of it as three stages of PQC readiness. The first lab (CNSA 2.0 with OpenSSL) taught you algorithm mechanics for federal use cases. The second lab (FIPS 203/204/205) broadened that to commercial compliance. This third expansion puts those same algorithms inside infrastructure that can actually manage certificates at scale — issuance, renewal, revocation, OCSP, CRL distribution, role-based access, and audit logging that doesn't live in a flat file. That progression is intentional. You can't meaningfully operate an enterprise PKI platform if you don't understand what's happening underneath it. And you can't stop at OpenSSL if your organization needs to manage more than a handful of certificates. The compliance clock is running - NIST is deprecating classical asymmetric algorithms by 2030, the NSA wants full CNSA 2.0 enforcement by 2033, and Australia is trying to eliminate classical public-key crypto entirely by 2030 (bless their ambitious hearts). Having people who can actually stand up and operate PQC certificate authorities isn't optional anymore. It's PKI Thunderdome! What You Can Do Next After completing the lab, you'll have a fully operational EJBCA instance with three CAs — the RSA ManagementCA for internal admin plumbing, plus your ML-DSA-87 Root and ML-DSA-65 Intermediate for quantum-resistant certificate operations. From here you can issue end-entity certificates through EJBCA's enrollment interface, configure CRL distribution points, set up OCSP responders, explore the REST API, and experiment with hybrid certificates that combine PQC and classical algorithms. You've got an enterprise PKI playground that happens to be quantum-resistant. The whole thing runs on a single VM if you want, that's what we did. No Docker, no scripts, no "just run this compose file and trust me." Every command is manual, every configuration file is edited by hand, and every step explains why. We remain faithful disciples of the "Learn Python the Hard Way" school of pedagogy, mostly because it works and partly because suffering builds character. The lab is open source, community-driven, and waiting for your pull requests. Go break something, then fix it. That's how you learn. Access the Complete Lab on GitHub → References Resource URL EJBCA Community Edition (Keyfactor) https://github.com/Keyfactor/ejbca-ce Keyfactor PQC Hybrid CA Tutorial https://docs.keyfactor.com/ejbca/latest/tutorial-create-pqc-hybrid-ca-chain Keyfactor EJBCA Installation Docs https://docs.keyfactor.com/ejbca-software/latest/installation WildFly 35 Documentation https://docs.wildfly.org/35/ PQC Coalition — International Requirements https://pqcc.org/international-pqc-requirements/Breaking Down the Quantum Challenge: Why Post-Quantum Cryptography Can't Wait
The Quantum Challenge is Now Post-quantum cryptography represents the next steps of our digital security evolution. Sure, quantum systems capable of breaking current encryption may still be an a few years away, but those beginning their transition now will be well-positioned for when the crypto hits the fan. Nation-state adversaries and sophisticated private entities may be collecting data today hoping to decrypt it tomorrow so it's never to early to start solving the problem now. It's an excellent time to get ahead of the curve with quantum-resistant cryptography. What does this mean for your organization? Any sensitive data encrypted today using standard methods (RSA, ECDSA) could potentially become readable to future quantum-powered attackers. F5 Community Evangelist Chase Abbott discusses the real world implications of quantum computing, and how you can prepare and migrate to NIST-approved hybrid PQC standards. The transition to post-quantum cryptography represents a perfect opportunity to modernize enterprise PKI practices. Those of you that begin planning today have ample time to implement these changes thoughtfully and strategically, positioning yourselves as leaders in the next generation of cybersecurity; high fives all around. The Business Impact: Beyond Technical Considerations Regulatory and Compliance Pressure Government regulations across the globe are creating concrete deadlines for migration strategies: NSA CNSA 2.0 mandates quantum-resistant algorithms for classified systems by 2030 NIST has standardized post-quantum cryptography algorithms (FIPS 203, 204, 205) Industry regulations in finance, healthcare, and defense are beginning to incorporate quantum-safety requirements adhering to the update FIPS governance Your Quantum-Ready Roadmap: A Manageable Transition Phase 1: Assessment and Inventory Action items for leadership: Conduct cryptographic inventory across all systems and applications Identify critical data requiring long-term protection Assess vendor and third-party quantum readiness Establish quantum cryptography governance and budget allocation Phase 2: Pilot Implementation Strategic focus areas: Deploy quantum-resistant algorithms in non-critical environments Train IT and security teams on post-quantum cryptography Establish partnerships with quantum-ready technology vendors Begin updating security policies and procedures Phase 3: Production Migration Enterprise-wide deployment: Implement hybrid classical/quantum-resistant systems and software Migrate critical applications and PKI aggregation points to quantum-safe algorithms Update business continuity and disaster recovery plans Achieve full compliance with regulatory requirements as a priority over other systems Key Takeaways for Business Leaders Start planning now: The quantum threat timeline is uncertain, but the need for preparation is immediate Prioritize critical assets: Focus initial efforts on protecting your most sensitive and long-lived data Invest in capabilities: Quantum cryptography expertise will become as essential as any other IT security skill Engage stakeholders: Quantum security requires coordination across IT, compliance, procurement, and business units Monitor developments: Stay informed about quantum computing advances and regulatory updates Mahalo! Further Reading: Post Quantum Cryptography Coalition: PQC Migration Roadmap Post Quantum Cryptography Coalition: International PQC Requirements Post Quantum Cryptography Coalition: Inventory Workbook Essence of Linear Algebra Quantum Computing for the Very Curious Looking Glass Universe: Why I Left Quantum Computing Research US National Quantum Initiative
Post-Quantum Cryptography, OpenSSH, & s1ngularity supply chain attack
This week in security: PQC by default, and a supply-chain gut check. At F5, we are publishing a forward‑looking series of blog posts which help security and IT leaders anticipate tomorrow’s risks and capitalize on emerging tech. Think of it as a field guide to future threats—and how to stay resilient as they arrive. We are about half way through the series, here are some of the highlights from my point of view.Meeting the Federal Quantum Challenge: How F5 Enables Compliance with New Government Mandates
The U.S. government has made it crystal clear: the transition to quantum-resistant encryption isn't optional—it's mandatory. With new federal directives setting aggressive timelines and billion-dollar funding commitments, organizations must act now to prepare for a post-quantum world. Here's how F5's comprehensive post-quantum cryptography (PQC) solutions can help you meet these critical mandates while protecting your business from tomorrow's threats.Future-Proofing Your Network: Enabling Quantum Ciphers on F5 BIG-IP TMOS 17.5.1
The quantum computing revolution is an imminent reality that demands attention from cybersecurity experts. As quantum computers advance toward breaking traditional RSA and elliptic curve cryptography, organizations must prepare their infrastructure with quantum-resistant encryption. F5's BIG-IP TMOS 17.5.1 introduces support for post-quantum cryptographic algorithms, positioning your network security ahead of the quantum curve. Understanding the Quantum Threat Traditional cryptographic methods like RSA-2048 and ECDSA rely on mathematical problems that classical computers find computationally intractable to solve. However, quantum computers running Shor's algorithm can factor large integers exponentially faster. This renders these encryption methods vulnerable within the next decade. The National Institute of Standards and Technology (NIST) has standardized several post-quantum cryptographic algorithms. They are designed to withstand both classical and quantum attacks. TMOS 17.5.1 implements ML-KEM (FIPS 203) for key encapsulation. The standard versions are based on the original CRYSTALS-Kyber and CRYSTALS-Dilithium algorithms. They include important changes to the parameters and requirements for how they are used to make sure they work well together in the future. Prerequisites and Planning Before implementing quantum ciphers on your BIG-IP system, ensure your environment meets these requirements: Hardware Requirements: BIG-IP appliances with sufficient processing power (quantum algorithms are computationally intensive) Minimum 8GB RAM for optimal performance Hardware Security Module (HSM) support recommended for key management Hardware Security Modules are not required to support post-quantum cryptographic algorithms, but they provide a higher level of assurance for cryptographic key storage. F5 offers a range of hardware that has built in hardware security modules. Also, if virtual F5 instances are selected, they offer the ability to integrate with a network based hardware security module. Software Requirements: TMOS version 17.5.1 or later Valid SSL/TLS certificates compatible with hybrid classical-quantum cipher suites Updated client applications capable of negotiating post-quantum algorithms The current implementation is a hybrid approach where classical and post quantum algorithms run in parallel. So you would use "classical" RSA/ECDSA certificates for the server authentication, but the actual TLS handshake would use ML-KEM for establishing quantum-safe session keys. Network Considerations: Increased bandwidth requirements due to larger key sizes and signature lengths Latency impact assessment for time-sensitive applications Compatibility testing with existing security infrastructure Enabling Quantum Ciphers: Step-by-Step Configuration Step 1: Access the BIG-IP Configuration Utility Log into your BIG-IP system through the web-based Configuration utility or connect via SSH for command-line configuration. Navigate to System/Configuration/Device/General to verify you're running TMOS 17.5.1. Or in the cli type tmsh show sys version Then follow along with F5 documentation. The details are all in the article for configuration either via TMUI or TMSH. This can all be configured via APIs or could be set up using tools like Ansible or Terraform if automation is required. https://my.f5.com/manage/s/article/K000149577 Step 2: Create a Cipher Rule Step 3: Create a new Cipher Group Step 4: Create a New Client SSL profile Create a client SSL profile. Associate the ciphergroup with the new client SSL profile. Remove No TLSv1.3 from the enabled options Step 5: Create a Virtual Server Example: tmsh create /ltm virtual quantum { destination 10.0.2.113:443 ip-protocol tcp pool quantumpool profiles add { quantum { context clientside } tcp } } Test In my case, I used Chrome. I enabled the developer tools and in the privacy and developer tools, looked at what was being negotiated. Sure enough, I am getting a quantum-safe connection. Monitoring and Troubleshooting Essential Monitoring Commands Monitor quantum cipher usage and performance: # Check quantum cipher statistics tmsh show ltm profile client-ssl quantum # View quantum key exchange metrics tmsh show ltm virtual quantum Common Issues and Solutions High CPU Usage: Quantum algorithms are computationally intensive. Consider hardware acceleration or load balancing across multiple devices. Compatibility Issues: Not all clients support quantum ciphers yet. Implement graceful fallback mechanisms and maintain hybrid cipher suites during the transition period. Browser Compatibility and the Chrome ML-KEM Transition A critical consideration for BIG-IP quantum cipher deployment is the ongoing browser transition from draft Kyber implementations to standardized ML-KEM. Chrome has phased out Kybersupport in favor of ML-KEM. This shift has significant implications for your BIG-IP configuration strategy. Configuring for Browser Compatibility To ensure seamless browser compatibility during this transition, configure your BIG-IP to prioritize ML-KEM Notably, the following cipher string did not work for me in Chrome as Kyber support has been removed in the latest versions of Chrome. X25519KYBER768 As per the k Article. Note: On June 24, 2025, Google released Chrome 138.7204.49 that no longer includes Kyber support. The chrome://flags options for PQC algorithms was also removed, and MLKEM is enabled by default. My Chrome Version was Version 138.0.7204.158, so Kyber support has gone. This DH cipher string worked for me in Chrome. X25519MLKEM768 The K article recommends the following cipher string. X25519MLKEM768:X25519KYBER768:DEFAULT To reiterate. If you are using anything earlier than TMOS version 17.5.1 and you attempt a test with a new version of Chrome, it will not work with ML-KEM as the support was only introduced in 17.5.1 and Kyber has been removed from Google Chrome, so if you were to test with 17.5.0 you would find that that Chrome would not be able to negotiate a quantum-safe connection. As per the knowledge article. BIG-IP TMOS version 17.5.0 (for Kyber), 17.5.1 (for MLKEM) or later Performance Considerations Quantum cipher implementation introduces several performance implications that require careful consideration. Key exchange operations using ML-KEM-768 consume about 25% more CPU cycles than traditional ECDHE exchanges. They have slightly better performance than the original Kyber implementation due to standardization optimizations. To make your computer run faster, use hardware acceleration when possible. Use intelligent cipher selection algorithms to balance security needs with performance limits. Consider implementing session resumption mechanisms to reduce the frequency of quantum key exchanges. Compliance and Regulatory Considerations Many industries are beginning to mandate post-quantum cryptography readiness. Financial services, healthcare, and government sectors are leading the adoption of quantum-resistant security measures. TMOS 17.5.1's ML-KEM support helps organizations meet emerging compliance requirements and prepare for future regulatory mandates. It also ensures compatibility with major browsers transitioning away from draft Kyber implementations. Ensure your quantum cipher implementation aligns with relevant standards, including NIST SP 800-208, FIPS 203 (ML-KEM), and industry-specific quantum security guidelines. The transition from draft Kyber to standardized ML-KEM is critical for long-term browser compatibility and regulatory compliance. Future-Proofing Your Investment As quantum computing technology evolves, so too will post-quantum cryptographic standards. F5’s modular approach to quantum cipher implementation ensures that your BIG-IP infrastructure can adapt to future algorithm updates and security enhancements without requiring complete system replacement. Regular software updates and security patches will introduce new quantum-resistant algorithms and performance optimizations. Maintain an active support relationship with F5 to stay current with the latest quantum security developments. Conclusion Implementing quantum ciphers on F5 BIG-IP TMOS 17.5.1 represents a critical step in preparing your network infrastructure for the quantum era. While the transition requires careful planning and performance considerations, the security benefits far outweigh the implementation challenges. Start your quantum-resistant journey today by enabling hybrid cipher suites and gradually transitioning to full quantum protection. The quantum threat is real, but with proper preparation and F5's advanced security capabilities, your organization can maintain robust protection against both classical and quantum adversaries. The future of network security is quantum-resistant, and TMOS 17.5.1 provides the tools you need to secure that future today. Begin your quantum security implementation now, before the quantum advantage becomes a quantum threat.What is Quantum Computing?
Quantum computing represents a significant shift in information processing. It leverages the principles of quantum mechanics to solve problems far beyond the capabilities of classical computers. Unlike classical computers, which use bits to represent either 0 or 1, quantum computers use qubits. This enables them to exist in multiple states simultaneously through superposition. Additional quantum properties like entanglement and quantum interference further enhance computational efficiency, making quantum systems uniquely equipped to tackle complex, intractable problems. This breakthrough has profound implications for cryptography. Many classical cryptosystems, such as RSA and ECC, rely on mathematical problems that are easy to compute but difficult to reverse without a secret key. Quantum algorithms like Shor’s Algorithm can solve these problems quickly. This makes traditional encryption vulnerable to quantum-based attacks. Similarly, Grover’s Algorithm increases the speed of brute-force searches, halving the effective security of symmetric cryptographic algorithms like AES. Quantum computing has caused the need for new cryptography systems. These systems are designed to protect against attacks from quantum computers. Notably, these systems don’t require quantum properties themselves; instead, they employ mathematical techniques robust against quantum algorithms. For example, lattice-based cryptography is considered one of the most promising approaches for ensuring future-proof security. As quantum computing capabilities progress, experts warn that classical encryption methods may soon reach the end of their "cryptographic cover time," the duration during which encrypted data remains secure. Data intercepted today could be decrypted retroactively by adversaries when quantum threat models mature—a concept referred to as "harvest now, decrypt later." This underscores the urgency of transitioning to quantum-resistant technologies. Post-quantum cryptographic algorithms, combined with hybrid approaches in protocols like TLS, can protect sensitive communications from future quantum threats. Given estimates that functional quantum computers capable of breaking RSA-2048 could emerge within the next decade, governments and organizations are advised to begin implementing these technologies now to ensure long-term data security. For a deeper exploration of quantum computing and its cryptographic implications, read the full F5 Labs article.The State of Post-Quantum Crypto (PQC) on the Web
Introduction No one knows exactly when Q-day will arrive, but recent developments have seen the estimated number of Q-bits required to crack traditional encryption plummet from 1 billion in 2012, to 20 million in 2019, to just 1 million as of May 2025.2 Since Google is now predicting that sufficiently powerful quantum computers may be here by 2030, it may already be too late for many organizations to deploy post-quantum cryptography (PQC) to protect their web applications. READ THE FULL REPORT HERE Q-Day Arrival There is a growing disconnect between the rapid pace of advancements in quantum computing and the priority to which CISOs assign to the associated risk. Recent predictions now estimate the arrival of Q-Day (the date when quantum computers become powerful enough to break widely used public key cryptography) will happen as early as 2029. Yet, according to the ISACA Pulse of Quantum Computing poll, only 5% of CISOs say that post-quantum cryptography (PQC) is a ‘high business priority’ for the near future. 1 This report evaluates the current state of PQC adoption among the world’s top 1 million websites and the most commonly used web browsers and devices. Among the top one million websites, only 8.6% support hybrid PQC key exchange mechanisms. This reflects a broad hesitancy to transition and, more worryingly, 25% of websites still do not support TLS 1.3 at all, with 16% failing to implement quantum-resistant symmetric ciphers. Conversely, PQC adoption is more visible among the world’s most popular sites, with 42% of the top 100 supporting it, though this figure drops to 26% for ranks 100–200, and averages just 21.9% across the top 1,000. Support falls further to 13.9% for the top 10,000 sites and 8.4% for the top 100,000. Websites that support post-quantum cryptography The uptake of PQC is particularly low in some of the most security-sensitive sectors. Only 3% of banking websites support PQC, placing the industry among the lowest adopters—even within its own Financials sector (Figure 1). Healthcare and government websites are also lagging. Websites that support post-quantum cryptography (PQC) tend to have stronger overall TLS configurations. They offer fewer and more modern cipher suites while disabling outdated protocols like SSLv3 and TLSv1.0. Those with PQC enabled offered significantly fewer cipher suites (suggesting deliberate hardening) compared to non-PQC sites, which still commonly support weak and obsolete protocols. This contrast highlights PQC support as a strong proxy for broader cryptographic hygiene. Geographically, TLD analysis shows that countries like Australia (.au), Canada (.ca), and the UK (.uk) are leading in PQC deployment when considering both adoption rate and volume. However, when company headquarters are considered, the United States stands out as the global frontrunner. The UK, Canada, and Australia follow closely behind. Browser Support On the client side, browser support plays a major role in overall PQC readiness. While 93% of Chrome requests are PQC-ready, Safari’s lack of support reduces the global readiness rate to just 57%. Firefox, despite accounting for only 2% of requests, sees 85% of its traffic coming from PQC-capable versions. The data suggest that while technical capability for PQC adoption exists—especially given the widespread use of TLS 1.3—the practical rollout is lagging in many critical areas. For organizations with data that must remain confidential well into the future, failing to deploy PQC measures today may already be too late. Conclusion The full report explains the implications of quantum computing on TLS, the current state of PQC standards and protocols, which servers, industries, and geographies have been quickest to adopt, and suggests some steps to take if you have yet to begin your PQC journey. READ THE FULL REPORT HERE
