Feedback on directions for OQS

[dstebila]

Looking to the next phase of OQS, we'd like to collect your feedback on what parts of the Open Quantum Safe project should be prioritized and which are less important.

As a reminder, here are the various components the OQS project team maintains:

• liboqs: C library for prototyping and experimenting with quantum-resistant cryptography, providing generic and optimized implementations for all algorithms standardized or still part of the PQC competition by NIST
• OQS-OpenSSL: Fork of OpenSSL 1.1.1 that includes post-quantum and hybrid key exchange and signatures in TLS 1.3, and post-quantum and hybrid signatures in X.509, S/MIME, and CMS
• oqs-provider: An OpenSSL 3 provider that provides post-quantum and hybrid key exchange in TLS 1.3, and post-quantum and hybrid signatures in X.509, S/MIME, and CMS
• OQS-BoringSSL: Fork of BoringSSL that includes prototype quantum-resistant key exchange and authentication in the TLS 1.3 handshake
• OQS-OpenSSH: Fork of OpenSSH that includes prototype quantum-resistant key exchange and authentication in SSH
• OQS libssh: Fork of libssh that includes prototype quantum-resistant key exchange and authentication in SSH
• OQS Demos: Repository of instructions, patches, and Docker images demonstrating post-quantum algorithms in curl, Apache httpd, nginx, Chromium, HAproxy, Wireshark, Epiphany, QUIC, Mosquitto, and OpenVPN
• test.openquantumsafe.org: Interoperability test server for post-quantum and hybrid key exchange and signatures in TLS 1.3
• Benchmarking: Automated benchmarking platform measuring performance of raw algorithms and TLS connections on Intel x86_64 and ARMv8 (generic ARM64 and Apple M1)
• Language wrappers: Bindings for accessing basic KEM and signature operations from liboqs in C++, Go, Java, .Net, Python, and Rust

Following the NIST July 2022 announcement with the selection of algorithms for standardization and the selection of algorithms advancing to round 4, we will be pruning the list of algorithms supported to those advanced by NIST. We may also continue to support algorithms removed after Round 3 for which there is strong external interest; see/participate in the discussion at #1245. We will incorporate tweaks submitted for Round 4. This will be the focus of the liboqs 0.8.0 release which will come after the Round 4 submission deadline of October 1, 2022. We will also intend to include schemes involved in NIST's forthcoming signature reopening.

Key questions:

• Which subprojects are important to maintain? Or put another way, which subprojects would be missed if they were removed?
• What architectures and platforms are most imporant? Should OQS actively work towards integration with specific OS/distributions? Which ones?
• What improvements or new functionality is desired? Is there interest for new non-functional properties, e.g., further testing/hardening?

[baentsch]

Benchmarking: There does not seem to be much change/improvement work going on for the algorithms. What about completely suspending running benchmarking until this changes again?

[baentsch]

OQS-BoringSSL: Does anyone know whether someone uses this for something else beyond ourselves in the Chromium demo? As we now have another OQS-enabled browser epiphany what about the suggestion to drop maintenance of BoringSSL (and the chromium demo along with it)?

[dstebila]

Some feedback from the folks at AWS via @crockeea:

Here is our list of projects that we’d like to see maintained:

• We’re still committed to working on pq-ssh via the draft. We would love to see the OQS-OpenSSH implementation (and to a lesser extent, libssh) maintain compliance with that draft, because Panos has plans to interop test these implementations with our own fork of OpenSSH as part of NCCOE.
• We would like to see the OQS-OpenSSL (1.1.1) be maintained, because we would like to interop testing as part of NCCOE and our ongoing work with s2n.
• The liboqs library (with algorithm KATs) is important for ensuring algorithm compliance as part of NCCOE.
• The OpenSSL test server will be important for NCCOE testing.

We’d also like to propose the following enhancements:

• Add a test server for OQS-OpenSSH for interop testing as part of NCCOE.
• Add a test server for your QUIC demo for interop testing as part of NCCOE.
• Add TLS 1.3 hybrid key exchange KATs to OQS-OpenSSL (1.1.1). Panos spoke to Christian about this recently.