Is this worth being a separate PR?

BTW: I like this approach. The native types might stretch it a bit to handle things going out of scoping.

I originally wrote this as a means to an end. If we think this is good general approach then I can have a go a pulling this out as a separate PR and making it more generic.

I'm willing to have a go at the other types once this is merged (or before). I coded something which addresses the alignment issues in #9246. That should be reusable.

The other thing I think that could be addressed is scoping -- it would be nice if a function could be called that added an auto variable to a template without losing the value. This shouldn't be too difficult to support. For the two string types and BIGNUM, it should also be possible (and the _PTR versions not cloning the value).

@levitte what do you think about this approach compared to #9246 and #9254 ? To me, it seems to sit nicely in the middle.

I'm willing to have a go at the other types once this is merged

Great. In that case. I'll leave this within this PR, and let you refactor it as part of a wider PR.

I see this a a temporary measure until we have better key management (i.e. where non-legacy keys are entirely managed in the provider and treated as an object in its own right rather than just a bunch or parameters passed via init).

I see this a a temporary measure until we have better key management (i.e. where non-legacy keys are entirely managed in the provider and treated as an object in its own right rather than just a bunch or parameters passed via init).

Even with the better key management in place we will still need this. For example some keys will be loaded from file by libcrypto and then transferred to the provider. Or similarly keys will be exported from a provider. Or transferred from one provider to another. Some providers may not implement import/export, but I expect at least our providers will.

I guess we'll have to see.

Refer #9305 for a first stab at something similar but including other types.

Could this be just key B<exchange> algorithm.
Maybe Keyexchange is a better name for the type???

I find it more confusing to just write key B<exchange> algorithm.

I'm open to a different type name, but EVP_KEYEXCHANGE seems a little long. Other possibilities could be EVP_KEYEXCH, EVP_KEYEX, EVP_KEXCHANGE

I dont like EVP_KEYEX, either of the other 2 are fine.

I have absolutely no idea what this "internal" property really does..
I cant see this property anywhere.

There are a number of algorithms (such as HKDF) which (for historical reasons) have been forced into the "derive" API. They have nothing to do with key exchange - they are KDFs, and are now available via the EVP_KDF APIs. For backwards compatibility we need to be able to support them when doing implicit fetches. But I don't think we should encourage their use in an explicit fetch. For that reason I thought we might add an additional "internal" property only for use when doing implicit fetching. I'd expect those "key exchange" algorithms which are really KDFs to have the internal property, but not have the "default" property.

It's not currently used because I've only brought DH across as part of this PR. I expect future PRs to pull across the other algorithms.

If this is controversial I could drop this from this PR, and reintroduce it when we bring those algorithms across.

Even a TODO above it would be fine..

TODO added

I don't think we should have a behaviour difference like this between implicit and explicit handling - that is asking for issues. Basically the decision on implicit/explicit shouldn't remove something that is available on implicit simply because the caller is using the explicit interface. That inconsistency is (in my view) substantially more concerning than someone using a less desirable interface.

Shouldn't the code just fail in this situation? This is the key exchange code and it's considering (the unrelated) KDFs. That seems wrong.

Would a better way be having the PKEY legacy support make the decision to go to either the key exchange code or the KDF code?

This is the legacy support code....it shouldn't fail, it should dispatch to the "correct" API.

Since this is controversial, I've just removed this for now. We can think more about what to do with this when we move the KDFs that use the "derive" API into the providers in a later PR.

Should this use secure memory?

Or more generally, is a way for the OSSL_PARAM_get_BN call to allocate in secure memory desirable?

I think having a "get_privateBN" API makes sense. Of course you'll need #8886 (or a replacement) merged first.

|| (priv_key = BN_secure_new()) == NULL would work here, but the problem will be more widespread I suspect.

Whether you do it in two steps (allocate the BN) or one (add a params API) doesn't matter to me. But yes, the provider will have to know which parameters are private key material, which doesn't seem like a big deal to me.

If it's a common consensus that all keys (or at least their private bits) should reside in secure memory if possible, then the provider can decide on its own what to put there and what not. If the provider of an algorithm implementation doesn't intimately know its own keys, that provider needs a rewrite.

I changed this to explicitly allocate the BN via BN_secure_new()

This should be either secure_free or normal free shouldn't it?

I don't think this needs to be fixed here, it will be resolved by #9305 or #9254 (which ever ends up being selected). But a TODO might be worthwhile.

Yeah, good point. Most of the time it should actually be OPENSSL_secure_clear_free, because we expect the key to have a private element. I've changed it to that for now, and added a TODO.

Similar comment about secure_free.

Most of the time OPENSSL_free should be fine because we don't expect this key to have a private element - but I added a TODO anyway.