Snapshot 2026-08-04 12:18:05 UTC · version 1
oqsprovider - Open Quantum Safe provider for OpenSSL (>=v3) =========================================================== Purpose ------- This repository contains code to enable quantum-safe cryptography (QSC) in a standard OpenSSL (>v1.1) distribution by way of implementing a single shared library, the OQS provider. Status ------ Currently this provider fully enables quantum-safe cryptography for KEM key establishment in TLS1.3 including management of such keys via the OpenSSL
This repository contains code to enable quantum-safe cryptography (QSC) in a standard OpenSSL (>v1.1) distribution by way of implementing a single shared library, the OQS provider.
Currently this provider fully enables quantum-safe cryptography for KEM key establishment in TLS1.3 including management of such keys via the OpenSSL (3.0) provider interface and hybrid KEM schemes. Also, QSC signatures including CMS and CMP functionality are available via the OpenSSL EVP interface. Key persistence is provided via the encode/decode mechanism, X.509 data structures, and PKCS#12 for bundling a private key with its corresponding X.509 certificate. Starting with OpenSSL 3.2 support for TLS1.3 signature functionality is available and final glitches for CMS have been resolved.
The standards implemented are documented in the separate file STANDARDS.md.
This implementation makes available the following quantum safe algorithms:
bikel1*, p256_bikel1*, x25519_bikel1*, bikel3, p384_bikel3, x448_bikel3, bikel5, p521_bikel5efrodo640aes, p256_efrodo640aes, x25519_efrodo640aes, efrodo640shake, p256_efrodo640shake, x25519_efrodo640shake, efrodo976aes, p384_efrodo976aes, x448_efrodo976aes, efrodo976shake, p384_efrodo976shake, x448_efrodo976shake, efrodo1344aes, p521_efrodo1344aes, efrodo1344shake, p521_efrodo1344shake, frodo640aes, p256_frodo640aes, x25519_frodo640aes, frodo640shake, p256_frodo640shake, x25519_frodo640shake, frodo976aes, p384_frodo976aes, x448_frodo976aes, frodo976shake, p384_frodo976shake, x448_frodo976shake, frodo1344aes, p521_frodo1344aes, frodo1344shake, p521_frodo1344shakehqc1, p256_hqc1, x25519_hqc1, hqc3, p384_hqc3, x448_hqc3, hqc5, p521_hqc5mlkem512, p256_mlkem512, x25519_mlkem512, bp256_mlkem512, mlkem768, p384_mlkem768, x448_mlkem768, bp384_mlkem768, X25519MLKEM768, SecP256r1MLKEM768, mlkem1024, p521_mlkem1024, SecP384r1MLKEM1024, bp512_mlkem1024mldsa44, p256_mldsa44, rsa3072_mldsa44, mldsa65, p384_mldsa65, mldsa87, p521_mldsa87falcon512, p256_falcon512, rsa3072_falcon512, falconpadded512, p256_falconpadded512, rsa3072_falconpadded512, falcon1024, p521_falcon1024, falconpadded1024, p521_falconpadded1024mayo1, p256_mayo1, mayo2, p256_mayo2, mayo3, p384_mayo3, mayo5, p521_mayo5CROSSrsdp128balanced, CROSSrsdp128fast*, CROSSrsdp128small*, CROSSrsdp192balanced*, CROSSrsdp192fast*, CROSSrsdp192small*, CROSSrsdp256small**, CROSSrsdpg128balanced*, CROSSrsdpg128fast*, CROSSrsdpg128small*, CROSSrsdpg192balanced*, CROSSrsdpg192fast*, CROSSrsdpg192small*, CROSSrsdpg256balanced*, CROSSrsdpg256fast*, CROSSrsdpg256small*OV_Is**, p256_OV_Is**, OV_Ip**, p256_OV_Ip**, OV_III**, p384_OV_III**, OV_V**, p521_OV_V**, OV_Is_pkc**, p256_OV_Is_pkc**, OV_Ip_pkc, p256_OV_Ip_pkc, OV_III_pkc**, p384_OV_III_pkc**, OV_V_pkc**, p521_OV_V_pkc**, OV_Is_pkc_skc**, p256_OV_Is_pkc_skc**, OV_Ip_pkc_skc, p256_OV_Ip_pkc_skc, OV_III_pkc_skc**, p384_OV_III_pkc_skc**, OV_V_pkc_skc**, p521_OV_V_pkc_skc**snova2454, p256_snova2454, snova2454shake**, p256_snova2454shake**, snova2454esk, p256_snova2454esk, snova2454shakeesk**, p256_snova2454shakeesk**, snova37172, p256_snova37172, snova2583**, p256_snova2583**, snova56252**, p384_snova56252**, snova49113**, p384_snova49113**, snova3784**, p384_snova3784**, snova2455, p384_snova2455, snova60104**, p521_snova60104**, snova2965, p521_snova2965slhdsasha2128s, slhdsasha2128f, slhdsasha2192s, slhdsasha2192f, slhdsasha2256s, slhdsasha2256f, slhdsashake128s, slhdsashake128f, slhdsashake192s, slhdsashake192f, slhdsashake256s, slhdsashake256fmqom2cat1gf16fastr5, p256_mqom2cat1gf16fastr5, mqom2cat1gf16fastr3*, p256_mqom2cat1gf16fastr3*, mqom2cat1gf16shortr5*, p256_mqom2cat1gf16shortr5*, mqom2cat1gf16shortr3*, p256_mqom2cat1gf16shortr3*, mqom2cat3gf16fastr5, p384_mqom2cat3gf16fastr5, mqom2cat3gf16fastr3*, p384_mqom2cat3gf16fastr3*, mqom2cat3gf16shortr5*, p384_mqom2cat3gf16shortr5*, mqom2cat3gf16shortr3*, p384_mqom2cat3gf16shortr3*, mqom2cat5gf16fastr5, p521_mqom2cat5gf16fastr5, mqom2cat5gf16fastr3*, p521_mqom2cat5gf16fastr3*, mqom2cat5gf16shortr5*, p521_mqom2cat5gf16shortr5*, mqom2cat5gf16shortr3*, p521_mqom2cat5gf16shortr3*As the underlying liboqs
at build time may be configured to not enable all algorithms, and the
underlying openssl installation at runtime may deliver some algorithms
already it is advisable to check the possible subset of algorithms actually
enabled via the standard commands, i.e.,
openssl list -signature-algorithms -provider oqsprovider and
openssl list -kem-algorithms -provider oqsprovider.
In addition, the above algorithms that ARE NOT denoted with either "*" or "**" ARE enabled for TLS operations. The above algorithms that ARE denoted with "*" ARE NOT enabled for TLS operations; this can be changed by modifying the "enabled" flags in the main algorithm configuration file. The above algorithms that ARE denoted with "**" ARE NOT enabled; this cannot be changed as these algorithms are incompatible with with RFC 8446.
In order to support parallel use of classic and quantum-safe cryptography this provider also provides different hybrid algorithms, combining classic and quantum-safe methods. There are two types of combinations: The Hybrids are listed above with a prefix denoting a classic algorithm, e.g., for elliptic curve: "p256_".
A full list of algorithms, their interoperability code points and OIDs as well as a method to dynamically adapt them, e.g., for interoperability testing are documented in ALGORITHMS.md.
Starting with version 3.5, OpenSSL natively implements a growing set of
standardized PQ algorithms (e.g., ML-KEM, ML-DSA and SLH-DSA) in its default
provider. Because these implementations are more advanced and better maintained
than the equivalent facilities in oqsprovider, the following rule applies:
A PQ algorithm is not available via
oqsprovideron OpenSSL >= 3.5 if OpenSSL's own default provider already implements that exact algorithm.
The rule keys on the algorithm as a whole, not on its components. It applies to
the standardized pure algorithms (ML-KEM, ML-DSA and SLH-DSA) and to any
standardized hybrid algorithm that OpenSSL ships natively (currently the hybrid
KEMs X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024).
A hybrid remains available through oqsprovider as long as OpenSSL does not
implement that specific combination, even when one of its components is
standardized: for example, x25519_mlkem512 and p256_mlkem512 stay available
even though OpenSSL provides their ML-KEM-512 component.
Everyone interested in testing any of the disabled standardized PQ algorithms
(pure as well as hybrid) via oqsprovider must therefore do so in an OpenSSL
version >= 3.2 and < 3.5.
[!NOTE] A concrete consequence is that SLH-DSA cannot be used for TLS via
oqsproviderwhen running in OpenSSL >= 3.5, because OpenSSL disables theoqsproviderimplementation but (as of this writing) does not itself offer SLH-DSA for TLS. Use an OpenSSL version>= 3.2and< 3.5to test SLH-DSA in TLS. OpenSSL >= 4.1 will add support for SLH-DSA on TLS (see this merged commit).
LibOQS version 0.16.0 includes support for both FrodoKEM variants, as specified in their submission for standardization under ISO. In said specification, the
name frodokem now refers to a new variant, labeled salted, while the original specification is renamed to efrodokem, the ephemeral
variant. Therefore, users must be aware that the string frodokem* will refer to different FrodoKEM variants depending upon the liboqs version employed.
All component builds and testing described in detail below can be executed by
running the scripts scripts/fullbuild.sh and scripts/runtests.sh
respectively (tested on Linux Ubuntu and Mint as well as MacOS).
By default, these scripts always build and test against the current OpenSSL master branch.
These scripts can be configured by setting various variables. Please note that these scripts do not install oqsprovider. This can be facilitated by running cmake --install _build (and following the activation instructions.
The below describes the basic build-test-install cycle using the standard
cmake tooling. Platform-specific notes are available for UNIX
(incl. MacOS and cygwin) and Windows.
All options to configure oqs-provider at build- or run-time are documented
in CONFIGURE.md.
To be able to build oqsprovider, OpenSSL 3.0 and liboqs need to be installed.
It's not important where they are installed, just that they are. If installed
in non-standard locations, these must be provided when running cmake via
the variables "OPENSSL_ROOT_DIR" and "liboqs_DIR". See CONFIGURE.md
for details.
cmake -S . -B _build && cmake --build _build && ctest --test-dir _build && cmake --install _build
Usage of oqsprovider is documented in the separate USAGE.md file.
oqsprovider is written to ensure building on all versions of OpenSSL
supporting the provider concept. However, OpenSSL still is in active
development regarding features supported via the provider interface.
Therefore some functionalities documented above are only supported
with specific OpenSSL versions:
In these versions, CMS functionality implemented in providers is not supported: The resolution of https://github.com/openssl/openssl/issues/17717 has not been not getting back-ported to OpenSSL3.0.
Also not supported in this version are provider-based signature algorithms used during TLS1.3 operations as documented in https://github.com/openssl/openssl/issues/10512.
Also not fully supported in 3.0.2 is performance testing as per the openssl
speed command as documented in #385.
These versions have full support for all TLS1.3 operations using PQ algorithms
when deploying oqsprovider, particularly with regard to the use of signature
algorithms. This also includes support for the "OSSL_SIGNATURE_PARAM_CONTEXT_STRING"
parameter that had not been supported before and for which limited support in
single PQ algorithms is available since liboqs version 0.12.
These versions are expected to support the openssl pkeyutl -encap/-decap
syntax for testing key encapsulation and decapsulation for test purposes. To
use this option, OQS provider should be built with
KEM encoding/decoding support.
Also new in this version is the possibility to retrieve all currently
active TLS signature algorithms via a new openssl list option:
openssl list -tls-signature-algorithms.
These versions also provide support for the new sign/verify message
interface, which are intended to sign arbitrary large data. The inclusion
of this capacity has modified the behavior of hybrid signature
components: unconditional hashing is no longer present, and will only
happen for EVP_PKEY_OP_SIGNMSG/EVP_PKEY_OP_VERIFYMSG operations. This
means that the behavior of EVP_PKEY_sign_init interface is modified, as
an appropriate message length for hybrid signature schemes is expected.
These versions include support for an increasing set of standardized PQC
algorithms (e.g., ML-KEM, ML-DSA and SLH-DSA). Accordingly, oqsprovider can no
longer succeed registering (O)IDs for these algorithms as these already exist.
In addition, oqsprovider functionally (e.g., support for several key formats)
and non-functionally (e.g., code quality) is not at par with the implementations
for these algorithms. Therefore, as described in
Using with OpenSSL >= 3.5, any algorithm whose
component is standardized and implemented in OpenSSL is disabled at runtime upon
detection of it being available in openssl. The same algorithms will continue
to work even using the same oqsprovider binary in OpenSSL installations with a
version older than 3.5.
This limitation might be resolved by implementing https://github.com/open-quantum-safe/oqs-provider/discussions/625. given sufficient interest. Contributions very welcome.
A limitation present in older OpenSSL versions is the number of default groups
supported: At most 44 default groups may be specified
, e.g., passing to SSL_CTX_set1_groups.
Therefore caution is advised activating all KEMs supported by oqsprovider
via the pre-build configuration facility:
This may lead to openssl crashing, depending on the OpenSSL version used:
The problem is gone in OpenSSL "master" branch and in the respective branches
since the releases 3.3.0, 3.2.2., 3.1.6 and 3.0.14.
A problem basically related to any TLS server installation is the observed limitation to 64 TLS signature algorithms by some TLS server implementations. Therefore, again caution is advised activating more than 64 PQ signature algorithms via the pre-build configuration facility.
In general, any use of the standardized algorithm families in any openssl version via
oqsprovider is strongly discouraged due to the disparities in key material representation
and key generation logic that has developed since 2024.
oqsprovider is primarily meant as a vehicle to enable testing of experimental PQ
crypto and has no intention of and/or commitment for duplicating the efforts going into
the development of production quality PQ crypto in openssl's default provider.
Project governance is documented in GOVERNANCE.md and contribution policy is documented in CONTRIBUTING.md.
The policy of this project is that all discussions pertaining to changes in the
functional and non-functional aspects of oqsprovider shall take place in
github. References to external discussion fora are discouraged to retain the
free and open flow of thoughts unencumbered by potentially differing or changing
access or data retention policies by github-external chat forums.
Contributors to the oqsprovider include:
cmake setup)Documentation on current and past releases ("code history") is documented in the separate file RELEASE.md.
oqsprovider came into existence as a branch of oqs-openssl
as part of the OQS project initially led by Douglas Stebila and Michele
Mosca at the University of Waterloo but split off to become a separate
project catering to the OpenSSL provider
concept. With OQS joining PQCA oqsprovider also
was folded into that organization.
The oqsprovider project had been supported through the NGI Assure Fund,
a fund established by NLnet with financial
support from the European Commission's Next Generation Internet programme,
under the aegis of DG Communications Networks, Content and Technology
under grant agreement No 957073.
Financial support for the development of Open Quantum Safe had been provided by Amazon Web Services and the Tutte Institute for Mathematics and Computing.
The OQS project would like to make a special acknowledgement to the companies who had dedicated programmer time to contribute source code to OQS, including Amazon Web Services, evolutionQ, Microsoft Research, Cisco Systems, and IBM Research.
Research projects which developed specific components of OQS have been supported by various research grants, including funding from the Natural Sciences and Engineering Research Council of Canada (NSERC); see here and here for funding acknowledgments.
THIS SOFTWARE IS PROVIDED WITH NO WARRANTIES, EXPRESS OR IMPLIED, AND ALL IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING ANY WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE.
This project follows the NIST PQC standardization process and aims to support experimentation with the various PQC algorithms under evaluation and in different stages of standardization by NIST. oqsprovider at this time cannot claim or prove adherence to any standards documents published. For more details, review the file STANDARDS.md carefully. Most notably, hybrid implementations exclusively implemented in oqsprovider are at a pre-standard/draft stage only. Over time the project aims to provide standards compliance and solicits input by way of contributions to achieve this state.
oqsprovider for the implementation of all pure PQC functionality
is completely dependent on liboqs and accordingly
cannot recommend any use beyond experimentation purposes:
WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS SOFTWARE IN A PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA. This software is meant to help with research and prototyping. While we make a best-effort approach to avoid security bugs, this library has not received the level of auditing and analysis that would be necessary to rely on it for high security use.
Further details and background available at:
Sign in to join the discussion.
Snapshot 2026-08-04 12:18:05 UTC · version 1
oqsprovider - Open Quantum Safe provider for OpenSSL (>=v3) =========================================================== Purpose ------- This repository contains code to enable quantum-safe cryptography (QSC) in a standard OpenSSL (>v1.1) distribution by way of implementing a single shared library, the OQS provider. Status ------ Currently this provider fully enables quantum-safe cryptography for KEM key establishment in TLS1.3 including management of such keys via the OpenSSL
This repository contains code to enable quantum-safe cryptography (QSC) in a standard OpenSSL (>v1.1) distribution by way of implementing a single shared library, the OQS provider.
Currently this provider fully enables quantum-safe cryptography for KEM key establishment in TLS1.3 including management of such keys via the OpenSSL (3.0) provider interface and hybrid KEM schemes. Also, QSC signatures including CMS and CMP functionality are available via the OpenSSL EVP interface. Key persistence is provided via the encode/decode mechanism, X.509 data structures, and PKCS#12 for bundling a private key with its corresponding X.509 certificate. Starting with OpenSSL 3.2 support for TLS1.3 signature functionality is available and final glitches for CMS have been resolved.
The standards implemented are documented in the separate file STANDARDS.md.
This implementation makes available the following quantum safe algorithms:
bikel1*, p256_bikel1*, x25519_bikel1*, bikel3, p384_bikel3, x448_bikel3, bikel5, p521_bikel5efrodo640aes, p256_efrodo640aes, x25519_efrodo640aes, efrodo640shake, p256_efrodo640shake, x25519_efrodo640shake, efrodo976aes, p384_efrodo976aes, x448_efrodo976aes, efrodo976shake, p384_efrodo976shake, x448_efrodo976shake, efrodo1344aes, p521_efrodo1344aes, efrodo1344shake, p521_efrodo1344shake, frodo640aes, p256_frodo640aes, x25519_frodo640aes, frodo640shake, p256_frodo640shake, x25519_frodo640shake, frodo976aes, p384_frodo976aes, x448_frodo976aes, frodo976shake, p384_frodo976shake, x448_frodo976shake, frodo1344aes, p521_frodo1344aes, frodo1344shake, p521_frodo1344shakehqc1, p256_hqc1, x25519_hqc1, hqc3, p384_hqc3, x448_hqc3, hqc5, p521_hqc5mlkem512, p256_mlkem512, x25519_mlkem512, bp256_mlkem512, mlkem768, p384_mlkem768, x448_mlkem768, bp384_mlkem768, X25519MLKEM768, SecP256r1MLKEM768, mlkem1024, p521_mlkem1024, SecP384r1MLKEM1024, bp512_mlkem1024mldsa44, p256_mldsa44, rsa3072_mldsa44, mldsa65, p384_mldsa65, mldsa87, p521_mldsa87falcon512, p256_falcon512, rsa3072_falcon512, falconpadded512, p256_falconpadded512, rsa3072_falconpadded512, falcon1024, p521_falcon1024, falconpadded1024, p521_falconpadded1024mayo1, p256_mayo1, mayo2, p256_mayo2, mayo3, p384_mayo3, mayo5, p521_mayo5CROSSrsdp128balanced, CROSSrsdp128fast*, CROSSrsdp128small*, CROSSrsdp192balanced*, CROSSrsdp192fast*, CROSSrsdp192small*, CROSSrsdp256small**, CROSSrsdpg128balanced*, CROSSrsdpg128fast*, CROSSrsdpg128small*, CROSSrsdpg192balanced*, CROSSrsdpg192fast*, CROSSrsdpg192small*, CROSSrsdpg256balanced*, CROSSrsdpg256fast*, CROSSrsdpg256small*OV_Is**, p256_OV_Is**, OV_Ip**, p256_OV_Ip**, OV_III**, p384_OV_III**, OV_V**, p521_OV_V**, OV_Is_pkc**, p256_OV_Is_pkc**, OV_Ip_pkc, p256_OV_Ip_pkc, OV_III_pkc**, p384_OV_III_pkc**, OV_V_pkc**, p521_OV_V_pkc**, OV_Is_pkc_skc**, p256_OV_Is_pkc_skc**, OV_Ip_pkc_skc, p256_OV_Ip_pkc_skc, OV_III_pkc_skc**, p384_OV_III_pkc_skc**, OV_V_pkc_skc**, p521_OV_V_pkc_skc**snova2454, p256_snova2454, snova2454shake**, p256_snova2454shake**, snova2454esk, p256_snova2454esk, snova2454shakeesk**, p256_snova2454shakeesk**, snova37172, p256_snova37172, snova2583**, p256_snova2583**, snova56252**, p384_snova56252**, snova49113**, p384_snova49113**, snova3784**, p384_snova3784**, snova2455, p384_snova2455, snova60104**, p521_snova60104**, snova2965, p521_snova2965slhdsasha2128s, slhdsasha2128f, slhdsasha2192s, slhdsasha2192f, slhdsasha2256s, slhdsasha2256f, slhdsashake128s, slhdsashake128f, slhdsashake192s, slhdsashake192f, slhdsashake256s, slhdsashake256fmqom2cat1gf16fastr5, p256_mqom2cat1gf16fastr5, mqom2cat1gf16fastr3*, p256_mqom2cat1gf16fastr3*, mqom2cat1gf16shortr5*, p256_mqom2cat1gf16shortr5*, mqom2cat1gf16shortr3*, p256_mqom2cat1gf16shortr3*, mqom2cat3gf16fastr5, p384_mqom2cat3gf16fastr5, mqom2cat3gf16fastr3*, p384_mqom2cat3gf16fastr3*, mqom2cat3gf16shortr5*, p384_mqom2cat3gf16shortr5*, mqom2cat3gf16shortr3*, p384_mqom2cat3gf16shortr3*, mqom2cat5gf16fastr5, p521_mqom2cat5gf16fastr5, mqom2cat5gf16fastr3*, p521_mqom2cat5gf16fastr3*, mqom2cat5gf16shortr5*, p521_mqom2cat5gf16shortr5*, mqom2cat5gf16shortr3*, p521_mqom2cat5gf16shortr3*As the underlying liboqs
at build time may be configured to not enable all algorithms, and the
underlying openssl installation at runtime may deliver some algorithms
already it is advisable to check the possible subset of algorithms actually
enabled via the standard commands, i.e.,
openssl list -signature-algorithms -provider oqsprovider and
openssl list -kem-algorithms -provider oqsprovider.
In addition, the above algorithms that ARE NOT denoted with either "*" or "**" ARE enabled for TLS operations. The above algorithms that ARE denoted with "*" ARE NOT enabled for TLS operations; this can be changed by modifying the "enabled" flags in the main algorithm configuration file. The above algorithms that ARE denoted with "**" ARE NOT enabled; this cannot be changed as these algorithms are incompatible with with RFC 8446.
In order to support parallel use of classic and quantum-safe cryptography this provider also provides different hybrid algorithms, combining classic and quantum-safe methods. There are two types of combinations: The Hybrids are listed above with a prefix denoting a classic algorithm, e.g., for elliptic curve: "p256_".
A full list of algorithms, their interoperability code points and OIDs as well as a method to dynamically adapt them, e.g., for interoperability testing are documented in ALGORITHMS.md.
Starting with version 3.5, OpenSSL natively implements a growing set of
standardized PQ algorithms (e.g., ML-KEM, ML-DSA and SLH-DSA) in its default
provider. Because these implementations are more advanced and better maintained
than the equivalent facilities in oqsprovider, the following rule applies:
A PQ algorithm is not available via
oqsprovideron OpenSSL >= 3.5 if OpenSSL's own default provider already implements that exact algorithm.
The rule keys on the algorithm as a whole, not on its components. It applies to
the standardized pure algorithms (ML-KEM, ML-DSA and SLH-DSA) and to any
standardized hybrid algorithm that OpenSSL ships natively (currently the hybrid
KEMs X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024).
A hybrid remains available through oqsprovider as long as OpenSSL does not
implement that specific combination, even when one of its components is
standardized: for example, x25519_mlkem512 and p256_mlkem512 stay available
even though OpenSSL provides their ML-KEM-512 component.
Everyone interested in testing any of the disabled standardized PQ algorithms
(pure as well as hybrid) via oqsprovider must therefore do so in an OpenSSL
version >= 3.2 and < 3.5.
[!NOTE] A concrete consequence is that SLH-DSA cannot be used for TLS via
oqsproviderwhen running in OpenSSL >= 3.5, because OpenSSL disables theoqsproviderimplementation but (as of this writing) does not itself offer SLH-DSA for TLS. Use an OpenSSL version>= 3.2and< 3.5to test SLH-DSA in TLS. OpenSSL >= 4.1 will add support for SLH-DSA on TLS (see this merged commit).
LibOQS version 0.16.0 includes support for both FrodoKEM variants, as specified in their submission for standardization under ISO. In said specification, the
name frodokem now refers to a new variant, labeled salted, while the original specification is renamed to efrodokem, the ephemeral
variant. Therefore, users must be aware that the string frodokem* will refer to different FrodoKEM variants depending upon the liboqs version employed.
All component builds and testing described in detail below can be executed by
running the scripts scripts/fullbuild.sh and scripts/runtests.sh
respectively (tested on Linux Ubuntu and Mint as well as MacOS).
By default, these scripts always build and test against the current OpenSSL master branch.
These scripts can be configured by setting various variables. Please note that these scripts do not install oqsprovider. This can be facilitated by running cmake --install _build (and following the activation instructions.
The below describes the basic build-test-install cycle using the standard
cmake tooling. Platform-specific notes are available for UNIX
(incl. MacOS and cygwin) and Windows.
All options to configure oqs-provider at build- or run-time are documented
in CONFIGURE.md.
To be able to build oqsprovider, OpenSSL 3.0 and liboqs need to be installed.
It's not important where they are installed, just that they are. If installed
in non-standard locations, these must be provided when running cmake via
the variables "OPENSSL_ROOT_DIR" and "liboqs_DIR". See CONFIGURE.md
for details.
cmake -S . -B _build && cmake --build _build && ctest --test-dir _build && cmake --install _build
Usage of oqsprovider is documented in the separate USAGE.md file.
oqsprovider is written to ensure building on all versions of OpenSSL
supporting the provider concept. However, OpenSSL still is in active
development regarding features supported via the provider interface.
Therefore some functionalities documented above are only supported
with specific OpenSSL versions:
In these versions, CMS functionality implemented in providers is not supported: The resolution of https://github.com/openssl/openssl/issues/17717 has not been not getting back-ported to OpenSSL3.0.
Also not supported in this version are provider-based signature algorithms used during TLS1.3 operations as documented in https://github.com/openssl/openssl/issues/10512.
Also not fully supported in 3.0.2 is performance testing as per the openssl
speed command as documented in #385.
These versions have full support for all TLS1.3 operations using PQ algorithms
when deploying oqsprovider, particularly with regard to the use of signature
algorithms. This also includes support for the "OSSL_SIGNATURE_PARAM_CONTEXT_STRING"
parameter that had not been supported before and for which limited support in
single PQ algorithms is available since liboqs version 0.12.
These versions are expected to support the openssl pkeyutl -encap/-decap
syntax for testing key encapsulation and decapsulation for test purposes. To
use this option, OQS provider should be built with
KEM encoding/decoding support.
Also new in this version is the possibility to retrieve all currently
active TLS signature algorithms via a new openssl list option:
openssl list -tls-signature-algorithms.
These versions also provide support for the new sign/verify message
interface, which are intended to sign arbitrary large data. The inclusion
of this capacity has modified the behavior of hybrid signature
components: unconditional hashing is no longer present, and will only
happen for EVP_PKEY_OP_SIGNMSG/EVP_PKEY_OP_VERIFYMSG operations. This
means that the behavior of EVP_PKEY_sign_init interface is modified, as
an appropriate message length for hybrid signature schemes is expected.
These versions include support for an increasing set of standardized PQC
algorithms (e.g., ML-KEM, ML-DSA and SLH-DSA). Accordingly, oqsprovider can no
longer succeed registering (O)IDs for these algorithms as these already exist.
In addition, oqsprovider functionally (e.g., support for several key formats)
and non-functionally (e.g., code quality) is not at par with the implementations
for these algorithms. Therefore, as described in
Using with OpenSSL >= 3.5, any algorithm whose
component is standardized and implemented in OpenSSL is disabled at runtime upon
detection of it being available in openssl. The same algorithms will continue
to work even using the same oqsprovider binary in OpenSSL installations with a
version older than 3.5.
This limitation might be resolved by implementing https://github.com/open-quantum-safe/oqs-provider/discussions/625. given sufficient interest. Contributions very welcome.
A limitation present in older OpenSSL versions is the number of default groups
supported: At most 44 default groups may be specified
, e.g., passing to SSL_CTX_set1_groups.
Therefore caution is advised activating all KEMs supported by oqsprovider
via the pre-build configuration facility:
This may lead to openssl crashing, depending on the OpenSSL version used:
The problem is gone in OpenSSL "master" branch and in the respective branches
since the releases 3.3.0, 3.2.2., 3.1.6 and 3.0.14.
A problem basically related to any TLS server installation is the observed limitation to 64 TLS signature algorithms by some TLS server implementations. Therefore, again caution is advised activating more than 64 PQ signature algorithms via the pre-build configuration facility.
In general, any use of the standardized algorithm families in any openssl version via
oqsprovider is strongly discouraged due to the disparities in key material representation
and key generation logic that has developed since 2024.
oqsprovider is primarily meant as a vehicle to enable testing of experimental PQ
crypto and has no intention of and/or commitment for duplicating the efforts going into
the development of production quality PQ crypto in openssl's default provider.
Project governance is documented in GOVERNANCE.md and contribution policy is documented in CONTRIBUTING.md.
The policy of this project is that all discussions pertaining to changes in the
functional and non-functional aspects of oqsprovider shall take place in
github. References to external discussion fora are discouraged to retain the
free and open flow of thoughts unencumbered by potentially differing or changing
access or data retention policies by github-external chat forums.
Contributors to the oqsprovider include:
cmake setup)Documentation on current and past releases ("code history") is documented in the separate file RELEASE.md.
oqsprovider came into existence as a branch of oqs-openssl
as part of the OQS project initially led by Douglas Stebila and Michele
Mosca at the University of Waterloo but split off to become a separate
project catering to the OpenSSL provider
concept. With OQS joining PQCA oqsprovider also
was folded into that organization.
The oqsprovider project had been supported through the NGI Assure Fund,
a fund established by NLnet with financial
support from the European Commission's Next Generation Internet programme,
under the aegis of DG Communications Networks, Content and Technology
under grant agreement No 957073.
Financial support for the development of Open Quantum Safe had been provided by Amazon Web Services and the Tutte Institute for Mathematics and Computing.
The OQS project would like to make a special acknowledgement to the companies who had dedicated programmer time to contribute source code to OQS, including Amazon Web Services, evolutionQ, Microsoft Research, Cisco Systems, and IBM Research.
Research projects which developed specific components of OQS have been supported by various research grants, including funding from the Natural Sciences and Engineering Research Council of Canada (NSERC); see here and here for funding acknowledgments.
THIS SOFTWARE IS PROVIDED WITH NO WARRANTIES, EXPRESS OR IMPLIED, AND ALL IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING ANY WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE.
This project follows the NIST PQC standardization process and aims to support experimentation with the various PQC algorithms under evaluation and in different stages of standardization by NIST. oqsprovider at this time cannot claim or prove adherence to any standards documents published. For more details, review the file STANDARDS.md carefully. Most notably, hybrid implementations exclusively implemented in oqsprovider are at a pre-standard/draft stage only. Over time the project aims to provide standards compliance and solicits input by way of contributions to achieve this state.
oqsprovider for the implementation of all pure PQC functionality
is completely dependent on liboqs and accordingly
cannot recommend any use beyond experimentation purposes:
WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS SOFTWARE IN A PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA. This software is meant to help with research and prototyping. While we make a best-effort approach to avoid security bugs, this library has not received the level of auditing and analysis that would be necessary to rely on it for high security use.
Further details and background available at:
Sign in to join the discussion.