Inspiration
NIST finalized four post-quantum cryptography standards in August 2024 — FIPS 203, 204, 205, and 206. Banks, governments, and cloud providers are actively deploying these algorithms right now to protect against future quantum computers. But I kept asking one question nobody seemed to be asking: is anyone actually checking whether these new quantum-safe algorithms are safely implemented? Timing side-channel attacks have been used to steal keys from AES and RSA — not by breaking the math, but by measuring how long operations take down to nanoseconds. I searched for an automated tool that could check the new NIST PQC algorithms for this class of vulnerability. Nothing existed. So I built one.
What it does
pqc-scanner is the first automated, pip-installable timing side-channel scanner for all four NIST post-quantum cryptography standards. It implements Test Vector Leakage Assessment (TVLA) as defined in ISO/IEC 17825, collecting timing measurements using CLOCK_MONOTONIC_RAW at nanosecond precision and applying Welch's t-test to detect statistically significant timing differences between fixed and random inputs. It covers 21 algorithms across two production library targets — liboqs 0.15.0 and OpenSSL 3.0 with oqs-provider — and generates PDF compliance reports, JSON output for CI/CD integration, interactive HTML reports with timing histograms, and SARIF 2.1.0 output for GitHub Advanced Security
How we built it
The scanner operates at two measurement layers: C layer — five C harnesses using CLOCK_MONOTONIC_RAW via clock_gettime() for nanosecond precision, targeting liboqs and OpenSSL directly through their native APIs. Noise is reduced via 500-trace warmup, 5% outlier trimming, and CPU affinity pinning via sched_setaffinity. Python layer — targets kyber-py and dilithium-py reference implementations via time.perf_counter_ns() for millisecond-level analysis. The novel derandomization technique works by calling OQS_KEM_encaps_derand() with a Qiskit-generated seed instead of OQS_KEM_encaps(), completely bypassing OQS_randombytes(). Comparing TVLA results before and after isolates the root cause of any detected leak:
Leak disappears (\implies) RNG-induced — fix the API usage Leak persists (\implies) algorithmic — fix the implementation
A REST API built with FastAPI serves a web dashboard where users can run live scans against any supported target, view results in real time, and download PDF compliance reports. The full tool is pip-installable with zero setup required beyond liboqs installation.
Challenges we ran into
Measurement noise was the biggest technical challenge. WSL2 adds 10–130ns of hypervisor noise per measurement — enough to drown out weak signals. I addressed this with warmup periods, outlier trimming, CPU affinity pinning, and confirmation on bare metal GitHub Actions runners where the noise floor drops significantly. Root cause analysis for the FALCON finding required reading the FALCON specification in detail and tracing the Golomb-Rice decompression implementation in codec.c line by line to identify the specific inner loop whose iteration count depends on signature coefficient magnitude.
Accomplishments that we're proud of
first pip installable , tvla methodology automatic pqc scanner with compliance report.
What we learned
How TVLA works and why it is the industry standard for constant-time verification The mathematical foundations of ML-KEM, ML-DSA, FALCON, and SLH-DSA How quantum randomness differs fundamentally from classical pseudorandomness and why that difference matters for cryptographic measurement How to conduct responsible security disclosure professionally and engage with world-class researchers That the gap between mathematically secure and securely implemented is real, measurable, and closing that gap matters right now as the world transitions to post-quantum cryptography.
Log in or sign up for Devpost to join the conversation.