The four-bar component breakdown. Why each weight is what it is.

Every Cipherwake report shows the DBR score as a sum of four weighted components. This page is a focused companion to the core DBR methodology — it documents only the visualizer, the weights, and how to read each component in isolation.

What the visualizer shows

Four horizontal bars on every report, each scored 0-10, each labeled with its weight. The total DBR score is:

DBR = (keyExchange × 0.50) + (certLifetime × 0.10) + (keyPersistence × 0.20) + (subdomainScale × 0.20)

The four components

Component	Weight	What low (0-3) means	What high (7-10) means
keyExchange	50%	Hybrid post-quantum TLS (e.g., X25519MLKEM768) — handshake is quantum-resistant	RSA-only or RSA-fallback accepted — handshake decryptable post-CRQC
certLifetime	10%	Aggressive rotation (≤30 days, e.g. ACM 14-day) — minimal classical-compromise window	Multi-year cert lifetime — long classical blast window
keyPersistence	20%	Fresh keypair per cert renewal (CT-log verified)	Same public key reused across many years of cert rotations — single compromise unlocks years of harvested traffic
subdomainScale	20%	Narrow hostname coverage, no wildcard	Wildcard SAN across many active subdomains, all sharing one key

Why these weights

The weights reflect what each component actually measures for the HNDL threat model:

• keyExchange (50%) — the gating factor and dominant mechanism. The literal HNDL question is "will harvested handshake material be decryptable when a CRQC arrives?" — and the key-exchange algorithm is the answer. Hybrid PQC means no; RSA/ECDHE means yes. Everything else is secondary.
• keyPersistence (20%) — measured directly from CT-log mining: did this domain rotate to a fresh keypair on each cert renewal, or did the same key span multiple cert lifetimes? A reused key turns one classical compromise into multi-year retroactive exposure. Our cross-rotation reuse detection is something no other ASM/TLS scanner exposes.
• subdomainScale (20%) — the breadth multiplier. A wildcard cert shared across 47 subdomains makes one key compromise into a 47× multiplier on traffic exposure.
• certLifetime (10%) — kept as a lighter signal. It's a useful proxy for crypto-agility and operational maturity (a domain auto-rotating every 14 days is a domain that can adopt PQC quickly). But it's not a dominant HNDL mechanism on its own; with TLS 1.3 + forward secrecy, cert key compromise doesn't decrypt past traffic. Weighted accordingly.

HSTS, headers, email security, and other ASM signals are reported as findings on every report but do not contribute to the DBR score. They measure different threat models (downgrade defense, email spoofing, XSS) and conflating them with HNDL would create perverse incentives.

Methodology changelog

v1.1 — 2026-05-09 (current)

• Removed HSTS from score. v1.0 penalized HSTS in keyPersistence on the rationale that "HSTS pinning amplifies key-compromise window." This was wrong: HSTS is a downgrade-defense mechanism, not a key-persistence signal. It does not pin specific keys, does not affect harvested-traffic decryptability, and is generally a security positive. Including it created an incentive to weaken downgrade protection in pursuit of a better grade — exactly the failure mode this scanner exists to surface in others. HSTS is now a finding (in httpHeaders) but not a score input.
• Rebranded keyPersistence to measure actual key reuse. Now scored from CT-log data: distinct public keys observed across cert rotations, longest-reuse window in years. Fresh-key-per-renewal scores 1; multi-year reuse scores 6-8.
• Reweighted to put keyExchange first. 35% → 50%. The literal HNDL mechanism deserves dominance.
• Reduced certLifetime weight. 25% → 10%. Useful agility signal but not a primary HNDL mechanism.
• Tightened certLifetime granularity at the short end. 14-day cert was raw=4 (under-rewarded); now raw=2.
• Removed the universal cross-component PQC discount (was 0.7×). v1.0 applied a discount across non-keyExchange components when hybrid PQC was detected. v1.1 removes this: each component now honestly measures what it claims, and PQC's effect is fully credited inside keyExchange (raw=1 for hybrid PQC). Other components (cert lifetime, key reuse, subdomain breadth) measure non-HNDL risks PQC does not mitigate, so they shouldn't be artificially discounted.

v1.0 — 2026-05-06 (original)

Weights: keyExchange 35%, certLifetime 25%, keyPersistence 15%, subdomainScale 25%. PQC discount: 0.7× multiplier on cert/keyPersistence/subdomainScale when hybrid PQC detected. keyPersistence measured HSTS rather than CT-log key reuse. Methodology bug: HSTS-as-key-persistence created incentive to weaken downgrade defense. Replaced by v1.1.

Why no PQC discount in v1.1?

v1.0 applied a 0.7× multiplier to all non-keyExchange components when hybrid PQC TLS was detected, on the rationale that "PQC mitigates direct HNDL risk so secondary components should drop." On reflection, this is methodologically muddy:

• Cert lifetime measures classical-compromise blast window, not HNDL. PQC doesn't reduce this risk at all — a stolen RSA-2048 cert key in 2026 is just as dangerous regardless of whether the handshake was PQC.
• Key reuse history measures whether a single private key is sprawled across multi-year cert lifetimes. This is a real, directly-observable signal whose weight should not depend on PQC presence.
• Subdomain scale measures breadth multiplier. PQC doesn't make a wildcard cert any narrower in scope.

v1.1 makes the design honest: PQC's effect is fully captured inside keyExchange (raw=1 for hybrid PQC, vs. raw=5 for ECDHE-only and raw=7-9 for RSA fallback / RSA-only). Combined with the 50% weight on keyExchange, that already gives PQC adopters a strong, defensible advantage — without artificially discounting unrelated components.

Score range — why the floor is ~1.5, not 0

The lowest achievable score in 2026 is approximately 1.5/10 (Grade A), even for a domain doing everything right: hybrid PQC TLS, ≤30-day cert rotation with a fresh key per renewal, and a narrow non-wildcard public surface. The floor exists because subdomainScale bottoms out at raw=3 ("narrow public surface") — any reachable HTTPS domain has at least some blast radius, and the score honestly reflects that.

A literal 0 would require technology that is not yet deployed anywhere on the public internet: pure ML-KEM TLS without classical hybrid, ML-DSA (FIPS 204) certificate signatures throughout the chain, and zero public-facing surface. Hitting 1.5 today means you've done everything currently possible — the score is calibrated against present-day cryptographic reality, not a theoretical future where the floor moves down as deployment of pure-PQC primitives becomes practical.

Coverage gaps (roadmap)

Things this score does NOT yet capture, queued for future versions:

• Session ticket TTL — long-lived TLS resumption tickets enable replay/persistence risk. Phase B detection in roadmap.
• 0-RTT (early data) — TLS 1.3 0-RTT has special replay semantics. Detection in roadmap.
• Cert chain weakest link — currently surfaced as a finding, not in the score. Future v1.2 may promote this to a score input.

How to read the bars

• One dominant bar. When a single component drives most of the score, the remediation path is obvious. A failing keyExchange bar means "disable RSA fallback"; a failing keyPersistence bar means "rotate the keypair."
• Two roughly-equal contributors. Suggests a structural issue (e.g. wildcard cert + long key reuse = systemic key-management practice).
• Four balanced bars. Rare. Indicates a generally weak crypto posture across the board, not a single fixable misconfiguration.

What this view does NOT claim

• It does not say which fix is cheapest. A 50% weight on keyExchange means it dominates the score, not that fixing keyExchange is the cheapest path to a better grade.
• It does not capture internal exposure. Public-surface only. Internal Blast Radius is empirically 12-40× the public score. See DBR: what the score does not measure.
• It does not cover post-handshake risks. Session-ticket TTL, 0-RTT, and early-data risks are not in v1. Roadmap items.

Try it

• Web: every report shows the four-bar visualizer.
• API: /api/scan?domain=... returns components object with the four values.