open-quantum-safe / openssl

UNSUPPORTED Fork of OpenSSL 1.1.1 that includes prototype quantum-resistant algorithms and ciphersuites based on liboqs PLEASE SWITCH TO OQS-Provider for OpenSSL 3
https://openquantumsafe.org/
Other
286 stars 124 forks source link

Gracefully handle algorithm enablement #420

Closed baentsch closed 1 year ago

baentsch commented 1 year ago

As soon as https://github.com/open-quantum-safe/liboqs/issues/1331 lands, tests for algorithms disabled in oqs-openssl would fail if only an algorithm subset is enabled, e.g., STD. This issue is to collect options how to handle this: Initial ideas: 1) Don't care, i.e., do not support/perform (CI) testing with "standard-only" algorithm selections. 2) Create a possibly convoluted script to filter algorithms under test in https://github.com/open-quantum-safe/openssl/blob/OQS-OpenSSL_1_1_1-stable/oqs-test/common.py using information from "oqsconfig.h" (un-set #defines). 3) Add code throughout oqs-openssl to explicitly permit unavailability of an algorithm, possibly guarded by an environment variable "OQS_TEST_ONLY".

Preferences? Further alternatives? @xvzcf @dstebila @christianpaquin ?

Options 1 (not testing what is actually deployed) and 3 (possibly extensive code changes for test-only behaviour changes) have such undesirable consequences that I personally think 2 ought to be implemented. But I'm all ears for alternatives.

christianpaquin commented 1 year ago

Option 2 indeed sounds more robust. Meanwhile, a README warning to explain the failure should be added (option 1-ish).

Does OpenSSL support a mechanism to deal with non-always present algs (like GOST)?

baentsch commented 1 year ago

Does OpenSSL support a mechanism to deal with non-always present algs (like GOST)?

OpenSSL is built with or without algs, i.e., things are compiled (by defines) to handle alg absence/presence gracefully (incl.GOST). The same is valid for oqs-provider (as it statically links in available algorithms). This is only not true for oqs-openssl as it dynamically links to liboqs -- and then such "surprises" can occur.

dstebila commented 1 year ago

The OpenSSL project has indicated that OpenSSL 1.1.1 will reach end-of-life in September 2023. As such, we are discontinuing development on OQS-OpenSSL 1.1.1, and recommend all users switch to OpenSSL 3 and the OQS Provider for OpenSSL 3, which provides all the same functionality that OQS-OpenSSL 1.1.1 does. Hence we are closing open pull requests and issues in OQS-OpenSSL 1.1.1 as won't-fix.