Handling future oqs-provider releases

[praveksharma]

Once openquantumsafe/liboqs#1745 is merged liboqs will provide additional formally verified implementations which can be enabled for certain platforms (x86 on Linux/Darwin); these implementations are pulled from libjade. How should oqs-provider handle future releases once liboqs provides formally verified implementations:

1. Multiple releases with verified and non-verified implementations?
2. Default to formally verified implementations as soon as they are available?
3. Default to formally verified implementations once libjade has more complete algorithm coverage? Right now, libjade only provides Kyber512 and Kyber768. If we go this route, what level of algorithm coverage will we need?
4. Something else?

[baentsch]

Thanks for starting this discussion. My take on these options:

1. Creates more build/support obligations I'm not willing to take on. Non-starter in my eyes until there are more active maintainers.
2. Makes most sense
3. Don't see a difference to 2: "The more the merrier" I'd say, as everything is fully automated: The more libjade code becomes available, it'd be fully automatically imported.
4. Sure: Make available a separate provider only containing formally verified algorithms. This reduces the attack/vulnerability surface of such provider (to not include --even traces of-- "experimental" liboqs code). Such provider would only work on the platforms supported by libjade. But the same thought as on proposal option 1: I'm not willing to shoulder this additional work that would "only" benefit productive use for which there seems to be no serious appetite/interest/commitment by the community.

[praveksharma]

I'm okay with option 2 if you are. Would I be correct in assuming that with automation the release process for options 1 and 4 could be made nearly as person-hour efficient as it would be for option 2? Of course, the work to set up the automation would need to be done.

[baentsch]

the work to set up the automation would need to be done.

That's the key issue. Who'd do that? And regarding option 2: That still needs implementing if I'm not mistaken (at the very least set OQS_LIBJADE_BUILD for oqs-provider builds; better of course would be a test that ascertains that code to be running -- though I have no idea how to facilitate that).

[praveksharma]

Thank you for reminder @baentsch. I've created issues #517 and #518 to track these and assigned them to myself.