Is Your Data Already Compromised?

Post-quantum cryptography is no longer theoretical. NIST finalized FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) in August 2024. The standards are production-ready. The migration timeline is running.

This post covers data compromise — what it means for existing exposure, what actually needs to change, and how to do it without rebuilding your stack.

The Context

Quantum computers will break RSA and ECC. The timeline estimates range from 2030 to 2035, but the threat is already active. Nation-state actors are executing "harvest now, decrypt later" attacks — capturing encrypted traffic today with the intention of decrypting it when quantum hardware matures.

For existing exposure, this means every piece of sensitive data transmitted or signed with classical algorithms is a future liability. The data doesn't expire. The risk accumulates.

NIST's response was to standardize post-quantum algorithms that resist both classical and quantum attacks. nation-state actors storing encrypted traffic. These aren't experimental — they're the result of an eight-year evaluation process involving hundreds of cryptographers worldwide.

What This Means for Existing Exposure

The impact on existing exposure is specific and measurable. Systems that rely on asymmetric cryptography — retroactive decryption of stored ciphertext — need to transition to NIST post-quantum alternatives.

The good news: symmetric encryption (AES-256) and hash functions (SHA-256, SHA-3) are already quantum-resistant. Your data-at-rest encryption doesn't change. Your integrity checks don't change. Your application logic doesn't change.

What changes is the asymmetric layer: key exchange, digital signatures, and certificate infrastructure. This is a well-defined surface area.

The Migration Surface

For most organizations, the migration touches four categories:

• Key exchange — Every TLS handshake, API authentication, and session establishment that uses RSA or ECDH needs to be upgraded to ML-KEM (FIPS 203). This is the highest-priority item because it protects data in transit.
• Digital signatures — Code signing, document signing, certificate chains, and API request authentication that uses RSA or ECDSA needs ML-DSA (FIPS 204). This protects integrity and authenticity.
• Certificate infrastructure — X.509 certificates need to support post-quantum algorithms. This is operationally complex but well-understood. Hybrid certificates (containing both classical and post-quantum keys) are available during the transition.
• Long-term secrets — Encryption keys, signing keys, and master secrets with lifetimes beyond 2030 should be rotated to post-quantum alternatives now. This is the HNDL defense.

Three Approaches to Migration

Option 1: Full Stack Rebuild

Replace your cryptographic libraries, re-issue all certificates, update every client SDK, retrain your engineering team. Cost: $2M–$18M depending on scale. Timeline: 12–24 months. Risk: high — you're changing production cryptography across every system simultaneously.

This approach makes sense for organizations with dedicated cryptography teams and the budget to execute a multi-year migration program. For most organizations, it's overkill.

Option 2: Hybrid Mode

Run classical and post-quantum algorithms in parallel. ML-KEM alongside ECDH for key exchange. ML-DSA alongside ECDSA for signatures. If the post-quantum layer has an issue, the classical layer provides fallback.

This is NIST's recommended transition approach. It reduces risk but increases complexity — your systems need to negotiate both algorithm types, and your certificates need to carry both key types.

Cost: $500K–$2M. Timeline: 6–12 months. Risk: moderate — you maintain backward compatibility while adding quantum resistance.

Option 3: API Abstraction

Route cryptographic operations through an API that handles post-quantum algorithms on the backend. Your application code calls one endpoint. The API handles ML-KEM, ML-DSA, STARK proofs, and FIPS compliance automatically.

This is what H33 provides. One API call. No library changes. No certificate re-issuance. No infrastructure rebuild. The cryptographic complexity is abstracted behind a REST endpoint.

POST /v1/decision
{
  "input": data,
  "policy": "pq_sign"
}
→ returns: result + H33-74 proof (74 bytes, post-quantum attested)

Cost: $0–$200/mo to start. Timeline: days. Risk: low — your application code doesn't change.

Implementation Details

Key Sizes and Performance

Post-quantum algorithms have larger key and signature sizes than their classical counterparts. ML-DSA-65 (Dilithium) public keys are 1,952 bytes vs. 256 bytes for RSA-2048. Signatures are 3,309 bytes vs. 256 bytes.

This matters for bandwidth-constrained environments and certificate chain validation. But the computational performance is comparable — H33's production pipeline processes ML-DSA sign + verify in under 400 microseconds. At scale, we sustain 1.6M+ attestations per second on Graviton4 hardware.

The performance penalty of post-quantum is not in computation — it's in data size. And for most systems, that's a manageable tradeoff.

Algorithm Selection

NIST standardized multiple algorithms for a reason — no single algorithm covers all use cases optimally:

• ML-KEM (Kyber) — Key encapsulation. Use for session establishment, TLS handshakes, encrypting symmetric keys. Fast, compact, well-studied.
• ML-DSA (Dilithium) — Digital signatures. Use for signing, authentication, attestation. Good balance of key size and signature size.
• FALCON — Digital signatures with smaller signatures than ML-DSA (690 bytes vs. 3,309 bytes). More complex implementation. Good for bandwidth-constrained scenarios.
• SLH-DSA (SPHINCS+) — Stateless hash-based signatures. Minimal security assumption (hash function security only). Large signatures but unbreakable if the hash function holds.

H33 uses all three signature families simultaneously — ML-DSA, FALCON, and SPHINCS+. This provides defense in depth: the attestation breaks only if all three independent mathematical assumptions fail simultaneously. You don't choose the algorithm. H33 handles it automatically.

Continuous Compliance with HATS

Migration is not a one-time event. New services get deployed. Configurations drift. Dependencies update. A system that was post-quantum compliant last month might not be today.

HATS (H33 Attestation Trust Standard) continuously attests that your post-quantum controls are operating as declared. If a service falls back to classical cryptography, HATS detects it in real time and produces a cryptographic record of the deviation.

This is critical for regulated industries. Auditors don't want to hear "we migrated." They want proof that migration is maintained — continuously, not periodically.

Regulatory Pressure Is Accelerating

The regulatory landscape is moving faster than most organizations realize:

• Federal agencies — NSM-10 requires cryptographic inventory. OMB M-23-02 requires migration plans. CNSA 2.0 sets hard deadlines for DoD systems.
• Financial services — FFIEC guidance on quantum risk. OCC awareness bulletins. European Central Bank quantum readiness assessments.
• Healthcare — HIPAA requires "state of the art" encryption. Post-quantum will become the standard. PHI encrypted with RSA today is a future HIPAA violation.
• Cyber insurance — Insurers are beginning to require evidence of post-quantum readiness for policy renewal. HATS attestation provides that evidence mathematically.

The organizations migrating now are getting ahead of compliance requirements. The organizations waiting are accumulating technical debt and regulatory risk.

Start Now

The migration path is clear. The standards are finalized. The tools are available. The only question is whether you start now — when it's a controlled transition — or later, when it's an emergency.

H33 provides the fastest path to NIST post-quantum compliance: one API, no rebuild, provable from day one.

You are not integrating cryptography. You are calling an endpoint.

Sandbox free. No credit card. Full NIST FIPS 203/204 compliance from your first call.