Algorithm enablement
baentsch opened this issue · 5 comments
Following up on #1245 (comment) this is to propose implementing a cmake build option labelled "OQS_ALGS_ENABLED" with the following possible values and effects:
- STD: Enabling Kyber512,768,1024 (no 90s), Dilithium2,3,5 (no AES), SPHINCS+ (not robust), Falcon
- NIST_R4: Enabling All algs explicitly listed for round 4 of the NIST competition
- EXPERIMENTAL: Enabling all algs not removed from liboqs; this would also activate for example Dilithium5AES or "robust" SPHINCS+ (and possibly NTRUPrime algs along the lines of this discussion).
Proposed default value: "STD" (also to be activated if "OQS_ALGS_ENABLED" is not explicitly set).
Comments/alternative proposals welcome before implementing as described.
I agree with the categories you propose. Since some algs in the EXPERIMENTAL bucket might not be "experimental" but simply non-NIST (e.g., Frodo selected by BSI, OpenSSH's ntru), then we could perhaps rename it: ALL.
then we could perhaps rename it: ALL
Completely agreed. So also reads the comment in the new code :-)
Open question remaining: What alg names shall be on the list of NIST_R4?
Open question remaining: What alg names shall be on the list of NIST_R4?
NIST_R4 would for now be BIKE, HQC, and Classic McEliece. Once there have been submissions to the additional call for signatures, we could add to that or create a separate flag for that.
In terms of dealing with the downstream build problems that came when I prematurely merged #1333, what about changing it so that that the default is ALL, so that all the downstream tests will see an unchanged list of algorithms. Expert users can use the added liboqs CMake option to build a subset of the algorithms. At this point in time they'd also need to regenerate code in the downstream projects if they wanted to build against that subset of algorithms, but perhaps someday we'd find the time to do something smoother.