How to Add Post-Quantum Encryption to Your Existing API

Most organizations treat post-quantum migration as a future project. They assume it requires replacing their entire cryptographic stack, rebuilding authentication systems, and re-architecting key management. This assumption is wrong. You can add post-quantum encryption to your existing API today, as an overlay, without modifying your application code, your database schema, or your deployment pipeline.

The H33 gateway approach treats PQC as a middleware layer that sits between your clients and your existing API. Your API continues to operate exactly as it does today. The gateway adds post-quantum key exchange, post-quantum signatures, and three-family attestation to every request and response. Your clients get quantum-safe protection. Your backend gets an attestation trail. Your engineering team gets a migration path that does not require a rewrite.

The Overlay Architecture

The traditional approach to PQC migration follows a "rip and replace" model: identify every cryptographic dependency, replace each one with a post-quantum equivalent, test the entire system, and deploy. This model is appropriate for greenfield systems but catastrophically expensive for production systems with years of accumulated integrations, dependencies, and operational knowledge.

The overlay model inverts this approach. Instead of replacing cryptographic primitives inside the application, the overlay adds a PQC layer on top of the existing system. The existing cryptography continues to function. The PQC layer provides additional protection that is quantum-safe. The system is protected by both layers simultaneously during the transition period.

In practice, this means deploying the H33 Gateway as a reverse proxy in front of your existing API. The gateway terminates TLS connections from clients using a hybrid key exchange that combines classical ECDH with ML-KEM (FIPS 203). The hybrid approach ensures that the connection is at least as secure as classical TLS even if the ML-KEM implementation has an undiscovered flaw, while providing quantum-safe protection against harvest-now-decrypt-later attacks.

After the hybrid TLS termination, the gateway signs every API response with ML-DSA (FIPS 204) and attaches a 74-byte H33-74 attestation header. The attestation provides post-quantum proof that the response originated from the authenticated server and was not modified in transit. The gateway then forwards the request to your existing backend over the existing internal connection.

Step 1: Deploy the Gateway

The H33 Gateway deploys as a Docker container or a standalone binary. The deployment requires three configuration parameters: the upstream URL (your existing API), the H33 API key, and the TLS certificate for the gateway's public-facing endpoint.

The gateway listens on the public-facing port and proxies requests to your upstream API. All requests pass through the PQC layer. The gateway adds the following to each transaction:

Inbound: Hybrid TLS termination (ECDH + ML-KEM). The client connects to the gateway using a TLS 1.3 connection with a hybrid key exchange. The session key is derived from both the ECDH shared secret and the ML-KEM shared secret, using a combined key derivation function. This ensures that an attacker must break both ECDH and ML-KEM to recover the session key.

Outbound: ML-DSA response signing. Every API response is signed with an ML-DSA-65 signature. The signature covers the response body, the response headers, the timestamp, and a nonce. The signature is included in a custom response header (X-H33-Signature) that clients can verify.

Attestation: H33-74 attestation. In addition to the ML-DSA signature, each response receives a 74-byte post-quantum attestation that is anchored to the H33 attestation chain. This attestation uses three independent signature families and provides long-term verifiable proof that the response was generated at a specific time by a specific server.

Step 2: Configure Client Verification

Client-side verification is optional but recommended. Clients that support hybrid TLS will automatically negotiate the quantum-safe key exchange. Clients that do not support hybrid TLS will fall back to classical TLS, maintaining backward compatibility.

For response signature verification, clients can include a lightweight SDK that checks the X-H33-Signature header against the H33 public key. The verification is a single ML-DSA-65 verify operation that takes approximately 200 microseconds. This is a non-blocking operation that can be performed asynchronously after the response is received.

For organizations that want to enforce PQC verification, the gateway can be configured in "strict" mode, which requires clients to present a hybrid TLS ClientHello with ML-KEM support. Clients that do not support hybrid TLS are rejected. This mode is appropriate for internal APIs and partner integrations where client upgrades can be mandated.

Step 3: Verify the Attestation Chain

Every response from the gateway produces a verifiable attestation record. These records are stored in the H33 attestation chain and can be independently verified at any time using the H33 verification API or the open-source verifier CLI.

The attestation chain provides several capabilities that are not available with classical TLS. First, it provides non-repudiation: the server cannot deny having sent a specific response because the response is bound to a signed attestation. Second, it provides temporal proof: the attestation timestamp is anchored to an immutable record, proving when the response was generated. Third, it provides quantum-safe durability: the attestation will remain verifiable even after quantum computers are available, because the signatures use post-quantum algorithms.

For audit and compliance purposes, the attestation chain provides a complete, immutable record of every API interaction. This record can be presented to auditors, regulators, or insurers as evidence of the API's security posture over time.

What Your Backend Does Not Need to Change

The key advantage of the overlay approach is that your backend application requires zero modifications. Your existing API continues to receive requests and send responses exactly as it does today. The backend does not need to support ML-KEM, ML-DSA, or any post-quantum algorithm. It does not need new libraries, new key management, or new certificate infrastructure.

The gateway handles all PQC operations. The backend operates in its existing cryptographic environment (typically TLS 1.2 or 1.3 with classical algorithms) on the internal network between the gateway and the backend. The assumption is that the internal network is trusted or protected by other controls (network segmentation, VPN, etc.), which is the same assumption that exists today for any reverse proxy architecture.

This separation of concerns means that PQC migration does not touch the application codebase. There is no risk of introducing bugs in business logic. There is no need to update dependency trees or resolve library conflicts. There is no application-level testing required beyond verifying that the gateway proxies requests correctly.

Hybrid Mode and Rollback

The overlay model supports a hybrid mode during the transition period. In hybrid mode, the gateway maintains both classical and quantum-safe cryptographic operations. If the ML-KEM implementation encounters an issue, the gateway can be configured to fall back to classical-only TLS without any disruption to the backend.

This rollback capability is critical for production deployments. Post-quantum algorithms are newer than their classical counterparts, and while they have been rigorously analyzed and standardized by NIST, production deployments may encounter edge cases that were not present in testing. The ability to roll back to classical cryptography without touching the backend or the client provides a safety net that makes PQC deployment less risky than a traditional rip-and-replace migration.

The rollback is a configuration change on the gateway: set the key exchange mode from "hybrid" to "classical" and restart. The backend is unaffected. Clients that support hybrid TLS will automatically negotiate classical TLS when the gateway stops offering hybrid. The transition is seamless and requires no client-side changes.

Performance Impact

The performance overhead of the PQC overlay is measurable but small. The hybrid key exchange adds approximately 1 millisecond to the TLS handshake due to the additional ML-KEM encapsulation. For long-lived connections or HTTP/2 multiplexed connections, this overhead is amortized across many requests and is effectively negligible.

The ML-DSA response signing adds approximately 100 microseconds per response. For APIs with response times in the tens or hundreds of milliseconds, this overhead is less than 0.1% of the total response time. For high-frequency APIs with sub-millisecond response times, the overhead is more significant proportionally but still well within acceptable limits for most applications.

The H33-74 attestation adds approximately 50 microseconds per response for the attestation generation and anchoring. Combined with the signing overhead, the total per-response overhead is approximately 150 microseconds, which is smaller than a typical network round-trip time.

For comparison, the alternative -- rebuilding the API with native PQC support -- would involve months of development time, extensive testing, and deployment risk. The overlay approach achieves quantum-safe protection in hours of deployment time with sub-millisecond per-request overhead.

Code Integration Examples

For organizations that want deeper integration than the gateway proxy, H33 provides language-specific SDKs that add PQC operations directly to API request and response processing.

The Rust SDK provides the most complete integration. A typical usage adds PQC attestation to an existing Axum handler:

use h33_sdk::attestation::PqAttestation;

async fn handle_request(req: Request) -> Response {
    let response = existing_handler(req).await;
    let attestation = PqAttestation::attest(&response.body()).await;
    response.headers_mut().insert(
        "X-H33-Attestation",
        attestation.to_header_value()
    );
    response
}

The Python SDK wraps existing Flask or FastAPI handlers:

from h33_sdk import pq_attest

@app.route("/api/data")
@pq_attest
def get_data():
    return existing_handler()

The Node.js SDK provides Express middleware:

const { pqMiddleware } = require('@h33/sdk');
app.use(pqMiddleware({ apiKey: process.env.H33_API_KEY }));

In each case, the existing handler code is unchanged. The PQC layer is added as middleware or a decorator that processes the response after the handler produces it. The integration is a few lines of code regardless of the complexity of the underlying API.

Key Management

The gateway manages its own PQC key material. ML-KEM key pairs are generated locally on the gateway and rotated according to a configurable schedule (default: every 24 hours). ML-DSA signing keys are generated during initial gateway setup and can be rotated through the H33 key management API.

The gateway does not require access to your existing TLS private keys. It generates its own TLS certificate for the public-facing endpoint and forwards requests to the backend using the backend's existing TLS configuration. This separation ensures that PQC key management does not interfere with existing PKI infrastructure.

For organizations with strict key management requirements (FIPS 140-2/3 HSM storage, hardware key generation, etc.), the gateway supports external key providers through a pluggable key management interface. The key material never leaves the HSM boundary; the gateway sends signing requests to the HSM and receives signatures back.

Migration Timeline

The overlay approach enables an immediate start to PQC migration with a gradual path to full adoption. The typical timeline follows three phases.

Phase 1 (Day 1-5): Deploy the gateway in monitoring mode. The gateway proxies all requests and adds PQC attestation headers but does not enforce hybrid TLS or signature verification. This phase validates that the gateway correctly proxies requests without affecting the existing API.

Phase 2 (Week 2-4): Enable hybrid TLS for clients that support it. Clients with ML-KEM support automatically negotiate quantum-safe key exchange. Legacy clients continue to use classical TLS. Monitor the percentage of requests using hybrid vs. classical to track adoption.

Phase 3 (Month 2+): Progressively enable client-side signature verification. Roll out the H33 SDK to API consumers. Optionally, enforce hybrid TLS for new integrations. Establish the attestation chain as a compliance and audit resource.

The entire migration from "no PQC" to "PQC overlay deployed and attesting" takes days, not months. The migration from "PQC overlay" to "full PQC enforcement" takes weeks to months depending on the number of API consumers and their ability to adopt hybrid TLS.

The overlay does not preclude a future native PQC integration. Organizations can deploy the overlay now for immediate protection and plan a native integration on their own timeline. The overlay provides protection against harvest-now-decrypt-later attacks from day one, which is the most urgent quantum threat for APIs transmitting sensitive data.