Hands-On Quantum-Safe PKI: A Practical Post-Quantum Cryptography Implementation Guide
Updated 01.16.26 for FrodoKEM/BIKE/HQC alternate algorithms 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-65/87, ML-KEM-768/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-65 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-65, ML-DSA-87 FIPS 204 Key Establishment ML-KEM-768, ML-KEM-1024 FIPS 203 Hash Functions SHA-384, SHA-512 FIPS 180-4 Note: CNSA 2.0 currently does NOT support ML-DSA-44, SLH-DSA, or Falcon algorithms. 📚 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 CA using ML-DSA-65 for operational certificate issuance 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 (Module-Lattice Key Encapsulation Mechanism), formerly known as Kyber, is a NIST-standardized quantum-resistant key encapsulation mechanism specified in FIPS 203. ML-KEM-768 provides roughly AES-192 equivalent security. 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 documentationBreaking 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
Decrypting tcpdumps in Wireshark without key files (such as when FIPS is in use)
Problem this snippet solves: This procedure allows you to decrypt a tcpdump made on the F5 without requiring access to the key file. Despite multiple F5 pages that claim to document this procedure, none of them worked for me. This solution includes the one working iRule I found, trimmed down to the essentials. The bash command is my own, which generates a file with all the required elements from the LTM log lines generated by the iRule, needed to decrypt the tcpdump in Wireshark 3.x. How to use this snippet: Upgrade Wireshark to Version 3+. Apply this iRule to the virtual server targeted by the tcpdump: rule sessionsecret { when CLIENTSSL_HANDSHAKE { log local0.debug "CLIENT_RANDOM [SSL::clientrandom] [SSL::sessionsecret]" log local0.debug "RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]" } when SERVERSSL_HANDSHAKE { log local0.debug "CLIENT_RANDOM [SSL::clientrandom] [SSL::sessionsecret]" log local0.debug "RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]" } } Run tcpdump on the F5 using all required hooks to grab both client and server traffic. tcpdump -vvni 0.0:nnnp -s0 host <ip> -w /var/tmp/`date +%F-%H%M`.pcap Conduct tests to reproduce the problem, then stop the tcpdump (Control C) and remove the iRule from the virtual server. Collect the log lines into a file. cat /var/log/ltm | grep -oe "RSA Session.*$" -e "CLIENT_RANDOM.*$" > /var/tmp/pms Copy the .pcap and pms files to the computer running Wireshark 3+. Reference the "pms" file in "Wireshark > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename" (hence the pms file name). Ensure that Wireshark > Analyze > Enabled Protocols > "F5 Ethernet trailer" and "f5ethtrailer" boxes are checked. Open the PCAP file in Wireshark; it will be decrypted. IMPORTANT TIP: Decrypting any large tcpdump brings a workstation to its knees, even to the point of running out of memory. A much better approach is to temporarily move the pms file, open the tcpdump in its default encrypted state, identify the problem areas using filters or F5 TCP conversation and export them to a much smaller file. Then you can move the pms file back to the expected location and decrypt the smaller file quickly and without significant impact on the CPU and memory. Code : Please refer to the "How to use this Code Snippet" section above. This procedure was successfully tested in 12.1.2 with a full-proxy virtual server. Tested this on version: 12.1Moving FIPS keys from 8900 to 10200
Hello, According to DOC, it seems likely FIPS-2 keys sync is not possible between 8900 and 10200 due to FIPS hardware difference (no exact platform mention, but it's close enough): https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-platform-fips-administration.pdf?sr=32944290 Important: Because of hardware differences, it is not possible to synchronize security domains between the newer platforms(10000/11000/11050 platforms) and older platforms (6900/8900platforms). Q: Assuming identical software version and security world configuration - is there an alternate way to move FIPS keys from 8900 to 10200? Regards,
Unable to import SSL Keys in FIPS
Hi F5 Community ! I have to upgrade hadware of a LTM cluster. FIPS is enabled on this platforms. I have activated the FIPS on the new cluster. When i try to import SSL keys on the new BIGIP from the old cluster, every keys in FIPS mode can not be imported on the new appliance. I 'm getting this following message on the GUI and in SSH: Dec 7 12:29:22 Fips-1 err mcpd[7623]: 010713e4:3: FIPS subsystem reported error while attempting file object operation: import_key_file: failed to open key file(s) /config/ssl/ssl.cavfips/.exp, /config/ssl/ssl.cavfips/.exp, /config/ssl/ssl.cavfips/.key.exp. Dec 7 12:29:22 Fips-1 err mcpd[7623]: 01070712:3: Caught configuration exception (0), unable to import key (/Common/****.key) in FIPS card. Did you meet this type of error ? And if yes what is the workaround. Thanks for your help B.
