Dilithium ML-DSA-65 Attestation | HICS-PQ

Q: Is Dilithium the same thing as ML-DSA?

Yes. Dilithium (from CRYSTALS-Dilithium) is the pre-standardization name for the algorithm NIST finalized as ML-DSA in FIPS 204. This page attests H33's ML-DSA-65 implementation.

Q: Does H33 own or prove the ML-DSA standard?

No. ML-DSA (FIPS 204) is an external NIST standard. H33 implements it, conforms to it, and verifies against its KAT vectors. The attestation on this page proves the implementation's quality, not the underlying standard, which H33 does not own or invent.

Q: If two of the three signature families verify, is the evidence accepted?

No. Acceptance is an AND of all three families: ML-DSA and FALCON/FN-DSA and SLH-DSA must all validate. A 2-of-3 outcome is a false grant and is rejected. There is no majority or threshold acceptance across the crypto families.

Q: How does ML-DSA relate to HATS, Verification, and Agent-008?

ML-DSA is used by H33-74 to produce portable evidence. HATS records and continuously monitors operations. Verification renders the independent verdict on that evidence. Agent-008 governs the decision made under it. The primitive itself is the external NIST standard the evidence is built from.

Dilithium (ML-DSA) is an external NIST post-quantum digital-signature standard — "Dilithium" is the pre-standard CRYSTALS name for the algorithm NIST finalized as ML-DSA in FIPS 204 (August 2024). This page is a HICS-PQ attestation of H33's implementation of ML-DSA-65. H33 does not own, invent, or "prove" the ML-DSA standard; it implements, conforms to, and verifies against FIPS 204, and uses ML-DSA as one of three signature families that produce the portable 74-byte post-quantum evidence primitive anchored by H33-74.

Why this attestation exists. A signature implementation is only trustworthy if its correctness, side-channel behavior, and FIPS 204 conformance can be checked by someone other than its author. Every metric below is computed by the HICS-PQ algorithm, proven by a STARK, and signed — so the score is verifiable, not asserted.

PQ Library Attestations

Dilithium ML-DSA-65 Kyber ML-KEM-768 FALCON-512 SPHINCS+ SLH-DSA BFV FHE CKKS FHE

100 / 100

HICS-PQ Attestation

dilithium.rs + dilithium_native.rs + dilithium_ntt.rs

Last scanned: March 30, 2026 · Auto-updates on release

✓ STARK Proof Valid

✓ Dilithium Signature Valid

✓ Certificate Current

Correctness 100 / 100

Weight: 40%

✓ 26 / 26 unit tests passing (incl. 8 KAT)
✓ Level 2, 3, 5 keygen-sign-verify round-trip
✓ Cross-level verification correctly rejects
✓ Tampered message detection verified
✓ Expanded signer matches regular sign output
✓ Base64 encoding round-trip verified
✓ Batch sign correctness verified
✓ Level detection from key bytes validated

Security 100 / 100

Weight: 30%

✓ Branchless NTT butterfly (aarch64 NEON)
✓ Branchless conditional reduce (caddq)
✓ Branchless polynomial add/sub
✓ Montgomery multiplication (no division)
✓ No secret-dependent branching in NTT
✓ Invalid signature rejection verified
✓ FIPS 204 parameter validation (KAT-1)
✓ Timing consistency analysis (CV < threshold)

Performance 97 / 100

Weight: 15%

✓ Sign + Verify: 189µs per 32-user batch
✓ Batch attestation: 1 sign per 32 users
✓ Montgomery NTT: zero division in hot path
✓ NEON acceleration on aarch64
✓ Expanded key pool: amortized keygen
✓ Public key: 1,952 bytes (spec-compliant)
✓ Signature: 3,309 bytes (spec-compliant)

Standards 100 / 100

Weight: 15%

✓ NIST FIPS 204 (ML-DSA) compliant
✓ q = 8,380,417 (spec parameter)
✓ n = 256, K = 6, L = 5 (Level 3)
✓ ETA = 4, TAU = 49, GAMMA1 = 2^19
✓ All 3 security levels implemented
✓ FIPS 204 NTT zetas (reference values)
✓ Pure Rust, zero C dependencies

Parameter Specifications

Parameter	Value
Security Level	NIST Level 3 (~AES-192)
Polynomial Degree (n)	256
Modulus (q)	8,380,417
Matrix Dimensions (K x L)	6 x 5
Public Key Size	1,952 bytes
Secret Key Size	4,032 bytes
Signature Size	3,309 bytes
Batch Attestation Latency	189 µs (32 users)
Source Files	3 (3,127 lines)
Unit Tests	26 (incl. 8 FIPS 204 KAT)
Implementation	Pure Rust + NEON

Source Files

src/pqc/dilithium.rs 1,369 lines — API, keypair structs, batch operations, key pool

src/pqc/dilithium_native.rs 990 lines — Pure Rust ML-DSA-65, Montgomery NTT, ~2x vs C

src/pqc/dilithium_ntt.rs 768 lines — NTT module, FIPS 204 zetas, NEON branchless butterfly

Verify STARK Proof Download .h33 Certificate Dilithium Deep Dive How Attestation Works

When to Use ML-DSA (Dilithium)

✓ Use ML-DSA when you need post-quantum proof of authorship or integrity — the replacement for RSA, ECDSA, and Ed25519 signatures.
✓ Use it as one family, not the whole answer. H33 signs evidence with three independent families — ML-DSA and FALCON/FN-DSA and SLH-DSA — and accepts only when all three validate. A 2-of-3 result is a false grant and is refused; there is no majority pass.
! Do not use ML-DSA for key exchange — that is ML-KEM (FIPS 203, see Kyber). And do not re-implement FIPS 204 yourself if you only need to consume or verify signatures.

Concept Boundaries

The primitive (ML-DSA / ML-KEM / SLH-DSA) is an external NIST/FIPS standard that H33-74 uses to produce the evidence — H33-74 does not own or invent the primitive.
H33-74 produces the portable evidence; it does not record or continuously monitor operations — that is HATS.
H33-74 produces the evidence; the independent verdict on it is rendered by Verification, and the decision made under it is governed by Agent-008.

Frequently Asked Questions

Is "Dilithium" the same thing as ML-DSA?

Yes. "Dilithium" (from CRYSTALS-Dilithium) is the pre-standardization name for the algorithm NIST finalized as ML-DSA in FIPS 204. This page attests H33's ML-DSA-65 implementation.

Does H33 own or prove the ML-DSA standard?

No. ML-DSA (FIPS 204) is an external NIST standard. H33 implements it, conforms to it, and verifies against its KAT vectors. The attestation on this page proves the implementation's quality — not the underlying standard, which H33 does not own or invent.

If two of the three signature families verify, is the evidence accepted?

No. Acceptance is an AND of all three families: ML-DSA and FALCON/FN-DSA and SLH-DSA must all validate. A 2-of-3 outcome is a false grant and is rejected. There is no majority or threshold acceptance across the crypto families.

How does ML-DSA relate to HATS, Verification, and Agent-008?

ML-DSA is used by H33-74 to produce portable evidence. HATS records and continuously monitors operations. Verification renders the independent verdict on that evidence. Agent-008 governs the decision made under it. The primitive itself is the external NIST standard the evidence is built from.