Best Post-Quantum Cryptography Libraries in 2026

Published · Updated

By Post Quantum Field · We verify claims against NIST publications, vendor changelogs, and IETF drafts. Experimental support is never presented as production-ready.

Choosing a cryptographic library for post-quantum cryptography (PQC) in 2026 depends on your platform, your compliance requirements, and whether you need production-grade implementations or are still in the evaluation phase. The landscape has matured significantly since NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024.

This comparison covers five widely used libraries: liboqs, BoringSSL, wolfSSL, OpenSSL 3.5, and Bouncy Castle (Java/C#). For each, we document which algorithms are supported, the production readiness, the license, and the intended use case.

Implementation-specific readers can continue with the Java Bouncy Castle PQC guide or the Python PQC library comparison after choosing a platform.

Quick comparison table

LibraryML-KEMML-DSASLH-DSAHybrid TLSProduction-readyFIPS validated (PQC)License
OpenSSL 3.5Yes (512/768/1024)Yes (44/65/87)YesYes (X25519MLKEM768)YesIn processApache 2.0
BoringSSLYes (768)Yes (44/65/87)NoYes (X25519MLKEM768)Yes (Google internal)Via AWS-LC forkISC-style
AWS-LCYes (512/768/1024)Yes (44/65/87)NoYes (multiple hybrids)YesML-KEM validated (cert. #5314); not ML-DSAApache 2.0 + ISC
wolfSSLYes (512/768/1024)Yes (44/65/87)YesYesYesIn processGPLv2 + commercial
liboqsYes (512/768/1024)Yes (44/65/87)YesVia oqs-providerNo (research/testing)NoMIT
Bouncy CastleYes (512/768/1024)Yes (44/65/87)YesNot directlyPartial (non-FIPS)FIPS module separateMIT (Java), MIT (C#)

OpenSSL 3.5

Released: April 8, 2025

OpenSSL 3.5 is the first mainline OpenSSL release with native PQC support, requiring no external providers or plugins. Previously, PQC in OpenSSL required the OQS-provider from Open Quantum Safe.

Algorithms supported

  • ML-KEM: ML-KEM-512, ML-KEM-768, ML-KEM-1024 (FIPS 203)
  • ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87 (FIPS 204)
  • SLH-DSA: All parameter sets (FIPS 205)
  • Hybrid TLS groups: X25519MLKEM768 (default in 3.5.0+); SecP256r1MLKEM768 and curveSM2MLKEM768 added in 3.6.0+

Production readiness

OpenSSL 3.5 is a Long-Term Support (LTS) release with upstream support scheduled through April 8, 2030. Upstream OpenSSL 3.0 public support ended on September 7, 2026, after its final security-fixes-only year. That lifecycle boundary does not mean every operating-system package or commercial build became unsupported on the same date: distributions and paid providers can maintain separate support windows. Check the lifecycle of the binary you actually deploy.

The PQC implementations are part of the default and FIPS providers. OpenSSL has submitted version 3.5.4 for FIPS 140-3 validation including PQC algorithms (as of October 2025). Validation is in process but not yet issued.

For most server deployments (NGINX, Apache, HAProxy), upgrading to OpenSSL 3.5 is the simplest path to hybrid PQ TLS.

Limitations

  • FIPS validation is pending (not yet certified)
  • Pre-hash ML-DSA signature generation is not supported natively (users must pre-hash externally)
  • Older applications linked against OpenSSL 3.0/3.1 need recompilation or provider configuration

License

Apache License 2.0 (since OpenSSL 3.0)

Best for

General-purpose servers, Linux infrastructure, and applications already using OpenSSL. Treat the move from 3.0 to 3.5 as an application and platform migration: inventory linked runtimes and providers, test configuration and interoperability, and follow your operating-system vendor’s packaging guidance.

BoringSSL

Maintained by: Google

BoringSSL is Google’s fork of OpenSSL, used internally across all Google services and products including Chrome, Android, and Google Cloud. It is not versioned with traditional releases; users consume it at specific Git commits.

Algorithms supported

  • ML-KEM: ML-KEM-768 (via X25519MLKEM768 hybrid in TLS)
  • ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87
  • Hybrid TLS: X25519MLKEM768 (enabled by default in Chrome 131+)

Production readiness

BoringSSL with ML-KEM is production-deployed at massive scale. Chrome negotiates X25519MLKEM768 by default since version 131 (November 2024). All Google Cloud internal network traffic uses ML-KEM for key exchange. This is arguably the most battle-tested PQC TLS deployment in the world.

However, BoringSSL’s API stability guarantees are explicitly absent. Google states: “BoringSSL is not intended for general use.” The API can change without notice. Third parties typically use BoringSSL through higher-level wrappers (like Go’s crypto/tls) or through the AWS-LC fork.

Limitations

  • No formal versioning or release schedule
  • No API stability guarantees
  • No standalone FIPS validation (though AWS-LC, a fork, has FIPS validation)
  • Limited algorithm selection compared to OpenSSL (only ML-KEM-768 for TLS)
  • SLH-DSA not implemented

License

ISC-style (permissive, similar to MIT/BSD)

Best for

Projects that already depend on BoringSSL (Go applications, Chromium-derived browsers). Not recommended for direct third-party integration unless you are prepared to track HEAD and handle API breakage.

AWS-LC

Maintained by: Amazon Web Services

AWS-LC is Amazon’s general-purpose cryptographic library, forked from BoringSSL but maintained independently with a focus on FIPS compliance and stability. It powers all AWS services including KMS, S3, and CloudFront.

Algorithms supported

  • ML-KEM: ML-KEM-512, ML-KEM-768, ML-KEM-1024
  • ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87
  • Hybrid TLS groups: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024
  • XMSS/LMS: Hash-based signatures

Production readiness

AWS-LC 3 Cryptographic Module (static) received Active FIPS 140-3 certificate #5314 on June 5, 2026. The approved algorithm list includes ML-KEM key generation and encapsulation/decapsulation, but does not list ML-DSA. AWS’s December 2024 post announced that AWS-LC FIPS 3.0 had entered the validation process; it was not an issued validation certificate. Verify the exact static or dynamic module rather than applying #5314 to AWS-LC 4 or every AWS-LC build.

Limitations

  • API derived from BoringSSL (similar caveats about compatibility with OpenSSL APIs)
  • Not a drop-in replacement for OpenSSL in all contexts
  • Tightly coupled to AWS ecosystem

License

Apache 2.0 + ISC (dual-licensed)

Best for

AWS deployments, applications using s2n-tls or the AWS SDK, and Rust projects via aws-lc-rs. If you need FIPS-validated ML-KEM, AWS-LC 3 is a current option; that certificate does not validate ML-DSA.

wolfSSL

Maintained by: wolfSSL Inc.

wolfSSL is a lightweight, portable TLS library targeting embedded, IoT, and RTOS environments. It also serves enterprise and government deployments requiring FIPS compliance and broad algorithm support.

Algorithms supported

  • ML-KEM: ML-KEM-512, ML-KEM-768, ML-KEM-1024 (native in wolfCrypt)
  • ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87 (native in wolfCrypt)
  • SLH-DSA: All parameter sets (FIPS 205)
  • LMS/XMSS: Hash-based stateful signatures
  • Hybrid TLS: Supported via --enable-pqc build flag

wolfSSL 5.8.0 (released 2025) includes the full CNSA 2.0 post-quantum algorithm suite natively in wolfCrypt, without depending on liboqs.

Production readiness

wolfSSL positions its PQC implementations as production-ready for embedded and enterprise use. The base wolfCrypt module has Active FIPS 140-3 certificate #4718, but that certificate’s approved algorithm list does not include ML-KEM, ML-DSA or SLH-DSA. A separate wolfCrypt FIPS 140-3 submission remains in the CMVP Modules in Process list. That pending entry is not an issued PQC validation.

wolfSSL benchmarks show competitive performance against OpenSSL 3.5 for ML-KEM operations, with particular advantages on ARM and RISC-V targets.

Jetson Orin Nano evidence

wolfSSL published vendor-run measurements on September 4, 2026 for wolfSSL 5.9.2 on one Jetson Orin Nano Developer Kit. The tested configuration used six Cortex-A78AE cores at 1728 MHz in MAXN_SUPER with jetson_clocks, L4T Ubuntu 22.04.5, and kernel 5.15.148-tegra. The figures below are single-threaded, per-core operations per second—not aggregate Jetson throughput and not results for every Jetson module or TLS stack.

Parameter setKey generationEncapsulate / signDecapsulate / verify
ML-KEM-51267,88958,92843,016
ML-KEM-76842,13637,28728,125
ML-KEM-102424,53722,77918,159
ML-DSA-4411,9043,62811,317
ML-DSA-656,3332,3307,020
ML-DSA-874,2421,8444,184

The same report documents a separate key-protection path: Jetson Orin exposes an OP-TEE fTPM at /dev/tpmrm0, backed by the Tegra Security Engine. wolfTPM can use the standard Linux TPM interface with --enable-devtpm for TPM-resident authentication keys. That fTPM path protects keys; it is not the accelerator behind the software ML-KEM and ML-DSA figures above, and it does not show that arbitrary robotics workloads gain the same performance.

Limitations

  • Dual-licensed: GPLv2 for open source, commercial license required for proprietary use
  • Smaller ecosystem and community compared to OpenSSL
  • Some PQC features require specific build flags (--enable-pqc)
  • PQC-specific FIPS validation remains in process; certificate #4718 does not cover PQC

License

GPLv2 (open source) or commercial license. The commercial license is required for most proprietary embedded and enterprise deployments.

Best for

Embedded systems, IoT devices, RTOS environments, government/DoD projects requiring CNSA 2.0 compliance, and any deployment needing lightweight PQC with commercial support.

liboqs (Open Quantum Safe)

Maintained by: Open Quantum Safe project (academic, led by Douglas Stebila and Michele Mosca)

liboqs is a C library providing implementations of post-quantum algorithms for prototyping, testing, and research. It is the most comprehensive PQC library in terms of algorithm coverage.

Algorithms supported

NIST standards:

  • ML-KEM: ML-KEM-512, ML-KEM-768, ML-KEM-1024 (FIPS 203)
  • ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87 (FIPS 204)
  • SLH-DSA: All parameter sets (FIPS 205)

Additional/experimental:

  • BIKE, Classic McEliece, FrodoKEM, HQC (KEM candidates)
  • Falcon (FN-DSA): Expected standardization 2026
  • SPHINCS+: Predecessor to SLH-DSA

liboqs builds on Linux, macOS, and Windows, supports x86_64 and ARM architectures, and works with clang, gcc, and MSVC.

Production readiness

liboqs is explicitly NOT recommended for production use. The project’s own documentation states it is intended for prototyping and experimentation. From the Cloudflare PQC support documentation: “Reference implementations, not recommended for production.”

Reasons liboqs is not production-grade:

  • Implementations may not be constant-time on all platforms
  • No FIPS validation (and no plans for it)
  • API stability is not guaranteed
  • Security audits are limited
  • Side-channel protections are not comprehensive

Integration

liboqs integrates with OpenSSL via the oqs-provider (replaces the older OQS-OpenSSL fork). This allows testing PQC algorithms through OpenSSL’s API without waiting for native OpenSSL support. With OpenSSL 3.5 shipping native PQC, the primary use case for oqs-provider shifts to accessing experimental algorithms not yet in OpenSSL.

License

MIT License

Best for

Research, testing, prototyping, interoperability testing, experimenting with algorithms not yet standardized (HQC, Classic McEliece, Falcon). Not for production deployments.

Bouncy Castle

Maintained by: Legion of the Bouncy Castle (David Hook / Keyfactor)

Bouncy Castle is the dominant PQC library for Java and C# .NET ecosystems. It provides pure-Java and pure-C# implementations independent of platform native crypto.

Algorithms supported (BC Java 1.80+, BC C# .NET 2.6.0+)

  • ML-KEM: ML-KEM-512, ML-KEM-768, ML-KEM-1024 (FIPS 203)
  • ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87 (FIPS 204)
  • SLH-DSA: All parameter sets (FIPS 205)
  • Falcon (FN-DSA): Available (expected NIST standardization 2026)
  • HQC: Available
  • LMS/XMSS: Hash-based stateful signatures
  • Hybrid KEM/signatures: Combiners for mixing PQ and classical algorithms

Production readiness

Bouncy Castle’s non-FIPS editions (BC Java, BC C# .NET) include PQC algorithms and are widely used in enterprise Java applications. The algorithms are considered mature and well-tested.

The FIPS editions are separate products. BC-FJA for Java has Active FIPS 140-3 validations, including Interim certificate #4943 for version 2.1.1. Its approved algorithm list does not include ML-KEM, ML-DSA or SLH-DSA. The older BC-FNA FIPS 140-2 certificate #4416 is now Historical, while a BC-FNA FIPS 140-3 module remains in process. PQC availability in a Bouncy Castle package therefore does not establish validated PQC operation.

Limitations

  • No direct TLS integration (Bouncy Castle provides crypto primitives, not a TLS stack)
  • Applications must handle protocol integration themselves or use JSSE providers
  • FIPS-certified PQC is not yet available
  • Pure-software implementations may be slower than native C libraries for high-throughput use cases

Java ecosystem context

Java 24+ (via JEP 497) provides ML-DSA APIs in the standard library. Java 27 (via JEP 527) adds ML-KEM with default TLS integration. For Java versions below 24, Bouncy Castle is the primary path to PQC. Even with newer Java versions, Bouncy Castle provides algorithms (Falcon, HQC, SLH-DSA) not available in the JDK.

License

MIT License (for both Java and C# editions)

Best for

Java and C# enterprise applications, Android apps, certificate generation/validation, applications needing broad algorithm coverage (including pre-standardization algorithms), and environments where native libraries are not available or practical.

Decision matrix

RequirementRecommended library
FIPS-validated ML-KEMAWS-LC 3 (certificate #5314)
General Linux server TLSOpenSSL 3.5
Embedded / IoTwolfSSL
Java enterprise applicationBouncy Castle
C# / .NET application.NET 10 (SymCrypt) or Bouncy Castle C#
Research / testing all algorithmsliboqs
Google Cloud / Chrome ecosystemBoringSSL (via Go or Chromium)
AWS ecosystem (Rust)aws-lc-rs
Maximum algorithm coverageliboqs (testing) or Bouncy Castle (production)
CNSA 2.0 compliancewolfSSL or AWS-LC

Performance considerations

Post-quantum algorithms have different performance characteristics than classical algorithms. Key sizes and computation times vary significantly:

  • ML-KEM-768 encapsulation: Approximately 2x faster than RSA-2048 key generation but produces larger keys (1,184-byte public key, 1,088-byte ciphertext)
  • ML-DSA-65 signing: Faster than RSA-2048 signing, but signatures are 3,309 bytes (vs. 256 bytes for RSA-2048)
  • SLH-DSA: Very slow signing (orders of magnitude slower than ML-DSA) but has minimal security assumptions

wolfSSL published benchmark comparisons with OpenSSL 3.5 showing competitive ML-KEM performance, with wolfSSL showing advantages on ARM Cortex-A and RISC-V platforms due to architecture-specific optimizations.

For TLS handshakes, the hybrid overhead is primarily in bandwidth (larger key shares in ClientHello/ServerHello) rather than CPU. Chrome’s deployment data shows that the X25519MLKEM768 hybrid adds approximately 1 KB to the TLS handshake with negligible latency impact on broadband connections.

Migration strategy

  1. Evaluation phase: Use liboqs or Bouncy Castle to test algorithm behavior, key sizes, and performance in your specific application context.

  2. Hybrid deployment: Deploy hybrid TLS (classical + PQ) using OpenSSL 3.5 or your platform’s native library. This provides protection without risking regression if a PQ algorithm is found to have issues.

  3. Production PQC: Move to a production library (OpenSSL 3.5, AWS-LC, wolfSSL, or Bouncy Castle) with the NIST-standardized algorithms only (ML-KEM, ML-DSA, SLH-DSA).

  4. FIPS compliance: If required, use AWS-LC (validated) or wait for OpenSSL 3.5/wolfSSL validation to complete.

References

  • NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
  • NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024)
  • NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (August 2024)
  • OpenSSL 3.5 Release Notes (April 2025): openssl-library.org
  • Open Quantum Safe liboqs ALGORITHMS.md: github.com/open-quantum-safe/liboqs
  • wolfSSL: “Post-Quantum Benchmark Comparison: ML-KEM wolfSSL 5.8.0 vs. OpenSSL 3.5” (May 2025)
  • NIST CMVP: AWS-LC 3 Cryptographic Module (static), certificate #5314 (June 2026)
  • Keyfactor: “Post-Quantum Algorithm Update in Bouncy Castle” (September 2023)
  • Cloudflare: “PQC Support” documentation (updated June 2026)
  • arxiv.org: “A Survey of Post-Quantum Cryptography Support in Cryptographic Libraries” (2025)

FAQ

Which library should I use for a new project in 2026?

For most server-side applications on Linux, OpenSSL 3.5 is the default choice. For Java applications, Bouncy Castle. For AWS workloads, AWS-LC (via s2n-tls or aws-lc-rs). For embedded/IoT, wolfSSL. For research and testing non-standard algorithms, liboqs.

Is liboqs safe for production?

No. liboqs explicitly warns that it is not intended for production use. It is designed for prototyping and testing. Implementations may not be constant-time, have not undergone comprehensive security audits, and have no FIPS validation.

Which library has FIPS 140-3 validation for PQC?

AWS-LC 3 certificate #5314 includes ML-KEM in its approved algorithm list and was issued in June 2026. It does not list ML-DSA. OpenSSL 3.5 and wolfSSL have PQC-specific validation efforts in process. The FIPS 140-2 to FIPS 140-3 transition guide explains why algorithm support, module validation and approved scope must be checked separately.

Can I use Bouncy Castle for TLS with PQC?

Not directly. Bouncy Castle provides cryptographic primitives but not a TLS stack. You would need to use it through a JSSE provider or integrate it with a TLS library. For Java TLS with PQC, Java 27+ (JEP 527) provides native ML-KEM TLS support through the JDK’s built-in SSL/TLS implementation.

What about libsodium, Crypto++, and MbedTLS?

As of early 2026, libsodium has no PQC support. Crypto++ has experimental Kyber/Dilithium code but it is not standardized to FIPS 203/204. MbedTLS has limited PQC support (via experimental modules) and does not include the full CNSA 2.0 suite. None are recommended for PQC in production today.

Do I need to switch from OpenSSL 3.0 to 3.5 for PQC?

For new upstream-based PQC deployments, use OpenSSL 3.5 LTS or a later compatible release rather than 3.0. OpenSSL 3.0 does not include native PQC support, and upstream public support ended on September 7, 2026. The OQS provider can still be useful with older OpenSSL 3.x builds for research and interoperability testing, but it does not restore upstream support for the underlying library. A Linux distribution or commercial provider may support its packaged 3.0 build on a different schedule, so verify that contract before planning the upgrade.

Use the OpenSSL 3.0-to-3.5 migration worksheet to turn that version decision into an application, provider, protocol, test, and rollback plan.

Which algorithms should I actually implement?

Focus on NIST standards only: ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for signatures. Use SLH-DSA (FIPS 205) only where stateless hash-based signatures are specifically required (it is much slower than ML-DSA). Avoid non-standardized algorithms in production.

Sources

Related articles

PQC Library Comparison Matrix

Structured comparison of six major cryptographic libraries for post-quantum support. ML-KEM, ML-DSA, SLH-DSA, FIPS status, and licensing.

Python PQC Libraries Compared

Comparing Python post-quantum cryptography libraries for production readiness, algorithm support, and ease of use in 2026.

AWS vs Azure vs Google Cloud Post-Quantum Support

Compare cloud PQC support by workflow: ML-DSA, ML-KEM, KMS, HSM, key import, TLS, PKI, status, and migration use cases.

Android Post-Quantum Support in 2026

What Android versions support ML-KEM and ML-DSA today. TLS stack, Keystore, Conscrypt updates, and what app developers need to know.