Conversion of decapsulation ML-KEM to encapsulation key fails with NOPUBKEY_IN_PRIVKEY

[tomato42]

Describe the bug
When the oqs-provider is compiled with the NOPUBKEY_IN_PRIVKEY option, conversation of private key to public key fails.

To Reproduce
Steps to reproduce the behavior:

1. Compile the oqs-provider with the NOPUBKEY_IN_PRIVKEY option
2. openssl genpkey -provider default -provider oqsprovider -out priv.pem -algorithm mlkem512
3. openssl pkey -provider default -provider oqsprovider -in priv.pem -pubout -out pub.pem

Expected behaviour
A public key in pub.pem created

Encountered behaviour

8042B03D907F0000:error:400C0102:lib(128):oqsx_spki_pub_to_der:passed a null parameter:/builddir/build/BUILD/oqs-provider-0.8.0/oqsprov/oqs_encode_key2any.c:498:
8042B03D907F0000:error:400C0100:lib(128):oqsx_key_to_pubkey:malloc failure:/builddir/build/BUILD/oqs-provider-0.8.0/oqsprov/oqs_encode_key2any.c:165:

Environment (please complete the following information):

• OS: RHEL-10
• OpenSSL version: 3.2.2
• oqsprovider version: 0.8.0

Additional context
The ML-KEM decapsulation key (dk) is actually a concatenation of the dk_PKE (the underlying decryption key) and ek_PKE (the underlying encryption key), so conversion of a private key to a public key is as simple as dropping the first 384 * k bytes from the beginning...

[baentsch]

Thanks for the report @tomato42 . I'll look at it after a resolution to #623 has been found.

The ML-KEM decapsulation key (dk) is actually a concatenation of the ek_PKE (the underlying decryption key) and ek_PKE (the underlying encryption key), so conversion of a private key to a public key is as simple as dropping the first 384 * k bytes from the beginning...

True statement, but again a quick reminder: oqsprovider is completely algorithm-agnostic -- it does not know or handle any PQC algorithm specifically/"especially" but just wraps OQS APIs and its key formats completely transparently: The goal of oqsprovider was to enable use/trialing of all NIST PQC candidates, not optimizing for any one in particular.

But your comment triggered me to finally propose an idea I had in the back of my mind for quite some time and that should solve your problem much better than any algorithm-specific "hack": openssl/openssl#26649.

[tomato42]

so, basically we would need to have a completely new API in liboqs which would be something like public_key_derive(pk) that would take private key as input and output the public key, and then have that implemented for all algorithms...?

yes, that sure looks rather ugly

[baentsch]

yes, that sure looks rather ugly

:-/ I'm not sure I'd call it "ugly" -- "cumbersome" is what came to my mind :-)

Anyway, all I wanted to say is that it's not as simple as it might have been if there had been an algorithm-specific/optimized provider logic for each PQC algorithm -- but that's simply untenable for a single maintainer "looking after" (currently) 82 signature and 43 KEM algorithms.