How PQ Crypta Validates Every Algorithm, Every 15 Minutes
A deep dive into the continuous cryptographic verification system behind this dashboard.
Beyond the Typical Health Check
Most API health checks answer a simple question: "Is the server running?" PQ Crypta's health check answers a fundamentally different one: "Can every cryptographic algorithm still generate keys, encrypt data, and decrypt it back to the original plaintext?"
This distinction matters. A server can return HTTP 200 while its post-quantum key encapsulation is silently producing malformed ciphertexts. A process can be alive while a memory corruption has broken one specific signature scheme out of thirty-three. Traditional liveness probes cannot catch these failures. PQ Crypta's health system can.
| Approach | What It Checks | Catches Crypto Failure? | Typical Frequency |
|---|---|---|---|
| Liveness Probe | Process is running, port responds | No | Every 10-30s |
| Readiness Probe | Database connected, dependencies reachable | No | Every 10-30s |
| Synthetic Monitor | One representative API call succeeds | Partially | Every 1-5 min |
| PQ Crypta Health Check | Full cryptographic workflow for every algorithm and every endpoint | Yes | Every 15 min |
The Full Verification Workflow
Every 15 minutes, a compiled Rust binary executes a complete cryptographic round-trip for each of the 35 implemented algorithms. The workflow is not simulated. Real keys are generated, real data is encrypted, and real decryption is performed. If the decrypted output does not match the original plaintext, the algorithm is marked as unhealthy.
Each step is tracked independently. The dashboard above shows per-component status indicators so operators can pinpoint exactly where a failure occurs: was it key generation that failed, encryption, or decryption? This granularity transforms debugging from "the algorithm is broken" to "ML-KEM-1024 key generation is returning malformed public keys."
What Gets Tested
The health check validates every registered API endpoint, not just the cryptographic engines. Authentication routes, analytics endpoints, ML/AI services, streaming interfaces, and utility endpoints are all included. Each receives a real HTTP request with appropriate method, headers, and payload.
Eleven Validation Layers
Beyond round-trip correctness, the health check applies eleven distinct validation layers to catch classes of failure that a simple encrypt-decrypt cycle would miss — from configuration errors through biased RNG to nonce reuse.
Algorithm Families Under Continuous Verification
Architecture
The health check system is built as a standalone Rust binary that runs independently from the API server. This separation is deliberate: if the API has a catastrophic failure, the health check binary can still report the outage rather than silently dying alongside the service it monitors.
Why This Approach
The FIPS 140-3 Parallel
NIST's FIPS 140-3 standard requires certified cryptographic modules to run Known Answer Tests (KATs) at power-on and periodically during operation. These tests feed known inputs through the cryptographic algorithms and verify the outputs match expected values. If a KAT fails, the module must enter an error state and refuse to process further requests.
"A cryptographic module shall perform power-up self-tests and conditional self-tests to ensure that the module is functioning properly. [...] If a self-test fails, the module shall enter an error state and shall output an error indicator."
PQ Crypta's health check is the software-service equivalent of this requirement. Rather than testing at power-on alone, the system tests continuously. It combines KAT-style fingerprint validation (verifying that each algorithm reports the correct cryptographic primitives) with full round-trip verification (generating fresh keys, encrypting, and decrypting). This dual approach catches a broader class of failures including silent primitive swaps, memory corruption, entropy exhaustion, key size regressions, and library upgrades that alter algorithm behavior.
The Case for Continuous Verification
Post-quantum cryptography is a rapidly evolving field. Libraries update, algorithm parameters change, and hardware environments shift. A deployment that worked last Tuesday might fail after a kernel update changes the available entropy sources or a library upgrade subtly alters key encapsulation behavior.
By running a complete cryptographic workflow every 15 minutes, PQ Crypta detects these regressions within minutes rather than discovering them when a customer's data fails to decrypt. The cost of running the check is a few seconds of CPU time. The cost of a silent cryptographic failure is immeasurably higher.
No Test Mode, No Shortcuts
The health check binary hits the same API endpoints, through the same authentication middleware, with the same request validation, using the same cryptographic code paths as production traffic. There is no test mode, no mock layer, and no bypass. If the health check passes, production works. If it fails, production is broken.
Reading This Dashboard
The endpoint groups above are organized by functional area rather than alphabetically. Each group header shows a fraction indicating how many endpoints in that group are healthy. Click any group to expand it and see individual endpoint details.
For each endpoint, the dashboard displays:
Public API Access
The health check results are also available programmatically via the API subdomain. Both endpoints require no API key.
GET https://api.pqcrypta.com/health — Returns a lightweight JSON status: service health, database connectivity, version, feature flags, and the circuit breaker: which algorithms the API is refusing to callers right now (circuit_breaker.refused) and whether its state verified (state_verified). It reads degraded while any algorithm is refused.
GET https://api.pqcrypta.com/health?detailed=true — Returns the complete dataset powering this dashboard: per-endpoint response times, error messages, algorithm results, and session metadata.