Post-Quantum Algorithm Compatibility Matrix

1. Scope

This document defines the compatibility status of NIST-standardized post-quantum cryptographic algorithms across H33 products and services. Each cell in the matrix indicates whether a given algorithm is supported, required, optional, or not applicable for the specified product.

Algorithm references follow NIST FIPS publication numbers. Security level designations follow the NIST Post-Quantum Cryptography Standardization process category definitions, where Level 1 corresponds to the computational difficulty of AES-128 key recovery, Level 3 to AES-192, and Level 5 to AES-256.

This matrix reflects production deployments as of the publication date. Planned capabilities are noted with target dates where available.

2. Algorithm Reference

The following table enumerates the post-quantum algorithms evaluated in this compatibility matrix, with their NIST designations, underlying hardness assumptions, and key material sizes.

Algorithm	NIST Standard	Type	Security Level	Public Key	Signature / Ciphertext	Hardness Assumption
ML-DSA-65	FIPS 204	Digital Signature	Level 3	1,952 bytes	3,293 bytes	Module-LWE (MLWE)
ML-KEM-1024	FIPS 203	Key Encapsulation	Level 5	1,568 bytes	1,568 bytes (ciphertext)	Module-LWE (MLWE)
FALCON-512	FIPS 206 (pending)	Digital Signature	Level 1	897 bytes	666 bytes (avg)	NTRU lattice
SLH-DSA-SHA2-128f	FIPS 205	Digital Signature	Level 1	32 bytes	17,088 bytes	Hash function preimage resistance

3. Status Designations

Required

The algorithm is a mandatory dependency. The product cannot function without it. All code paths invoke this algorithm unconditionally.

Supported

The algorithm is implemented, tested, and available in production. It is invoked when the configuration or protocol context selects it.

Optional

The algorithm is supported but not required for baseline operation. Omitting it does not degrade core functionality.

N/A

The algorithm is not applicable to this product. The product's function does not involve the algorithm class (e.g., key encapsulation is not applicable to a document signing product).

Planned

Implementation is committed to the roadmap with a target date. Not yet available in production.

4. Primary Compatibility Matrix

Each row represents an H33 product or service. Each column represents one of the four post-quantum algorithms under evaluation.

Product	ML-DSA-65 FIPS 204	ML-KEM-1024 FIPS 203	FALCON-512 FIPS 206*	SLH-DSA-SHA2-128f FIPS 205
H33-74 Attestation	Required	N/A	Required	Required
H33-128 (BFV)	Required	N/A	Required	Required
H33-256 (Level 5)	Required	N/A	Required	Required
H33-CKKS	Required	N/A	Required	Required
H33-TFHE	Required	N/A	Required	Required
ArchiveSign	Required	N/A	Required	Required
H33-Agent-Zero	Required	Supported	Required	Required
H33-Gateway	Supported	Required	Supported	Supported
H33-MPC	Required	Required	Optional	Optional
H33-Key	Supported	Required	Supported	Supported
H33-Vault	Required	Required	Required	Required
H33-Shield	Required	Supported	Required	Required
H33-Health	Required	Required	Required	Required
BotShield	Required	N/A	Optional	Optional
FraudShield	Required	N/A	Required	Required
DeviceProof	Required	Supported	Required	Required
ZK-KYC	Required	N/A	Required	Required
Biometrics (FHE)	Required	N/A	Required	Required

5. Algorithm-Specific Notes

5.1. ML-DSA-65 (FIPS 204)

ML-DSA-65 is the primary digital signature algorithm across the H33 platform. It is used in all attestation pipelines and constitutes the first layer of the three-key signing bundle. ML-DSA-65 provides NIST Level 3 security (equivalent computational difficulty to AES-192 key recovery).

The algorithm is based on the Module Learning With Errors (MLWE) problem over polynomial rings. Key generation, signing, and verification are deterministic given fixed randomness. H33 implementations use the deterministic variant specified in FIPS 204, Section 6.

Performance characteristics on Graviton4 (ARM64): signing at approximately 28 microseconds per operation; verification at approximately 12 microseconds per operation. These timings include the domain separator prepend specified in the H33-74 specification.

5.2. ML-KEM-1024 (FIPS 203)

ML-KEM-1024 provides key encapsulation at NIST Level 5 security. It is required in products that establish encrypted channels (H33-Gateway, H33-Key, H33-Vault, H33-MPC, H33-Health) and optional or not applicable in products that only sign or attest.

The algorithm produces a 32-byte shared secret from a 1,568-byte ciphertext exchange. H33 uses ML-KEM-1024 exclusively for session key establishment; long-term key material is managed through the three-key signing infrastructure.

Encapsulation and decapsulation are each approximately 40 microseconds on Graviton4. The shared secret is used as input to HKDF-SHA3-256 to derive per-session symmetric keys.

5.3. FALCON-512

FALCON-512 is the second signature algorithm in the three-key bundle. Its security rests on the hardness of the Short Integer Solution (SIS) problem over NTRU lattices, which is structurally independent from the MLWE assumption underlying ML-DSA-65.

FALCON-512 provides NIST Level 1 security. It produces compact signatures (666 bytes average) relative to other lattice-based schemes, at the cost of requiring a Gaussian sampler during signing. H33 implementations use constant-time sampling to prevent timing side-channels.

FALCON is pending final standardization as FIPS 206. H33 tracks the draft standard and will adopt the final version upon publication. Current implementations conform to the Round 3 submission with the modifications specified in the NIST draft.

5.4. SLH-DSA-SHA2-128f (FIPS 205)

SLH-DSA-SHA2-128f is the third signature algorithm in the three-key bundle. Its security depends exclusively on the preimage and second-preimage resistance of SHA-256 -- a fundamentally different mathematical assumption from the lattice problems underlying ML-DSA-65 and FALCON-512.

The algorithm is stateless, which eliminates the state-management complexity and single-point-of-failure risks associated with stateful hash-based schemes (XMSS, LMS). The trade-off is a larger signature size (17,088 bytes). The "f" parameter set prioritizes signing speed over signature compactness.

SLH-DSA-SHA2-128f provides NIST Level 1 security. The H33 production implementation uses the OpenSSL SHA-256 acceleration shim for FIPS-compatible hash computation. Signing latency is approximately 3.2 milliseconds on Graviton4; verification is approximately 1.8 milliseconds.

6. Three-Key Bundle Composition

All H33 attestation products require the full three-key signing bundle. The bundle produces three independent signatures over identical input. An attestation is valid if and only if all three signatures verify. This design ensures that compromise of any single post-quantum hardness assumption does not compromise attestation integrity.

Bundle Slot	Algorithm	Hardness Class	Signature Size	Key Size (pk + sk)
Slot 1	ML-DSA-65	MLWE lattice	3,293 bytes	1,952 + 4,032 bytes
Slot 2	FALCON-512	NTRU lattice	~666 bytes	897 + 1,281 bytes
Slot 3	SLH-DSA-SHA2-128f	Hash preimage	17,088 bytes	32 + 64 bytes

Total signature bundle size: approximately 21,047 bytes before H33-74 distillation. The H33-74 attestation primitive compresses the verification-relevant metadata to 74 bytes; the full signatures are retained in the attestation receipt for independent verification.

7. FHE Algorithm Independence

The FHE engines (H33-128, H33-256, H33-CKKS, H33-TFHE) operate on lattice-based encryption parameters that are structurally separate from the post-quantum signature algorithms. FHE security depends on the Ring-LWE or LWE problems with parameters selected to meet or exceed NIST Level 1 security thresholds.

The signature algorithms listed in this matrix are used to attest the results of FHE computations. They do not participate in the FHE encryption, evaluation, or decryption operations themselves. This separation ensures that signature algorithm updates or replacements do not require changes to FHE parameter sets.

Conversely, changes to FHE parameters (e.g., polynomial degree, modulus chain length) do not affect the signature layer. The two subsystems interact only at the attestation boundary, where the FHE computation output is signed by the three-key bundle.

8. FIPS Compliance Notes

Algorithm	FIPS Standard	Publication Date	H33 Conformance Status	Test Vector Source
ML-DSA-65	FIPS 204	August 2024	Conformant	NIST ACVTS
ML-KEM-1024	FIPS 203	August 2024	Conformant	NIST ACVTS
FALCON-512	FIPS 206 (draft)	Pending	Draft-conformant	Round 3 KATs
SLH-DSA-SHA2-128f	FIPS 205	August 2024	Conformant	NIST ACVTS

All FIPS-published algorithms are validated against NIST Automated Cryptographic Validation Test System (ACVTS) vectors. FALCON-512 is validated against the Round 3 Known Answer Test (KAT) vectors and will be re-validated against FIPS 206 vectors upon publication.