FIPS 203 ML-KEM vs RSA and ECDH

Use FIPS 203 for ML-KEM algorithm behavior, including key generation, encapsulation, decapsulation, and the ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter sets.

Use SP 800-56A for ECDH and other discrete-logarithm key-agreement schemes; use SP 800-56B for RSA key agreement or key transport based on integer factorization.

Identify whether the claim is KEM-based (ML-KEM), key-agreement-based (ECDH or RSA), or key-transport-based (RSA) before mapping to the applicable NIST publication.

FIPS 203 applies to federal systems that select ML-KEM for establishing a shared secret, including systems operated for agencies under contract. Private and commercial organizations may also adopt it.

SP 800-56A and SP 800-56B specify approved classical schemes for systems that select ECDH, finite-field Diffie-Hellman, or RSA key establishment. The applicable contract or system policy determines who must follow them.

Do not infer a migration mandate from the actor's name. Identify the policy, contract, protocol, or risk decision that selects the scheme.

ML-KEM is a KEM: one party encapsulates to a public key and another decapsulates with the private key so both derive shared secret material under the conditions specified by FIPS 203.

ECDH is pair-wise key agreement; RSA key establishment under SP 800-56B can be key agreement or key transport, with scheme-specific key-confirmation and assurance requirements.

Distinguish KEM encapsulation (ML-KEM) from pair-wise key agreement (ECDH) or key transport (RSA); the mechanism type determines which NIST publication governs.

Record the ML-KEM parameter set, supported operations, input checks, RBG strength, key and ciphertext sizes, and handling of the 32-byte shared secret for the implementation and operating environment being cited.

Record the approved curve or finite-field group for ECDH, the RSA key size and scheme for RSA, plus the KDF, key-confirmation method, and protocol profile that bind the shared secret to the session.

The scheme name alone is insufficient. Preserve the parameters, operation, validation record, protocol binding, authentication method, and key-handling rules that make the implementation claim reproducible.

ML-KEM evidence should identify the validation record for the implementation, version, algorithm capability, operating environment, and whether the tested capability covers the operation relied on.

RSA and ECDH evidence should identify their own validation records and must not be reused as proof that an ML-KEM implementation has been tested.

Collect validation evidence for the specific algorithm variant and parameter set; ML-KEM CAVP records cannot substitute for RSA/ECDH records and vice versa.

Adding ML-KEM can require protocol support, hybrid or transition design, parameter-set selection, new validation evidence, and new customer-facing wording.

Keeping RSA or ECDH can be justified by interoperability, existing protocol profiles, certificate ecosystems, or validation timing, but the reason should be recorded rather than implied.

Justify the timing decision: ML-KEM requires post-quantum migration planning; RSA/ECDH can be justified by interoperability and existing protocol profiles.

If ML-KEM is part of a FIPS 140-3 claim, confirm that the implementation is inside the validated cryptographic module boundary and is described consistently in the module security policy and approved services.

For RSA or ECDH, confirm the same boundary, certificate, security policy, operating environment, and approved-mode conditions before relying on a product-level FIPS statement.

Confirm the FIPS 140-3 module boundary covers the correct algorithm; ML-KEM and RSA/ECDH boundary requirements are similar but parameter sets differ.

ML-KEM and RSA/ECDH implementations may both sit inside a FIPS 140-3 cryptographic module boundary, but each scheme needs matching algorithm-validation evidence and Security Policy treatment.

FIPS 203 specifies ML-KEM; SP 800-56A and SP 800-56B govern the cited classical schemes. FIPS 203 does not itself set a withdrawal date for RSA or ECDH. A hybrid design may require separate evidence for the post-quantum and classical components within the same module boundary.

If one module boundary is meant to cover both ML-KEM and RSA/ECDH, verify that the certificate, security policy, and validation records name each algorithm and operating environment explicitly; otherwise split the claim into separate scheme-specific evidence trails.

Use ML-KEM when the design, procurement, or transition plan specifically requires FIPS 203 post-quantum key encapsulation and the implementation evidence supports the claim.

Use RSA or ECDH language when the controlling protocol profile, legacy interoperability requirement, module certificate, or procurement clause is actually written around SP 800-56A or SP 800-56B schemes.

Do not collapse the three options into one checklist; make a scheme-by-scheme decision record with separate source, parameter, validation, and module-boundary fields.