TLS
Table of contents
We’ve integrated liboqs into forks of BoringSSL and OpenSSL1.1.1 as well as a standalone OQS provider for OpenSSL3 to provide prototype post-quantum key exchange and authentication and ciphersuites in the TLS protocol. Researchers looking to try additional post-quantum algorithms can easily add more algorithms that follow the OQS API. You can use our modified implementations to prototype quantum-resistant cryptography in applications that rely on OpenSSL (such as Apache httpd, nginx, haproxy, curl, or OpenVPN) or on BoringSSL (such as Chromium).
An Internet-Draft is available describing how the TLS 1.3 protocol was adapted to include the hybrid PQ key exchange algorithms.
The goal of these integration is to provide easy prototyping of quantum-resistant cryptography and should not be considered “production quality”. Please see more about limitations of our prototype software.
OQS-OpenSSL provider
The new, state-of-the-art OpenSSLv3 architecture provides a more clean way to integrate novel algorithms into TLS1.3: A fully separate binary plug-in component independent of the main TLS logic, a provider permits integration of post-quantum algorithms into TLS1.3 without changing the core logic of OpenSSL. Along the same lines, providers extend X.509 certificate management functions provided by OpenSSL to new algorithm classes.
The oqsprovider is thus making all quantum-safe algorithms supported by OQS as well as their hybrid (classic/quantum-safe) variants readily available to OpenSSLv3 users and applications. It has matured to the level of being used as validation test for the OpenSSL3 provider functionality. This ensures that all quantum-safe algorithms supported by OQS are readily available without code changes to any installation running OpenSSLv3. All limitations/open issues are documented at the issues tracker for the oqsprovider project. Functional limitations of the different OpenSSL3 versions are documented here.
- OQS-OpenSSL provider version 0.7.0 aligned with liboqs 0.11.0 (October 8, 2024) current version
- OQS-OpenSSL provider version 0.6.1 aligned with liboqs 0.10.1 (June 14, 2024)
- OQS-OpenSSL provider version 0.6.0 aligned with liboqs 0.10.0 (April 12, 2024)
- OQS-OpenSSL provider version 0.5.2 aligned with liboqs 0.9.0 (October 21, 2023)
- OQS-OpenSSL provider version 0.5.1 aligned with liboqs 0.8.0 (July 25, 2023)
- OQS-OpenSSL provider version 0.5.0 aligned with liboqs 0.8.0 (June 9, 2023)
- OQS-OpenSSL provider version 0.4.0 aligned with liboqs 0.7.2 (August 22, 2022)
- OQS-OpenSSL provider version 0.3.0 aligned with liboqs 0.7.1 (January 13, 2022)
OQS-OpenSSL
Note: The OpenSSL project has announced that its support for OpenSSL 1.1.1 will stop in September, 2023, and that all users should switch to OpenSSL 3. Consequently, the Open Quantum Safe project is discontinuing development of our OQS-OpenSSL 1.1.1 fork. No more releases are planned for OQS-OpenSSL 1.1.1. The OQS Provider for OpenSSL 3 (described above) provides full support for post-quantum key exchange and authentication in TLS 1.3, X.509, and S/MIME.
Our OpenSSL fork implements post-quantum and hybrid key exchange and post-quantum public key authentication in TLS 1.3, and also supports post-quantum algorithms in X.509 certificate generation and S/MIME / CMS message handling, all based on the current OpenSSL 1.1.1 code base.
See the OQS-OpenSSL README for the current list of supported algorithms and usage instructions.
OpenSSL 1.1.1 releases
The OQS-OpenSSL-1.1.1 series provides post-quantum algorithms in TLS 1.3, X.509, and S/MIME; its maintenance will end when OpenSSL1.1.1 support ends, on September 11, 2023. Until then regular updates to follow/merge the upstream/main OpenSSL project releases occur(ed):
- OQS-OpenSSL 1.1.1 snapshot 2023-07 aligned with liboqs 0.8.0 (July 7, 2023) current version end of life
- OQS-OpenSSL 1.1.1 snapshot 2022-08 aligned with liboqs 0.7.2 (August 24, 2022)
- OQS-OpenSSL 1.1.1 snapshot 2022-01 aligned with liboqs 0.7.1 (January 6, 2022)
- OQS-OpenSSL 1.1.1 snapshot 2021-08 aligned with liboqs 0.7.0 (August 11, 2021)
- OQS-OpenSSL 1.1.1 snapshot 2021-03 aligned with liboqs 0.5.0 (March 26, 2021)
- OQS-OpenSSL 1.1.1 snapshot 2020-08 aligned with liboqs 0.4.0 (August 11, 2020)
- OQS-OpenSSL 1.1.1 snapshot 2020-07 aligned with liboqs 0.3.0 (July 10, 2020)
- OQS-OpenSSL 1.1.1 snapshot 2019-10 aligned with liboqs 0.2.0 (October 8, 2019)
- OQS-OpenSSL 1.1.1 snapshot 2018-11 aligned with liboqs 0.1.0 (November 13, 2018)
- all releases
The OQS-OpenSSL-1.0.2 series provided post-quantum algorithms in TLS 1.2. It is deprecated and no longer maintained.
Click here to see archived OQS-OpenSSL 1.0.2 releases
- OQS-OpenSSL 1.0.2 snapshot 2019-10 aligned with liboqs 0.2.0 (October 8, 2019)
- OQS-OpenSSL 1.0.2 snapshot 2018-11 aligned with liboqs 0.1.0 (November 13, 2018)
- OQS-OpenSSL 1.0.2 snapshot 2018-05 (May 30, 2018)
- OQS-OpenSSL 1.0.2 snapshot 2018-04 (April 10, 2018)
OQS-BoringSSL
Our BoringSSL fork implements post-quantum and hybrid key exchange and post-quantum public key authentication in TLS 1.3.
See the OQS-BoringSSL README for the list of supported algorithms and usage instructions.
Releases
- OQS-BoringSSL snapshot 2024-10 aligned with liboqs 0.11.0 (October 10, 2024) current version
- OQS-BoringSSL snapshot 2023-06 aligned with liboqs 0.8.0 (July 4, 2023)
- OQS-BoringSSL snapshot 2022-08 aligned with liboqs 0.7.2 (August 25, 2022)
- OQS-BoringSSL snapshot 2022-01 aligned with liboqs 0.7.1 (January 6, 2022)
- OQS-BoringSSL snapshot 2021-08 aligned with liboqs 0.7.0 (August 11, 2021)
- OQS-BoringSSL snapshot 2021-03 aligned with liboqs 0.5.0 (March 26, 2021)
- OQS-BoringSSL snapshot 2020-08 aligned with liboqs 0.4.0 (August 11, 2020)
- OQS-BoringSSL snapshot 2020-07 aligned with liboqs 0.3.0 (July 10, 2020)
Continued updates to OQS-BoringSSL are currently not planned due to lack of interest in this software. Statements of interest should be voiced here.
OQS-Engine
oqs-engine is a C-based OpenSSL ENGINE that enables in (vanilla) OpenSSL the use of post-quantum digital signature algorithms from liboqs. Changes and/or additions to the algorithms supported by liboqs will be dynamically reflected in the ENGINE, thereby facilitating the deployment and evaluation of post-quantum digital signature algorithms in contexts where it might be expensive or infeasible to replace OpenSSL wholesale with our corresponding fork.
We are grateful to Senetas for contributing this ENGINE to the OQS project. Hear about Senetas’ work on the ENGINE for OQS in their interview on episode 581 of the Risky Business podcast.
This subproject has been discontinued in line with the strategic OpenSSL architecture and replaced by the actively maintained OQS-provider.
Demo integrations
The easiest way to get started with experimenting with post-quantum cryptography is to use our pre-built Docker images containing post-quantum-enabled versions of the web servers Apache httpd and nginx, the high-availability web proxy haproxy or the command-line web client curl. You can also download a pre-built binary of post-quantum-enabled Chromium and Wireshark.
There also exists a post-quantum-enabled docker image for SSH.
OQS Docker images on Docker Hub
HTTP(s) servers
Using our fork of OpenSSL, we’ve enabled support for post-quantum and hybrid key exchange and authentication in the Apache httpd web server, the nginx web server and the haproxy load balancer. There are links below to instructions on how to use the pre-built Docker images, or you can build your own.
Apache httpd
- Getting and running the pre-built post-quantum enabled Apache httpd demo Docker image
- Building your own Apache httpd demo Docker image
nginx
- Getting and running the pre-built post-quantum enabled nginx demo Docker image
- Building your own nginx demo Docker image
haproxy
- Getting and running the pre-built post-quantum enabled haproxy demo Docker image
- Building your own haproxy demo Docker image
HTTP(s) clients
Using our forks of OpenSSL and BoringSSL, we’ve enabled support for post-quantum and hybrid key exchange and authentication in the curl command-line web client and the Chromium and Epiphany web browsers.
curl
- Getting and running the pre-built post-quantum enabled curl demo Docker image
- Building your own curl demo Docker image
Chromium
- Pre-built Chromium binary for Ubuntu 20.04 (64bit x86) at liboqs v0.7.2 (149 MB)
- Building your own Chromium binary (warning: painful!)
epiphany
- Getting and running the pre-built post-quantum enabled epiphany browser demo Docker image
- Building your own epiphany demo Docker image
Wireshark
- Getting and running the pre-built post-quantum enabled Wireshark demo Docker image and usage instructions
- Building your own Wireshark demo Docker image
(Interoperability) Test server
We’re interested in design and draft standards for hybrid authentication and key exchange as well as interoperability testing with other implementers. As an initial step to facilitate such testing we have set up a first iteration of such a demonstration and interoperability test server at https://test.openquantumsafe.org. All of the clients above can be used with this test server using the above post-quantum enabled nginx. Any usage and all feedback is very welcome.
QUIC
The QUIC protocol uses TLS1.3 for secure session establishment. We thus could also make available post-quantum enabled QUIC client and server components:
- Getting and running the pre-built post-quantum enabled nginx-quic demo Docker image
- Getting and running the pre-built post-quantum enabled msquic (reach) demo Docker image
- Building your own QUIC-enabled client- and server components
- Additional Dockerfiles exist to provide post-quantum enablement for ngtcp2.
Note: This code is still based on oqs-openssl111
thus may become unsupported as soon as OpenSSL1.1.1 support ends in September 2023.
MQTT
The MQTT protocol also uses TLS for session security. We thus could also make available post-quantum enabled MQTT broker, subscriber and publisher based on Mosquitto:
- Getting and running pre-built quantum-safe Mosquitto docker images.
- Building your own quantum safe Mosquitto docker images.
Note: This code is still based on oqs-openssl111
thus may become unsupported as soon as OpenSSL1.1.1 support ends in September 2023.