As quantum computing advances toward practical capability, the cryptographic foundations securing our digital infrastructure face an unprecedented threat. Post-quantum cryptography (PQC) has emerged as the leading solution to this challenge, with several open-source libraries now offering implementations of quantum-resistant algorithms. For organizations planning their quantum security transition, choosing the right library can significantly impact security posture, performance, and integration complexity.
This comprehensive analysis examines three leading open-source PQC libraries—liboqs, OpenSSL 3.4, and BoringSSL—evaluating their strengths, limitations, and suitability for different deployment scenarios. Whether you’re a security architect planning a quantum-safe migration strategy or a developer implementing quantum-resistant protocols, understanding the nuances between these libraries is essential for making informed decisions in the rapidly evolving post-quantum landscape.
Post-quantum cryptography libraries provide implementations of cryptographic algorithms designed to withstand attacks from quantum computers. Unlike traditional cryptographic libraries that primarily implement RSA, ECC, and other quantum-vulnerable algorithms, PQC libraries focus on quantum-resistant alternatives based on lattices, hash functions, codes, and other mathematical problems believed to resist quantum attacks.
These libraries serve multiple critical functions in the quantum security ecosystem. They provide reference implementations for standardization efforts, enable interoperability testing, facilitate performance benchmarking, and ultimately allow organizations to deploy quantum-resistant security measures before large-scale quantum computers become available. The development of these libraries has accelerated significantly following NIST’s post-quantum cryptography standardization process, which has now selected specific algorithms for standardization.
The Open Quantum Safe project’s liboqs stands as the most comprehensive open-source implementation of post-quantum algorithms. Developed primarily by researchers at the University of Waterloo, liboqs has established itself as the reference implementation for most post-quantum candidates.
liboqs implements a broad spectrum of algorithms, including all NIST selections (ML-KEM/Kyber, ML-DSA/Dilithium, Falcon, and SPHINCS+) and numerous additional candidates like BIKE, Classic McEliece, HQC, and NTRU-Prime. It also includes implementations of stateful hash-based signature schemes like LMS and XMSS. This breadth makes liboqs particularly valuable for research, experimentation, and comparison of different PQC approaches.
The library is designed with a C API that emphasizes algorithm abstraction, allowing applications to use PQC algorithms through a consistent interface regardless of the underlying implementation. This design supports both the standardized NIST selections and provides a testbed for emerging algorithms still under consideration.
One of liboqs’ key strengths is its extensive testing infrastructure, which includes comprehensive unit tests, continuous integration, and interoperability testing with other implementations. This focus on correctness makes liboqs a reliable foundation for organizations conducting PQC research or planning early deployments.
OpenSSL’s approach to post-quantum cryptography marks a significant milestone in bringing quantum-resistant algorithms to mainstream deployments. With the release of OpenSSL 3.4, the world’s most widely used cryptographic library has begun incorporating NIST-selected PQC algorithms into its core functionality.
Unlike liboqs, which aims for comprehensive algorithm coverage, OpenSSL has taken a more focused approach by initially implementing only the algorithms selected by NIST for standardization. This includes ML-KEM (formerly Kyber) for key encapsulation and ML-DSA (formerly Dilithium) for digital signatures. This selective implementation reflects OpenSSL’s production-oriented focus and prioritization of standardized algorithms.
OpenSSL 3.4’s implementation is notable for its integration with the library’s existing architecture. The PQC algorithms are implemented as providers within OpenSSL’s modular architecture, allowing applications to use quantum-resistant cryptography through the same familiar APIs they use for traditional cryptography. This integration extends to TLS protocols, enabling hybrid classical-quantum key exchange mechanisms critical for the transition period.
A significant advantage of OpenSSL’s approach is its focus on performance optimization and security hardening. The implementations include protections against side-channel attacks and have undergone extensive performance tuning to minimize the computational overhead of post-quantum algorithms, which typically require more resources than their classical counterparts.
BoringSSL, Google’s fork of OpenSSL, has taken a distinct approach to post-quantum cryptography that reflects its origins as an internal security library for Google’s infrastructure. Rather than attempting to implement a broad range of algorithms, BoringSSL has prioritized practical deployment considerations and real-world testing of post-quantum protocols.
The library has been at the forefront of experimental PQC deployments in production environments. Google has used BoringSSL to test post-quantum key exchange in Chrome and its services, providing valuable real-world data on the performance and compatibility challenges of PQC deployments. This production-testing approach has informed both the library’s implementation choices and contributed to the broader understanding of PQC deployment challenges.
BoringSSL’s PQC implementation focuses primarily on NIST selections, with particular emphasis on Kyber/ML-KEM for key encapsulation. However, it maintains some significant differences from OpenSSL’s approach, particularly in its implementation of hybrid classical-quantum protocols. BoringSSL pioneered several approaches to hybrid key exchange that balance security, performance, and compatibility.
The library also features a more streamlined API compared to OpenSSL, reflecting Google’s focus on internal use cases rather than general-purpose deployment. This can make BoringSSL more challenging to adopt for organizations without significant cryptographic expertise but potentially more efficient for specific deployment scenarios.
The three libraries differ significantly in their algorithm coverage:
liboqs offers the most comprehensive selection, implementing all NIST PQC selections plus additional candidates and alternative approaches. This includes multiple parameter sets for each algorithm, enabling security-performance tradeoffs. The library supports both key encapsulation mechanisms (KEMs) like ML-KEM, BIKE, and Classic McEliece, and signature schemes like ML-DSA, Falcon, and SPHINCS+.
OpenSSL 3.4 focuses exclusively on NIST-selected algorithms, primarily ML-KEM and ML-DSA. This narrower focus reflects OpenSSL’s production orientation and prioritization of standardized approaches. The implementation includes multiple security levels for each algorithm but omits many of the experimental algorithms available in liboqs.
BoringSSL has the most selective algorithm implementation, concentrating primarily on ML-KEM with some support for ML-DSA. However, BoringSSL’s implementation includes specialized optimizations for specific platforms and deployment scenarios not found in the other libraries. It also features unique hybrid classical-quantum constructions designed based on Google’s large-scale testing.
Performance characteristics vary significantly across the three libraries, reflecting their different priorities and implementation approaches:
liboqs provides solid baseline performance across a wide range of algorithms but generally doesn’t include the most aggressive optimizations. Its implementation prioritizes correctness, portability, and algorithm diversity over maximizing performance on specific platforms. For most algorithms, liboqs serves as a reference implementation rather than a highly optimized one.
OpenSSL 3.4 delivers superior performance for the NIST-selected algorithms it implements. Its ML-KEM implementation shows approximately 15-20% better performance than liboqs in key generation and encapsulation operations, reflecting OpenSSL’s focus on optimizing standardized algorithms for production use. The library includes platform-specific optimizations for x86-64 (using AVX2 instructions) and ARM64 architectures.
BoringSSL demonstrates the best performance in specific deployment scenarios, particularly for ML-KEM operations in TLS handshakes. Google’s extensive profiling and optimization of critical paths has resulted in implementations that outperform both other libraries in typical web serving scenarios by 5-10%. However, this performance advantage is more pronounced in Google’s target use cases and may not translate to all deployment scenarios.
The integration pathways for each library reflect their different design philosophies and target users:
liboqs provides a clean, algorithm-agnostic API that makes it straightforward to experiment with different PQC approaches. It offers wrappers for multiple languages and integration with OpenSSL through a provider module. This flexibility makes liboqs particularly valuable for research and experimentation. The library also maintains extensive documentation that facilitates integration into existing systems.
OpenSSL 3.4 offers the most straightforward integration path for most organizations due to its widespread deployment and familiar API. PQC algorithms are accessible through the same interfaces as traditional cryptography, allowing gradual migration with minimal code changes. The library’s support for hybrid certificates and TLS extensions provides a comprehensive solution for organizations planning quantum-safe migrations.
BoringSSL presents the most challenging integration path for organizations not already using Google’s infrastructure. Its API differs significantly from standard OpenSSL, and documentation focuses on internal Google use cases. However, for organizations willing to invest in the integration effort, BoringSSL’s streamlined implementation can offer performance advantages and early access to features being tested in Google’s ecosystem.
Security implementation details vary across the libraries in ways that may impact their suitability for different threat models:
liboqs emphasizes clean, reference implementations that closely follow algorithm specifications. While this approach maximizes fidelity to the original algorithms, it may be more vulnerable to side-channel attacks compared to the hardened implementations in the other libraries. The library includes basic constant-time implementation practices but lacks some of the advanced protections found in production-focused libraries.
OpenSSL 3.4 provides the most comprehensive security hardening, reflecting its focus on production deployments. Its implementations include protections against timing attacks, cache attacks, and other side-channel vulnerabilities. The library’s formal security review process and widespread scrutiny by security researchers provide additional confidence in its implementation security.
BoringSSL incorporates Google’s defensive security engineering practices, including fuzz testing, formal verification of critical components, and deployment-based testing. Its implementations include platform-specific mitigations for side-channel attacks, particularly for mobile and cloud environments where Google has significant deployment experience.
Organizations implementing post-quantum cryptography face several common challenges regardless of which library they choose. The increased key sizes and computational requirements of PQC algorithms can impact network performance, storage requirements, and processing overhead. Each library offers different approaches to mitigating these challenges.
For bandwidth constraints, OpenSSL 3.4 and BoringSSL both implement compression techniques for public keys and signatures that can reduce the network overhead of PQC algorithms by 15-30% in typical deployments. liboqs generally adheres more strictly to reference implementations without such optimizations.
Memory constraints present another significant challenge, particularly for embedded systems. BoringSSL offers the most memory-efficient implementation for constrained environments, with specialized variants of ML-KEM that reduce memory usage by approximately 40% compared to reference implementations. OpenSSL offers moderate memory optimizations, while liboqs prioritizes algorithm correctness over memory efficiency.
Hybrid classical-quantum approaches represent a critical transition strategy, allowing systems to maintain compatibility with traditional cryptography while adding quantum resistance. OpenSSL 3.4 provides the most comprehensive support for standardized hybrid approaches, including X.509 certificate extensions and TLS protocol extensions. BoringSSL includes several experimental hybrid constructions based on Google’s deployment experience, while liboqs offers flexible primitives for building custom hybrid schemes.
The post-quantum cryptography landscape continues to evolve rapidly, with each library following a different development trajectory that will influence its future utility.
liboqs is positioned to remain the most comprehensive implementation of post-quantum algorithms, with planned support for emerging candidates from NIST’s additional standardization efforts and other research directions. The library’s academic roots suggest it will continue to prioritize algorithm diversity and correctness over production optimization.
OpenSSL’s roadmap indicates increasing integration of post-quantum cryptography into core functionality, with planned support for quantum-resistant certificates, additional TLS extensions, and optimized implementations across more platforms. The library’s standardization focus suggests it will continue to implement algorithms only after they achieve significant formal recognition.
BoringSSL will likely continue to pioneer practical deployments of post-quantum cryptography in Google’s ecosystem, providing early real-world testing of approaches that may eventually be adopted more broadly. Its development will probably remain focused on Google’s specific needs rather than general-purpose deployment.
All three libraries face the ongoing challenge of adapting to evolving standards and research findings. The continuing NIST standardization process, particularly for additional signature schemes and potential revisions to existing selections, will drive development priorities across the ecosystem.
Organizations planning long-term quantum security strategies should consider maintaining awareness of developments across all three libraries, as each offers unique insights into different aspects of the post-quantum transition. Participants at the World Quantum Summit 2025 will have opportunities to discuss these implementation challenges directly with experts in quantum-resistant cryptography deployments.
The comparison of liboqs, OpenSSL 3.4, and BoringSSL reveals distinct approaches to implementing post-quantum cryptography, each with different strengths aligned to specific use cases. Organizations planning their quantum security transition should consider these differences when selecting a library for their implementation.
liboqs offers the most comprehensive algorithm coverage and flexibility, making it ideal for research, experimentation, and scenarios requiring non-standard algorithms. Its academic focus provides high confidence in implementation correctness but may require additional hardening for production deployments.
OpenSSL 3.4 delivers the most straightforward path for organizations seeking to implement standardized post-quantum algorithms in production environments. Its integration with existing cryptographic workflows, comprehensive security hardening, and widespread support make it the default choice for most enterprise deployments.
BoringSSL provides insights into Google’s approach to post-quantum deployment, with unique optimizations for specific platforms and use cases. While its specialized nature makes it less suitable as a general-purpose solution, organizations with similar requirements to Google may benefit from its performance optimizations and real-world testing.
As quantum computing continues to advance, the importance of quantum-resistant cryptography will only increase. Organizations should begin planning their transition strategies now, considering not just the current state of these libraries but their development trajectories and alignment with emerging standards. The choice between liboqs, OpenSSL 3.4, and BoringSSL should be guided by specific security requirements, performance constraints, deployment environments, and organizational capabilities.
Ready to explore quantum-resistant security strategies for your organization? Join industry leaders and PQC experts at the World Quantum Summit 2025 in Singapore, September 23-25, 2025. Get hands-on with implementation workshops, connect with library maintainers, and develop your quantum security roadmap. Sponsorship opportunities are available for organizations leading the quantum security transition.
World Quantum Summit 2025
Sheraton Towers Singapore
39 Scotts Road, Singapore 228230
23rd - 25th September 2025
