Artifact GuideGLOBALFIPS-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.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
May 28, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
10

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 28, 2026
Overview

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.

Side-by-side comparison

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.

Review all sources
First framework
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.

Second framework
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.

Comparison row 1

Scope

FIPS 203 ML-KEM

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.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 2

Covered actors

FIPS 203 ML-KEM

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.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH 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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 3

Trigger

FIPS 203 ML-KEM

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.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 4

Core obligations

FIPS 203 ML-KEM

Record the ML-KEM parameter set and the supported operations, such as KeyGen and EncapDecap, for the implementation and operating environment being cited.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 5

Evidence

FIPS 203 ML-KEM

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.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 6

Timing

FIPS 203 ML-KEM

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

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 7

Enforcement

FIPS 203 ML-KEM

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.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 8

Overlap

FIPS 203 ML-KEM

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.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism StandardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Revision 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm CryptographySources 1
Operational implication

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 StandardSources 1
Comparison row 9

Practical decision rule

FIPS 203 ML-KEM

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.

NIST FIPS 203 ML-KEM standardSources 1
RSA and ECDH key establishment

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.

NIST SP 800-56A Rev. 3 discrete-logarithm key establishmentSources 1NIST SP 800-56B Rev. 2 integer-factorization key establishmentSources 2
Operational implication

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 CMVP validated modules searchSources 1
Practical decision rule

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.
NIST FIPS 203 ML-KEM standardSources 1NIST SP 800-56A Rev. 3 discrete-logarithm key establishmentSources 2NIST SP 800-56B Rev. 2 integer-factorization key establishmentSources 3NIST CAVP overviewSources 4NIST CMVP validated modules searchSources 5
Section 1

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
Defines ML-KEM, its parameter sets, and its key-generation, encapsulation, and decapsulation scope.
NIST SP 800-56A Rev. 3 discrete-logarithm key establishment
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
Primary source for RSA-based pair-wise key-establishment schemes.
NIST CAVP overview
Explains that algorithm validation tests approved algorithms and is a prerequisite for cryptographic module validation.
Section 2

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
Grounds the ML-KEM side of the decision and the three named parameter sets.
NIST SP 800-56A Rev. 3 discrete-logarithm key establishment
Grounds ECDH scheme and parameter decisions.
NIST SP 800-56B Rev. 2 integer-factorization key establishment
Grounds RSA key-establishment decisions and key-confirmation context.
NIST CMVP validated modules search
Official source for checking whether a cryptographic module has been validated to FIPS 140-1, FIPS 140-2, or FIPS 140-3.
Section 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
Explains how CAVP records identify vendor, implementation, operating environment, validation date, and algorithm details.
NIST CAVP validation search
Public validation-search source for checking algorithm records before citing validation evidence.
NIST CMVP validated modules search
Public source for matching a product claim to a specific validated cryptographic module record.
NIST FIPS 140-3 security requirements for cryptographic modules
Primary FIPS source for module-validation framing when algorithm evidence is being used inside an approved mode claim.
Recommended next step

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.

Assessment workflow
Open Assessment Autopilot for FIPS algorithm evidence

Convert ML-KEM, RSA, and ECDH choices into owners, evidence requests, validation checks, and release gates.

Explore next step
Research workflow
Research FIPS key-establishment source questions

Resolve source, parameter, validation, and module-boundary questions before public or procurement claims are written.

Explore next step
Talk to Sorena
Talk through implementation

Review the scheme choices, evidence gaps, and FIPS-facing wording with Sorena.

Explore next step
Section 4

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
Grounds post-quantum ML-KEM scope and prevents treating ML-KEM as a signature standard.
NIST post-quantum cryptography FIPS approval announcement
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
Classical ECDH grounding for migration comparisons that retain elliptic-curve key agreement.
NIST SP 800-56B Rev. 2 integer-factorization key establishment
Classical RSA grounding for migration comparisons that retain RSA key agreement or transport.
Section 5

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
Source for ML-KEM implementation and parameter-set checks.
NIST SP 800-56A Rev. 3 discrete-logarithm key establishment
Source for ECDH and other discrete-logarithm key-establishment checks.
NIST SP 800-56B Rev. 2 integer-factorization key establishment
Source for RSA key-establishment checks.
NIST CAVP overview
Source for the distinction between algorithm validation and module validation evidence.
Section 6

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
Source for limiting ML-KEM claims to key encapsulation and its specified parameter sets.
NIST CAVP overview
Source for separating algorithm validation from cryptographic module validation claims.
NIST CMVP validated modules search
Source for checking validated module records before using product-level FIPS wording.
Primary sources

References and citations

NIST CAVP overview
csrc.nist.gov
Referenced sections
  • Source for algorithm-validation evidence rules.
"cryptographic algorithm validation process"
NIST CAVP validation search
csrc.nist.gov
Referenced sections
  • Public validation-search source for checking algorithm records before citing validation evidence.
"validation-search"
Related guides

Explore more topics

AES FIPS 197 requirements and evidence
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
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
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
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
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
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
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
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
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
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
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
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
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
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
How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
FIPS-approved cryptographic algorithms FAQ
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
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
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
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
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
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
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
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
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?
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.