Back to Home

NIST FIPS 203/204 Compliance

Last Updated: August 2, 2026

Here is a detailed breakdown of how we abide by NIST FIPS 203/204 and how we can mathematically and architecturally prove this compliance to auditors, customers, or partners.

1. Do we abide by NIST FIPS 203/204?

Yes. The platform fully abides by the official standards:

  • FIPS 203 (ML-KEM): We use the ML-KEM-768 (crystals-kyber) algorithm for session key encapsulation.
  • FIPS 204 (ML-DSA): We use ML-DSA-65 (crystals-dilithium) for identity verification and digital signatures.

How do we prove it?

Our cryptographic core implements these algorithms via liboqs (Open Quantum Safe). This is the industry-standard, globally audited open-source library used by major technology firms (like Cloudflare and Google) to implement NIST post-quantum standards.

  • Ciphertext Lengths: You can verify that we conform to the exact parameters of the FIPS 203 standard. For example, in our Python PQC server code (cqws_pqc_server.py), the ciphertext length generated and transmitted is exactly 1088 bytes, which is the mathematically defined ciphertext size for standard-compliant ML-KEM-768.
  • Key Generation: Our licensing and secure daemon start-ups hook into liboqs to generate standard-compliant module-lattice-based public and private keys.

2. Standard Compliance vs. Lab Certification (Defensibility)

In enterprise security, it is critical to distinguish between Algorithm Compliance and Cryptographic Module Certification:

  • Algorithm Compliance (What we have now): The mathematics and code in CQWS are 100% compliant and identical to the FIPS 203/204 specifications published by NIST in August 2024. Any auditor inspecting the codebase or running packet captures can verify that standard-compliant handshakes are taking place.
  • CMVP / FIPS 140-3 Certification (Roadmap): A formal FIPS 140-3 "Certification" requires submitting the software module to a NIST-accredited third-party laboratory for a multi-year evaluation process (CMVP - Cryptographic Module Validation Program).
Defensible Statement

"The CQWS cryptographic module is engineered in strict conformance with the mathematical specifications of NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) using audited open-source implementations. Formal FIPS 140-3 CMVP validation is on the product roadmap."

3. How the Double-Locked Hybrid Handshake Works

The hybrid key exchange combining ML-KEM-768 and classical X25519 is the absolute gold standard recommended by the NSA (CNSA 2.0 guidelines) and European agencies (ANSSI). Here is the breakdown:

  • Classical Layer (X25519 / RFC 7748): Based on the hardness of Elliptic Curve Diffie-Hellman. It provides standard protection against all classical eavesdroppers and is extremely fast.
  • Quantum Layer (ML-KEM-768 / FIPS 203): Based on the hardness of the Learning With Errors (LWE) problem over module lattices. Standard computers cannot solve this, and even a Cryptographically Relevant Quantum Computer (CRQC) running Shor's algorithm cannot solve it.
The "Double Lock" (XOR combination)

During the handshake, both a classical X25519 shared secret (S_classical) and an ML-KEM-768 shared secret (S_quantum) are generated independently.

The final symmetric key used to encrypt the traffic is derived by combining both secrets using a key derivation function (KDF) or XOR mixing:

Final Key = KDF(S_classical || S_quantum)

Why this is bulletproof: If a mathematician breaks lattice cryptography tomorrow, the classical X25519 layer still protects the data. If a quantum computer is built tomorrow to break X25519, the ML-KEM-768 layer protects the data. An attacker must break both completely independent mathematical problems to compromise the data.