Disable support for standardized algorithms

[baentsch]

Triggered by #609 this is to discuss whether oqsprovider should keep supporting standardized algorithms as and when they are available in built-in providers of openssl.

The code driving oqsprovider does not have the same quality and reliability as the code in openssl and therefore, oqsprovider should not make available algorithms when more reliable implementations are available.

Further, the goal of oqsprovider is to support prototyping and experimentation of novel PQC (e.g. in the NIST competition or other, not-yet standardized use cases), not do the same as standard PQC code.

[baentsch]

#613 provides another argument for dropping support for standardized algorithms:

the IETF LAMPS consensus is that private keys of all three of the NIST algorithms should be stored as seeds

Thus, their use now starts to deviate substantially from what NIST specified and what is still being used as key formats in the other/ongoing NIST competition that oqsprovider want to support, so bespoke code would have to be added for those algorithms. And that'd be pretty much lost work given that exactly these algorithms are bound to be available in openssl anyway.

[dstebila]

We talked in a previous meeting about continuing to support standardized algorithms where we have implementations with distinctive characteristics.

[levitte]

This makes perfect sense, and as long as those characteristics don't become concrete clashes, it will most probably not disturb most users. Those who want implementation specific characteristics will simply have to provide a property query string that facilitates that selection.

[baentsch]

Once we get the naming aligned, I agree, users should not be disturbed. I'm more concerned that people will think that they only get "something better" opting for an implementation with a "distinct characteristic" while in reality they are getting something different: For example, I'm positively impressed by the level of code diligence, "vertical integration" thinking and interop testing at OpenSSL that is not present in OQS. "Distinctive Characteristics" definitely goes both ways...

In my opinion, if oqsprovider keeps supporting standardized algorithms, OpenSSL and OQS should jointly agree how things are phrased as to what it means for users when switching propq: Simple things like where to ask questions and which platforms being supported; but also more complex ones, like which specific guarantees/tests, e.g., in the space of constant time properties, are (still/not) available when switching implementations or what level of interoperability is (not) guaranteed in either setting.

And there must be (more) people willing to contribute to OQS (surely, provider: The code is in dire need of refactoring --to put it mildly :) if it were to deliver PQ algs with distinctive characteristics. And that I don't see (happening). Primarily because of that and in my personal opinion, OQS would be serving the community much better if it were focusing on what it did well before: Support completely new research algorithms in the "real world". Standard algorithm implementations with distinctive characteristics could very well prove their value via PRs to openssl master (or openssh, or whatever). Or are you considering opening an AppStore, err, ProviderStore, @levitte? :)

[levitte]

I am not personally considering a store, no. However, I've always thought that an ecosystem of providers could be a thing, just like with most pluggable systems.

What the users choose is up to them. "something better" is, in the end, their judgement, and what we as provider authors can do best is to document it's characteristics, allowing the users to make an informed judgement and choice. In the course of working on OpenSSL, I repeated "know your provider" so much it may have become a mantra...

As for conversations between provider authors to try to align the things their providers have in common, I completely agree that they should happen. I was thinking that such conversations were part of participating in that ecosystem.

[baentsch]

Conceptually I agree with the notion that users should decide (what's best for them).

The thing is, there's users and users: The former are the direct integrators, companies like IBM/RedHat or Cisco. The latter are end users, say your mom.

The former are able to make a judgement call, the latter are not. And even the former are unlikely to know the provider they use when they don't regularly and actively contribute to it.

That (low level of contribution) is one reason why I keep arguing for documenting oqsprovider as something that should not be used productively. Support for standardized algorithms runs counter to such disclaimers as standards are expected to be used productively, so if you claim support for a standard you implicitly agree with productive use, right?

That line of thought actually makes me think for a solution to this quandary and your wish to drop the research disclaimer, @dstebila @ashman-p : What about the idea to consider dropping it when there's at least 3 constantly active ("committed") contributors to oqsprovider from different companies that actually use the software stack in production? That'd be a significant improvement over the current 0 (and I apologize for not considering "committed" anyone just not very active by way of problem-solving PRs but nevertheless interested or adding new features; My gauge in this context is GH contribution activity enhancing code reliability).

Coming back to your "judgement call" thought @levitte, I'm further concerned that companies' judgement calls can be driven by commercial considerations ("I need something now, don't want to spend time doing reliable code or don't have developers to do that, so just use some FOSS provider. I'll protect myself by stating it's the FOSS community's responsibility to deal with problems and security weaknesses.") and not those of the people doing the work in those communities. That might be OK if the community is paid to do that and has committed people -- but it's absolutely not OK for a community of non-committed, not commercially incentivized people mostly interested in furthering the "state of the art" (aka, researchers).

In sum, it seems really beneficial to switch off default support for standardized algorithms: Companies willing to use the code can still toggle this default setup in their integration, can decide to contribute to improve OQS(provider) with active work such as to make the code reliable and the team comfortable also toggling the default back (making standardized algs available by default again) -- as then, they'll be around to help bear the responsibility/work load for the code.

[levitte]

... And even the former [integrators] are unlikely to know the provider they use when they don't regularly and actively contribute to it.

That sounds extreme... I was thinking more at a level of having good enough documentation to read on the provider in question, and understanding how to use it for what purpose they have.

And BTW, this goes for any user that uses the provider "directly", be it an integrator or your aunt; it does require a sufficient level of knowledge and understanding, which again, comes back to documentation of the provider.

Regarding those that don't have sufficient technical knowledge (my mom, or your aunt?), I don't expect them to deal directly with providers; I hope that someone will make good enough higher level tools that does the right thing, and makes the right choices. This really isn't a unique problem of OpenSSL or any provider...

But all of that nonwithstanding, I hear what you say regarding the risk of researchers being unfairly exploited. That is certainly a concern, and I can fully understand that as an incentive to want to disable standard algorithms when they get supported by other orgs with better financial backing. I hadn't caught on to that concern.

[baentsch]

again, comes back to documentation of the provider.

Fully agreed. I do think oqsprovider is suitably documented -- if there's things missing in your view, please, by all means let me know.

I hope that someone will make good enough higher level tools that does the right thing, and makes the right choices. This really isn't a unique problem of OpenSSL or any provider...

Completely agree again. This is FOSS and anyone has to make the right choices when using it. All I want is assure no-one makes them without as much information as is available; No appearances should be created that are not backed by facts or reality (am I really saying this on the Inauguration day of President Trump? :}

[mouse07410]

IMHO, the current situation is screwed up - OpenSSL merged a commit that prevents other providers from registering ML-KEM and ML-DSA, but takes its sweet time merging the implementation.

The correct solution IMHO would be for OpenSSL to back out (revert) the OIDs-registering commit until the time that OpenSSL provider is ready and included in the build.

[levitte]

OpenSSL merged a commit that prevents other providers from registering ML-KEM and ML-DSA

Wait, what? Oh, the OID registry? How does that prevent anyone?

[baentsch]

See discussion here: #623 (edit/add: and re-design proposal here: #625)

[catharsis71]

I hope you will continue support for X25519MLKEM768 for a while

Compiling the provider & library is not a big deal but the prospect of entirely replacing my OpenSSL with a self-compiled version just to get MLKEM support is much more intimidating

(I'm holding out hope that Ubuntu 26 might end up with a version of OpenSSL that supports MLKEM but that's a long way out)

[baentsch]

I hope you will continue support for X25519MLKEM768 for a while

Don't see a problem with that (yet :) so will do my best. But here's another proposal that might alleviate your concern in a better way: openssl/openssl#26649.

[ashman-p]

A couple of questions on the wide ranging topics...

1. OQSProvider dropping support for standardized algorithm (because they are included in OpenSSL) ... is the idea that liboqs would also follow suit?
2. If said algorithms remained present in liboqs how would they be consumed in similar a manner as they are today?
3. On the topic collisions between providers registering the same OIDs... is there a design plan to account for that?
4. As the OQS code base matures it is possible that some components of the library could be seen as mature. I am hopeful that we will get to consensus on what that looks like and how to arrive there.

My hope would be that OQSProvider maintains support for algorithms even if they are implemented in OpenSSL.

[levitte]

Having said that, I'm of course getting interested in playing with liboqs directly. 😉

[ashman-p]

Not sure I understand why liboqs would have to remove anything. It's a separate library, isn't it? Are there no other consumers, or could there not be other consumers? Why should they suddenly be deprived of algorithm implementations?

Thanks for the response @levitte . Similarly, since OQSProvider is the most visible (if not, the only) only open source component that allows easy integration with OpenSSL, shouldn't it stay intact?
While the team is very small currently, but, that may change over time. So, hang in there, see what happens down the road 😃.

[baentsch]

Having said that, I'm of course getting interested in playing with liboqs directly.

Any help would be very welcome indeed: PQCA in my view introduced a significant discrepancy between demands by LinuxFoundation/corporate folks and (what I perceive as a dearth of) actual, problem-solving contributions: This really is the key reason for this discussion item: the need to prioritize/focus in the absence of more real contributions (allowing me to keep (at least some :) sanity).

@ashman-p the one impact a decision to keep supporting PQC standard algs in oqsprovider would have on liboqs would be the need to adapt it to the breadth of key representations (see e.g. open-quantum-safe/liboqs#2032) as oqsprovider is completely dependent on what liboqs offers; otherwise, I agree with all questions asked by @levitte above pertaining to your question 1.

The answers to questions 2 and 3 are contained in #625. I explicitly mentioned this in an OQS meeting. No feedback/input there after 3 weeks from the PQCA/OQS community seems indicative of a lack of interest (or time/willingness/ability to help) on oqsprovider, though (or of agreement with my course of action :).

Item 4 is not really a question but two statements - so allow me to comment on each:

As the OQS code base matures it is possible that some components of the library could be seen as mature.

The term "matures" makes me wonder: What do you understand by this @ashman-p ? Some measurable level of software strength? If so which? Or just the passage of time? Or the introduction of some "control processes"?

And even if assuming the former, i.e., some real, measurable strength, I think I cannot agree with the statement: The strength of a security software stack like OQS should be measured/defined by its weakest component, not by the mere presence of "some" components "seen" as "mature" (quotation marks to indicate need for more clarity on those terms). Here's a concrete approach that would allow such measurement: open-quantum-safe/tsc#137.

I am hopeful that we will get to consensus on what that looks like and how to arrive there.

That would be great. I am hopeful in turn that this consensus will be worked towards openly, e.g., via continued discussion on PQCA/TAC#44 and not via one-on-one or "closed bubble" conversations concluded again by another PQCA-corporate-majority-result-guaranteed "vote" possibly not fully taking into consideration the concerns of end users, contributors and maintainers.

[ashman-p]

Thanks @baentsch. On the last point... Maturity to me means that the component has been developed to

• meet requirements
• have the correct implementation
• have a development process
• acceptance
• etc
  But i want the team to build what it is.
  By seeking consensus, i mean that in the broadest sense possible and i intent make this a public discussion. Reaching out in the meetings that we already attend and to you and Douglas is my attempt to gain traction (I see no point in presenting an approach if you guys are not even slightly supportive).

I am not proposing that we carte blanche remove the experimentation tag from OQS. Instead the proposal is that we devise a policy with which we can use to designate some algorithms in OQS as "mature". And those would be fit for safe use in products with the usual caveats. We could then have build flags to build only those components and exclude the experimental components. But this, i think is a discussion for the other thread.

On your other points... I do get your frustration regarding timeliness and participation.

[baentsch]

Thanks for the direct meeting and effective conversation @ashman-p @dstebila . To recap/put in writing for everyone who did not attend:

• The discussion is not just about conditions for declaring "some" algorithms "mature" (each term in quotation marks requiring definition) but on all code components required to run them
• The exact "thing" (components) to be declared "production ready" need a precise delineation/boundary
• The responsibility to bring these "things" to "production ready" state and maintain them there must be borne by a new/incremental set of people with reasonable long-term commitment to maintain this state, too and cannot be expected to be done by the current OQS core team.

Looking forward to your proposal to make things more concrete along those lines, @ashman-p .

[mouse07410]

Here's my take.

• OpenSSL-3.4.x can use ML-KEM from oqsprovider.
• Right now, OpenSSL-3.5.0-dev has no (usable) ML-KEM at all.

When OpenSSL-3.5.0(-dev) gets its ml-kem branch fully operational and merged - it would be fine by me if oqsprovider stopped offering ML-KEM algorithm. Until then, I think the maintainers made a bad decision to merge just enough of ML-KEM (I don't really care to dive into the details of exactly what they merged - it's irrelevant) to stop oqsprovider from supplying ML-KEM.

IMHO:

• what OpenSSL should do: merge everything ML-KEM-related only when ml-kem branch containing the actual impelmentation is ready foр merging, not peace-meal style. Perhaps, best to back out the current changes and move them to ml-kem branch?
• what oqsprovider should do: stop supporting/including ML-KEM (for OpenSSL-3.5.+ only! not for 3.4!) after OpenSSL finishes merging ml-kem.

I know it's easy to tell others what they should do (especially when they work for free) - sorry about that.
But since I cannot just fix this myself (without probably breaking things I don't really want broken), I have to leave it to you and suffer from apparently-bad decisions made by others. ;-)

[baentsch]

Thanks for taking the time to provide your thoughts and a concrete proposal @mouse07410 . Regarding oqsprovider it fully aligns with my thinking: Simply drop supporting algorithms that don't "register" -- which is equivalent to what this issue argues for . I'd gladly review a PR by anyone interested "bringing them back" to OpenSSL releases > 3.4 (or work on that myself as time & interest permits).

Regarding openssl I think executing on your proposal would mean unnecessary work as the time to merge feature/ml-kem to master is pretty close for all I can see. In addition, the core problem, #623, is triggered by (not) registering to ML-DSA (O)IDs, not ML-KEM ones.

[baentsch]

@feventura While implementing this proposal (disabling standardized PQC algs in oqsprovider when finding them already present in OpenSSL), I hit a snag with Composite sigs: This call cannot work under those circumstances as the name "mldsaxx" is not present in the OpenSSL OBJ_ registry and now cannot be registered any more as the OID already is registered under the name "ML-DSA-xx". And of course the internal "reliance" on oqsprovider data structures for PQC cannot work any more as the OpenSSL built-in providers have a completely different logic.

--> Do you have a suggestion how to get around this, e.g., introducing/using an "oqsprovider-internal" NID registry? Otherwise, I'm afraid we'd have to "summarily" also disable support for composite signatures of standardized PQC algs when running oqsprovider in OpenSSL versions >= 3.5.

In general, I think a complete overhaul of hybrid & composite logic is necessary now that the "basic" PQC algs are made available via the OpenSSL built-in providers: Such new code should rely no longer only for the classic crypto but now also for the PQC algs only on EVP calls, not any oqsprovider internal data structures any more. And once that is considered, I begin to wonder whether it wouldn't be more sensible to do a standalone composite provider (as already discussed in #624 (reply in thread))? The only advantage of oqsprovider would be the conceptual possibility to do composites with non-standardized algs. But that currently is not done in your config for composites, so arguably there is no reason retaining support for composites in oqsprovider running in OpenSSL >= 3.5 unless such complete overhaul is done.
Thus, for now, I'm disabling composite support in this config. It will keep operating if oqsprovider is loaded into OpenSSL installations with version < 3.5.0.

[baentsch]

fwiw/fyi & twimc, oqsprovider now builds and tests OK again in openssl master using the approach outlined above.

Anyone asking for something different is cordially invited to actively contribute.

But as per the discussions, beware that this is a non-trivial undertaking both from the perspective of the design of oqsprovider as well as the fact that there's now also substantially better/more complete PQC code available in openssl master that any update in oqsprovider (and liboqs) would need to catch up with to allow "downstream users" (including our moms and aunts :) to use both interchangeably.

[mouse07410]

I confirm that ML-KEM now works perfectly with OpenSSL-3.4.1 and OpenSSL-3.5.0-dev.

The only thing - OpenSSL-3.5.0-dev ML-KEM performance (default provider?) appears to be much worse than that of OpenSSL-3.4.1 (oqsprovider?):

$ openssl3 speed ML-KEM-1024
Doing ML-KEM-1024 keygen ops for 10s: 27011 ML-KEM-1024 KEM keygen ops in 9.85s
Doing ML-KEM-1024 encaps ops for 10s: 289551 ML-KEM-1024 KEM encaps ops in 9.90s
Doing ML-KEM-1024 decaps ops for 10s: 199213 ML-KEM-1024 KEM decaps ops in 9.93s
version: 3.5.0-dev
built on: Thu Feb 20 15:30:29 2025 UTC
options: bn(64,64)
compiler: clang -fPIC -arch x86_64 -O3 -std=gnu18 -march=native -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -DOQS_ALGS_ENABLED=STD -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DZLIB_SHARED
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000008029c67af:0x00000000bc000600:0x0000000000000000:0x0000000000000000
                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                ML-KEM-1024 0.000365s 0.000034s 0.000050s    2742.2   29247.6   20061.7
$ 
$ openssl speed mlkem1024
Doing mlkem1024 keygen ops for 10s: 280330 mlkem1024 KEM keygen ops in 9.95s
Doing mlkem1024 encaps ops for 10s: 529713 mlkem1024 KEM encaps ops in 9.96s
Doing mlkem1024 decaps ops for 10s: 473259 mlkem1024 KEM decaps ops in 9.96s
version: 3.4.1
built on: Wed Feb 12 17:13:30 2025 UTC
options: bn(64,64)
compiler: /usr/bin/clang -fPIC -arch x86_64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000008029c67af
                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                  mlkem1024 0.000035s 0.000019s 0.000021s   28173.9   53184.0   47516.0
$ 

@levitte any comment...?

[vdukhovni]

I confirm that ML-KEM now works perfectly with OpenSSL-3.4.1 and OpenSSL-3.5.0-dev.

The only thing - OpenSSL-3.5.0-dev ML-KEM performance (default provider?) appears to be much worse than that of OpenSSL-3.4.1 (oqsprovider?):

What is the platform here? Is it an Intel Mac? Is it Apple silicon emulating X86_64? ...

$ openssl3 speed ML-KEM-1024
Doing ML-KEM-1024 keygen ops for 10s: 27011 ML-KEM-1024 KEM keygen ops in 9.85s
Doing ML-KEM-1024 encaps ops for 10s: 289551 ML-KEM-1024 KEM encaps ops in 9.90s
Doing ML-KEM-1024 decaps ops for 10s: 199213 ML-KEM-1024 KEM decaps ops in 9.93s
version: 3.5.0-dev
built on: Thu Feb 20 15:30:29 2025 UTC
options: bn(64,64)
compiler: clang -fPIC -arch x86_64 -O3 -std=gnu18 -march=native \
   -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk \
  -g -DOQS_ALGS_ENABLED=STD -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL \
  -DZLIB -DZLIB_SHARED
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000008029c67af:0x00000000bc000600:0x0000000000000000:0x0000000000000000
                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                ML-KEM-1024 0.000365s 0.000034s 0.000050s    2742.2   29247.6   20061.7

The above keygen numbers look quite anomalous. On a modest AMD64 NUC, I see:

compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
CPUINFO: OPENSSL_ia32cap=0x7ef8320b078bffff:0x0040069c219c97a9:0x0000000000000010:0x0000000000000000:0x0000000000000000
                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                ML-KEM-1024 0.000042s 0.000021s 0.000032s   24002.7   47610.9   31056.9

version: 3.4.1
built on: Wed Feb 12 17:13:30 2025 UTC
options: bn(64,64)
compiler: /usr/bin/clang -fPIC -arch x86_64 -pipe -Os
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
-arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
-DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL
-DZLIB -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000008029c67af
keygen encaps decaps keygens/s encaps/s decaps/s
mlkem1024 0.000035s 0.000019s 0.000021s 28173.9 53184.0 47516.0
$

The compiler flags are also noticeably different.

[baentsch]

For me, the performance differential is an absolutely logical consequence of the design goals of each project: The OpenSSL code has been designed for maximum standards adherence (even those that don't yet exist :), security (e.g. constant time) and portability (all platforms supported by OpenSSL) while the primary non-functional properties OQS code focuses on is performance and (for now, ML-KEM only) "formal verification" between spec and code (and that on specific platforms only).

--> IMO OQS is a research project geared to show how "good" PQC software may be given enough work on specific properties and platforms while OpenSSL delivers what's needed to provide the best security for a "messy world".

Also see openssl/openssl#25879: Maybe the folks that did the optimizations upstream of OQS at some point may find the time to contribute to that issue, too -- or someone else versed in x64 and/or aarch64 assembly.

[vdukhovni]

Another measurement, this time MacOS, Apple Silicon laptop, default build (./config):

version: 3.5.0-dev
built on: Fri Feb 21 17:10:46 2025 UTC
options: bn(64,64)
compiler: cc -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
CPUINFO: OPENSSL_armcap=0x987d
                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                     X25519 0.000020s 0.000045s 0.000024s   48993.9   22031.7   42494.6
                 ML-KEM-512 0.000011s 0.000007s 0.000011s   90731.6  144371.0   93848.8
                 ML-KEM-768 0.000018s 0.000010s 0.000015s   56587.4   98996.4   65299.9
                ML-KEM-1024 0.000027s 0.000014s 0.000021s   37088.7   70232.0   47738.3

[vdukhovni]

And here are numbers for ML-KEM-768 on a Fedora 41 system with OpenSSL 3.2 + OQS vs. OpenSSL 3.5

                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                   mlkem768 0.000020s 0.000018s 0.000018s   49558.3   55688.5   55317.4
                 ML-KEM-768 0.000027s 0.000016s 0.000024s   36886.7   62932.7   41051.8

The difference between encaps and decaps times is due to the precomputation and caching of the matrix during keygen in the OpenSSL case, which also partly accounts for the slower keygen, since some of the cost is paid there. And of course the OpenSSL 3.5 code is not assembly optimised.

[baentsch]

And of course the OpenSSL 3.5 code is not assembly optimised.

Hence the reference to openssl/openssl#25879 for anyone willing to contribute that. If interested in comparing apples to apples (no assembly optimizations active), build oqsprovider with liboqs built-configured with OQS_ENABLE_KEM_ml_kem_[512|768|1024]_[x86_64|aarch64]=OFF.

[martinschmatz]

I might well be that I don't really get the essence of the discussion, which I have to admit confuses me.

To better understand, I equipped myself with the following (all done inside an UBI9.5 container on an Ubuntu22.04 bare-metal Intel Icelake host):

• I've built Openssl v3.5-dev (commit: ac80e1e15dcd13c61392a706170c427250c7bb69 from today).
• I've built the OQS provider v0.8.0 (commit: ec1e843)
• OQS provider makes use of liboqs v0.12.0 (commit: f4b96220e4bd208895172acc4fedb5a191d9f5b1)
• See below for defines and configs used during build
• The openssl.cnf file does not load any providers.

With the above, I started to experiment...

---

I executed openssl speed commands and generated the output below (same server, openssl speed executed one right behind the other, BUT with different sequence when loading the oqsprovider and default provider):

[root@e07d76e0cfd3 /]# openssl speed -seconds 2 -provider default -provider oqsprovider mlkem768
Doing mlkem768 keygen ops for 2s: 16979 mlkem768 KEM keygen ops in 1.99s
Doing mlkem768 encaps ops for 2s: 32327 mlkem768 KEM encaps ops in 2.00s
Doing mlkem768 decaps ops for 2s: 20060 mlkem768 KEM decaps ops in 1.99s
version: 3.5.0-dev
built on: Tue Mar  4 18:28:30 2025 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -DFAST_PCLMUL -DECP_NISTZ256_ASM -DO3
CPUINFO: OPENSSL_ia32cap=0x7ffef3ffffebffff:0x40417f5ef3bfb7ef:0x00000000bc040412:0x0000000000000000:0x0000000000000000
                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                   mlkem768 0.000117s 0.000062s 0.000099s    8532.2   16163.5   10080.4
[root@e07d76e0cfd3 /]# openssl speed -seconds 2 -provider oqsprovider -provider default mlkem768
Doing mlkem768 keygen ops for 2s: 17137 mlkem768 KEM keygen ops in 1.98s
Doing mlkem768 encaps ops for 2s: 62959 mlkem768 KEM encaps ops in 1.97s
Doing mlkem768 decaps ops for 2s: 62104 mlkem768 KEM decaps ops in 2.00s
version: 3.5.0-dev
built on: Tue Mar  4 18:28:30 2025 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -DFAST_PCLMUL -DECP_NISTZ256_ASM -DO3
CPUINFO: OPENSSL_ia32cap=0x7ffef3ffffebffff:0x40417f5ef3bfb7ef:0x00000000bc040412:0x0000000000000000:0x0000000000000000
                               keygen    encaps    decaps keygens/s  encaps/s  decaps/s
                   mlkem768 0.000116s 0.000031s 0.000032s    8655.1   31958.9   31052.0

Minor comment: I had to beef up MAX_SIG_NUM in openssl speed to 256. While on it, also did it for MAX_KEM_NUM.

---

Next, I enabled providers in openssl.cnf:

[ provider_sect ]
default = default_sect
oqsprovider = oqsprovider_sect

[ default_sect ]
activate = 1
[ oqsprovider_sect ]
activate=1
module=/usr/lib64/ossl-modules/oqsprovider.so

I added the following to my Docker file where I built the above:

# (0) Override OIDs (by appending ".1" to the default OID)
ENV OQS_OID_MLDSA44=2.16.840.1.101.3.4.3.17.1
ENV OQS_OID_MLDSA65=2.16.840.1.101.3.4.3.18.1
ENV OQS_OID_MLDSA87=2.16.840.1.101.3.4.3.19.1
ENV OQS_CODEPOINT_MLKEM512 1234

I also built cURL v8.12.1 and HAproxy v3.1.5 in the same Dockerfile (including prerequisites).
I then generated certificate chains (leaf and root) for mldsa65, mldsa65_p256, and prime256v1.

I was then able to connect cURL to HAproxy (from where I go to the OQS interoperability server):
curl -vk https://<xxx.yyy>.com:8443/ --curves "mlkem512:*MLKEM512"
curl -vk https://<xxx.yyy>.com:8443/ --curves "*mlkem512:MLKEM512"
and verified with WireShark that the TLSv1.3 key agreement was done once with code point 512 (=0x0200) and once with code point 1234.
Certificates were successfully verified, here one example for the relevant cURL verbose mode output:

*   Certificate level 0: Public key type mldsa65_p256 (128/128 Bits/secBits), signed using mldsa65_p256
*   Certificate level 1: Public key type mldsa65_p256 (128/128 Bits/secBits), signed using mldsa65_p256

---

Now here's what I don't understand in the current discussion: I'm obviously able to run tests with ML-KEM from both providers (default and oqsprovider). Same is true for ML-DSA certs. All of that runs nicely. The standardized algorithms are not supposed to change. And having a baseline for any comparison is essential (per definition, because without a base there can not be a comparison) - and a 2-3x uncertainty factor disqualifies as baseline to be blunt.

So why exactly should ML-KEM and/or ML-DSA be dropped (which I guess implies work) rather than just be left in as it is obviously useful stuff?

---

PS:

• OpenSSL build config:

    ./Configure linux-x86_64 \
        --prefix=/usr \
        --with-rand-seed=rdcpu,os \
        -DFAST_PCLMUL \
        -DECP_NISTZ256_ASM \
        -DO3 \
        enable-ec_nistp_64_gcc_128 enable-tls1_3 \
        no-ssl no-tls1 no-tls1_1 no-afalgeng no-tests \
        shared threads -lm

• liboqs build defines:

                   -DCMAKE_INSTALL_PREFIX=/usr \
                   -DBUILD_SHARED_LIBS=ON \
                   -DOQS_USE_OPENSSL=OFF \
                   -DCMAKE_BUILD_TYPE=Release \
                   -DOQS_BUILD_ONLY_LIB=ON \
                   -DOQS_DIST_BUILD=ON \

• oqsprovider build defines:

              -DCMAKE_INSTALL_PREFIX=/usr/lib64/ossl-modules/ \
              -DOPENSSL_ROOT_DIR=/usr \
              -Dliboqs_DIR=/usr/lib64/cmake/liboqs \
              -DCMAKE_BUILD_TYPE=Release \