03 · Our approach

Which layer simulates it, which layer mitigates it

Simulate and mitigate are different jobs and they land on different layers. This page maps each attack onto the stack, then shows how the whole thing is actually deployed — from a single laptop to a sovereign installation.

Correlation matrix HNDL pipeline QKD lab design Claims boundary Deployment architecture Topologies Security controls

The master map

Eight attacks, three layers, two verbs

Where a cell is empty that is a finding, not an omission — it means that layer genuinely has nothing to contribute to that attack, and pretending otherwise would be the mistake.

Attack	Origin PilotOS	Karsa Quantum OS	QryptOn	Net position
Harvest-now-decrypt-later	Batch orchestration of scenario sweeps across thousands of assets	Simulates. HNDL Batch & Vault Lab — portfolio exposure sweep plus synthetic harvest snapshot, live	Mitigates. Hybrid ML-KEM key exchange; scanner measures whether it is actually negotiated	Covered end to end
Shor — RSA factoring	Executes toy factorisations; supplies real backend constraints for estimation	Simulates. Demonstration and resource-estimation workflow, explicitly labelled	Mitigates. ML-KEM-768 replaces RSA key transport; ML-DSA-65 replaces RSA signatures	Covered
Shor — ECDLP	Same execution path; ECC circuits are smaller than RSA	Simulates. Must score ECDH assets distinctly — cheaper attack, higher urgency	Mitigates. Hybrid X25519 + ML-KEM-768 seal	ECC weighting still to refine
Grover	Search-circuit demonstrations at toy scale	Simulates. Correctly separates Grover from Shor in the risk model	Mitigates. AES-256 guidance; deliberately does not score symmetric crypto	Covered and correctly de-prioritised
QKD implementation attacks	Orchestrates the workload. Photonic integration exists; no QKD application in the control plane itself	Simulates. QKD Security Lab — per-pulse BB84-family Monte Carlo with four Eve strategies, live	Supplies the authenticated classical channel a real QKD link requires	Built — external validation pending
Downgrade / hybrid stripping	—	Should surface fallback posture as an inventory attribute	Detects. A real TLS 1.3 handshake offering only the hybrid group — negotiated, not declared	Covered by evidence classes
Trust anchor & code signing	—	Migration Optimizer carries PKI and signature-workflow assets	Reports signature algorithm availability; certificate-in-use analysis is roadmap	Partial — PKI depth to come
Crypto-agility failure	—	Inventory, CBOM and approval workflow are named in the architecture map	`--fail-under N` exits non-zero for CI — the scan becomes a gate, not a report	Covered, if operationalised

Scroll the table horizontally to see all columns.

End to end

HNDL: a complete pipeline, four of five stages built

01 · measure

Ground truth

Scanner across the estate. Which hosts can negotiate PQ TLS and SSH today, with declared versus negotiated evidence and a confidence figure per host.

Built

02 · inventory

CBOM

Asset schema, crypto dependency per asset, data classification, secrecy lifetime, retention value, business owner.

Seeded

03 · model

Vault & exposure

Per-asset exposure window across the portfolio; synthetic ciphertext and metadata vault; which sessions stay sensitive if key establishment breaks later.

Built

04 · execute

Orchestration

Parameter combinations submitted as managed workloads: queueing, priority, retry, monitoring, evidence capture.

Native

05 · act

Migrate & verify

Optimizer produces waves under budget and capacity constraints; hybrid ML-KEM deployed; scanner re-run as a CI gate to prove the change took.

Built

Why orchestration earns its place. For a single asset this arithmetic runs in a spreadsheet. The case appears at scale: when the threat horizon moves — and three papers moved it inside twelve months — you need to re-evaluate every asset against a new assumption, under several scenarios, and keep the evidence. That is a batch job with a lifecycle, a queue and an audit trail.

The synthetic-by-design rule. The harvest stage uses generated lab traffic or approved captures — never production interception. The vault stores ciphertext metadata only. The future-decryption stage demonstrates Shor on toy integers and runs resource estimation for real key sizes. At no point does the platform claim to decrypt anything real, because it cannot.

QKD Security Lab

A domain service behind the same control plane

Reuse the queueing and telemetry conventions; expose QKD-specific parameters and results. What must not happen is QKD being modelled as an ordinary chip-compute task.

User / API

Scenario

Protocol, pulse count, distance, detector efficiency, dark counts, channel loss, Eve model, random seed.

Service · built

QKD engine

Per-pulse state preparation, channel model, attack injection, basis sifting, error estimation, and the asymptotic privacy-amplification bound.

Control plane

Orchestration

Submit, queue, run, batch, monitor, retry, return result — using the existing job contract.

Execution · built

CPU → photonic

Classical Monte Carlo, shipping today. Photonic simulator and real optics remain future stages.

Protocol profiles

BB84 — baseline security model Live
Decoy-state BB84 — multi-photon risk Live
E91 — entanglement-based Live
B92 — reduced-state comparison Live
MDI-QKD — detector-attack countermeasure family Planned

Attack profiles

Intercept–resend and basis guessing Live
Photon-number splitting Live
Detector blinding and faked state Live
Dark counts and channel loss Live
Time-shift, dead-time, loss discrimination Planned

Acceptance criteria

Repeatability — seeded run reproduces sifted key and error rate exactly Pass
Noise calibration — baseline follows the configured channel and detector model Pass
Eve sensitivity — intercept–resend raises the error rate as predicted Pass
Integration — submit → queue → run → evidence through the adapter Pass

Still ahead: validation against an independent QKD library or published reference vectors, finite-key security-proof effects (this build uses the asymptotic bound), and MDI-QKD as a selectable protocol. None of this is claimed as production security — it is a verified Monte Carlo model of protocol behaviour.

The boundary that protects the claim

What each layer may say, and what it may never say

A capability that is overclaimed is worth less than one scoped honestly, because the overclaim invalidates everything next to it. These are the rules we hold ourselves to.

Origin PilotOS may claim

Multi-backend access, scheduling, hybrid lifecycle, compilation, monitoring, noise correction
Reproducible batch execution with an auditable evidence trail
Real superconducting execution on the Wukong estate

May never claim

Cryptographic protection of enterprise traffic
A native QKD or HNDL capability
That photonic-compute support implies QKD hardware support

Karsa Quantum OS may claim

Explainable exposure and migration-priority modelling under stated assumptions
Protocol behaviour demonstration as parameters change
Orchestration, batching, telemetry and evidence capture
A prepared integration contract for a future photonic or QKD backend

May never claim

"QKD implemented in software" as a production control
A universal ~11% error threshold for every implementation
That its exposure formula predicts a date
That any displayed primitive protects real traffic

QryptOn may claim

Deterministic, readable measurement of one host's TLS/SSH/runtime capability
Hybrid X25519 + ML-KEM-768 encryption and ML-DSA-65 signing
NIST known-answer vector conformance for the implemented algorithms

May never claim

FIPS 140-3 validation or an external audit — neither has happened
Organisational readiness from a single-host scan
Forward secrecy in the seal
Compliance with a standard that does not exist yet

The one rule underneath all of them. A software simulator is valuable for research, design and training, and it does not turn a conventional network into a secure one. Modelling an attack is not defending against it, and measuring a host is not migrating an organisation.

04 · Deployment

One control plane, three security engines

The strongest architecture keeps the control plane generic and makes QKD, HNDL and PQC explicit domain services. That preserves backend portability and stops quantum-compute semantics being confused with cryptographic-protection semantics.

Security engines

QKD Security Lab — protocol, channel, detector, Eve · HNDL Simulator — secrecy lifetime, harvest model, exposure ranking · PQC Migration — inventory, CBOM, benchmark, roadmap

Adapter & policy layer

Auth · token brokerage · canonical job contract · idempotency · state mapping · retry and fallback · evidence capture · ZMQ termination · event stream fan-out

Control plane

Multi-backend orchestration · hybrid lifecycle · scheduling · compilation · resource management · monitoring · photonic integration

Execution targets

CPU pool · quantum simulator · photonic simulator · optional QPU

Deliberately outside this stack: the HSM, key vault and PKI. Private keys, trust anchors, machine identities and crypto-agility controls stay in the enterprise security estate. Nothing in the quantum control plane should ever hold a production private key.

Three network zones

Zone A · client tier

Browser application · static HTML/CSS/JS, no framework, no CDN

State · browser-local, shape-checked and reseeded on corruption

Egress · same-origin HTTP and event stream to the adapter only

Holds · no API key, no token, no private key, no socket

Works fully offline

Zone B · application tier

Adapter · single process, serves the app and terminates ZMQ. One origin, no CORS surface

Security services · HNDL engine, QKD engine, optimiser, benchmark harness — separate workers

PQC runtime · isolated classical workers, never in the web process

The only tier holding credentials

Zone C · execution tier

Quantum simulator · Router and Pub sockets, four modalities

Control plane · console, HTTPS API, MySQL, MongoDB

Classical compute · CPU pool for PQC benchmarks and Monte Carlo

External · HSM / key vault / PKI — reached by the security services only

No inbound path from Zone A

The zone boundary is doing real work. Because the browser tier cannot reach Zone C at all, a compromised or hostile client cannot submit a task, read a status topic or touch a database. Every capability the interface exposes is one the adapter chose to expose, under its own authorisation — which is what makes the adapter, not the console, the correct place to put policy.

Sizing

The same architecture, at four sizes

The contract does not change between these. That is the design property that makes a laptop demo and a sovereign installation the same system.

Topology	What runs	Identity & secrets	Suitable for
T1 · Standalone	Browser only. A static file server, or open the file directly	None	Demonstration, training, offline review. No network dependency at all
T2 · Single-host lab	Adapter and simulator on one machine, one origin, one process to start	Localhost trust; no external credential	Development, contract verification, QKD and HNDL engine work. Where the security labs get built
T3 · Enterprise	Adapter and security workers behind a reverse proxy; control plane on its own host with databases; CPU pool for benchmarks	Enterprise SSO at the proxy; keys and tokens in a vault; HSM for any real key material	Production migration programmes: inventory, batch modelling, benchmark campaigns, evidence retention
T4 · Sovereign	Full T3, plus mirrored package repositories and an internal CA	National PKI, on-premises HSM, no third-party dependency in the data path	Government and critical infrastructure

Scroll the table horizontally to see all columns.

Sizing baseline. The control-plane host wants four or more modern cores, 64 GB of fast memory, a terabyte of reserved storage and a 10 Gbps interface — the last because quantum state space grows exponentially and the network must not become the bottleneck. The adapter and security workers are comparatively light; the benchmark and Monte Carlo pool is where you buy cores, not qubits.

One thing to resolve before designing T4. Control-plane licence activation requires outbound internet access to the vendor's verification endpoint, and an expired licence suspends system functions. Any air-gapped or nationally isolated installation must settle this with the vendor at design time, not at commissioning.

Before any shared deployment

Nine controls, and where each one lives

Control	Layer	Requirement
Identity & authentication	Adapter	The prototype adapter is localhost-trusted with no authentication. Before any shared deployment: enterprise SSO at the proxy, per-user sessions, multi-user session handling. This is the top item on the "move beyond localhost" list.
Authorisation	Adapter	Console roles are display state today. They must become enforced scopes at the adapter, because the browser cannot be trusted to enforce its own permissions.
Secret handling	Adapter · workers	API keys and database credentials live in a vault and are injected at runtime. Never in browser storage, never in the static bundle, never in a repository.
Key protection	External	HSM, key vault and PKI stay outside the platform. Private keys must not be in the business database — enforced with network policy, not convention.
Workload isolation	Execution	PQC operations run in isolated classical workers using approved libraries. The web process performs no cryptography, so a web-tier compromise yields no key material.
Idempotency & retry	Adapter	Canonical job IDs with idempotent submission. Error codes must be classified: transport failures are retryable; "this circuit can never fit this topology" is not. Conflating them produces an infinite loop against an impossible task.
Evidence & audit	Adapter · control plane	Every security-relevant job keeps inputs, seed, backend, timestamps and outputs. The control plane already provides tiered persistence — use it rather than rebuilding it.
Safety labelling	Adapter · interface	Outputs carry their class — simulation, demonstration or resource estimate — through the API and into the interface. A label applied only at render time will eventually be lost in an export.
Egress control	Network	Zone A reaches only the adapter. Zone C accepts no inbound connection from Zone A. Licence verification is the one documented outbound exception and must be explicitly allowed.

Scroll the table horizontally to see all columns.

See status and roadmap Back to the threat analysis