In August 2024, after eight years of evaluation involving hundreds of cryptographers worldwide, NIST published three final post-quantum cryptography standards: FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures), and FIPS 205 (SLH-DSA for stateless hash-based signatures). These standards represent the most significant change to federal cryptographic requirements since the AES standardization in 2001.
For the first time in the history of standardized cryptography, organizations have approved algorithms that will remain secure against both classical and quantum computers. This article explains what FIPS 203 and FIPS 204 require in plain English, who must comply and when, and how V100 implements both standards to deliver post-quantum video communications.
The Road to Post-Quantum Standards: 2016-2024
NIST's post-quantum standardization process was the largest and most rigorous cryptographic evaluation in history:
NIST PQ standardization timeline
The evaluation process was intentionally slow and conservative. Each candidate was subjected to years of public cryptanalysis by hundreds of independent researchers. Multiple candidates were eliminated after researchers discovered vulnerabilities — exactly the kind of vetting that gives confidence in the surviving algorithms.
FIPS 203: ML-KEM (Key Encapsulation Mechanism)
FIPS 203 specifies ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), formerly known as CRYSTALS-Kyber. Its purpose is to establish a shared secret between two parties over an insecure channel — the same function that ECDH and RSA key exchange perform today, but resistant to quantum attacks.
What ML-KEM does
ML-KEM is a key encapsulation mechanism (KEM), not a key exchange protocol. The distinction matters: in a KEM, one party generates a shared secret and encapsulates it (encrypts it to the other party's public key). The other party decapsulates it (recovers the shared secret using their private key). The shared secret is then used as input to a key derivation function (KDF) to produce session keys for symmetric encryption.
The security of ML-KEM is based on the Module Learning With Errors (MLWE) problem. In simple terms: given a system of linear equations with small random noise added to each equation, find the original solution. When the system uses polynomial rings (modules), this becomes a lattice problem that no known classical or quantum algorithm can solve efficiently.
ML-KEM parameter sets
| Parameter Set | NIST Level | Public Key | Ciphertext | Shared Secret |
|---|---|---|---|---|
| ML-KEM-512 | Level 1 (128-bit) | 800 bytes | 768 bytes | 32 bytes |
| ML-KEM-768 | Level 3 (192-bit) | 1,184 bytes | 1,088 bytes | 32 bytes |
| ML-KEM-1024 | Level 5 (256-bit) | 1,568 bytes | 1,568 bytes | 32 bytes |
V100 uses ML-KEM-768 (NIST Level 3, equivalent to 192-bit classical security). This provides a substantial security margin while keeping key sizes manageable for real-time video signaling. The 1,184-byte public key is a one-time transmission per participant at session start — negligible compared to the megabytes per second of video data.
FIPS 204: ML-DSA (Digital Signature Algorithm)
FIPS 204 specifies ML-DSA (Module-Lattice-Based Digital Signature Algorithm), formerly known as CRYSTALS-Dilithium. Its purpose is to create and verify digital signatures — the same function that ECDSA, RSA signatures, and EdDSA perform today, but resistant to quantum attacks.
What ML-DSA does
Digital signatures prove two things: authentication (this message came from who it claims) and integrity (the message has not been modified). In video conferencing, signatures authenticate participant identities, verify protocol messages, and sign recordings to prove they have not been tampered with.
ML-DSA's security is also based on the Module Learning With Errors problem (the same family as ML-KEM, though the constructions are different). It uses a "Fiat-Shamir with Aborts" framework: the signer creates a commitment, hashes it with the message to produce a challenge, computes a response, and checks that the response does not leak information about the secret key. If it would leak information, the signer aborts and tries again (this is invisible to the verifier).
ML-DSA parameter sets
| Parameter Set | NIST Level | Public Key | Signature | Sign Time |
|---|---|---|---|---|
| ML-DSA-44 | Level 2 (128-bit) | 1,312 bytes | 2,420 bytes | ~0.2 ms |
| ML-DSA-65 | Level 3 (192-bit) | 1,952 bytes | 3,309 bytes | ~0.3 ms |
| ML-DSA-87 | Level 5 (256-bit) | 2,592 bytes | 4,627 bytes | ~0.5 ms |
V100 uses ML-DSA-65 (NIST Level 3) for primary authentication and recording signatures. The 3,309-byte signature is significantly larger than ECDSA's 64 bytes, but V100's Rust implementation keeps signing latency to approximately 0.3 milliseconds — imperceptible in the context of video communication.
FIPS 205: SLH-DSA (Bonus Standard)
While FIPS 203 and 204 are the primary standards, FIPS 205 specifies SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), formerly known as SPHINCS+. Its security relies solely on the properties of hash functions — the most conservative cryptographic assumption known. SLH-DSA produces larger signatures (up to 49,856 bytes) and is slower than ML-DSA, but it provides an insurance policy: even if lattice-based cryptography is broken, hash-based signatures remain secure.
V100 uses SLH-DSA for long-lived attestations (H33-74 substrate proofs) where maximum long-term assurance matters more than signature compactness. This gives V100 three independent mathematical families: MLWE lattices (ML-KEM, ML-DSA), NTRU lattices (FALCON-512), and hash functions (SLH-DSA).
Who Must Comply: The Expanding Compliance Circle
FIPS standards are mandatory for federal systems, but their influence extends far beyond government:
Mandatory: Federal Agencies
All federal civilian agencies must comply with FIPS standards per FISMA (Federal Information Security Modernization Act). The OMB memo on post-quantum cryptography (M-23-02) directs agencies to inventory their cryptographic systems and develop migration plans. CNSA 2.0 sets hard deadlines: 2030 for key exchange, 2033 for signatures.
Mandatory: Federal Contractors and CUI Handlers
Organizations that process Controlled Unclassified Information (CUI) or operate systems on behalf of federal agencies must meet FIPS requirements. This includes defense contractors (CMMC), IT service providers (FedRAMP), and research institutions with federal grants. DFARS 252.204-7012 already requires FIPS 140 validated cryptography — PQ will follow.
Expected: HIPAA-Covered Entities
HIPAA requires "reasonable and appropriate" safeguards for protected health information (PHI). As NIST publishes PQ standards and the quantum threat timeline shortens, regulators will increasingly expect PQ protection for PHI — especially for telehealth recordings that must remain confidential for the patient's lifetime. HHS has not yet mandated PQ, but enforcement guidance will follow NIST publications.
Expected: Financial Services
OCC, FFIEC, and SEC cybersecurity guidance increasingly references NIST standards. Financial institutions handling long-lived sensitive data (trading algorithms, M&A communications, customer PII) face regulatory expectation to adopt PQ protections as standards mature. The NY DFS cybersecurity regulation (23 NYCRR 500) requires "commercially reasonable" encryption — PQ will become part of that standard.
Recommended: All Organizations with Long-Lived Sensitive Data
Any organization whose data sensitivity outlasts the quantum timeline (estimated 2030-2040) should adopt FIPS 203/204 now. This is not a compliance mandate — it is a risk management decision. The harvest-now-decrypt-later threat affects any organization whose encrypted traffic has future intelligence value.
How V100 Implements FIPS 203 and FIPS 204
V100 implements both standards across its entire video communication stack. There is no "PQ mode" toggle or enterprise tier requirement — every V100 session uses FIPS 203 key exchange and FIPS 204 signatures by default.
V100 FIPS 203/204 implementation details
Practical Implications: What Changes for Users
For V100 users, the implementation of FIPS 203 and 204 requires no action. The post-quantum cryptography is transparent:
No configuration required. ML-KEM-768 and ML-DSA-65 are the default (and only) key exchange and signature algorithms. There is no "enable PQ" setting.
No perceptible latency. The PQ operations add less than 1 millisecond total to session establishment. Users cannot distinguish a PQ session from a classical one by feel.
No bandwidth concerns. ML-KEM public keys (1,184 bytes) and ML-DSA signatures (3,309 bytes) are transmitted once during signaling. Video streams are megabytes per second — a few extra kilobytes of signaling is invisible.
Visual indicator. V100 displays a green PQ-E2E badge in the meeting UI, confirming that the session is using post-quantum encryption. This badge indicates FIPS 203/204 compliance at a glance.
The CNSA 2.0 Compliance Timeline
The NSA's CNSA 2.0 establishes the most aggressive timeline for PQ adoption. Organizations that supply to or interact with the federal government should treat these dates as planning constraints:
| Deadline | Requirement | Applies To | V100 Status |
|---|---|---|---|
| 2025 | PQ software/firmware signing | NSS vendors | Compliant |
| 2027 | PQ for web/cloud key exchange | NSS infrastructure | Compliant |
| 2030 | All key establishment PQ | All NSS | Compliant |
| 2033 | All digital signatures PQ | All NSS | Compliant |
V100 meets every CNSA 2.0 requirement today — four to seven years ahead of the compliance deadlines. Organizations that deploy V100 now can demonstrate proactive compliance rather than scrambling to meet deadlines.
Frequently Asked Questions
Can I use ML-KEM without ML-DSA (or vice versa)?
Technically yes, but it provides incomplete protection. ML-KEM without ML-DSA gives you quantum-safe confidentiality but classical-only authentication (vulnerable to impersonation attacks). ML-DSA without ML-KEM gives you quantum-safe authentication but classical-only confidentiality (vulnerable to HNDL). A complete post-quantum system requires both. V100 deploys both by default.
Are FIPS 203/204 backward-compatible with existing systems?
Not directly. ML-KEM and ML-DSA are entirely new algorithms with different key formats, message sizes, and APIs compared to RSA/ECDH/ECDSA. Systems must be updated to support them. This is why hybrid modes (PQ + classical) are recommended during transition: they maintain interoperability with legacy systems while adding PQ protection. V100's hybrid mode (ML-KEM-768 + X25519) follows this best practice.
What if ML-KEM or ML-DSA is broken in the future?
This is why V100 uses three independent algorithm families. If MLWE lattices (underlying both ML-KEM and ML-DSA) are broken, V100 still has FALCON-512 (NTRU lattices, a different mathematical assumption) and SLH-DSA (hash-based, completely independent of lattice problems). Breaking all three simultaneously would require advances against three separate areas of mathematics — an extraordinarily unlikely scenario.
Do FIPS 203/204 replace FIPS 186 (ECDSA/RSA signatures)?
Eventually, yes. FIPS 186 algorithms (RSA, DSA, ECDSA) will be deprecated for new systems. However, they will remain approved for legacy systems during a transition period. NIST has not yet set a formal deprecation date for FIPS 186, but CNSA 2.0 makes clear that national security systems must transition by 2033. For new deployments in 2026, FIPS 204 (ML-DSA) should be the default choice.
Is FIPS 140-3 validation required for FIPS 203/204 implementations?
For federal systems and contractors, yes — cryptographic modules must be FIPS 140-3 validated. NIST's CMVP (Cryptographic Module Validation Program) is in the process of updating its testing requirements to include ML-KEM and ML-DSA. V100's implementation is designed for FIPS 140-3 validation and will submit for validation as CMVP testing guidance is finalized.
FIPS 203 + 204 compliant video, available now
V100 implements ML-KEM-768 (FIPS 203) and ML-DSA-65 (FIPS 204) on every video session by default. Meet CNSA 2.0 requirements years ahead of the deadline. No configuration required — every call is post-quantum from day one.