Every TLS scanner answers one binary question: “is post-quantum cryptography enabled?” That's the wrong question. The HNDL question is continuous: “if an adversary harvests this traffic today and decrypts it in 2035, how much past + future data unlocks?” This page documents how cipherwake.io measures it.
Every TLS scanner I know of answers a binary question: does this server support post-quantum cryptography? Yes/no.
That question is wrong.
If post-quantum cryptography is enabled (rare today), it doesn't mean past traffic is safe — adversaries have been recording encrypted sessions for years, and once a cryptographically-relevant quantum computer arrives, every recorded handshake from before the upgrade becomes decryptable. If post-quantum cryptography is not enabled (almost everywhere), the relevant question isn't "is it bad" — it's "how bad."
How bad has dimensions:
A binary "yes / no" obliterates all of these dimensions. We propose a continuous metric instead.
The Decryption Blast Radius score is a 0-10 number (with an A-F grade) representing how much past + future data unlocks if one private key tied to this domain is decrypted by a future quantum computer.
It is not a security score. It is not a compliance grade. It is specifically a measurement of the harvest-now-decrypt-later risk surface, expressed in dimensions a CISO can take to a board: volume × time-window × subjects affected.
Most TLS scanners report what gets negotiated on a default handshake. They miss something important: even if a server prefers ECDHE (forward-secret) key exchange, it might still accept plain-RSA key exchange when offered. That's a "fallback exists" condition — an on-path adversary can downgrade the handshake during a man-in-the-middle window, and once they have an RSA-encrypted handshake, a single cert key compromise unlocks every recorded session.
We probe this by attempting three handshakes with different cipher policies:
Output classifications:
This is the most interesting signal in the methodology, and the one almost no other tool surfaces.
Many large enterprises rotate certificates annually (a regulatory or operational requirement). But their crypto teams often reuse the same keypair across CSRs — because "the key isn't compromised, why generate new entropy?"
The problem: that same private key has been live on every TLS handshake the certificate has ever served. If it's harvested today and decrypted in 2035, every recorded session for the entire reuse window — possibly 4+ years of past traffic — becomes plaintext.
We detect this by querying Certificate Transparency logs for every certificate ever issued for the domain, extracting the public key from each, computing the SHA-256 fingerprint, and grouping certificates by key fingerprint. The largest span (max notAfter − min notBefore) within any group is the "key-reuse window."
Empirically: 4-6 year key-reuse windows are common at large banks and healthcare systems. We've seen up to 8 years.
A single private key compromise affects every TLS session served by certificates that share that key. If those certificates are wildcard SANs spanning 47 subdomains, the blast multiplier is 47×.
We measure this by:
Even if the leaf cert uses a strong algorithm (ECDSA P-256), the intermediate that signs it might be RSA-2048. CRQC arrival breaks the intermediate, and every cert ever signed by it becomes untrustable.
We retrieve the full chain via the TLS handshake, parse each certificate, and identify the weakest-link algorithm + key size.
The score is computed as a weighted combination of four components, each scored 0-10 (methodology v1.1, 2026-05-09):
total = (keyExchange × 0.50)
+ (certLifetime × 0.10)
+ (keyPersistence × 0.20)
+ (subdomainScale × 0.20)
keyExchange is weighted highest because it is the literal HNDL mechanism — the algorithm that decides whether harvested handshake material is decryptable post-CRQC. keyPersistence is CT-log-driven: it surfaces multi-year private-key reuse across cert rotations, which turns a single classical compromise into multi-year retroactive exposure. subdomainScale is the breadth multiplier. certLifetime is a lighter signal — useful as an agility/operational-maturity proxy but not a primary HNDL mechanism with TLS 1.3 forward secrecy in play. See score components for the full breakdown and v1.0→v1.1 changelog.
The grade A-F is a deterministic mapping from the score:
The Decryption Blast Radius score measures only the public surface — what an adversary can observe by recording a TLS handshake from outside the network. It does NOT measure:
Internal Blast Radius — what one harvested key would unlock across the full attack surface — is empirically 12-40× the public score, depending on sector. Banking is closer to 12×; healthcare can exceed 40×.
A passing public-surface grade does not mean low internal exposure. It means the public surface is well-tuned. The bigger conversation is internal.
Cryptographically-relevant quantum computers are projected by NIST IR 8547, NSA CNSA 2.0, and major academic working groups to arrive between 2030 and 2040. Adversaries have been documented in publicly-disclosed SIGINT programs as recording encrypted internet traffic for long-term storage. Encrypted records harvested today and decrypted in that window remain sensitive if the data type's lifetime exceeds the gap.
For categories where data has lifetime sensitivity — medical records, identity documents, security clearances, intellectual property — the calculation is concrete: if an adversary has been recording your TLS handshakes since 2024, and they decrypt them in 2035, what gets exposed?
The Decryption Blast Radius score is our attempt to make that question quantifiable, comparable across organizations, and actionable.
npx pqcheck <domain>Feedback on the scoring model is welcome. The data is observable; the methodology is open. The intent is to surface a class of risk that binary "is PQC enabled" tools mask.