Post-Quantum Readiness

Where we are today

All temporalBLOCK traffic — both the marketing site at temporalblock.com and the API at api.temporalblock.com — is served over TLS, with certificates managed and terminated at Microsoft Azure's edge and renewed automatically. The API enforces a minimum inbound TLS version of 1.3 with a forward-secret ECDHE key exchange and AES-256-GCM bulk encryption.

The key exchange and signature algorithms in use today are classical (ECDHE for key agreement, RSA / ECDSA for certificate signatures). They are not post-quantum, and they share the broad public-internet posture: secure against any computer that exists in 2026, theoretically vulnerable to a sufficiently large quantum computer at some future date.

Where customer-impacting cryptography lives

Three places in the request path carry customer data or authenticate a counterparty:

• API-key transport. Your X-API-Key and any syncApiKey you pass through (your BYO Brave / SerpAPI / Perplexity / OpenAI / Anthropic / Google key) travel inside the TLS 1.3 tunnel described above. They are never persisted on our side and are redacted from server logs by a dedicated log filter that ships with a lock-in test.
• NTS authentication of time sources. When the Temporal Spiral anchor reaches out to a Network Time Security (NTS) server such as time.cloudflare.com, the key-exchange channel is TLS 1.3 and the per-packet NTP authentication uses AES-SIV-CMAC (RFC 8915). The symmetric authentication path is already considered quantum-acceptable at the AES-256 key strength we use.
• Audit log integrity. Audit lines (anchor heartbeats, billing events, waitlist signups, rate-limit decisions) are written into an Azure Log Analytics workspace whose tamper-evidence today comes from ingest immutability plus role-based access control on the workspace itself — not from an application-layer cryptographic signature.

Harvest-now-decrypt-later — honest assessment

The “harvest-now, decrypt-later” concern is that an adversary records today’s ciphertext and stores it until a future quantum computer can break it. Our exposure on this axis is low:

• No long-lived secrets in payloads. Calibration blocks, briefings, and spiral coordinates are not confidential. They are deterministic outputs you prepend to a system prompt — a recorded copy decrypted years from now is a stale paragraph of public-shape data.
• API keys are revocable bearer tokens. A harvested key has value only until you rotate it. Rotation is a single configuration change and does not require any cryptographic ceremony.
• BYO provider keys are customer-owned. The protection of your OpenAI / Anthropic / Brave key is ultimately governed by your rotation discipline. Our contribution is preventing any accidental log exposure on our side; the lock-in test for that redaction runs on every release.
• No persistent customer payload storage. We do not retain the bodies of your requests or responses outside of metadata audit lines.

Forward plan — what we are tracking

These are upstream-blocked. We will enable them when our platform exposes them, not before, and we will not claim them in marketing copy before they actually ship.

• Hybrid TLS key exchange (X25519 + ML-KEM / FIPS 203). We will adopt hybrid key exchange on api.temporalblock.com and the marketing site as soon as Azure exposes it on App Service and Static Web Apps. The TLS 1.3 minimum we already enforce is a prerequisite for the hybrid suites and has been pinned in advance.
• Node.js + OpenSSL PQC primitives. OpenSSL 3.5 adds ML-KEM, ML-DSA, and SLH-DSA behind feature flags. We are tracking Node.js LTS release notes for the corresponding node:crypto exposure.
• ML-DSA-signed audit log entries (FIPS 204). Evaluating signing high-integrity audit lines (anchor heartbeats, billing events) with ML-DSA once the primitive is available in a supported Node runtime. A real engineering effort, not a doc change.

Questions from enterprise procurement?

If your vendor-review process has questions not covered here, reach out to us directly.