Algorithms disabled in liboqs should be disabled in OpenSSL.

[xvzcf]

When liboqs is built, autoconf outputs config.h, which contains preprocessor defines that state what algorithms are enabled at the variant level; for e.g.: if in the file we have ... #define OQS_ENABLE_SIG_qTESLA_I 1 /* #define OQS_ENABLE_SIG_qTESLA_III_size*/ ... this means qTESLA_I is enabled and qTESLA_III_size is not.

OpenSSL should also be able to enable and disable the use of these algorithms according to the config.h output.

[dstebila]

Yes, although when we implement this we should make use of include/oqs/oqsconfig.h, rather than the config.h output by autoconf directly. (Using a config.h from one autoconf output in another project can lead to weird things happening. oqsconfig.h is a filtered version of the autoconfig config.h with just the OQS-specific stuff kept.)

[baentsch]

@dstebila When looking at how to resolve this issue I wondered whether this is entirely an OpenSSL/H issue: For example, shouldn't OQS_KEM_alg_identifier (implemented in liboqs/src/kem/kem.c) also properly #ifdef the algorithm families? Example: Disabling Frodo in liboqs has it still report Frodo (as active) inOQS_KEM_alg_identifier (also btw causing a CI failure in tests/example_kem.c) and in consequence cause an error when running openssl speed (which uses this list to determine which algorithms are actually supported by a specific liboqs library build).

--> Would it be sensible to also create a liboqs issue for this? Or should openssl create its own lists of supported OQS algorithms exclusively based on oqsconfig.h #defines?

[dstebila]

All algorithms are listed in OQS_KEM_alg_identifier. OQS_KEM_alg_is_enabled indicates whether they are enabled are not, which is based on compile-time #ifdef's.

[baentsch]

Another question on this topic: Am I assuming correct that we would not want (to make) users run oqs-template/generate.py (and consequently make generate_crypto_objects) after disabling some algorithms in liboqs?

If so, this would mean that all tests and all NIDs remain as-is (checked in) in oqs-openssl. This in turn will mean that the tests checking disabled algorithms will fail as I don't know a (straightforward) way to check from within Python which C-defines are (not) set on a library openssl depends on (i.e., liboqs) before triggering client&server processes that are bound to fail due to algorithm absence... Of course, we could set out to parse oqsconfig.h from within oqs_test/tests/test_openssl.py to eliminate disabled algorithms -- but would want to do that?

Beyond testing, in general, I guess my question is this: How shall the behaviour of oqs-openssl change --beyond what it currently does, i.e., fail, always outputting the name of the "curve" requested-- if some liboqs-provided algorithms are disabled and someone triggers their use?

The only place I found in openssl where we can test-and-disable liboqs algs (automatically) prior to their use is in speed testing. But the moment someone explicitly requests an openssl operation using a 'curve'/liboqs algorithm not provided, failure is inevitable (and, again, output already). We could do some more code to distinguish between completely bogus algorithm names and "only" disabled algorithms, e.g., in the "curves setting" functions. But is that what you had in mind with this issue?

If, on the other hand, we demand running the generator scripts after disabling some liboqs algs, much more is reasonably doable (changing NID tables, changing tests)...

[dstebila]

Another question on this topic: Am I assuming correct that we would not want (to make) users run oqs-template/generate.py (and consequently make generate_crypto_objects) after disabling some algorithms in liboqs?

Correct. I would have hoped that there is enough information from liboqs's .h files available to OQS-OpenSSL at compile-time to carry out this goal.

If so, this would mean that all tests and all NIDs remain as-is (checked in) in oqs-openssl. This in turn will mean that the tests checking disabled algorithms will fail as I don't know a (straightforward) way to check from within Python which C-defines are (not) set on a library openssl depends on (i.e., liboqs) before triggering client&server processes that are bound to fail due to algorithm absence... Of course, we could set out to parse oqsconfig.h from within oqs_test/tests/test_openssl.py to eliminate disabled algorithms -- but would want to do that?

That's a very good point, one that I hadn't thought of.

No one has asked for this, it was just something I thought we should do if we could. Perhaps it is best to leave as it is now, and if we hear of a scenario where people are disabling algorithms in liboqs and then trying to use in OQS-OpenSSL and encounter difficulties, we can revisit.

Edited to add: In some sense, I don't have much insight into the use-case of disabling algorithms even in liboqs. I'm guessing someone might want to do it to produce a stripped-down library, with only their desired algorithm, for use in a constrained environment. But I haven't heard of any such uses, so that is also hypothetical to me.

[baentsch]

Edited to add: In some sense, I don't have much insight into the use-case of disabling algorithms even in liboqs. I'm guessing someone might want to do it to produce a stripped-down library, with only their desired algorithm, for use in a constrained environment. But I haven't heard of any such uses, so that is also hypothetical to me.

I did that a couple of times -- but so far also only to see what size-savings result (they are significant), not because of hard requirement.

So I'll do a 'simplified' PR addressing this to some degree (warning of disablement, clearly indicating inspeed what algorithms are actually supported): That way one can see at runtime which liboqs has been built into a given oqs-openssl.