Post-Quantum OpenSSL

OpenSSL 3.5 (2025) ships native ML-KEM, ML-DSA, and SLH-DSA — no third-party provider required for the FIPS algorithms. For the not-yet-standardized schemes, the OQS oqs-provider extends OpenSSL 3 the same way. This page covers both paths with real commands.

Path 1: native PQC in OpenSSL 3.5+

Confirm your version and what is built in. From 3.5 the FIPS KEM and signature algorithms appear with no extra configuration:

openssl version            # expect 3.5.0 or newer

# List the post-quantum KEMs and groups now available natively
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -Ei 'ml-dsa|slh-dsa'

Generate keys and sign

ML-DSA keys and signatures use the standard genpkey / pkeyutl workflow:

# Generate an ML-DSA-65 private key
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key

# Derive the public key
openssl pkey -in mldsa65.key -pubout -out mldsa65.pub

# Sign and verify a message
openssl pkeyutl -sign  -inkey mldsa65.key -rawin -in message.txt -out message.sig
openssl pkeyutl -verify -pubin -inkey mldsa65.pub -rawin -in message.txt -sigfile message.sig

Negotiate a post-quantum TLS handshake

The recommended deployment is a hybrid group such as X25519MLKEM768, which pairs classical X25519 with ML-KEM-768:

# Client side: request the hybrid group explicitly
openssl s_client -connect example.com:443 -groups X25519MLKEM768

# Experimental example only: a pure PQ group is not the default production recommendation
openssl s_client -connect example.com:443 -groups MLKEM768

# Server side: restrict the offered groups
openssl s_server -accept 4433 -cert server.crt -key server.key \
  -groups X25519MLKEM768:X25519

For production migration, the recommended choice is a hybrid group such as X25519MLKEM768; a pure PQ group is only for experiments or specific interoperability testing and should not be the default production recommendation. Inspect the negotiated group in the handshake output — OpenSSL reports the selected key-exchange group, confirming the post-quantum exchange actually happened.

Path 2: the oqs-provider (everything else)

For Classic McEliece, HQC, BIKE, FrodoKEM, or Falcon — algorithms OpenSSL does not ship natively — build the OQS provider against liboqs:

# Build oqs-provider against an installed liboqs
git clone --depth 1 https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
cmake -S . -B build -Dliboqs_DIR=/usr/local/lib/cmake/liboqs
cmake --build build
sudo cmake --install build

Load it from your OpenSSL configuration so both the default and OQS providers are active:

# openssl.cnf
[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[default_sect]
activate = 1

[oqsprovider_sect]
activate = 1

With the provider loaded, the OQS algorithms appear alongside the native ones:

# Point at your config and enumerate the now-expanded list
OPENSSL_CONF=./openssl.cnf openssl list -kem-algorithms | grep -Ei 'mceliece|hqc|bike'

# Generate a Falcon key via the provider
OPENSSL_CONF=./openssl.cnf openssl genpkey -algorithm falcon512 -out falcon512.key

Which path do I use?

• ML-KEM / ML-DSA / SLH-DSA — prefer OpenSSL 3.5+ native support; for compliance use, verify the specific FIPS provider, module version, certificate number, and parameter-set boundary.
• Experimental KEMs and Falcon — use oqs-provider.
• Stuck on OpenSSL 3.0–3.4? Use oqs-provider for everything, or upgrade to 3.5 for the native FIPS algorithms.

Related

Standards & references

• OpenSSL — the project shipping native ML-KEM/ML-DSA/SLH-DSA from 3.5.
• oqs-provider — OpenSSL 3 provider adding the non-FIPS PQC schemes.
• Open Quantum Safe — the project behind oqs-provider and liboqs.
• Resources — full standards register