Provide support for using KEMs in command line utils

[tomato42]

while it's possible to generate a private key for ML-KEM-512 or Kyber-512 (if they're included in the osqprovider) using the openssl genpkey utility, like so:

openssl genpkey -provider default -provider oqsprovider -out /tmp/kyber512.pem -algorithm kyber512

and it's possible to convert it then to a public key:

openssl pkey -provider default -provider oqsprovider -pubout -in /tmp/kyber512.pem -out /tmp/pub.pem

there is no way to actually perform the encapsulate operation with them...

if I try to perform a Diffie-Hellman like derive, the operation fails:

# openssl pkeyutl -provider oqsprovider -provider default -derive -out /tmp/shared.key -inkey /tmp/ml_kem_512.pem 
pkeyutl: Error initializing context
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:04000066:object identifier routines:OBJ_create:oid exists:crypto/objects/obj_dat.c:781:
80527EDC987F0000:error:03000096:digital envelope routines:EVP_PKEY_derive_init_ex:operation not supported for this keytype:crypto/evp/exchange.c:362:

in fact, if I look for the EVP_PKEY_encapsulate() API in apps/ I see it only in speed.c...

[nhorman]

I'm a bit confused here, and could use some clarification

I understand what you're saying (I think) in that you would like to be able to encapsulate a key to send it securely to a peer.

But the command you're using isn't meant for encapsulation, its meant to derive a shared secret using your private key, and the public key that has already been sent to you (as specified by the -perrkey option to pkeyutil)

It looks like the oqs provider hasn't implemented a derivation method yet.

That all said, can you clarify what the request is here? From the title it sounds like what you're after is a new subcommand

openssl pkeyutil -encap

or some such, that translates a shared secret into an encapsulated format suitable for sharing over a network. I suppose that could be done, but I'm not sure what the output format could or should be.

Nominally other software uses this library call (see ssl_encapsulate for an example), to create an encapsulated secret in a memory buffer suitable for sending over a network using whatever format/protocol is appropriate. I'm not aware of a use case in which the output of the encapsulated key should be output from a command line utility.

[beldmit]

Yes, the new subcommand looks like the best option. We would like to use this command for test purposes so I think we need encap/decap pair

[tomato42]

@nhorman yes, I know it's not for encapsulation; but DH and RSA encryption is closest to a KEM that is possible to be done with the command line utilities

yes, a subcommand is most likely what we will need

also, it's not a translation of a shared secret to something that can be transferred over the network; the main difference between KEM operations and DH is that the only input the the KEM encapsulation operation is the encapsulation key; and there are two outputs: the shared secret and the encapsulated shared secret

Basically the same thing those utilities here do: https://github.com/tomato42/kyber-py/tree/interop-with-openssl/interop

the use case is the same as basically all of the OpenSSL command line utility: testing, interoperability most specifically. It's no different than having the -derive option in pkeyutil: it's for DH, and "nobody" is expected to actually use it from the command line utility. But it's good to have there to experiment with different inputs and outputs without having to write C code.

[nhorman]

ok, so we're clear on the direction, a new applet subcommand to do encapsulation for the purpose of testing/interop/etc.

I guess the next question is, @tomato42, do you want to write such a PR? I'm not sure when the core openssl team will get to scheduling this. We can consider it for 3.5 but I can't promise anything. It might be done more quickly if you can put up a PR for it.

Let me know what you think, and I'll either assign it to you as a community issue, or list it on the consideration list for 3.5

[tomato42]

sorry, I won't have the time to work on it in the foreseeable future and the simple tools I created do what I need

[tomato42]

(I might end up getting merged here: https://github.com/GiacomoPope/kyber-py/pull/80, just in case the branch gets deleted later)

[slontis]

Can this be closed now?

[tomato42]

yes, absolutely, fixed by https://github.com/openssl/openssl/pull/25127