Post-Quantum Cryptography in Open Source: What’s Ready and What’s Coming [Part 3]

In Part 1, we explored the urgent “harvest now, decrypt later” threat. In Part 2, we decoded which algorithms to deploy: ML-KEM for key exchange, ML-DSA for signatures. But knowing which algorithms to use solves only half the problem.

Now comes the practical question every engineering team asks: “Where can I actually use these algorithms today?”

While cloud providers like AWS and Google Cloud have deployed PQC, the real story lies in the open source foundations that power them. The answer is both encouraging and nuanced. Post-quantum cryptography in open source has reached an inflection point: hybrid key exchange is production-ready right now. Container signing? That’s still catching up. Understanding what’s ready versus what’s coming determines whether your migration succeeds or stalls.

The Open Source PQC Ecosystem in 2026

The open source landscape transformed dramatically between April 2025 and today. Two foundational releases changed everything: OpenSSL 3.5 and Go 1.24. These aren’t incremental updates; they represent a fundamental shift in how the internet’s cryptographic infrastructure operates.

OpenSSL 3.5, released on April 8, 2025, delivered native ML-KEM, ML-DSA, and SLH-DSA support directly in the library, with no external providers, no third-party patches, no complex compilation flags needed. More importantly, it changed the default TLS 1.3 key shares to offer X25519MLKEM768 and X25519, making hybrid post-quantum key exchange the default behavior for any application linked against it.

Go 1.24, released in February 2025, followed the same philosophy. The crypto/tls package now defaults to X25519MLKEM768 as the first preference in its CurvePreferences. No code changes required. Any Go application compiled with Go 1.24+ automatically negotiates post-quantum key exchange when connecting to a capable server.

PQC by Inheritance: The Cloud-Native Ripple Effect

The ripple effects extended across the cloud-native ecosystem. Kubernetes, etcd, Istio, containerd (all written in Go) inherited quantum resistance simply by upgrading their Go runtime. This “PQC by inheritance” model means the infrastructure securing containers, orchestrating workloads, and managing service meshes gained quantum protection without explicit cryptographic code changes.

Here’s what’s ready versus what’s coming:

OpenSSL 3.5: The Foundation of Open Source PQC

OpenSSL 3.5 represents the most significant cryptographic library update in a decade. It’s not just an incremental release; it’s the foundation that enables post-quantum adoption across millions of applications worldwide. From NGINX to Apache, from Python’s ssl module to PHP’s openssl extension, countless applications depend on OpenSSL for their cryptographic operations.

What’s New for Post-Quantum

The release includes native support for all three finalized NIST PQC standards. ML-KEM (FIPS 203) for key encapsulation replaces vulnerable RSA and ECDH key exchanges. ML-DSA (FIPS 204) for digital signatures provides quantum-resistant authentication. SLH-DSA (FIPS 205) offers a conservative hash-based signature alternative for scenarios demanding maximum long-term security.

The critical change lies in the defaults. OpenSSL 3.5 updated its default TLS supported groups list to include and prefer hybrid PQC KEM groups. The default TLS keyshares now offer X25519MLKEM768 and X25519 automatically. Applications compiled against OpenSSL 3.5 negotiate hybrid post-quantum key exchange without any configuration changes.

This matters because hybrid key exchange provides defense-in-depth. X25519MLKEM768 combines classical X25519 elliptic curve Diffie-Hellman with ML-KEM-768. The final shared secret derives from both mechanisms combined. If ML-KEM is somehow broken, X25519 still protects the connection. If X25519 falls to quantum computers, ML-KEM provides protection. An attacker must break both simultaneously, an extremely conservative security posture.

This library carries Long Term Support (LTS) status, meaning it will receive security patches until April 8, 2030. Organizations can confidently deploy knowing their cryptographic foundation remains supported for the next five years, ample time to plan subsequent upgrades.

Working with PQC in OpenSSL

Verifying your OpenSSL installation takes seconds:

# Verify OpenSSL version
openssl version
# Expected: OpenSSL 3.5.0 8 Apr 2025

# List available PQC KEM algorithms
openssl list -kem-algorithms

# List available PQC signature algorithms
openssl list -signature-algorithms

# Verify OpenSSL version
openssl version
# Expected: OpenSSL 3.5.0 8 Apr 2025

# List available PQC KEM algorithms
openssl list -kem-algorithms

# List available PQC signature algorithms
openssl list -signature-algorithms

Generating post-quantum keys is equally straightforward:

# Generate ML-KEM-768 keypair for key encapsulation
openssl genpkey -algorithm ML-KEM-768 -out mlkem768.key

# Generate ML-DSA-65 signing key for digital signatures
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key

# Extract public key from ML-DSA keypair
openssl pkey -in mldsa65.key -pubout -out mldsa65.pub

# Test hybrid TLS connection to a PQC-enabled server
openssl s_client -connect cloudflare.com:443 \
  -groups X25519MLKEM768:X25519

# Generate ML-KEM-768 keypair for key encapsulation
openssl genpkey -algorithm ML-KEM-768 -out mlkem768.key

# Generate ML-DSA-65 signing key for digital signatures
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key

# Extract public key from ML-DSA keypair
openssl pkey -in mldsa65.key -pubout -out mldsa65.pub

# Test hybrid TLS connection to a PQC-enabled server
openssl s_client -connect cloudflare.com:443 \
  -groups X25519MLKEM768:X25519

The EVP API provides crypto-agility without code rewrites. Applications using OpenSSL’s EVP abstraction layer can switch algorithms through configuration rather than code changes. This architectural decision proves invaluable as the post-quantum landscape continues evolving. When NIST finalizes HQC (expected 2027) or future algorithms emerge, EVP-based applications can adopt them without modification.

Go 1.24 and the Cloud-Native Ripple Effect

Go 1.24’s release in February 2025 triggered a cascade effect across the entire cloud-native ecosystem. Because Kubernetes, etcd, Istio, containerd, and countless other infrastructure projects are written in Go, a single runtime change propagated quantum resistance across the stack.

The Default That Changed Everything

Go’s crypto/tls package now includes X25519MLKEM768 in the default CurvePreferences. Examining the defaults.go source shows the preference order: X25519MLKEM768, X25519, CurveP256, CurveP384, CurveP521. Applications that don’t explicitly set CurvePreferences automatically negotiate post-quantum key exchange.

The X25519MLKEM768 constant uses CurveID 4588, assigned by IANA’s TLS registry. This standardized identifier ensures interoperability across different implementations, so a Go client can negotiate PQC with an OpenSSL-based server seamlessly.

Here’s what this means in practice:

// Go 1.24+ automatically uses X25519MLKEM768 by default
// No configuration needed for PQC key exchange

package main

import (
    "crypto/tls"
    "fmt"
    "net/http"
)

func main() {
    // Default TLS config uses X25519MLKEM768 in Go 1.24+
    client := &http.Client{
        Transport: &http.Transport{
            TLSClientConfig: &tls.Config{
                MinVersion: tls.VersionTLS13,
                // CurvePreferences defaults include X25519MLKEM768
            },
        },
    }
    
    resp, err := client.Get("https://cloudflare.com")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    
    // Verify negotiated key exchange
    fmt.Printf("Curve ID: %v\n", resp.TLS.CurveID)
    // Output: 4588 (X25519MLKEM768)
}

// Go 1.24+ automatically uses X25519MLKEM768 by default
// No configuration needed for PQC key exchange

package main

import (
    "crypto/tls"
    "fmt"
    "net/http"
)

func main() {
    // Default TLS config uses X25519MLKEM768 in Go 1.24+
    client := &http.Client{
        Transport: &http.Transport{
            TLSClientConfig: &tls.Config{
                MinVersion: tls.VersionTLS13,
                // CurvePreferences defaults include X25519MLKEM768
            },
        },
    }
    
    resp, err := client.Get("https://cloudflare.com")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    
    // Verify negotiated key exchange
    fmt.Printf("Curve ID: %v\n", resp.TLS.CurveID)
    // Output: 4588 (X25519MLKEM768)
}

For environments requiring fallback to classical cryptography, the GODEBUG=tlsmlkem=0 environment variable reverts to pre-PQC defaults. This escape hatch proves useful when dealing with legacy systems, debugging compatibility issues, or satisfying compliance requirements that haven’t yet approved PQC algorithms.

Looking ahead, Go 1.26 (expected February 2026) will add SecP256r1MLKEM768 and SecP384r1MLKEM1024 to the default preferences, providing additional hybrid options for organizations requiring NIST P-curve compatibility.

Kubernetes 1.33: PQC by Inheritance

Kubernetes 1.33, released in April 2025, uses Go 1.24. Consequently, Kubernetes control plane TLS connections automatically negotiate X25519MLKEM768 when connecting to PQC-capable endpoints. The official Kubernetes blog confirmed this inheritance model.

This means quantum resistance arrived in Kubernetes without explicit PQC code changes. The API server, kubelet, scheduler, and controller-manager all benefit from Go’s default CurvePreferences. TLS connections between these components use hybrid post-quantum key exchange automatically.

A practical example: upgrading kubectl to v1.33 (Go 1.24) while your cluster runs v1.32 (Go 1.23) means kubectl-to-API-server connections silently downgrade to classical cryptography. The TLS handshake succeeds, but PQC protection disappears. Monitor your Go versions across all components; inconsistency undermines the entire security model.

Container Signing: The Gap in the PQC Story

Key exchange protects data in transit. Digital signatures protect authenticity, often for years after signing. This distinction explains why container signing represents the most significant gap in the current PQC ecosystem.

Current State: ECDSA Only

Sigstore and Cosign, the de facto standards for container signing in Kubernetes environments, currently use ECDSA signatures. Similar to how we architect robust authentication systems with multiple layers of protection, container signing requires quantum-resistant foundations for long-term security.

The problem: A signature created today may be verified years from now. Container images signed in 2025 could remain in production registries through 2030 or beyond. If quantum computers become practical by then, an attacker could forge signatures for any previously signed artifact. Unlike key exchange (which protects ephemeral session data), signatures carry long-term implications.

Consider the supply chain security implications. An attacker with future quantum capability could retroactively forge signatures on malicious container images, making them appear legitimately signed by your CI/CD pipeline. The cryptographic authenticity guarantee breaks down when the signing algorithm becomes vulnerable.

The ML-DSA Roadmap

According to the Sigstore PQC roadmap, the project is taking a measured, responsible approach:

The public Sigstore instance will wait for reliable, vetted ML-DSA support in Go’s standard crypto package. This cautious approach makes sense: signing infrastructure requires absolute reliability. A bug in signature generation or verification could compromise the entire software supply chain.

Private Sigstore instances can experiment sooner. Once Trail of Bits completes cryptographic agility work across Fulcio, Rekor, and timestamp authorities, operators can bring their own ML-DSA implementation for end-to-end testing. Cloud KMS providers already offer ML-DSA through their APIs, enabling hybrid approaches where signing uses KMS while verification remains ECDSA until ecosystem support matures.

What’s Not Ready: Honest Limitations

Transparency about gaps prevents wasted effort and unrealistic expectations. Several critical capabilities remain unavailable or limited:

The pattern emerges clearly: key exchange is ready, signatures are not. TLS connections can negotiate hybrid PQC today. Certificate chains signed with ML-DSA? Not until the CA/Browser Forum approves usage, root programs update policies, and audits complete for certificate authorities.

The current situation creates an interesting asymmetry. Your TLS connection to a website uses quantum-resistant key exchange, but the certificate authenticating that server still uses classical ECDSA signatures. This is acceptable for now. The signature verifies the server’s identity at connection time, and breaking that signature after the fact doesn’t help an attacker who couldn’t intercept the connection.

Quick Start: Three Things You Can Do Today

Before diving into implementation, verify your infrastructure’s PQC readiness. These three commands take five minutes and tell you exactly where you stand.

Action 1: Verify Your OpenSSL Version

openssl version
# Need 3.5.0+ for native PQC support
# RHEL 9.6+, Ubuntu 24.04+ include OpenSSL 3.x (may need upgrade to 3.5)

openssl version
# Need 3.5.0+ for native PQC support
# RHEL 9.6+, Ubuntu 24.04+ include OpenSSL 3.x (may need upgrade to 3.5)

If your version shows anything below 3.5.0, you’ll need to upgrade before PQC becomes available through defaults. Plan the upgrade path: OpenSSL 3.5 is an LTS release supported through 2030, making it a stable foundation for the transition.

Action 2: Check Your Go Version

go version
# Need 1.24+ for default X25519MLKEM768
# Kubernetes 1.33+ requires Go 1.24

go version
# Need 1.24+ for default X25519MLKEM768
# Kubernetes 1.33+ requires Go 1.24

Go 1.24+ applications automatically negotiate PQC without code changes. Older versions won’t, and worse, Go 1.23’s draft Kyber implementation (X25519Kyber768Draft00) is incompatible with Go 1.24’s finalized ML-KEM (X25519MLKEM768). Mixed versions silently downgrade to classical cryptography.

Action 3: Test Hybrid TLS Connection

# Test against a PQC-enabled server
openssl s_client -connect cloudflare.com:443 \
  -groups X25519MLKEM768:X25519 2>&1 | grep -i "Server Temp Key"
# Look for "X25519MLKEM768" in output

# Test against a PQC-enabled server
openssl s_client -connect cloudflare.com:443 \
  -groups X25519MLKEM768:X25519 2>&1 | grep -i "Server Temp Key"
# Look for "X25519MLKEM768" in output

If you see X25519MLKEM768 in the Server Temp Key line, your TLS connection negotiated hybrid post-quantum key exchange. Your data in transit is protected against future quantum decryption. The harvest-now-decrypt-later threat no longer applies to that connection.

Frequently Asked Questions

Do I need to rewrite my applications to use PQC?

For key exchange, no. If using Go 1.24+ or OpenSSL 3.5+, PQC hybrid key exchange is automatic: it happens at the TLS layer without application changes. Your application’s code doesn’t know or care which key exchange algorithm the TLS library negotiated. For signatures, code changes will eventually be needed once ML-DSA libraries mature and you decide to adopt them. Focus on key exchange first; it addresses the immediate harvest-now-decrypt-later threat.

Can I use OpenSSL 3.5 PQC in containers today?

Yes. Base your containers on images with OpenSSL 3.5, such as Alpine 3.21+ or Ubuntu 24.04 with backports. Your applications will automatically negotiate hybrid PQC key exchange with no code changes. The cryptographic upgrade happens at the library level; your Dockerfile change (updating the base image) is the only modification needed.

What about FIPS compliance?

OpenSSL 3.5’s PQC algorithms are not yet FIPS 140-3 validated. For FIPS-required environments, monitor NIST’s Cryptographic Module Validation Program for ML-KEM and ML-DSA certifications expected in 2025-2026. Until validation completes, hybrid deployments provide quantum resistance while maintaining FIPS compliance for the classical X25519 component. The hybrid approach ensures you meet current FIPS requirements while gaining forward secrecy against quantum threats.

Bottom Line: The Building Blocks Are Here

The post-quantum cryptography open source ecosystem has crossed the production-readiness threshold for key exchange. OpenSSL 3.5 provides ML-KEM and ML-DSA directly in the library with sensible defaults. Go 1.24 makes PQC automatic for the entire cloud-native stack. Kubernetes 1.33 inherits quantum-resistant key exchange without configuration changes.

Container signing remains the gap: plan for late 2026 when Sigstore adopts ML-DSA after Go’s crypto package support stabilizes.

Your action plan is straightforward: verify your current versions with three commands, upgrade OpenSSL and Go where needed, and let the defaults handle the cryptographic transition. The building blocks exist. The defaults are secure. The migration path is clear.

What’s Next: Compliance and Mandates

Understanding the technology is essential. But PQC migration doesn’t happen in a vacuum: regulatory requirements are driving timelines.

In Part 4, we examine the compliance landscape: NSA CNSA 2.0 requirements for US government contractors with hard deadlines starting in 2027, the EU Cyber Resilience Act (CRA) with its December 2027 deadline, and NIS-2 directive implications. We’ll cover cryptographic inventory discovery, how to find every RSA and ECDSA key in your infrastructure, and how to document your PQC readiness for auditors.

The tools exist. The standards are clear. Now let’s understand when you’re required to act.

Download Resources

Free Algorithm Selection Flowchart: Get our visual decision tree that maps your requirements to the right post-quantum algorithm in 60 seconds.

PQC Migration Checklist: A comprehensive checklist covering discovery, planning, pilot, and production rollout phases.