Handling the combinatorial explosion of SP 800-227 KDFs and Combiners

[Nidhi Damodaran]

I have a question regarding the practical integration of NIST SP 800-227 in major cryptographic libraries, specifically OpenSSL.

SP 800-227 provides a lot of flexibility—it supports various KDFs from SP 800-56C and key combiners from SP 800-133, and the specification does not mandate any particular order for the inputs to the KDF (as long as a NIST-approved algorithm is included).

Given the massive combinatorial explosion this flexibility can generate, I’m curious about the consensus on how this will be implemented at the API level:

• Subset vs. Universal Support: Are libraries like OpenSSL planning to support only a very specific, hardcoded subset of these combinations (e.g., pre-defined Named Groups tied to IETF standards like TLS 1.3 or CMS), or is the goal to provide generic EVP_KEM APIs that allow developers to dictate the KDF and input ordering?

  Any insights from folks tracking the OpenSSL roadmap or IETF/NIST standardization on this front would be greatly appreciated.  

[Dimitri John Ledkov]

Hi,

So far these 3 combinations are implemented for TLS

https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem-04#name-shared-secret

And this one for SSH

https://datatracker.ietf.org/doc/html/draft-ietf-sshm-mlkem-hybrid-kex#name-mlkem768x25519-sha256

All specify specific pairs, with specific order, specific lengths and so far use concatenation.

Update to NIST SP 800-52 would be nice to update the guidance.

I am not sure what you mean by CMS. It already supports multiple signers and multiple signatures without any combiners. Support for ML-DSA was added in https://datatracker.ietf.org/doc/html/rfc9882 

There is no support implemented to have any sort of multi-algorithm single signature yet in major libraries with interop.

The https://datatracker.ietf.org/doc/html/draft-reddy-pquip-pqc-signature-migration-01 discusses how to migrate to dual / hybrid signatures. But so far no concrete proposals are implemented or interoperable as far as I know for either X.509 or CMS.

Regards,

Dimitri.

[Nidhi Damodaran]

Thanks for the links clarifying the rigid pairs for TLS/SSH, and apologies for the confusion regarding signatures in my original post!

​My follow-up question is about Key Wraps. Since session protocols bake the KEM and KDF into fixed identifiers (like Named Groups), how is key wrapping expected to fit into OpenSSL's architecture?

​Will the entire chain (KEM + KDF + Wrap algorithm) be locked into monolithic identifiers to prevent combinatorial explosion? Or will OpenSSL leave them as decoupled API calls (e.g., calling EVP_KEM, then a KDF, then a wrap cipher separately), leaving the combination choice to the developer?