openssl
openssl copied to clipboard
openssl
ML-KEM digest fetching
I came across that fetching parameters are ignored when creating ML-KEM public key from data. I want to fetch supplementary digests with particular properties.
EVP_KEYMGMT object for ML-KEM supports OSSL_PKEY_PARAM_PROPERTIES only for key generation, not for fetching.
EVP_PKEY_fromdata calls evp_keymgmt_util_fromdata implemented as
https://github.com/openssl/openssl/blob/f426dd1311eecd12f24190c94f56eb85e62aaa27/crypto/evp/keymgmt_lib.c#L319-L331
Fetching of supplementary digests (SHAKE, SHA3) happens when we call evp_keymgmt_newdata (ossl_ml_kem_key_new callback) and parameters are processed only in evp_keymgmt_import.
Can we improve this situation?
Note: for the FIPS provider this is irrelevant since the fetch can only come from it's internal library context. For the default provider, this is an issue.
Can anyone please give a clue how can it be implemented? I think the preferred way is to try fetching the digests from the same provider we have the EVP_KEYMGMT respecting the properties and then fallback if we failed
Perhaps ml_kem_import could be augmented to refetch the digests in the event that a properties param has been provided?
From a quick check, it seems that the property query could be set on the decoder between it being created and the key imported. The key isn't actually created until ossl_ml_kem_d2i_PUBKEY gets called. Key creation triggers the digest fetches. There doesn't, however, appear to be any way to get the current provider inside this routine to force fetching from it rather than honouring the property query string.
It would be possible to add a ?provider="xxx" in the caller but it's the usual messing around with property query strings.
I think the digests are fetched earlier...
They are. But they're not used until later. Hence my suggestion to "refetch" them on import.
@slontis Yes - but but from the FIPS perspective this one is of the most interest