Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Algorithm enablement #1331

Closed
baentsch opened this issue Dec 13, 2022 · 5 comments · Fixed by #1333 or #1355
Closed

Algorithm enablement #1331

baentsch opened this issue Dec 13, 2022 · 5 comments · Fixed by #1333 or #1355
Assignees

Comments

@baentsch
Copy link
Member

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.

@christianpaquin
Copy link
Contributor

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.

@baentsch
Copy link
Member Author

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?

@baentsch baentsch self-assigned this Dec 13, 2022
@dstebila
Copy link
Member

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.

@dstebila
Copy link
Member

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.

@baentsch
Copy link
Member Author

changing it so that that the default is ALL

So changed in #1355

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
3 participants