Support derivation of KEM key pairs

[bifurcation]

In #1994, we have been discussing adding support for the "seed" format of ML-KEM keys. As I looked into implementation, it occurred to me that the approach outlined in that issue is not sufficient for implementing HPKE and protocols such as MLS and TLS ECH that rely on it. The proposed solution here is to add a "derive key pair" method to the KEM interface, that would provide the correspondingly-named function in the HPKE specification.

The addition to the KEM struct would be something like:

	/** The length, in bytes, of a seed from which a keypair can be derived for this KEM. */
	size_t length_seed;

	/**
	 * Keypair generation from a seed.
	 *
	 * Caller is responsible for allocating sufficient memory for `public_key` and
	 * `secret_key`, based on the `length_*` members in this object or the per-scheme
	 * compile-time macros `OQS_KEM_*_length_*`.
	 *
	 * @param[out] public_key The public key represented as a byte string.
	 * @param[out] secret_key The secret key represented as a byte string.
	 * @param[in] seed The entropy from which the key pair is derived.
	 * @return OQS_SUCCESS or OQS_ERROR
	 */
	OQS_STATUS (*derive_keypair)(uint8_t *public_key, uint8_t *secret_key, const uint8_t *seed);

This approach would support HPKE and downstream protocols, and would remove the need for a separate ML-KEM instance based on the seed, since the application could expand the seed themselves.

It seems like the major challenge here would be addressing all the existing KEMs. I'm not all that familiar with the copy_from_upstream tooling, but presumably we would add a parameter to the YAML file to point to an implementation of this method. If we could generate a default "always return failure" function when that parameter isn't present, it seems like that would enable a smooth migration.

[SWilson4]

Hi @bifurcation, please see #1206 and #1877—it may be the case that this in-progress (admittedly stalled due to other priorities) work addresses or partially addresses the use case. Your insight on the approach taken in that draft PR would be very welcome!

[bifurcation]

Thanks, @SWilson4, closing this as a dup of #1206.

[baentsch]

I'm not all that familiar with the copy_from_upstream tooling, but presumably we would add a parameter to the YAML file to point to an implementation of this method. If we could generate a default "always return failure" function when that parameter isn't present, it seems like that would enable a smooth migration.

That sounds like a technically doable approach. As the "copy_from_upstream" tooling is not exactly well documented and meant just for internal use, the best proposal I can make right now is point you to #1919 which shows the "tooling in action" adding an API to all algs: Everything starts with "copy_from_upstream.py" reading the config and applying all patches (if needed) and running the jinja2 fragments below the scripts/copy_from_upstream folder (one file each for each main source code file with template code)...

The general approach (of adding yet another API) is one I don't feel competent enough to comment on right now without understanding the protocols you mention. As you mention TLS though, I've got to ask how this is supposed to wind up in that protocol (by way of oqsprovider to OpenSSL or some other mechanism/some other TLS software)?

[SWilson4]

I'll also drop this link regarding copy_from_upstream documentation: https://github.com/open-quantum-safe/liboqs/wiki/Patching-upstream-sources

This doesn't thoroughly document the script itself, but it does explain fairly well how to use it, which helps with understanding the code.