Standalone ml-kem and ml-dsa along with openssl-3.5.0

[samettonyali]

Hi all,

I have just built and installed the latest oqs-provider, but when I checked to see the supported signatures and kem algorithms I couldn't see standalone ml-kem and ml-dsa, but only hybrid variants in the list. Then, I realized the note about openssl-3.5.0's (and above) including these algorithms, so they will be not provided by the oqs-provider. I understand that, but still wondering if there is a way to provide these algorithms along with openssl-3.5.0 using oqs-provider.

Sincerely yours,
Samet

[qathy]

Hi,

Well, as sticking with OQS Provider 0.6.1 when using OpenSSL 3.5.0 introduces a strong incompatibility (see #27435), that may be the right choice, dropping implementation of standardized algorithms.

By the way, I was also surprised with dropping some of the experimental algorithms.

Is this just for simplification's sake?

Best regards,
TQ

[dstebila]

By the way, I was also surprised with dropping some of the experimental algorithms.

Which experimental algorithms were dropped? We have temporarily disabled HQC due to a security flaw in the algorithm, but will re-enable it once that's been fixed by its creators.

[qathy]

By the way, I was also surprised with dropping some of the experimental algorithms.

Which experimental algorithms were dropped? We have temporarily disabled HQC due to a security flaw in the algorithm, but will re-enable it once that's been fixed by its creators.

All the KEM algorithms seems to have been dropped except two: p256_mlkem512 and x25519_mlkem512.

See #668 for reference.

[baluduvvuri1]

hi

Hi all,

I have just built and installed the latest oqs-provider, but when I checked to see the supported signatures and kem algorithms I couldn't see standalone ml-kem and ml-dsa, but only hybrid variants in the list. Then, I realized the note about openssl-3.5.0's (and above) including these algorithms, so they will be not provided by the oqs-provider. I understand that, but still wondering if there is a way to provide these algorithms along with openssl-3.5.0 using oqs-provider.

Sincerely yours, Samet

I was able to get the oqsprovider implementation to be used for the mldsa algorithms by not doing registration from the OpenSSL side. From the OpenSSL side we have to build openssl with "no-ml-dsa" option and revert changes in openssl/openssl@d31fce1
This will make sure algorithm from oqsprovider is used for ml-dsa and ml-kem

[petrovr]

It seems to me "dynamic" check is quite tricky - OpenSSL does not offer cross-provider dependency capability.

Engines are deprecated loadable modules. If I remember well exist feature that allows certain features to be associated to an engine.

Providers accept parameters (properties) either from configuration of command line.

So instead to exclude a key-type at "build" time why do not exclude/include them at run time?

---

The default list cold be "hard-coded" at build time depending on OpenSSL release.
Override could allow to enable a oqs key type when default provider is not loaded.

[baentsch]

So instead to exclude a key-type at "build" time why do not exclude/include them at run time?

The default list cold be "hard-coded" at build time depending on OpenSSL release.
Override could allow to enable a oqs key type when default provider is not loaded.

Run-time algorithm en/disablement precisely is the intent of the rt_algo_filter. That said, the code base for all standardized algorithms has fallen out of maintenance here as there doesn't seem to be value in duplicating code/an effort executed much better within the OpenSSL project. In general, oqsprovider always was meant to extend default provider behaviour, never to supersede any of it.

Final thought: oqsprovider cannot work if default provider is not loaded as it relies on it for various functions, such as randomness or classic crypto for hybrid algorithms. Thus --unless and until default provider is massively re-factored to split out those functionalities-- such scenario is not realistic and IMO shouldn't drive design decisions (or work) in this project. If this is the intent of the statement

It seems to me "dynamic" check is quite tricky - OpenSSL does not offer cross-provider dependency capability.

we're in agreement @petrovr .