Quantum-Safe API Security
Drop-In Post-Quantum Protection for REST Endpoints

APIs Are the #1 Quantum Attack Surface

Modern applications are API-first. A typical enterprise runs hundreds of microservices, each exposing REST or gRPC endpoints, each establishing TLS connections, each authenticating requests with tokens signed by classical algorithms. A single user action -- logging in, making a payment, retrieving a medical record -- triggers a cascade of API calls, each one performing key exchange (typically ECDHE) and authentication (typically ECDSA or RSA-signed JWTs).

This means APIs concentrate quantum vulnerability. Every inter-service call is a key exchange that can be recorded for later quantum decryption. Every JWT is a digital signature that a quantum computer can forge. Every mTLS certificate chain relies on algorithms that Shor's algorithm will break. The attack surface is not a single endpoint -- it is the entire mesh of API communication that constitutes your application.

Consider the scale: a mid-size SaaS platform might process 10 million API calls per day. Each call involves a TLS handshake (or session resumption from a prior handshake) and an authenticated request. That is 10 million key exchanges and 10 million signature verifications per day, all using algorithms with a known expiration date. Over a year, that is 3.65 billion quantum-vulnerable operations.

The Specific Vulnerabilities

API security rests on three cryptographic foundations, all of which are quantum-vulnerable:

1. Recorded TLS Sessions (Key Exchange)

TLS 1.3 uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key exchange. An adversary who records the TLS handshake -- specifically the ClientHello and ServerHello messages containing the ephemeral public keys -- can use a quantum computer to solve the elliptic curve discrete logarithm problem and recover the shared secret. Once the shared secret is recovered, the entire session (every API request and response in that session) is decrypted. This is the Harvest Now, Decrypt Later attack applied specifically to API traffic.

2. Forged API Tokens (Digital Signatures)

JWTs (JSON Web Tokens) are the standard authentication mechanism for REST APIs. Most JWTs are signed with RS256 (RSA-2048 PKCS#1 v1.5) or ES256 (ECDSA with P-256). A quantum computer running Shor's algorithm can recover the private key from any RSA or ECDSA public key, enabling the attacker to forge arbitrary JWTs with any claims, any expiration, and any subject. This is not session decryption -- it is identity theft at the cryptographic level.

3. Compromised Certificate Chains (Trust Infrastructure)

mTLS (mutual TLS), increasingly used for service-to-service authentication in microservice architectures, relies on X.509 certificate chains signed with RSA or ECDSA. A quantum attacker who recovers a CA's private key can issue fraudulent certificates for any service, enabling man-in-the-middle attacks against the entire service mesh. Even if individual API calls use short-lived tokens, the underlying trust infrastructure is built on quantum-vulnerable signatures.

What Quantum-Safe API Security Looks Like

A fully quantum-safe API security architecture replaces all three vulnerable foundations:

The first two layers (ML-KEM key exchange and ML-DSA signatures) provide parity with classical API security -- the same guarantees, but quantum-resistant. The third and fourth layers (FHE payload encryption and STARK verification) go beyond classical API security by ensuring that data remains encrypted even during server-side processing and that verification can occur without data exposure.

H33's API-First Approach

H33 was built API-first because APIs are where quantum vulnerability concentrates. Our design philosophy is that post-quantum protection should be invisible to the application developer -- no cryptographic parameter selection, no key management, no algorithm migration planning. You import the SDK, initialize it with your API key, and every subsequent API call is quantum-safe.

The integration is minimal. Here is what it looks like in practice:

// Initialize H33 client with your API key
const h33 = new H33Client({ apiKey: "h33_pk_..." });

// Wrap your existing API call -- PQ protection is automatic
const response = await h33.secureRequest({
  method: "POST",
  url: "https://api.yourservice.com/v1/transactions",
  body: transactionData
});

Behind these three lines, the SDK performs ML-KEM key encapsulation with the H33 gateway, signs the request with ML-DSA, optionally FHE-encrypts the payload (for supported data types), and attaches a STARK proof for verification. The developer's code does not change. The API contract does not change. The response format does not change. Only the cryptographic underpinning changes -- from quantum-vulnerable to quantum-safe.

Performance Impact: 38.5 Microseconds

The most common objection to adding a cryptographic layer to API calls is latency. In classical API security, the TLS handshake and JWT verification add roughly 1-5 milliseconds per call (dominated by the network round trip for TLS, not the cryptographic operations). H33's post-quantum layer adds 38.5 microseconds per authentication operation on the server side.

To put that in context:

For any API call that crosses a network boundary -- which is the vast majority of real-world API traffic -- the PQ overhead is statistically insignificant. It is only in the extreme case of same-process or in-memory operations that the overhead becomes measurable, and those operations typically do not need API-level security.

H33 achieves this performance through production-optimized engineering on AWS Graviton4 ARM infrastructure: Montgomery-form NTT arithmetic, batch CBD sampling, NTT-domain fused inner products, in-process DashMap ZKP caching, and batch attestation (one Dilithium sign+verify per 32-user batch). The full pipeline processes 2.17 million authentications per second sustained with less than 1% variance.

The Compliance Angle

Post-quantum API security is not just a technical improvement -- it is a compliance advantage. As regulatory frameworks update to address quantum risk, organizations with PQ-protected APIs will be ahead of the curve:

• SOC 2 Type II: H33 maintains SOC 2 Type II compliance at 100% in Drata. When your auditor asks about quantum-safe controls, you can point to your H33 integration and the corresponding SOC 2 report.
• HIPAA: For healthcare APIs transmitting PHI, H33's FHE layer provides encryption that exceeds HIPAA's "encryption at rest and in transit" requirement by adding encryption during processing. PHI never exists in plaintext on the server.
• PCI DSS: Payment APIs using H33 benefit from quantum-safe key exchange on cardholder data transmission, addressing the post-quantum requirements expected in PCI DSS v4.1.
• ISO 27001: H33 is ISO 27001 certified. The use of NIST-standardized PQ algorithms (FIPS 203, 204) satisfies ISO 27001's Annex A.10 cryptographic controls with forward-looking quantum resistance.

Migration Path: Proxy Mode vs SDK Mode

H33 offers two integration approaches, designed for different stages of adoption:

Proxy Mode: Zero Code Changes

In proxy mode, H33 operates as a reverse proxy in front of your existing API endpoints. You update your DNS to point to the H33 gateway, and all incoming traffic is automatically upgraded to post-quantum TLS on the client-facing side. H33 terminates the PQ-TLS connection, performs ML-DSA signature verification on incoming requests, and forwards the request to your origin server over a PQ-secured backend connection.

Proxy mode requires zero code changes to your application. Your API endpoints, authentication logic, and business logic remain untouched. The PQ protection is applied transparently at the network layer. This is ideal for rapid deployment: you can have PQ protection on your production APIs within hours of signing up.

The trade-off is that proxy mode provides transport-layer PQ protection (ML-KEM key exchange, ML-DSA request signing) but does not provide application-layer FHE encryption. Your payloads are decrypted at the H33 gateway for forwarding. For most use cases, this is sufficient -- the transport-layer protection eliminates the HNDL threat and prevents quantum forgery of API tokens.

SDK Mode: Full Integration

In SDK mode, your application imports the H33 SDK and uses it to encrypt, sign, and verify API payloads directly. This provides the full stack: ML-KEM key exchange, ML-DSA signatures, BFV FHE payload encryption, and STARK verification. Data is encrypted client-side before transmission and remains encrypted throughout processing.

SDK mode is the recommended approach for applications handling the most sensitive data: healthcare records, financial transactions, biometric templates, classified information. The additional integration effort (typically 1-2 days for a standard REST API) provides defense-in-depth that transport-layer protection alone cannot match.

Both modes can be used simultaneously. Many H33 customers deploy proxy mode immediately for broad coverage, then incrementally adopt SDK mode for their most sensitive endpoints.

What About GraphQL, gRPC, and WebSockets?

H33's proxy mode supports any protocol that runs over TLS, including GraphQL (typically HTTP POST), gRPC (HTTP/2), and WebSocket connections (WSS). The PQ-TLS termination is protocol-agnostic -- it operates at the TLS layer below the application protocol.

SDK mode currently supports REST (HTTP/HTTPS) and gRPC natively, with WebSocket support in beta. GraphQL is supported through the REST transport (GraphQL over HTTP POST) without additional configuration. For streaming protocols (Server-Sent Events, WebSocket long-lived connections), the SDK establishes the PQ key exchange at connection time and uses the PQ-derived symmetric keys for the duration of the connection, with automatic rekeying at configurable intervals.

Getting Started

H33 offers a free tier that includes full post-quantum protection on every API call. There is no feature gating between tiers -- the cryptographic protection is identical whether you are on the free tier or the enterprise plan. The free tier is rate-limited but functionally complete, making it suitable for development, testing, and proof-of-concept deployments.

For production deployments, H33 uses credit-based pricing that puts the per-authentication cost under $0.000001 at scale. There are no per-endpoint charges, no bandwidth surcharges, and no separate fees for ML-KEM, ML-DSA, FHE, or ZKP operations -- every API call includes the full post-quantum stack.

1. Sign up at h33.ai/pricing and get your API key
2. Choose proxy mode (DNS change, zero code) or SDK mode (import and initialize)
3. Your APIs are now quantum-safe

Further Reading

• API Documentation -- Full integration guides, SDK reference, code examples
• Pricing -- Credit-based pricing with free tier for development
• Developer Portal -- SDKs, sample applications, and migration guides
• ML-KEM Deep Dive -- Technical details on post-quantum key exchange
• Cost of PQ Migration -- Why API integration beats DIY implementation
• Performance Benchmarks -- 2.17M auth/sec sustained on Graviton4