--- title: "FIPS 203 ML-KEM vs RSA and ECDH key establishment" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh" author: "Sorena AI" description: "Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP grounding." published_at: "2026-05-09" updated_at: "2026-05-28" keywords: - "FIPS 203" - "ML-KEM" - "RSA key establishment" - "ECDH" - "SP 800-56A" - "SP 800-56B" - "CAVP" - "CMVP" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 203 ML-KEM vs RSA and ECDH key establishment Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP grounding. *Artifact Guide* *GLOBAL* *FIPS-approved cryptographic algorithm requirements* ## FIPS 203 ML-KEM vs RSA and ECDH Compare ML-KEM, RSA, and ECDH as key-establishment choices without turning algorithm approval into an unsupported product-validation claim. Grounded in FIPS 203, NIST SP 800-56A, NIST SP 800-56B, CAVP, and CMVP/FIPS 140-3 context. Use it as implementation guidance, not for legal interpretation. Use this page when a product, protocol, procurement response, or validation file must explain how FIPS 203 ML-KEM relates to existing RSA and ECDH key-establishment choices. The practical question is not which label sounds newer; it is which NIST source governs the scheme, which parameter set or key-establishment method is implemented, which CAVP evidence exists, and whether the claim is inside a FIPS 140-3 cryptographic module boundary. ## FIPS 203 ML-KEM vs RSA and ECDH: what changes operationally? Use this comparison to decide which NIST source, parameter choices, validation records, and module-boundary evidence control an ML-KEM, RSA, or ECDH key-establishment claim. - **FIPS 203 ML-KEM**: ML-KEM is a FIPS 203 key-encapsulation mechanism with three parameter sets and distinct KeyGen, encapsulation, and decapsulation evidence needs. - **RSA and ECDH key establishment**: RSA and ECDH are classical key-establishment choices grounded in the SP 800-56 series, with scheme, parameter, KDF, and key-confirmation evidence that differs from ML-KEM. | Dimension | FIPS 203 ML-KEM | RSA and ECDH key establishment | Operational implication | Sources | | --- | --- | --- | --- | --- | | Scope | 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) or key-agreement-based (ECDH/RSA) before mapping to the applicable NIST publication. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Covered actors | Federal agencies, contractors, and cryptographic module vendors implementing ML-KEM under FIPS 203 for post-quantum key encapsulation, hybrid key exchange, or NIST-approved lattice-based key establishment. | Federal agencies, contractors, and module vendors implementing RSA key establishment under SP 800-56B or ECDH key agreement under SP 800-56A for classical key-establishment schemes in existing protocols and approved federal systems. | Map the actor role to the algorithm family: ML-KEM actors are planning post-quantum transitions; RSA/ECDH actors are maintaining current approved key-establishment. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Trigger | 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. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Core obligations | Record the ML-KEM parameter set and the supported operations, such as KeyGen and EncapDecap, 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. | Record the parameter set and operation for ML-KEM; record the curve, group, or key size and scheme for RSA/ECDH to support evidence-trail validation. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Evidence | 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. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Timing | 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. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Enforcement | 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. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Overlap | ML-KEM and RSA/ECDH implementations may both sit inside a FIPS 140-3 cryptographic module boundary, requiring consistent CAVP validation evidence, module security policy documentation, and SP 800-131A algorithm-transition review. | Both FIPS 203 and the SP 800-56 series depend on NIST SP 800-131A for approved algorithm status and transition timelines. A hybrid key-establishment design may require evidence for both ML-KEM and a classical scheme in the same module boundary assessment. | 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. | [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations.
[NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. | | Practical decision rule | 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. | [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Primary source for the ML-KEM side of the decision rule.
[NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Primary source for ECDH-side decision records.
[NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Primary source for RSA-side decision records.
[NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Use module records to support product-level FIPS wording. | Sources for Scope - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Scope - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Scope - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Covered actors - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Covered actors - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Covered actors - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Trigger - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Trigger - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Trigger - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Core obligations - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Core obligations - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Core obligations - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Evidence - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Evidence - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Evidence - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Timing - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Timing - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Timing - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Enforcement - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Enforcement - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Enforcement - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Overlap - FIPS 203 ML-KEM: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Overlap - RSA and ECDH key establishment: - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. Sources for Overlap - operational implication: - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. Sources for Practical decision rule - FIPS 203 ML-KEM: - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Primary source for the ML-KEM side of the decision rule. - Quote: "Module-Lattice-Based Key-Encapsulation Mechanism Standard" Sources for Practical decision rule - RSA and ECDH key establishment: - [NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Primary source for ECDH-side decision records. - Quote: "SP 800-56A Rev. 3" - [NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Primary source for RSA-side decision records. - Quote: "SP 800-56B Rev. 2" Sources for Practical decision rule - operational implication: - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Use module records to support product-level FIPS wording. - Quote: "FIPS 140-3" ### How to choose the controlling claim - Choose FIPS 203 when the claim is about ML-KEM algorithm behavior, parameter sets, or post-quantum key encapsulation. - Choose SP 800-56A or SP 800-56B when the claim is about classical ECDH or RSA key-establishment schemes. - Choose CAVP evidence when the claim is about a tested algorithm implementation, and CMVP evidence when the claim is about a validated cryptographic module. - Escalate the wording when marketing, procurement, or security documentation says FIPS compliant without naming the algorithm validation, module certificate, and approved-mode basis. Sources for the practical decision rule: - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Primary source for ML-KEM decisions. - Quote: "ML-KEM" - [NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Primary source for ECDH key-establishment decisions. - Quote: "Discrete Logarithm Cryptography" - [NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Primary source for RSA key-establishment decisions. - Quote: "Integer Factorization Cryptography" - [NIST CAVP overview](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Source for algorithm-validation evidence rules. - Quote: "cryptographic algorithm validation process" - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Source for module-validation evidence checks. - Quote: "Validated Modules Search" ## What changes when ML-KEM enters an RSA or ECDH design? FIPS 203 standardizes ML-KEM as a key-encapsulation mechanism with key generation, encapsulation, decapsulation, and three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. RSA and ECDH key-establishment work is grounded in the SP 800-56 series instead: SP 800-56B for integer-factorization schemes, including RSA, and SP 800-56A for discrete-logarithm schemes, including elliptic-curve Diffie-Hellman. That difference matters operationally because ML-KEM, RSA, and ECDH do not produce the same evidence record. A defensible comparison should name the implemented scheme, parameter set or key size, key-derivation and key-confirmation context, protocol profile, CAVP status, and CMVP module boundary before making any FIPS-facing claim. - Treat ML-KEM as a FIPS 203 KEM decision, not as a drop-in synonym for all existing key agreement. - Treat ECDH as an SP 800-56A discrete-logarithm key-agreement decision tied to approved curves, roles, and domain parameters. - Treat RSA key establishment as an SP 800-56B integer-factorization decision tied to RSA key-pair generation, key agreement or key transport, and key-confirmation choices. - Keep the algorithm evidence separate from the module-validation evidence until the FIPS 140-3 certificate boundary and approved mode are confirmed. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM, its parameter sets, and its key-generation, encapsulation, and decapsulation scope. - [NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Primary source for ECDH and other pair-wise key-establishment schemes based on discrete logarithm cryptography. - [NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Primary source for RSA-based pair-wise key-establishment schemes. - [NIST CAVP overview](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Explains that algorithm validation tests approved algorithms and is a prerequisite for cryptographic module validation. ## Key-establishment decision rules for ML-KEM, RSA, and ECDH Start with the source that actually governs the implemented primitive. Use FIPS 203 for ML-KEM parameter-set and algorithm-behavior claims; use SP 800-56A for ECDH-style pair-wise key agreement; use SP 800-56B for RSA key agreement or key transport. If the system also claims FIPS 140-3 validation, confirm that the algorithm implementation is tested or otherwise permitted for the module and operating environment in question. Avoid claims that a primitive is FIPS validated by itself. CAVP evidence supports an algorithm implementation, while CMVP evidence supports a cryptographic module. A product, service, protocol, or library claim should say which certificate, validation entry, module version, operating environment, and approved-mode statement the team is relying on. - For ML-KEM, record ML-KEM-512, ML-KEM-768, or ML-KEM-1024 and whether the evidence covers KeyGen, EncapDecap, or both. - For ECDH, record the SP 800-56A scheme, approved curve or finite-field group, party role, key-confirmation choice, and KDF context. - For RSA, record the SP 800-56B scheme, key size, key agreement or key transport use, key-confirmation choice, and KDF or wrapping context. - For FIPS 140-3 claims, connect the algorithm evidence to the specific module certificate, security policy, operational environment, and approved mode. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Grounds the ML-KEM side of the decision and the three named parameter sets. - [NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Grounds ECDH scheme and parameter decisions. - [NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Grounds RSA key-establishment decisions and key-confirmation context. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Official source for checking whether a cryptographic module has been validated to FIPS 140-1, FIPS 140-2, or FIPS 140-3. ## Evidence to keep for a FIPS-facing comparison The comparison should produce an evidence record, not a generic preference statement. For each implementation, keep a row that ties the source, algorithm identifier, parameter choice, implementation version, operational environment, protocol use case, CAVP validation status, and CMVP module status together. When CAVP evidence exists, verify that the validation entry matches the algorithm implementation and operating environment being used. When a FIPS 140-3 claim exists, verify the module certificate and security policy rather than assuming every algorithm in a product inherits the module's approved-mode claim. - Source: FIPS 203, SP 800-56A, or SP 800-56B section or publication that governs the implemented scheme. - Algorithm evidence: CAVP validation entry, algorithm capability, implementation name, version, vendor, and operating environment. - Module evidence: CMVP certificate, module name and version, security policy, approved services, and approved-mode conditions. - Protocol evidence: TLS, SSH, CMS, VPN, or application profile showing how the shared secret is derived, confirmed, and consumed. - Change trigger: reassess when parameter sets, curves, RSA key sizes, KDFs, protocol profiles, module boundaries, or operating environments change. Sources for this answer: - [NIST CAVP overview](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Explains how CAVP records identify vendor, implementation, operating environment, validation date, and algorithm details. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public validation-search source for checking algorithm records before citing validation evidence. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Public source for matching a product claim to a specific validated cryptographic module record. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://csrc.nist.gov/pubs/fips/140-3/final?ref=sorena.io) - Primary FIPS source for module-validation framing when algorithm evidence is being used inside an approved mode claim. *Recommended next step* *Placement: after practical guidance* ## Operationalize ML-KEM, RSA, and ECDH decisions Use the comparison to produce a source-linked record of schemes, parameters, validation evidence, module boundaries, and customer-facing wording. - [Open Assessment Autopilot for FIPS algorithm evidence](/solutions/assessment.md): Convert ML-KEM, RSA, and ECDH choices into owners, evidence requests, validation checks, and release gates. - [Research FIPS key-establishment source questions](/solutions/research-copilot.md): Resolve source, parameter, validation, and module-boundary questions before public or procurement claims are written. - [Talk through implementation](/contact.md): Review the scheme choices, evidence gaps, and FIPS-facing wording with Sorena. ## Migration planning without overclaiming post-quantum coverage ML-KEM is designed for post-quantum key establishment, while RSA and ECDH are classical public-key mechanisms. That does not make every ML-KEM integration automatically production-ready, FIPS 140-3 validated, protocol-approved, or suitable for every relying party. The migration plan still needs protocol support, hybrid or transition design, algorithm validation, module validation, performance testing, and customer acceptance evidence. When a system keeps RSA or ECDH during migration, document why: interoperability, certificate ecosystem constraints, protocol profile limits, customer requirements, or staged module-validation timing. When it adds ML-KEM, document the target parameter set, validation path, fallback behavior, and how the shared secret is combined or consumed. - Do not describe ML-KEM as a signature replacement; keep it scoped to key encapsulation and key establishment. - Do not describe RSA and ECDH as deprecated unless the specific procurement clause, protocol profile, transition table, or assessor rule says so. - If a hybrid design is used, record exactly how ML-KEM output is combined with classical key-establishment output and which source governs that construction. - Use CAVP and CMVP records to support validation claims, not marketing descriptions of algorithm support. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Grounds post-quantum ML-KEM scope and prevents treating ML-KEM as a signature standard. - [NIST post-quantum cryptography FIPS approval announcement](https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved?ref=sorena.io) - NIST announcement describing FIPS 203 as a key-establishment standard designed for post-quantum migration. - [NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Classical ECDH grounding for migration comparisons that retain elliptic-curve key agreement. - [NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Classical RSA grounding for migration comparisons that retain RSA key agreement or transport. ## Implementation checklist for ML-KEM vs RSA and ECDH Use this checklist as the release or evidence gate for a product-level decision. Each item should be answerable from a source, a validation record, a module security policy, a protocol profile, or an engineering artifact. - Name the controlling source for each scheme: FIPS 203 for ML-KEM, SP 800-56A for ECDH, and SP 800-56B for RSA key establishment. - Record the parameter set, curve, group, RSA key size, KDF, key-confirmation behavior, and protocol profile used by the implementation. - Check CAVP validation evidence for the exact implementation, algorithm capability, version, and operating environment being cited. - Check CMVP evidence before making a FIPS 140-3 module or approved-mode claim; cite the module certificate and security policy, not only the algorithm name. - Document migration exceptions, fallback behavior, hybrid design choices, and customer-facing wording so post-quantum support is not overstated. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Source for ML-KEM implementation and parameter-set checks. - [NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Source for ECDH and other discrete-logarithm key-establishment checks. - [NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Source for RSA key-establishment checks. - [NIST CAVP overview](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Source for the distinction between algorithm validation and module validation evidence. ## Common mistakes to avoid when handling ML-KEM vs RSA and ECDH Most failures come from collapsing three different questions into one sentence: whether the algorithm is specified by NIST, whether an implementation has algorithm validation evidence, and whether a product uses that implementation inside a validated module's approved mode. - Do not cite post-quantum signature standards for this comparison unless the page is also making a separate digital-signature claim. - Do not call ML-KEM a replacement for RSA signatures or ECDSA; it is a key-encapsulation mechanism. - Do not reuse an ECDH or RSA CAVP entry for ML-KEM evidence; each algorithm capability and operating environment needs its own support. - Do not claim a product is FIPS 140-3 validated from a CAVP algorithm validation alone. - Do not hide unsupported transition claims behind phrases such as quantum safe, FIPS ready, or compliant without naming the source and evidence. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Source for limiting ML-KEM claims to key encapsulation and its specified parameter sets. - [NIST CAVP overview](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Source for separating algorithm validation from cryptographic module validation claims. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Source for checking validated module records before using product-level FIPS wording. ## Primary sources - [NIST FIPS 203 ML-KEM standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Primary source for ML-KEM decisions. - Quote: "ML-KEM" - [NIST SP 800-56A Rev. 3 discrete-logarithm key establishment](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final?ref=sorena.io) - Primary source for ECDH key-establishment decisions. - Quote: "Discrete Logarithm Cryptography" - [NIST SP 800-56B Rev. 2 integer-factorization key establishment](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final?ref=sorena.io) - Primary source for RSA key-establishment decisions. - Quote: "Integer Factorization Cryptography" - [NIST CAVP overview](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Source for algorithm-validation evidence rules. - Quote: "cryptographic algorithm validation process" - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Source for module-validation evidence checks. - Quote: "Validated Modules Search" - [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Defines ML-KEM parameter sets, key generation, encapsulation, and decapsulation obligations. - [NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography](https://doi.org/10.6028/NIST.SP.800-56Ar3?ref=sorena.io) - Defines ECDH and finite-field Diffie-Hellman key-agreement requirements. ## Related Topic Guides - [AES FIPS 197 requirements and evidence](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims. - [CAVP and ACVP validation evidence for FIPS algorithms](/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation.md): How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim. - [CAVP Validation Evidence Workflow for FIPS Algorithms](/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow.md): Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records. - [FIPS 180-4 and FIPS 202 secure hash guidance](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Choose and evidence SHA-2, SHA-3, and SHAKE use under FIPS 180-4, FIPS 202, CAVP validation, and FIPS 140-3 module claims. - [FIPS 186-5 and FIPS 204 digital signatures](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries. - [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md): FAQ on how FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA fit FIPS-approved cryptographic algorithm planning, implementation evidence, and validation checks. - [FIPS Algorithm Procurement Evidence FAQ](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md): What procurement teams should collect before accepting FIPS algorithm or module claims: CAVP certificates, CMVP module status, security policy scope, and supplier change triggers. - [FIPS approved algorithm selector workflow](/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow.md): A source-linked workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims. - [FIPS approved mode procurement: certificates, boundaries, and evidence](/artifacts/global/fips-crypto-algorithms/approved-mode-procurement.md): Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase. - [FIPS crypto transition and deprecation tracker](/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker.md): Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status. - [FIPS cryptographic algorithm selector](/artifacts/global/fips-crypto-algorithms/algorithm-selector.md): Choose between FIPS algorithm standards for AES, SHA-2, SHA-3, digital signatures, ML-KEM, ML-DSA, and SLH-DSA without overstating validation scope. - [FIPS KDF and MAC coverage for validated modules](/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage.md): Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries. - [FIPS Key Management Mapping for Algorithms and SSP Evidence](/artifacts/global/fips-crypto-algorithms/key-management-mapping.md): Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records. - [FIPS Procurement Evidence Review Workflow: CAVP, CMVP, Approved Mode](/artifacts/global/fips-crypto-algorithms/procurement-evidence-review-workflow.md): Review FIPS crypto procurement evidence by separating CAVP algorithm certificates from CMVP module certificates, Security Policy scope, approved mode, operating environment, change impact, and retention records. - [FIPS validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md): How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims. - [FIPS-approved cryptographic algorithms FAQ](/artifacts/global/fips-crypto-algorithms/faq.md): Answers to common FIPS algorithm questions: approved security functions, CAVP validation, CMVP module scope, AES modes, SHA-2, SHA-3, signatures, and post-quantum algorithms. - [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md): Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation. - [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md): Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries. - [ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5](/artifacts/global/fips-crypto-algorithms/ml-dsa-vs-ecdsa.md): Compare ML-DSA and ECDSA for FIPS-aligned digital signature designs, including parameter choices, key handling, CAVP algorithm evidence, and CMVP module boundaries. - [Post-quantum FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): A grounded guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ. - [Post-Quantum Migration for FIPS Cryptography](/artifacts/global/fips-crypto-algorithms/post-quantum-migration.md): Plan post-quantum migration for FIPS cryptography by separating ML-KEM key establishment, ML-DSA and SLH-DSA signatures, CAVP algorithm evidence, and CMVP module validation boundaries. - [Post-Quantum Migration Tracker for FIPS 203, 204, and 205](/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker.md): Track post-quantum cryptography migration evidence for FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, CAVP algorithm certificates, and CMVP module boundaries. - [SHA-2 vs SHA-3 under FIPS 180-4 and FIPS 202](/artifacts/global/fips-crypto-algorithms/sha-2-vs-sha-3.md): Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required. - [TLS use-case mapping for FIPS algorithm evidence](/artifacts/global/fips-crypto-algorithms/tls-use-case-mapping.md): Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims. - [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md): FIPS 197 defines AES as a FIPS-approved block cipher, but AES use alone is not the same as CAVP algorithm testing or FIPS 140-3 module validation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh