How to Test Whether Your System Is Quantum-Safe

Claiming your system is quantum-safe is easy. Proving it is hard. The difference between the two is the difference between marketing and engineering. This post provides a concrete, technical methodology for testing whether your system actually resists quantum attack, covering algorithm inventory, Known Answer Test (KAT) validation, hybrid mode verification, performance benchmarking, and the common failure modes that catch teams who ship before they validate.

Step 1: Cryptographic Algorithm Inventory

You cannot test what you have not mapped. The first step in quantum safety testing is a complete inventory of every cryptographic algorithm used in your system. This inventory must cover four categories.

Key exchange and encapsulation: What algorithms negotiate session keys? If your system uses TLS, check the cipher suites configured in your TLS library. Run openssl s_client -connect your.server:443 and inspect the negotiated cipher suite. If you see ECDHE, RSA, or DHE in the key exchange field, those key exchanges are quantum-vulnerable. Quantum-safe alternatives include ML-KEM (FIPS 203) and hybrid modes that combine ECDHE with ML-KEM.

Digital signatures: What algorithms sign data, certificates, and tokens? Check your certificate chain: are the certificates signed with RSA or ECDSA? Check your JWT library: are tokens signed with RS256 or ES256? Check your code signing: what algorithm signs your build artifacts? Quantum-vulnerable signature algorithms include RSA, ECDSA, and EdDSA. Quantum-safe alternatives include ML-DSA (FIPS 204) and SLH-DSA (FIPS 205).

Symmetric encryption: What algorithms encrypt data at rest and in transit? AES-128, AES-256, and ChaCha20 are generally considered quantum-resistant with appropriate key sizes (AES-256 provides 128 bits of security against Grover's algorithm). However, the key exchange mechanism used to distribute symmetric keys may be quantum-vulnerable. A system using AES-256 with RSA key exchange is quantum-vulnerable at the key exchange layer, even though the symmetric encryption itself is quantum-resistant.

Hash functions: What algorithms produce hashes for integrity checking, password storage, and key derivation? SHA-256 and SHA-3 are quantum-resistant. MD5 and SHA-1 are broken even classically and must be replaced regardless of quantum considerations.

The inventory should be documented as a spreadsheet or structured document listing every algorithm, where it is used, the library that implements it, and whether it is quantum-vulnerable. This inventory is the foundation for everything that follows.

Step 2: Known Answer Test (KAT) Validation

Once you have identified the post-quantum algorithms in your system (or the algorithms you plan to deploy), the next step is validating that your implementation produces correct results. This is where Known Answer Tests come in.

NIST publishes KAT vectors for each approved post-quantum algorithm. These are test inputs with known correct outputs. If your implementation produces the correct output for every KAT vector, it is implementing the algorithm correctly. If it fails any KAT vector, the implementation is broken, regardless of how well it performs or how clean the code looks.

This is not optional. We learned this lesson at H33 when a hand-rolled ARM SHA-256 intrinsics implementation passed all local tests but failed every NIST KAT vector. The code was fast, clean, and wrong. KAT validation must happen before any other testing. Performance numbers for an implementation that fails KAT vectors are meaningless.

For ML-KEM (FIPS 203), the KAT vectors test key generation, encapsulation, and decapsulation. Your implementation should produce identical ciphertexts and shared secrets for the provided key pairs and random seeds. For ML-DSA (FIPS 204), the KAT vectors test key generation, signing, and verification. Your implementation should produce identical signatures for the provided key pairs and messages. For SLH-DSA (FIPS 205), the KAT vectors test the same operations with the hash-based signature scheme.

Run the KAT validation suite against your implementation on the target hardware. Do not assume that an implementation that passes KATs on x86 will pass on ARM, or vice versa. Platform-specific optimizations (SIMD intrinsics, assembly routines, compiler-specific behavior) can introduce errors that only manifest on specific architectures.

Step 3: Hybrid Mode Testing

If your system uses hybrid mode (combining classical and post-quantum algorithms), test the hybrid key derivation independently. The most common hybrid approach combines the shared secrets from classical ECDH and post-quantum ML-KEM using a key derivation function (typically HKDF-SHA256 or SHA3).

Test the following properties of your hybrid implementation:

Classical fallback: If the ML-KEM component is removed (simulating a client that does not support PQC), does the connection fall back to classical-only key exchange? This fallback must work correctly for backward compatibility.

PQC-only mode: If the ECDH component is removed, does the connection still establish using ML-KEM alone? This verifies that the PQC key exchange is functional independently.

Key derivation correctness: Verify that the combined shared secret is derived from both the ECDH shared secret and the ML-KEM shared secret. A common bug is to derive the session key from only one of the two shared secrets, which would make the connection either non-quantum-safe (if using only ECDH) or non-classically-safe (if using only ML-KEM).

Downgrade attack resistance: Verify that an active attacker cannot force the connection to downgrade from hybrid to classical-only. This requires testing the TLS handshake negotiation to ensure that a man-in-the-middle cannot strip the ML-KEM component from the ClientHello.

Step 4: Performance Benchmarking

Post-quantum algorithms have different performance characteristics than classical algorithms. ML-KEM key generation is faster than RSA key generation. ML-DSA signing is faster than RSA signing for equivalent security levels. SLH-DSA signing is slower than both due to the hash-based construction. Key sizes and signature sizes are larger across all PQC algorithms compared to their classical equivalents.

Benchmark the following operations on your target hardware:

Key generation time: How long does it take to generate a key pair for each PQC algorithm in your system? ML-KEM-768 key generation is typically sub-millisecond. ML-DSA-65 key generation is typically sub-millisecond. SLH-DSA-SHA2-128f key generation involves precomputing hash trees and can take several milliseconds.

Signing and verification time: How long does it take to sign a message and verify a signature? ML-DSA-65 signing is typically under 1 millisecond. SLH-DSA-SHA2-128f signing is slower due to the Merkle tree traversal. Verification times are typically faster than signing times for all PQC signature schemes.

Encapsulation and decapsulation time: For ML-KEM, how long does encapsulation (the sender's operation) and decapsulation (the receiver's operation) take? Both are typically sub-millisecond.

Bandwidth impact: Measure the additional bandwidth consumed by PQC artifacts. ML-KEM-768 public keys are 1,184 bytes (versus 32 bytes for X25519). ML-DSA-65 signatures are 3,293 bytes (versus 64 bytes for Ed25519). SLH-DSA-SHA2-128f signatures are 17,088 bytes. These sizes affect TLS handshake duration, API response sizes, and storage requirements.

Sustained throughput: Run extended benchmarks (30 seconds minimum, 120 seconds preferred) to validate that performance does not degrade under sustained load. Short burst benchmarks can mask thermal throttling, memory allocation issues, and other problems that only manifest under sustained operation.

Step 5: Interoperability Testing

Your PQC implementation must interoperate with other implementations. If you are using ML-KEM for TLS key exchange, test that your server can complete a handshake with clients using different ML-KEM implementations (OpenSSL, BoringSSL, liboqs, etc.). If you are using ML-DSA for document signing, test that signatures produced by your implementation can be verified by other implementations, and vice versa.

Interoperability failures are common in the early stages of PQC adoption because implementations may differ in their handling of edge cases, serialization formats, or parameter encoding. The NIST PQC implementations provide reference code, but production implementations may diverge from the reference in ways that cause interoperability issues.

Test interoperability with at least two independent implementations of each PQC algorithm you deploy. Record any interoperability failures, diagnose the root cause, and ensure that your implementation conforms to the FIPS specification, not just to the reference implementation.

Step 6: Cryptographic Agility Testing

Crypto agility is the ability to switch cryptographic algorithms without rebuilding the system. Test that your system supports algorithm negotiation: can the system offer multiple algorithms and negotiate the preferred one with the peer? Can the system be configured to add or remove algorithms without code changes? Can the system handle a scenario where a deployed algorithm is deprecated and must be replaced?

The practical test is straightforward: configure your system to use a specific PQC algorithm, then change the configuration to use a different PQC algorithm without modifying any code. If this requires a code change, rebuild, or redeployment beyond a configuration update, your system is not crypto-agile.

Crypto agility is not just a convenience feature. It is a critical risk mitigation for PQC deployment. If a vulnerability is discovered in one PQC algorithm, a crypto-agile system can switch to an alternative algorithm in hours. A system without crypto agility may require weeks or months to update, during which time it remains exposed.

Step 7: Certificate Chain Validation

If your system uses X.509 certificates, test the entire certificate chain for quantum vulnerability. A quantum-safe leaf certificate signed by a quantum-vulnerable root CA does not provide quantum safety. An attacker who can forge the root CA's signature can issue fraudulent certificates that chain to the compromised root.

Check every certificate in the chain: root CA, intermediate CAs, and leaf certificates. All must use quantum-safe signature algorithms for the chain to be quantum-safe. This may require working with your CA provider to obtain certificates signed with PQC algorithms, or deploying a private CA that uses PQC signatures.

Step 8: Data-at-Rest Key Wrapping

If your system encrypts data at rest with symmetric algorithms (AES-256), the data itself is quantum-resistant. But how are the encryption keys stored and distributed? If the key encryption keys (KEKs) are wrapped using RSA or ECDH-derived keys, the data-at-rest encryption is quantum-vulnerable at the key wrapping layer.

Test that your key management system uses quantum-safe algorithms for key encapsulation and key derivation. If keys are exchanged using RSA, migrate the key exchange to ML-KEM. If keys are stored in an HSM that only supports classical algorithms, plan for HSM firmware updates that support PQC operations.

The H33 Testing Approach

H33's production testing methodology follows a rigorous sequence: KAT validation first, always. No performance optimization is attempted until every NIST KAT vector passes. Ground-truth sidecar testing runs a known-correct reference implementation alongside the optimized implementation and compares outputs for every operation. Property-based testing (proptest in Rust) generates random inputs and verifies that invariants hold across millions of test cases.

The three-family signing approach provides additional testing discipline. Because H33 uses ML-DSA, FALCON, and SLH-DSA simultaneously, the testing suite must validate each family independently and the combined bundle collectively. A failure in any single family is caught by the differential testing against the other two families, providing a defense-in-depth approach to correctness validation.

The testing checklist for any quantum-safe deployment:

1. Complete cryptographic algorithm inventory documenting every algorithm in every component.

2. NIST KAT validation for every PQC algorithm on every target hardware platform.

3. Hybrid mode testing confirming correct key derivation, classical fallback, and downgrade resistance.

4. Performance benchmarking with sustained load tests of at least 120 seconds.

5. Interoperability testing with at least two independent implementations per algorithm.

6. Crypto agility testing confirming algorithm switching via configuration change only.

7. Certificate chain validation confirming PQC signatures at every level.

8. Key wrapping validation confirming PQC key encapsulation for data-at-rest keys.

9. Regression testing confirming that PQC deployment does not break existing functionality.

10. Monitoring and attestation confirming that PQC algorithms remain in use in production.

Step 10 is where HATS continuous attestation closes the loop. Passing the testing checklist validates that the system is quantum-safe at deployment time. Continuous attestation validates that it remains quantum-safe over time. Without continuous verification, configuration drift can silently revert a quantum-safe system to classical-only operation. The testing validates the deployment. The attestation validates the operation.