Public accessor for ML-KEM algorithm NID

[DarkaMaul]

Problem:

AWS-LC provides EVP_PKEY_pqdsa_get_type (declared in evp.h) to retrieve the specific algorithm NID from an EVP_PKEY of type EVP_PKEY_PQDSA.

There is no equivalent function for EVP_PKEY_KEM keys.

Callers that receive an EVP_PKEY wrapping an ML-KEM key currently have no public API to determine which ML-KEM variant it holds. The NID is available internally, but it is not exposed through the public EVP interface.

Solution:

Add EVP_PKEY_kem_get_type, following the same pattern:

// EVP_PKEY_kem_get_type returns the |nid| of the configured KEM key.
// |pkey| must not be NULL.
OPENSSL_EXPORT int EVP_PKEY_kem_get_type(const EVP_PKEY *pkey);

• Does this change any public APIs? Yes — adds one new exported functionEVP_PKEY_kem_get_type. No existing APIs change.
• Which algorithm(s) will this impact? ML-KEM-*

Requirements / Acceptance Criteria:

• Unit tests in crypto/evp_extra/p_kem_test.cc covering:
  • Returns correct NID for each ML-KEM variant (512, 768, 1024)
  • Returns 0 and sets error when called on a non-KEM EVP_PKEY (e.g. RSA or PQDSA key)
  • Returns 0 when called with an uninitialized KEM key

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: N/A (API parity issue, not a new algorithm)
• Related Issues: None known
• Will the Usage Guide or other documentation need to be updated? The function should be documented in the header.
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly
  interesting/important unit tests.
  • Will this change trigger AWS LibCrypto Formal Verification changes? No
  • Should this change be fuzz tested? No

Note: In my current PR in pyca/cryptography, I currently use the public key size to determine the variant.

/cc @alex

[justsmth]

Hello! Thanks for the well-written issue. You're right that there's an asymmetry here. We should have an EVP_PKEY_kem_get_type accessor to match what we provide for PQDSA keys.

I've put up a draft PR for this here:

• Add EVP_PKEY_kem_get_type public accessor for KEM key NID #3179