person Tute World Team

Open Source PQC Libraries

The algorithms are standardized. Now comes the implementation. Here's a practical guide to the open source post-quantum cryptography libraries available today — what's production-ready, what's experimental, and how to get started without writing a single cryptographic primitive from scratch.

The Golden Rule: Never Implement Cryptography Yourself

Before diving into libraries, the most important rule in applied cryptography:

Never implement cryptographic algorithms from scratch. Not even if you fully understand the math. Cryptographic implementations fail through timing side-channels, cache-timing attacks, subtle algebraic mistakes, and implementation-specific edge cases that have nothing to do with the algorithm's mathematical security. Always use well-audited, widely deployed libraries.

This rule is even more critical for post-quantum algorithms — which are newer, more complex, and have subtle implementation pitfalls (like Gaussian sampling in lattice schemes) that are easy to get wrong.

liboqs: The Open Quantum Safe Project

liboqs (Open Quantum Safe) is the most comprehensive open source PQC library — a C library maintained by the Open Quantum Safe project (University of Waterloo). It implements all NIST-selected algorithms and many additional candidates.

liboqs

Production Candidate
Language: C (with bindings for Python, Go, Rust, Java) License: MIT

Implements: ML-KEM (all variants), ML-DSA (all variants), SLH-DSA, FN-DSA (Falcon), Classic McEliece, and more.

# Python bindings (oqs-python)
pip install liboqs-python

import oqs

# Key exchange with ML-KEM-768
kem = oqs.KeyEncapsulation("ML-KEM-768")
public_key = kem.generate_keypair()
ciphertext, shared_secret_server = kem.encap_secret(public_key)

# Client side
kem_client = oqs.KeyEncapsulation("ML-KEM-768")
shared_secret_client = kem_client.decap_secret(ciphertext)
# shared_secret_server == shared_secret_client

OQS also provides:

  • OQS-OpenSSL: A fork of OpenSSL with liboqs integration — enables PQC in any existing OpenSSL-based application
  • OQS-BoringSSL: BoringSSL with PQC support — useful for mobile and Chrome-based applications
  • OQS-curl: curl with PQC TLS support for testing PQ-enabled HTTPS connections

OpenSSL 3.x with OQS Provider

OpenSSL is the most widely deployed TLS library in the world. OpenSSL 3.x introduced a provider architecture that allows third-party algorithm implementations to be plugged in without modifying OpenSSL's core.

OpenSSL 3.x + oqs-provider

Production-ready for TLS
Language: C License: Apache 2.0 
# Install oqs-provider (builds on liboqs + OpenSSL 3.x)
# Then configure OpenSSL to use it:

# openssl.cnf addition:
[provider_sect]
default = default_sect
oqs = oqs_sect

[oqs_sect]
activate = 1

# Test with TLS 1.3 + ML-KEM:
openssl s_client \
  -connect example.com:443 \
  -groups mlkem768:X25519 \
  -tls1_3

The oqs-provider enables ML-KEM key groups in TLS handshakes, ML-DSA certificate signing, and all NIST-finalized PQC algorithms through the standard OpenSSL API.

BoringSSL (Google's Fork)

BoringSSL is Google's fork of OpenSSL, used in Chrome, Android, and Google's servers. It has built-in support for X25519Kyber768 (the hybrid deployed in Chrome) and is where Google does its PQC production work.

BoringSSL

In Production (Chrome, Android)
Language: C/C++ License: OpenSSL / ISC

Features X25519Kyber768 (ML-KEM-768 hybrid) natively. Used in production by billions of Chrome and Android users daily. If you're building Android apps or Chrome extensions that control TLS configuration, BoringSSL is the underlying library.

Note: BoringSSL is not designed for external use — it has no API stability guarantees. Use it through Chrome or Android APIs, not directly.

Language-Specific PQC Libraries

Rust — pqcrypto

Safe Rust bindings to the NIST PQC reference implementations. Includes ML-KEM, ML-DSA, SLH-DSA, and others. Works on stable Rust. Audited and maintained.

cargo add pqcrypto-kyber

Python — cryptography + oqs

The cryptography library (built on OpenSSL) plus liboqs-python for PQC. The most accessible Python PQC setup.

pip install cryptography liboqs-python

Go — circl (Cloudflare)

Cloudflare's CIRCL (Cloudflare Interoperable Reusable Cryptographic Library) includes ML-KEM, ML-DSA, and hybrid key exchange. Battle-tested in Cloudflare's production systems.

go get github.com/cloudflare/circl

Java — Bouncy Castle

Bouncy Castle has added PQC support starting with version 1.72. Includes CRYSTALS-Kyber, CRYSTALS-Dilithium, and SPHINCS+ — now accessible under their standardized FIPS names.

implementation 'org.bouncycastle:bcprov-jdk18on:1.78'

JavaScript / Node.js

Node.js doesn't yet have native PQC in its crypto module. Use WebAssembly builds of liboqs (available as npm packages) or the Web Crypto API with pqc extensions (in development).

npm install liboqs-node

.NET — Microsoft PQC

Microsoft.NET 9+ includes experimental ML-KEM support in System.Security.Cryptography. Full standardized PQC expected in .NET 10 and later versions of the Windows Cryptographic API.

<PackageReference Include="System.Security.Cryptography.Algorithms" />

PQClean: Clean Reference Implementations

PQClean is a project providing clean, well-documented reference implementations of post-quantum algorithms — optimized for readability and correctness verification rather than maximum performance. It's what cryptographic engineers use to audit implementations against the original algorithm specifications.

For learning: PQClean's code is excellent for understanding how PQC algorithms work in practice. The implementations are designed to be readable. Don't use them directly in production — use liboqs (which often incorporates PQClean implementations as its base).

Library Readiness Summary

LibraryML-KEMML-DSASLH-DSATLS IntegrationAudit
liboqs✓✓✓Via OQS-OpenSSLPartial
OQS-OpenSSL✓✓✓NativePartial
BoringSSLML-KEM-768PlannedPlannedNative (Chrome)Google internal
Cloudflare CIRCL✓✓✓HTTP clientCloudflare
Bouncy Castle✓✓✓Via JSSEPartial

Frequently Asked Questions

Are these libraries production-ready today?

For testing and development, yes. For high-security production use: liboqs and CIRCL are being used in production by Cloudflare and others, but full security audits of all algorithms in all libraries are ongoing. FIPS-certified implementations are lagging the standardization — NIST will issue FIPS-validated test vectors and validation programs for the new standards, and certified implementations will follow over 2025–2027. For US government use, wait for FIPS validation; for general enterprise use, the libraries are ready.

What if I'm using a cloud provider's managed TLS (like AWS ALB)?

Cloud providers are adding PQC support to their managed TLS offerings. AWS Application Load Balancer and CloudFront already support ML-KEM-768 hybrid in some regions. If you use managed TLS, check your provider's documentation — migrating may be a configuration change, not a library upgrade. This is one of the benefits of cloud-managed cryptography for operational agility.

Should I switch to PQC libraries now or wait for them to mature?

For TLS key exchange (hybrid ML-KEM): start now if you can. The hybrid approach is backward-compatible and the key exchange libraries are mature. For signatures (ML-DSA/SLH-DSA): testing and staging environments now, with a migration plan for 2025–2026. For data-at-rest encryption with long-lived secrets: plan and prototype now. The cost of waiting is more data collected under vulnerable cryptography — every month of delay increases exposure.

← PQC in Payments Next: The Road Ahead →

Frequently Asked Questions

What will I learn here?

This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.

How should I use this page?

Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.

What should I read next?

Use the navigation below to continue to the next lesson or explore related topics.