TLS

Table of contents

  1. OQS-OpenSSL provider
  2. OQS-OpenSSL
  3. OQS-BoringSSL
  4. OQS-Engine
  5. Demo integrations
    1. Apache httpd
    2. nginx
    3. haproxy
    4. curl
    5. Chromium
    6. epiphany
    7. Wireshark
    8. (Interoperability) Test server
    9. QUIC
    10. MQTT

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

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):

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-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

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

nginx

haproxy

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

Chromium

epiphany

Wireshark

(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.

Test server

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:

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:

Note: This code is still based on oqs-openssl111 thus may become unsupported as soon as OpenSSL1.1.1 support ends in September 2023.


Copyright © Open Quantum Safe a Series of LF Projects, LLC.
For website terms of use, trademark policy, and other project policies, please see https://lfprojects.org.
This site uses Just the Docs, a documentation theme for Jekyll. Background image by Rick Doble.