OQS Provider Wish List

[ashman-p]

1. Refactor code to support easy enabling/disabling of features.
   At the moment, the code is organized around a number of #ifdef statements (dependent on the value of OQSX_KEY_TYPE and the OpenSSL version). Refactoring the code by moving code for specific operations, .e.g. hybrid signatures, to dedicated files. Additionally, the Jinja2 templates which need to be modified when adding new features would benefit greatly from a reformat.

2. Add documentation.
   Existing documentation around the OpenSSL provider mechanism and its entry points is enough to support a developer experienced with working on OpenSSL, but the inexperienced developer may find it hard to use. Adding an OpenSSL provider/oqs-provider Guide (in the vein of https://github.com/pq-code-package/mlkem-native/blob/main/proofs/cbmc/proof_guide.md) would do a lot to reduce the barrier to entry for new contributors.

3. Algorithm-agnostic provider.
   oqs-provider was initially designed to be an algorithm-agnostic provider, but as APIs for standardized algorithms begin to diverge (e.g. NIST has communicated that FN-DSA will not support seed format keys), we must determine if this is a design principle we want to change. If not, we must determine how to provide seed support for some algorithms and not others while maintaining an algorithm-agnostic provider.

4. Seed support.
   oqs-provider does not support seeds at the moment, and points 1, 2, and 3 have been a barrier to fixing this. While points 1, 2, and 4 can be worked on in parallel, an organized roadmap would make things easier.

5. CI reorganization.
   oqs-provider would benefit from a better-organized, more modular CI framework like in liboqs.

6. Removing legacy features.
   OpenSSL developers have alluded to oqs-provider using older/non-standard OpenSSL features during in-person interactions. Determining the extent of this issue and actively communicating with OpenSSL developers via OpenSSL communities (https://openssl-communities.org/hub-committers/) would be helpful.

7. Enable ML-KEM/DSA in OpenSSL 3.5.
   Even though OpenSSL has native support for these algorithms, it would be beneficial to have alternative implementations via OQS.

8. Support SLH-DSA support.
   Same as 7.

[ashman-p]

@baentsch, do you mind posting you comments here?

[baentsch]

@baentsch, do you mind posting you comments here?

Thanks for moving this wish list away from emails and discussing it in the open @ashman-p. My offer to have a focused meeting to discuss this still stands -- I wish you'd take it up to allow us to move this forward more efficiently: I've got many questions on what you want to achieve (and how) and typing away several times (first in email, now here) costs me a lot of time I'd rather spend developing code and maintaining the project.

Let me respond to each issue separately such as to also have the discussion stay focused on each. A more focused approach surely would be to have separate discussion topics/issues (which on most topics above we already have -- but where no input has been forth coming). I'll also add a separate section asking general questions informing how to resolve this wish list.

[baentsch]

One more thought: Are you going to be present at the OpenSSL conference @ashman-p or also only present remotely? I'll be there and fine with setting some time aside to discuss. Also, it'd be nice to meet in person for the first time. It'd further be a good opportunity to also invite the above mentioned OpenSSL developers, assuming they'll also be present (?) and discuss the "older/non-standard OpenSSL features " mentioned.

[ashman-p]

One more thought: Are you going to be present at the OpenSSL conference @ashman-p or also only present remotely? I'll be there and fine with setting some time aside to discuss. Also, it'd be nice to meet in person for the first time. It'd further be a good opportunity to also invite the above mentioned OpenSSL developers, assuming they'll also be present (?) and discuss the "older/non-standard OpenSSL features " mentioned.

@baentsch This sounds great. I plan to be at the conference, and it will be good meeting in person.
We should also see who else in attendance could make such a meeting. Perhaps at the next OQS status call?

[baentsch]

Yes; I wanted to broach this in the last call, but attendance was "shallow", so by all means, @ashman-p please ask around at the next call (for me, the next, 10amEST, slot generally doesn't work so well). Please also reach out to all OpenSSL developers you refer-to above; in general, please also point anyone with any interest in the project to this discussion -- will also help to gauge true interest in it.

[baentsch]

Oh, and please don't hesitate to already now post feedback to my comments below or in the relevant issues to get a discussion going so we have a good basis for the in-person meeting or we lose another month: The thought for the re-factor was stated in #375 more than 15 months ago and it was again mentioned in my absence several months ago (even holding back a new contributor's PR then): Isn't it "about time" to discuss this in concrete terms -- and, again, see whether there is sufficient interest in the project to boot? We all could do other things and arguably should best focus on things that truly matter to others.

[t-j-h]

Enable ML-KEM/DSA in OpenSSL 8.5.

Perhaps OpenSSL 3.5 is what is meant there - 8.5 is still a long way off :-)

[baentsch]

Refactor code to support easy enabling/disabling of features.
At the moment, the code is organized around a number of #ifdef statements (dependent on the value of OQSX_KEY_TYPE and the OpenSSL version). Refactoring the code by moving code for specific operations, .e.g. hybrid signatures, to dedicated files. Additionally, the Jinja2 templates which need to be modified when adding new features would benefit greatly from a reformat.

This already is possible using C macros. This mechanism is being used as it is the basis for a lot of the OpenSSL provider "boiler plate" code. Please provide a suggestion for an alternative mechanism and state how to deal with the boilerplate code in that proposal, e.g., complete re-write of that (? IMO that'd require a lot of effort). A re-factor to minimize the amount of jinja2 templates (or the complete removal of those) would be sensible. PR would be welcome -- A first indeed may be the separation-out of all hybrid code (part of which is already done courtesy @bhess for KEMs: Please state what you have in mind for KEM hybrids beyond what has already been done; SIG hybrids should be easier to do now that you have removed composite signature support). My personal proposal would be to consider the development of a separate provider only doing hybrids: That'd be much cleaner and permit use of industry-grade ML-KEM/ML-DSA implementations also made available via the OpenSSL APIs and not just the libOQS APIs.

[baentsch]

Add documentation.
Existing documentation around the OpenSSL provider mechanism and its entry points is enough to support a developer experienced with working on OpenSSL, but the inexperienced developer may find it hard to use. Adding an OpenSSL provider/oqs-provider Guide (in the vein of https://github.com/pq-code-package/mlkem-native/blob/main/proofs/cbmc/proof_guide.md) would do a lot to reduce the barrier to entry for new contributors.

More documentation is always good. In this particular case, though, I'd like to state from experience that writing an OpenSSL provider without some insight on how OpenSSL uses a provider, i.e., knowledge of OpenSSL documentation (and best, also its source code) is hard-to-impossible.

A second risk with the approach you are suggesting is that contributors may rely on a documentation that can get outdated pretty quickly as OpenSSL evolves. To counter that, a person would need to stay abreast of what OpenSSL does and always update the documentation you suggest and make possible new contributors aware of that. In my eyes this generates more "management overhead" than it helps new contributors to join the project. But again, if you are willing to put up this effort/provide a PR, give it a try (and caveat emptor: The OpenSSL documentation may also be lacking details that only (knowledge of) its code reveals).

[baentsch]

Algorithm-agnostic provider.
oqs-provider was initially designed to be an algorithm-agnostic provider, but as APIs for standardized algorithms begin to diverge (e.g. NIST has communicated that FN-DSA will not support seed format keys), we must determine if this is a design principle we want to change. If not, we must determine how to provide seed support for some algorithms and not others while maintaining an algorithm-agnostic provider.

There is a discussion already covering this: #625. Please consider contributing there.

In a nutshell, my goal when writing oqs-provider was the creation of a provider integrating all PQ algorithms that liboqs may ever provide -- without any special code for special algorithms such as to retain its value allowing researchers to test their (new) PQ algorithms in a real-world application environment such as OpenSSLs.

Any algorithm-specific provider code in turn should be just there: In a separate, algorithm-specific provider. This also would permit many more algorithm-specific optimizations -- and this actually is exactly the way it is done in industry-grade code, such as the OpenSSL providers: Each algorithm has its separate, optimized back-end, making the code more secure and resilient than a "catch-all" provider can ever be.

In sum, changing this principle would end of the key value oqs-provider delivers.

[ashman-p]

@baentsch, With regards to the OQS provider being algorithm agnostic, I concluded that without a change, we would not be able to accommodate features like derived key generation, external Mu, hash ML-DSA, and others that may eventually gain favor or are added.
If I understand correctly, your position is that enhancements to include support for these examples would invalidate the OQS Provider's original intent and also have no research nor experimental value?

[baentsch]

Seed support.
oqs-provider does not support seeds at the moment, and points 1, 2, and 3 have been a barrier to fixing this. While points 1, 2, and 4 can be worked on in parallel, an organized roadmap would make things easier.

This is being discussed in #675. Please consider contributing there. We could try something similar for seeds as has been tried with adding composite support -- but you have removed this code in my absence -- and I think for good reason: It didn't fit with the clean, algorithm-agnostic design of oqs-provider.

[ashman-p]

--- but you have removed this code in my absence
@baentsch, Just to clear, this was a group decision and not an individual action.

I will add comments to #675.

[baentsch]

@baentsch, Just to clear, this was a group decision and not an individual action.

I didn't say or assume anything to the contrary.

I will add comments to #675.

When do you expect to do this @ashman-p ? This discussion drags on since 6 weeks and #675 now also went nearly 6 months without any input from your side.

[baentsch]

CI reorganization.
oqs-provider would benefit from a better-organized, more modular CI framework like in liboqs.

This is a true statement. Please provide concrete proposals for improvement and/or even PRs.

[baentsch]

Removing legacy features.
OpenSSL developers have alluded to oqs-provider using older/non-standard OpenSSL features during in-person interactions. Determining the extent of this issue and actively communicating with OpenSSL developers via OpenSSL communities (https://openssl-communities.org/hub-committers/) would be helpful.

What features are we talking about here? This sounds like "hear-say": Please provide concrete cases where this is at play (ideally pointing to GH issues elsewhere and/or pulling in the OpenSSL developers you are referring-to above). I'm particularly intrigued which "non-standard OpenSSL features" oqs-provider is using (or even, what this is :).

If you refer with this to OpenSSL features available in versions below 3.6/master (?) then please be aware that many distributions are not yet at that level. Another design principle of oqs-provider was to cater for all OpenSSL versions >= 3.0. Doing away with that principle would massively hurt the utility of oqs-provider as a PQ provider in older OpenSSL installations. Arguably, with the advent of all standard PQ in OpenSSL3.5, the ability to run oqs-provider in OpenSSL <3.5 is its primary benefit for OpenSSL users.

Finally, the community you mention above is the OpenSSL committers community -- I'm pretty sure that community is the least-interested one as OQS code can --for licensing reasons-- never be up-streamed to OpenSSL and thus, never become a topic for OpenSSL committers. The General community may be a better fit -- but again: What should be clearly documented is the benefit oqs-provider might have for any OpenSSL community you may want to involve.

[baentsch]

Enable ML-KEM/DSA in OpenSSL 8.5.
Even though OpenSSL has native support for these algorithms, it would be beneficial to have alternative implementations via OQS.

Assuming you mean OpenSSL 3.5 (and later), this is already being discussed in #667. Please consider contributing there.

[baentsch]

Support SLH-DSA support.
Same as 7.

This is your very own issue #331, no? Why not keep discussing there?

In my eyes, there was much more utility for this in 2023/2024 when you opened this issue, but time has moved on, so my key question is: What is this meant to achieve beyond what OpenSSL by now already provides? A clear statement of goals imo would be sensible -- just doing things that others have already done doesn't seem wise when there is a dearth of contributors already.

[baentsch]

General questions:

• What features (incl. non-functional ones) should oqs-provider have -- particularly in comparison to what OpenSSL has?
• What additional value should it bring?
• Who shall benefit from this?
• Who shall work on this?

Particularly an answer to the last question is imo most urgent: I've been absent for half a year and I now see a project with markedly fewer contributions than before (and two key persons doing actual code, Spencer and Pravek, have left for good), a reduction in feature-set (composites are gone), and hardly any maintenance (beyond doing releases or running pre-existing scripts): Many issues and discussions have not moved forward -- and I think a lack of interest and/or participation is the key reason for this -- making a re-design quite possibly a pipe-dream. But again, I may be wrong and there's people itching to do this -- for those, answers to the first 3 questions above will be essential to succeed. I had answered them for me when doing the code initially -- but time has moved on, so new answers would be very valuable, indeed.

[ashman-p]

• What features (incl. non-functional ones) should oqs-provider have -- particularly in comparison to what OpenSSL has?
  If this question relates to the operational state of features present in OpenSSL... My opinion is that there is value to having the OQS implementations available.

• What additional value should it bring?
  Enhancing access to as many features as possible in libOQS.

• Who shall benefit from this?
  As always, the entire community.

• Who shall work on this?
  As always, whomever has interest and desire. The purpose of these discussions is to arrive at consensus on mission fit, feasibility, and design/approach.

[baentsch]

If this question relates to the operational state of features present in OpenSSL... My opinion is that there is value to having the OQS implementations available.

Two comments on that one: 1) Can you please specify that value? 2) Are you aware of how much work this entails? And: Is it really worth spending that just to get functionally to par with many other PQC implementations, incl. those already in OpenSSL?

I personally have a hard time seeing value in re-doing things that already exist -- btw and imo in a more standards-compliant manner and with much more reliable code than what OQS can conceptually ever muster given its mission. To me, this sounds like chasing a panacea, draining time and resources from delivering what originally was the goal of this project, namely to push the state of the art integrating new PQC further: again, new algorithms, not regurgitating things already done and dealt with (as far as oqsprovider is concerned, in the OpenSSL world).

Enhancing access to as many features as possible in libOQS.

This is an answer with what seems to be a myopic view on OQS. My original question (and perspective) is meant to include a wider view as to include all PQC FOSS, particularly OpenSSL (this project is an OpenSSL provider after all -- meant to extend OpenSSL, not re-do things already there).

Again, wouldn't it be a much more worthwhile goal to rather prioritize OQS to include more and new PQC algorithms, not just to add more "features" to existing, particularly already standardized and readily available algorithms?

Who shall benefit from this?
As always, the entire community.

Again, without statement what you mean by "community", this statement can mean all or nothing. What I mean by "community" is all people interested in evaluating the value of new PQC algorithms in the OpenSSL ecosystem. Can you please spell out who you mean?

Who shall work on this?
As always, whomever has interest and desire. The purpose of these discussions is to arrive at consensus on mission fit, feasibility, and design/approach.

That's extremely vague and non-committal. Interest and desire are pretty fickle. May I place a bet: Without someone stating "I'll commit to doing xyz" that xyz won't come together by any concrete date under a "work commitment" phrased like the above?

Regarding mission, I'm afraid there's a wide gulf between what I see as the mission and what you do. Let me phrase mine:

oqsprovider is meant to make accessible to the OpenSSL ecosystem novel research PQC algorithms such as to enable real-world experimentation with these.

The word "novel" implicitly excludes algorithms already standardized.

Can you please add your mission proposal @ashman-p ?

[baentsch]

@2ashman-p ping... Do you have any time to provide further input? Or could point to the people that could, e.g. regarding the OpenSSL legacy features?

[baentsch]

Oops correct address is @ashman-p of course...

[tomato42]

Derivation of the public key when provided just the private key (#637) would be quite useful, as standard file formats (PKCS#8) don't need to include the public key but it's generally expected that operations like that are supported (e.g. when creating a CSR)

[ashman-p]

I believe this topic should be postponed. The objective was to share the list and discuss whether these items were desirable and feasible. However, it appears unlikely that we will reach a consensus. I am open to continuing this discussion if others find value in it.

While not the primary focus of the project, I considered some items as ‘easy’ issues that could benefit non-research members of the community.

As it stands, I would like to postpone the discussion.

Thanks.

[dstebila]

I don't think we have to have consensus on the priority of every item in the wishlist. Different features can be important to different groups. I think it would be problematic if different features were pulling in substantially different or contradictory directions.

I also don't think it's necessary to have -- at the level of a wishlist -- a clear plan for how to implement a feature or who's going to do it. In particular, responding to Michael's comment above, "who shall work on this" should not in my opinion be a blocking question for a brainstorm / wishlist.

The original idea of the feature wish list is to brainstorm things that people are interested in, and list that publicly so that people interested in contributing have some ideas of things at least some members of the community would be interested in seeing.

[baentsch]

The original idea of the feature wish list is to brainstorm things that people are interested in, and list that publicly so that people interested in contributing have some ideas of things at least some members of the community would be interested in seeing

Very well, then I apologize for taking the original ask too verbatim "do you mind posting you comments here".

My more simple answer could have been: "OK, please create new GH issues for discussion out of wish list item 1, 2, 5, 6 and 8. Please comment in #625 as that already covers item 3, GH issue #675 as that already covers item 4, GH issue #667 as that already covers item 7."

I would have then posted my concrete comments in the new GH issues allowing the brainstorming on them to proceed in a bit more focused manner. And one of them definitely is that I whole-heartedly agree and see a clear and present risk of

it would be problematic if different features were pulling in substantially different or contradictory directions

and items 4, 7, 8 diverting/distracting from the original goals of oqsprovider.

I also don't think it's necessary to have -- at the level of a wishlist -- a clear plan for how to implement a feature or who's going to do it.

Very well, I can agree to this, too -- I may simply be driven too much by thinking how something can practically be achieved. Mea culpa.

If not hearing statements to the opposite, I will create separate issues as proposed above, put the discussion comments on those there and create a separate Wiki listing all GH links along the same lines as https://github.com/open-quantum-safe/liboqs/wiki/Contribution-wishlist.

[RodriM11]

I believe the current logic of signatures in the provider could benefit from a number of updates that would increase the features available. Most notably, I would mention:

1. implement {sign|verify} message signature functionality #718 regarding the inclusion of a message interface and how to do so.
2. Enforce the use of context strings only for PQC algorithms that actually support it? #723 To only employ OQS_SIG_sign_with_ctx_str and the verify analogue for PQ schemes that actually do support it.
3. Enforce the use of context strings only for PQC algorithms that actually support it? #723 bis -> To supply the context string also to classical signatures in hybrid procedures, as there are algorithms that may support it (i.e. Ed25519, Ed448)